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

Jack Visoky <jmvisoky@ra.rockwell.com> Tue, 05 March 2019 22:06 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 47AFA1310AE for <tls@ietfa.amsl.com>; Tue, 5 Mar 2019 14:06:17 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 QIfWArBBYFgC for <tls@ietfa.amsl.com>; Tue, 5 Mar 2019 14:06:12 -0800 (PST)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700065.outbound.protection.outlook.com [40.107.70.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EE5131326 for <tls@ietf.org>; Tue, 5 Mar 2019 14:06:12 -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=ht2LOIyTrXPxq094Atj0wImVm2Ww14wYDlmGmrLWYSM=; b=un8TOi/I2W2Qw4jiUF93mokCGpFZGWhs4WNXEl81Ley0c/s0af5f9K2IUqHZoJTnROtMEEAci1/IcTYGMjdlsyoMrKJlalTMxWZmts3Xw+Os0qdVrBuiLdKMGul6PuCLHY/FjJmSgveisGXKWaGGKFyfzT5qKHLDm7WGqmy1etY=
Received: from BN6PR2201MB1092.namprd22.prod.outlook.com (10.174.88.29) by BN6PR2201MB1283.namprd22.prod.outlook.com (10.174.82.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Tue, 5 Mar 2019 22:06:09 +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.020; Tue, 5 Mar 2019 22:06:09 +0000
From: Jack Visoky <jmvisoky@ra.rockwell.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, John Mattsson <john.mattsson@ericsson.com>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC
Thread-Index: AQHU0t0JC4+xPO2Wk0a4FFQYJ/oSTqX9lgLQ
Date: Tue, 05 Mar 2019 22:06:09 +0000
Message-ID: <BN6PR2201MB109248EFB020405524B68AD199720@BN6PR2201MB1092.namprd22.prod.outlook.com>
References: <C75F0D18-90FB-46F2-80EB-850DF3C76607@ericsson.com> <EB6FED0C-59C9-474F-817E-F85EB5835CB4@ericsson.com> <BN6PR2201MB1092D75139ECFF6B2070169F99750@BN6PR2201MB1092.namprd22.prod.outlook.com> <84C5E2AD-7BD2-48AF-BCE7-311DD54CEDBB@ericsson.com> <BN6PR2201MB1092C3DFF3470D7A74BDA08A99710@BN6PR2201MB1092.namprd22.prod.outlook.com> <704c73d4-b748-da5c-2194-62e1924b3b0b@cs.tcd.ie>
In-Reply-To: <704c73d4-b748-da5c-2194-62e1924b3b0b@cs.tcd.ie>
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: 1b68e439-9823-4836-dd6c-08d6a1b6c5ec
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:BN6PR2201MB1283;
x-ms-traffictypediagnostic: BN6PR2201MB1283:
x-microsoft-exchange-diagnostics: 1;BN6PR2201MB1283;23:JNCuQpA0KjsYAgy8TU4VeRWi9Nqv49KUqU9nBfhEefWTbU09i3+q0RpJHBykjzyikfG1ZKJtptDbIeKhwaLjKkYcgCO80izLVUvGIRQVO8M/tzkx2G78e59wYzbJtt4owzzHEcWlbyfyabT8W1jFA+ZQnjZ2abbAsktq4GmBenv9ZhPumSqVnstbfeK3fvK+7/XsYgqd0FGNwkL0KLYFcWl+4H34CiNsLuIKtZNBiauIwO13+LruEpDSO8yPImy0q0LG8hybssfiyha0DEB9aZEySkcXPJcfXe8fvYMIib3du9SccGUD7LyiPRUTsyUtOMau/o45BRL5FlWbUmWnknYf+X9sq9BVe8Tr2Q6FAf/THuZBtUC3tDxPW9HZSQ6QOOl1uDzuE67Cgvg3LRx70hebjbpESEuuua4ET3fi1owhJoIteR35wQdW47FUF2PwcC+n1WeyhhEo0XUZqDa0XRRLoqu+f7HOMmCJqINreNLUqbXqMeeeww5R4KDHU4IRsaK2Mflqmjrn+9TcP3MCRBnFgr6S9rXg93Fx1HqwonBDjv1T7W2kD6oXtgISVVbVGl0UurWswS26abj0UGXAI3Om2U03PUCvOamYOBSbec1GGdtF0Q4MHK1YPTUKQK48xjiuPAVDpKoPE9Vd1Z9loILpGsoKvEZW7lWHDUaBpN7KeHZUBTA6K7+hGsC+K076h/pmaUR0nIihKivBSiHEQn8oYcoJrqsnoOq0wIqiacmH7EmJnGr38Z0jLbD79gz9wVv6oh73ddkmGAXWlnM0i1ky4X+me4XPZ4JXMC8w09NiRSHbuFVHBiLRjLXwyM0aSevfTgdId2h+hkulxH5OObs2CfJL9P8cYIZHft9BaOF36d8hRAOpl3wAUId5lIqvw4HXEPjOfbBvtb5++YPpw7gbeFQdf0WxZiykOnJ+aNvvdc9dO6+C54kpAqw8TQZaJVElbPV/fFpYV3c3ujEYCp9xC1usF1U3GRKhvnvDLxwFm18Ld2QgyLvb9SnXpNq5lWP533XdBnhv+hYMZAZwiKeloW3ckgc22hh7NBD4DoltHfeRkrOpAAWFwDNS/I99I2APWy2JDwyBDjG7Zh/gz4tJHybB3jpWd0T9qxu6oP1zbP5HEo6w+WR2CiXO8c0rEm5Bsf1GO94f8hM6+7ZJzZm6jTOJWeQ2mNxo+QzVuvg5CVqx6xDWgshx4AGxry6kEvRx042YppZuP0oms+kD9vzCYGzLjUU0kI+dksKatlPr2yE3deffxiF3ryk2/qqBHvNbKNp1nEYsZU7lCTg5fVvAKjjkoicj2G6rdKBD4np5Z7lkb5hGGk2XYDl+zAMu
x-microsoft-antispam-prvs: <BN6PR2201MB12839EDB1AE9EEA699DE3C9299720@BN6PR2201MB1283.namprd22.prod.outlook.com>
x-forefront-prvs: 0967749BC1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(346002)(136003)(376002)(13464003)(174874002)(189003)(199004)(51444003)(81156014)(8676002)(11346002)(97736004)(71190400001)(66066001)(478600001)(446003)(229853002)(14444005)(55016002)(52536013)(53936002)(2906002)(9686003)(86362001)(14454004)(71200400001)(68736007)(6436002)(316002)(296002)(3846002)(106356001)(105586002)(486006)(53546011)(93886005)(6506007)(26005)(186003)(110136005)(74316002)(256004)(305945005)(7696005)(7736002)(6116002)(6246003)(4326008)(99286004)(5660300002)(25786009)(33656002)(476003)(76176011)(102836004)(81166006)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR2201MB1283; 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: L37AFhYIskVPR5o1FDSDD7R5QsayrQf333/uwgs6uPsAbLTmL9MKLoXYQl2PPVaOEwJRP67SWthTwjJgKeOm0maEeoFKNqz4ZIAmIiSlPR1CvepOb4LUKcZJsv/Vqs0X2LPwxNzdT4wkr3OGTaHa4PWwm7OXIiZZBuUAQksX3Q5wAD0g538rlTmsGT2eVHj9+5WeBDqgxEEQwBIPH/oegGyS45kgoYvzDiIU25dWiigLyZgG+VbJ8kmacR0jGWEnG2MuR4JCqzwdadCm4huv3b5jz5ahO3htSRfEpeiDEgIdciYXm3Yx//ZlnA/5pMe+U+TPX0BVAlH3+VnlkoNxRQ/PKH+inZi/Yf36IeROsRBmrKHryYOfVSKeAKc1ThqBCmKk58R39epQ8HEkTmNlgJtRsNp2TSWRYGznW9yXAGU=
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: 1b68e439-9823-4836-dd6c-08d6a1b6c5ec
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 22:06:09.3796 (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: BN6PR2201MB1283
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qSA4ZorXlLrfrwJ9KDlT7XoAcbU>
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: Tue, 05 Mar 2019 22:06:18 -0000

Hi Stephen,

(I do appreciate the feedback, so I also hope the chairs don't mind this discussion continuing)

From my perspective I was thinking that a library could offer these ciphersuites as a compile-time option.  As this is targeted towards IoT devices not using HTTP this would be a completely different build environment than the "run of the mill" web communications use case.  So when building a particular IoT device these ciphersuites could be compiled in, and then potentially used if it is decided they are necessary.  That's what is being done with TLS 1.2 with at least one Industrial Protocol.  That is, a handful of authentication only suites (as well as confidentiality suites) are defined, and then when the device is configured the user must make a choice about which cipher suites to use. 

So the device vendor has to first make a decision that it even makes sense to offer these ciphersuites in their product, and then the user would have to configure the product to either use these ciphersuites or not, ideally having both decision driven by a thorough threat model.

I am sensitive to the tool-bending as you describe 😊  My hope is that these options would be clear enough that relevant IoT device vendors get the TLS benefits while not adding undue risk to the more well-known HTTP use case (as the ciphersuites would not even be present for a build supporting this).

Thanks,

--Jack

-----Original Message-----
From: Stephen Farrell <stephen.farrell@cs.tcd.ie> 
Sent: Monday, March 4, 2019 5:53 PM
To: Jack Visoky <jmvisoky@ra.rockwell.com>; John Mattsson <john.mattsson@ericsson.com>
Cc: tls@ietf.org
Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC


Jack,

(With the proviso that this isn't and I agree ought not be a WG item, so the chairs should feel free to tell me to
stop...)

On 04/03/2019 21:49, Jack Visoky wrote:
> OK I will add an update to the draft which further emphasizes that 
> these cipher suites are strictly to be used when confidentiality is 
> not a concern.
I don't understand how that can be usefully specified for a TLS implementer. AFAICS there's no credible way a library with these ciphersuites can refuse to make them available when there is a need for confidentiality but allow them to be used when there is apparently no need for confidentiality.
That's just one part of what makes these schemes dangerous.

I honestly don't think that's really fixable tbh. The best I can think of is to again try convince people who claim they don't need confidentiality in TLS that they're really actually better off with it - I don't believe there's any person or enterprise today who never needs TLS confidentiality ever, so these schemes also impose a real risk even on those who promote them. (As well as the rest of us.)

I'm not however expecting to convince you or others who are promoting this to drop it. (But do feel free:-) I guess all I can hope is that you've considered the overall costs to the ecosystem (incl. yourselves) in promoting this stuff.
If you were to document that analysis and those costs then I think that'd maybe be better than not doing so. But to add text saying to not use these when confidentiality is needed seems to me fairly pointless.

S.

PS: for those who really cannot use TLS confidentiality, e.g. for broadcast applications, my answer is that TLS is the wrong tool, not that they have gotten their requirements wrong. (But please don't damage a tool that's good for lots of other things by bending it out of shape;-)