Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC

Jack Visoky <jmvisoky@ra.rockwell.com> Wed, 27 February 2019 17:04 UTC

Return-Path: <jmvisoky@ra.rockwell.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A72131041 for <tls@ietfa.amsl.com>; Wed, 27 Feb 2019 09:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ra.rockwell.com
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 pyfjtcjiQIcc for <tls@ietfa.amsl.com>; Wed, 27 Feb 2019 09:04:01 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790051.outbound.protection.outlook.com [40.107.79.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628EF131023 for <tls@ietf.org>; Wed, 27 Feb 2019 09:04:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i23Me99LLrVAuxDUKPUkRB5g1TrJ6/rbzpeBsgZWGfw=; b=TIzaTZRICh1A7pN9jrJ703jUc+QCI5EfYNAGNX5oAejlE61jJLDvlHfN0Reb3hHU+tHrvAGRJb8oC5RT0OAyRFbyTWpSUoOXZqwzfTUZtdW4iJdr5+1QJnfrs3XCrODXTSPrE3cFPMJwA3Eu5B8so/YRDXz59l4bFDc5UfajWHc=
Received: from BN6PR2201MB1092.namprd22.prod.outlook.com (10.174.88.29) by BN6PR2201MB1492.namprd22.prod.outlook.com (10.174.89.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Wed, 27 Feb 2019 17:03:59 +0000
Received: from BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113]) by BN6PR2201MB1092.namprd22.prod.outlook.com ([fe80::dd5e:b340:8fa8:b113%5]) with mapi id 15.20.1665.015; Wed, 27 Feb 2019 17:03:59 +0000
From: Jack Visoky <jmvisoky@ra.rockwell.com>
To: Hanno Böck <hanno@hboeck.de>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC
Thread-Index: AdTOFIIaiE+qoBOKQdSotuuQ5A30qAAAjqKAAAB8szAAGaEngAAPRODQ
Date: Wed, 27 Feb 2019 17:03:59 +0000
Message-ID: <BN6PR2201MB10929ABE9CA6889031FDD6C199740@BN6PR2201MB1092.namprd22.prod.outlook.com>
References: <BN6PR2201MB1092B0FAD8AB0334CF151996997B0@BN6PR2201MB1092.namprd22.prod.outlook.com> <20190226220335.0d75968f@computer> <BN6PR2201MB1092253ADEAB76CD72B8976D997B0@BN6PR2201MB1092.namprd22.prod.outlook.com> <20190227103123.3b2af774@computer>
In-Reply-To: <20190227103123.3b2af774@computer>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com;
x-originating-ip: [205.175.250.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6088dbdf-fef9-4229-1ca7-08d69cd5914e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN6PR2201MB1492;
x-ms-traffictypediagnostic: BN6PR2201MB1492:
x-ms-exchange-purlcount: 1
x-microsoft-exchange-diagnostics: 1;BN6PR2201MB1492;23:UXlE1Vn/VVw4I6kffhIuUIhRPh3PybEH8PLNdcij0TixYFtkfSR6HMq/wEn9THfMCNpycq7cfN8ChYXEyRbS0RjVezN40JHiDgaPSDwaqtNIscHJnBtBXXBqZC/Kh97ln3+zmWyTXFGGBln8sKbWKNZVk3dC9u7OGFZS4ujp0nSqKEmnaD4ZaR2SR2FlOcxU7QEyh905Waoya6fGbXtZKpD9iQNl1grI04H36ksWyqpII4TbhGBWNTOSE8M2BfJJXTcVwgZ4iOl72o1FspuVCDEmrMHOee1dVsNUebdY5DDQ5jbcvwdwlbz79qbxiwNPnDVf3K+wVk5rtI9fcUzm8DqfX/gK9gN1mVGokoCOOZom9YrycgI4zJEx8BywTYc1uFN+5OaVt3InxU3nxXp+gEOAOxm1J/wkMb4BFx+GW8q/Q4VsJvU8aLPhgNH44dI6QtOItb3lruddK6vA7dz25tWnRNwBUMtqsf/lmALhpNNWkx9bqsC7SLIF02XKu51RxQiFlNHshffNfJZBw0SCkqZM4TlXk0D7eoEokGeHs28N+rtl2z5l66t2NTnopc5DJ/xsHJBWTDg34B/1+RHfk6sY00y2JL6fLUBCndWR6g8kQX5VdATcQMG1bvjkQOXGN7qLDfJ5HOxAi3xnmsg8KNJaEWfmdqqTFKjq7L6UyJVR//OrnaBoTQkYNoVXcZrjs/FBge2SGgTumpQ+lOZhdlGBBbvQo3v5mC0CxL/Se2zowK5cPLC9CEJUjHbaZ5XIfwkBiMznRzTZsfzpFyj7OTKkAEReQUQNGFjvdSob+G710vRelt5qC7IVvIhdDkcPDjHW+7lzWtDt9VfWh/Ja6Liwy+LxpZLSTCI0CLjwfIr+gL2MpRCrtIGH2eCKlu4cKBVOKwIXl4TP4buKrr1dIsANc9Lsrx52j1cIBTJvqdHzWEi5ZbbFATGLHnmiMKvT5P1criBy0c+cexXnbYoqVxzlOdj/XcQGR8P2iuO9OauClmgFctxWiw+7q3ZqWqkM56Z3CNasrTKy2xOzvQ8Tj3b4kBfwROBdyitPFMRafRs6ujeGVrqRA1vOcuRspsTtuaDNorTPICZurcZiRlQC+t+87sw1YazJRduWc/aJt8jQAa/baKRf+239m599DOnRnMqxkGtr17RnBF09/O1ml86JRl3x3uBeyxCJb81ZOB0ZhaZLG1ruQ6+OZkl3Pc9lS8B3DpoBPhPoqQ4WZBVCDJoGeEb8s0L840PiQj+6CYRLf+97Z9O83HMx2+5yhCd/SRrAg0gEi5vKS+6U7S29fj3pgccMWJMaptK0MUNkNbylKGfscur8qRuM15zyvFXc
x-microsoft-antispam-prvs: <BN6PR2201MB149243211E82AD356D52547099740@BN6PR2201MB1492.namprd22.prod.outlook.com>
x-forefront-prvs: 0961DF5286
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(346002)(136003)(376002)(189003)(199004)(13464003)(102836004)(25786009)(6916009)(93886005)(6506007)(316002)(97736004)(66066001)(33656002)(86362001)(53546011)(68736007)(14444005)(5660300002)(6246003)(478600001)(256004)(71190400001)(71200400001)(4326008)(305945005)(14454004)(6306002)(105586002)(52536013)(26005)(8676002)(966005)(9686003)(81166006)(66574012)(53936002)(11346002)(3846002)(76176011)(6116002)(446003)(186003)(81156014)(99286004)(8936002)(229853002)(6436002)(55016002)(2906002)(7696005)(476003)(486006)(7736002)(106356001)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1492; H:BN6PR2201MB1092.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: yquN+2oXKjAtBI3SAYcln+AcUN+npF5RL7Kb2bY+F8pWNRK6GC5yF1XrG3I8G439nt8uIa7//R0EfMIO1IUBOeseknGJ/943GOUPDc7cZL12aDPUny2VggDfIzksDntXyn2/Og1e4HGSdqx6a7lwZcCCVCtqqDCtQjT/xP6RlGdGPWeSu1PUoB4zkP6JQVOG5kp9dhskC9cy66ckeBBe4CSZYykbnCCm3kJcavTnJ4GncD6diYLKhg9dks6ins6nLPZFYqwDqc29Et5qk17b29ww99upwEe/5hgpB4j2tDtB+tb777HN2gp2OBRnroH4TQawdg0FZJ1Jz5LWWKDlORbl1J4ScNS7wza4sek5er6IOi7DVMkIrTMSBeXogR8rFD5jhb91CnCVYrHhItuQXwXFPyaYy0NACJhnr1o7jOg=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ra.rockwell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6088dbdf-fef9-4229-1ca7-08d69cd5914e
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 17:03:59.7865 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR2201MB1492
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8oKvGWWgb8q8FNXLDyaqsemGSag>
Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 27 Feb 2019 17:04:08 -0000

Hi Hanno,

No, the tests have not been published.  I can look at trying to make this data publicly available but I cannot guarantee that.

Tests were generally done with AES and SHA hashing.  One reason for this is that many in this industry have incorporated some hardware-based crypto acceleration into products, and it's been the case that this hardware has not included ChaCha20.  Although future products can include ChaCha20, in some industries (like Industrial Automation) hardware support can easily span 20 years, so the install base of products without ChaCha20 is non-trivial.

I do take your point around implementation pitfalls, and I realize that for the use cases that most on this list have in mind (e.g. Internet-based web communications) a cipher like this does not seem useful at all.  However there are a lot of IoT devices, and especially industrial devices, that would really benefit from being able to use TLS 1.3 to secure their communications.  These devices are growing rapidly in connectivity so communications security is becoming more and more important/pressing.  I don't represent a library vendor but I'd think this being optional would lend itself well to being compiled out of a library unless needed.

Thanks,

--Jack  

-----Original Message-----
From: Hanno Böck <hanno@hboeck.de> 
Sent: Wednesday, February 27, 2019 4:31 AM
To: Jack Visoky <jmvisoky@ra.rockwell.com>
Cc: tls@ietf.org
Subject: Re: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

Hi,

On Tue, 26 Feb 2019 21:26:45 +0000
Jack Visoky <jmvisoky@ra.rockwell.com> wrote:

> We have done tests on this and it there is a difference.

Have these tests in any way been published? Because otherwise it's a very weak argument.

There are some obvious questions, e.g.:
* What algorithm implementation was tested, was it optimized for the
  architecture in question and was it considered whether the
  optimization could be improved or maybe even whether already a more
  optimized implementation exists?
* Have you tried both AES and chacha20? And in both cases the most
  optimized implementation for the target plattform?
* If the bottleneck is the cipher have you considered whether a
  different cipher that provides reasonable security, but can be
  implemented better on lightweight hardware, would be an alternative?
  (Not keen having that option, I believe fewer options are better.)

> This probably goes without
> saying but of course the best line of defense is to properly design, 
> build, and configure the implementation.

I'm inclined to say that this is an outdated view of how to best do security in protocols.
We had plenty of situations in the past where the TLS spec was a minefield of possible implementation mistakes that led to long descriptions on how to properly design things to avoid these mistakes.
History shows it didn't work. (Let me just throw in "Padding Oracles" or "Bleichenbacher attacks" as very obvious examples.)

My takeaway and I believe that of many people is that the protocol should avoid implementation pitfalls whereever possible. And I believe an authentication-only ciphersuite is a dangerous implementation pitfall.


--
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42