Re: [TLS] Are we holding TLS wrong?

"Fossati, Thomas (Nokia - GB/Cambridge)" <thomas.fossati@nokia.com> Thu, 08 November 2018 04:30 UTC

Return-Path: <thomas.fossati@nokia.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 6DF2E130E01; Wed, 7 Nov 2018 20:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-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=nokia.onmicrosoft.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 A7j-4EneDs4C; Wed, 7 Nov 2018 20:30:23 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10108.outbound.protection.outlook.com [40.107.1.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FAD130DEB; Wed, 7 Nov 2018 20:30:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NE7jekdTBhIOtGlvlYJdHswzQm16BlKdVZeBdFJdgkU=; b=acvUy2NQfPRZIK76EOOO7+OFVDPQfY/MjMOokMVIxcwE+PAwvY5Fat56DiBOXuo/D42THz9l3e9C1x0iWybUItMhMxcYfFLnm2ktPJPwSlaJQ4R82cDRABcjQANYPy6gKzkmYe7arc5mgpGZZ9Pax2H0HbQVmZlzMKZLXgQ398E=
Received: from AM6PR07MB4930.eurprd07.prod.outlook.com (20.177.119.75) by AM6PR07MB5813.eurprd07.prod.outlook.com (20.178.93.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.11; Thu, 8 Nov 2018 04:30:18 +0000
Received: from AM6PR07MB4930.eurprd07.prod.outlook.com ([fe80::f95b:cf9a:b466:21d3]) by AM6PR07MB4930.eurprd07.prod.outlook.com ([fe80::f95b:cf9a:b466:21d3%3]) with mapi id 15.20.1339.009; Thu, 8 Nov 2018 04:30:18 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge)" <thomas.fossati@nokia.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
CC: "tls@ietf.org" <tls@ietf.org>, "draft-ietf-babel-dtls@ietf.org" <draft-ietf-babel-dtls@ietf.org>
Thread-Topic: [TLS] Are we holding TLS wrong?
Thread-Index: AQHUdwjYcgUag2IeKki+SnMcMjm3e6VFSWeA
Date: Thu, 8 Nov 2018 04:30:18 +0000
Message-ID: <20181108043010.GA11967@nokia.com>
References: <CAPDSy+7-ceNNLJpFK0Z4SitBaUgxTpxiea8Z0QtpeSr+MNLKFg@mail.gmail.com>
In-Reply-To: <CAPDSy+7-ceNNLJpFK0Z4SitBaUgxTpxiea8Z0QtpeSr+MNLKFg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:67c:1232:144:bac0:97b8:4485:abe0]
user-agent: Mutt/1.10.1 (2018-07-13)
x-clientproxiedby: SG2PR02CA0075.apcprd02.prod.outlook.com (2603:1096:4:90::15) To AM6PR07MB4930.eurprd07.prod.outlook.com (2603:10a6:20b:5e::11)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM6PR07MB5813; 6:FvYlLbLHBXMPnIc2cpfFP1hI3lhaX0Ouc6AbXtuJ0qGskbw4T1rzfWUOnYNb5W1GrEJ2kH3HlD3nyYf8baEnHwZVQA20EB6n/U7Ya5gz53lXTiCRs5FRm9u1Z5BqsZzZ/7Rv1pWvI5WnHUMcfQgYHzhiSS+rKDhehwhlaIrxF9VcFFE7kHRle2R8raQfpogj33KsVkT5zPPl+g03yTvGcXQ1yOPpu31nQDGhWt3VZp1SqI3rrK4+4uSO69sMJMAuLz76gnj1cMWzhpKWqmmmwzu2CNBr6gLs9t3lAzX+mR2hBBDkZYmmpKZvPjqVNbPVHi4KFrvYU+EXcXET1euNRnbJmf+M1kw4dzKVxu06BVOsO0NkEuzgoPTYJ+kTNQJf2Mjl5I0AxUCSm/PXLa6YtAOU+Birv7VYOB/LhR9bXSpxl4TJTCR4/xC3KbMJ8Px2dV1BHxFB45D0W3ckmYaFmQ==; 5:R2syF1BJwtpE2tS7o4jQrydkSOicjvIsatu53DkSuYdcp7FqI2QpUU/BxT3tPhgcVxTawCLuQJXubvniBEhyBElRCMF+sPV0yLl0UKLmMYD4V0EGKi9RbjreryOxQfctBpYfFcV2O2gqTEFpQAXezgHH6hF/b2OP63huj9Bgnjo=; 7:vOEyWjCgVJaUCRS5nT3KPgVOd2dSdAC3Q+2eCkvAjPpCMwN0/8V+2FGBRehnVtppYkbngTzidl+T/YAV+qjXSf/zgZP/KcU5Q7FGHcrwaJifO1eIxvKkjs+HaNTRkeb+wY4QTmxyappfl+CK6X3skA==
x-ms-office365-filtering-correlation-id: 214f3ccb-3f44-49a3-72ad-08d64532e2e0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM6PR07MB5813;
x-ms-traffictypediagnostic: AM6PR07MB5813:
x-microsoft-antispam-prvs: <AM6PR07MB58136E0DD43BCDD3B721C88E80C50@AM6PR07MB5813.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231382)(11241501184)(806099)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB5813; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB5813;
x-forefront-prvs: 0850800A29
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(136003)(39860400002)(396003)(53754006)(189003)(199004)(43544003)(46003)(52116002)(86362001)(476003)(6486002)(6512007)(446003)(2616005)(229853002)(486006)(68736007)(11346002)(6306002)(99286004)(106356001)(39060400002)(316002)(58126008)(105586002)(305945005)(7736002)(4326008)(33656002)(5660300001)(53936002)(8936002)(6246003)(8676002)(54906003)(2900100001)(81166006)(81156014)(36756003)(256004)(14444005)(186003)(1076002)(6116002)(478600001)(71200400001)(71190400001)(966005)(386003)(2906002)(6436002)(6506007)(25786009)(6916009)(97736004)(76176011)(102836004)(14454004)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5813; H:AM6PR07MB4930.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 9vCWDJ4Z9KKKqsuL/T+rMsxy5pHAHLwk9Sd3F7kopdxWI0VwhX9Y+YNcmTA6/GEFByNX9LGzl2eet6rQdX0vizevIXMGLS/Mnianp2mHpUTwDaijM6UgOxkcqc3nRvAzF3CN4E1DG0Ow2IOphRwdwbk4miqDqewEfAF14WbjoVWHF5b8Yl6EvYO7KGDBXoqsny2KzIqiBTQ3wLnkZZKV44sjEEAXHbsA0sLiHmUzGFGw9QbefCZx41/uY/3+rFJm/32+x9yeFP8fABXSsErxRK4MiRXMbJ9Q0PhXN8EFqf5Adh9lR6ZMjDZsPD+RKvskvrLazQLkiH7g/5Fsqgh2kmHAeIkjqlWg8ZkUqYhq9HE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <C9FA25674A687F4BBBA40475A80E2188@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 214f3ccb-3f44-49a3-72ad-08d64532e2e0
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2018 04:30:18.8083 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5813
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/INUXdvYTDPE24CF998FkFJCtFDE>
Subject: Re: [TLS] Are we holding TLS wrong?
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: Thu, 08 Nov 2018 04:30:27 -0000

Hi David,

A few quick notes below.

Cheers

The 11/08/2018 09:14, David Schinazi wrote:
> Hi everyone,
> 
> Over in the Babel working group we have a draft about securing Babel with
> DTLS:
> https://tools.ietf.org/html/draft-ietf-babel-dtls-01
> 
> It's 5 pages long, could any TLS experts please give it a quick read and
> let us know if we're using DTLS correctly?
> 
> Also, should the document contain guidance such as which DTLS version to
> use?
> 
> Thanks,
> David

Premise: I don't know Babel -- apologies for any nonsense!

One high level thing which I can't extrapolate from the draft (which is
probably due to my ignorance with Babel) is whether you envisage that
*every* node does DTLS on the unicast channel, IOW that non-DTLS nodes
are excluded from the mesh?  Or would it be acceptable to mesh HMAC and
DTLS neighbours?  What about clear-text speakers?  (It'd seem unwise to
let them in an otherwise secured enclave.)

You should probably provide some guidance about the kind of
credentials do you plan to use (certs, raw pkeys)?

It seems to me that the P2P nature of the protocol requires mutual
authentication, could you confirm it?  This seems to be a critical thing
to prevent a rogue node to spoof the lowest (highest, I have already
forgot, sorry) L-L address in a clear-text multicast Hello and bypass
authentication.

- s2.1
"Nodes SHOULD ensure that new client DTLS connections use different
 ephemeral ports from recently used connections to allow servers to
 differentiate between the new and old DTLS connections."

Maybe you could suggest using a sufficiently entropic connection id here
as a more robust alternative.

- s2.5
Not sure what the ceremonies around flushing a neighbor are, but I'd
make explicit signalling EOD at least a SHOULD?  It seems more polite
:-)

- s.3
Not sure which TLS stack Babel nodes will use (are you targeting
extremely constrained devices with custom TLS implementations?), but all
the stacks I know of let the application set the MTU and take care of
splitting the messages in MTU sized chunks transparently.

-- 
Thomas