Re: [Detnet] DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic

"Grossman, Ethan A." <eagros@dolby.com> Tue, 08 January 2019 18:38 UTC

Return-Path: <eagros@dolby.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FF8130F7B for <detnet@ietfa.amsl.com>; Tue, 8 Jan 2019 10:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=dolby.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 Dm5EJ_BJmE7J for <detnet@ietfa.amsl.com>; Tue, 8 Jan 2019 10:38:11 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780104.outbound.protection.outlook.com [40.107.78.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8249130F72 for <detnet@ietf.org>; Tue, 8 Jan 2019 10:38:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mKH2gH5VT2Dgwnv+56AKrwrQazqLMjCDEdFiwWRGn20=; b=jfeMXECVJpe0u65nXHMa3SEDM+lCQL7efJIWnxeGRMCYvhifqoLvcMzO91MmJzmy7U6q8WPLJwXBgHoFfbyfDiH5rJVkEMuvWcv777SjdUkfLP20EjZXh4WSBBgjvKwa8iOxBN8uY/m3AY3wai08LlehAujOyhu879W11tHW5Ok=
Received: from MN2PR06MB5664.namprd06.prod.outlook.com (20.178.243.214) by MN2PR06MB5440.namprd06.prod.outlook.com (20.178.244.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Tue, 8 Jan 2019 18:38:06 +0000
Received: from MN2PR06MB5664.namprd06.prod.outlook.com ([fe80::359b:a550:22dd:11af]) by MN2PR06MB5664.namprd06.prod.outlook.com ([fe80::359b:a550:22dd:11af%5]) with mapi id 15.20.1495.011; Tue, 8 Jan 2019 18:38:06 +0000
From: "Grossman, Ethan A." <eagros@dolby.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "Black, David" <David.Black@dell.com>
CC: "detnet@ietf.org" <detnet@ietf.org>, "ekr@rtfm.com" <ekr@rtfm.com>
Thread-Topic: DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic
Thread-Index: AdSX+/sLTp7DPyO1QkG1vyM68OeTlQAEW9GwAAoIQfAAUfnZsAAUxF1sA2vo08A=
Date: Tue, 08 Jan 2019 18:38:06 +0000
Message-ID: <MN2PR06MB56643A81E6ACE0D495E42F96C48A0@MN2PR06MB5664.namprd06.prod.outlook.com>
References: <BY1PR0601MB1403A041DF88D362261DA127C4BF0@BY1PR0601MB1403.namprd06.prod.outlook.com> <CE03DB3D7B45C245BCA0D24327794936303A55D1@MX307CL04.corp.emc.com> <85ff3ddbde5f498ab1c680e1a7d97641@XCH-RCD-001.cisco.com>, <CE03DB3D7B45C245BCA0D24327794936303A96D2@MX307CL04.corp.emc.com> <8B0117C3-ABCC-4B50-8BAF-5BE1D6D4329F@cisco.com>
In-Reply-To: <8B0117C3-ABCC-4B50-8BAF-5BE1D6D4329F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXGVhZ3Jvc1xhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTg1MGIyNDkzLTEzNzQtMTFlOS04MjA5LWFjYmMzMjdhNTFjNlxhbWUtdGVzdFw4NTBiMjQ5NS0xMzc0LTExZTktODIwOS1hY2JjMzI3YTUxYzZib2R5Lmh0bWwiIHN6PSIxMzAyMCIgdD0iMTMxOTE0NDYyNzkxMDQ5NTgzIiBoPSJNcUMzaU9yRHBYMVVMZGs0eWl3c1Erem5rOWM9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+
x-originating-ip: [8.39.141.5]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MN2PR06MB5440; 6:cGwBJsw2oKUzGJOzkO1dp+53WDlLiT0DpC+T+JU6716kNNNrAx5QyBgiQjX3JzGyClavpoORjERC+OfEYE6SHvGBDHEcWs5HE65MxK+pjZINHVYwdyOMk7TQM2SZaorZ7wjUz+ombhrv11UlbPvKWBvauI+oRrAgJJzGT77VoC3RlWAKolwWceaQS0XGziM1RHRzbUD/oa9srNioCgKnDXZbya0omnqLaSPgefJZtV9313jbSSTp3uCbEGvwJyFNE+uPMfR4DcKP713EWAguMtWqPAYZ2Egiuf6BZAgyzn6qRpHhtXxVc6KUN3Tof5dye7LHv0ep4RnoA8yeYsg2WIpRJ6Qs49D0+c5KGjv5h/86ZH1flrp0p5KJHlbjRPRLOYyHQrVHtVSPNIBBe7ekWh336AJdnfIFqa8HxRYC4pWMJnmDDzzklX3Oc7BdpfrW96QF7BYDOHFPDOfSrNbcTg==; 5:K9CiYjaInOndNzHbvye/Yr1SNO7xP+6j9CsfiiPX6kpjXMC4ERhRiJUAeLY0wHWCUwXblxiZJeKx2SLm1gbukzQGbOwzdrLjw2jsaBSKGTfI7bxRz0PQ/5lnQENMJ8ly9dEGr/lsdO6HQ+O6uESccjArDujR5YT6YE5xNJue1fpqA93JzzJc3der0ulSLIZX4iIQZbZSL0DS9+fLexsLsQ==; 7:wKIi/IWXMKfD1+/n8ZWRkLSy+8tnBA+/5AB/ugwg/LBLx1Vwhap1Rm7OxFJqAqeTWmGlwlkKRbTeYuHwLNUJ1rhh218nPhp0gqBLBxC0vHXhr0X/Wl4yHqrXuwuU+4deDZsNxLRoWNWh6lO6yoDXGQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: dfd449ae-e1a4-401e-ece1-08d675986e70
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR06MB5440;
x-ms-traffictypediagnostic: MN2PR06MB5440:
x-microsoft-antispam-prvs: <MN2PR06MB5440CA7D6F8A544E159DB0A0C48A0@MN2PR06MB5440.namprd06.prod.outlook.com>
x-forefront-prvs: 0911D5CE78
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(39860400002)(366004)(376002)(396003)(53754006)(199004)(189003)(71200400001)(7736002)(81166006)(6306002)(256004)(53936002)(11346002)(68736007)(236005)(99286004)(2420400007)(9686003)(74316002)(15650500001)(55016002)(2906002)(53546011)(3846002)(86362001)(7110500001)(446003)(66574012)(26005)(102836004)(10710500007)(478600001)(790700001)(6116002)(6346003)(186003)(486006)(54896002)(476003)(229853002)(66066001)(71190400001)(4326008)(105586002)(76176011)(6506007)(106356001)(8676002)(33656002)(316002)(93886005)(110136005)(6246003)(5660300001)(8936002)(14444005)(97736004)(14454004)(25786009)(81156014)(54906003)(6436002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR06MB5440; H:MN2PR06MB5664.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 8IEjbzDDlsPV6CmuGIw4OFt4XysSHU6XVJ+lP8gXSuLa9OMEKGkVf1dn4LZeruLQqnIRLRMtoAM60EIAQJIJ19qvfRbfpMVxxwBTu5c0nWPhIGV89FMHUx6W11CvIFvlvz97Xspl2UjAaKz+j7e0HAg9eu87MMmR7VHSS/O6yy8UAxxcGyH0sVPgW42Q2qE+UrlOjyQrvWN5WofZTKfI27asJWTEmRzZeIcI60UQA/1UpZ+iZZGpkzzzBlQjoFWVRhLY4VvGzZ0C3Afv0C6ulmmlaeN7f+dS131B8lrG5Ru/Czw1bpPedzsut2wQ4wIi
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MN2PR06MB56643A81E6ACE0D495E42F96C48A0MN2PR06MB5664namp_"
MIME-Version: 1.0
X-OriginatorOrg: dolby.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dfd449ae-e1a4-401e-ece1-08d675986e70
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2019 18:38:06.6936 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR06MB5440
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/UKIQreiLY-7uYt4l-CaCKX30Iv8>
Subject: Re: [Detnet] DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2019 18:38:14 -0000

Thanks David and Pascal for these thoughts; it looks like there is enough specific information here for me to spin up a section for the DetNet Security draft, something like “Encryption Considerations for DetNet”. At this point it looks like it would be in the form of describing the situation, then describing the pros and cons of the use of symmetric vs asymmetric crypto in this context (as noted below).

If y’all or anyone else on the list (DetNet Security draft co-authors??) has any further input on this topic I would love to incorporate it.
Thanks,
Ethan (as DetNet Security draft editor).

From: Pascal Thubert (pthubert) <pthubert@cisco.com>
Sent: Saturday, December 22, 2018 12:30 AM
To: Black, David <David.Black@dell.com>
Cc: Grossman, Ethan A. <eagros@dolby.com>; detnet@ietf.org; ekr@rtfm.com
Subject: Re: DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic

Hello David

We want every intermediate node to be able to detect bad packets as part of ingress filtering. If we use symmetrical keys then the key must be given to all relays which augments the risk of a leak. And if any relay is compromised or misbehaving it may inject traffic in the flow.
This is why if we could afford it an asymmetrical crypto would be preferable.

Merry Christmas!

Pascal

Le 21 déc. 2018 à 23:53, Black, David <David.Black@dell.com<mailto:David.Black@dell.com>> a écrit :
Hi Pascal,

I would not preclude that, but I would discourage it, as, if I understand what is proposed, it involves checking a digital signature on each packet at arbitrary intermediate points along the flow, which is indeed rather expensive.

If only endpoint checks or checks at a small number of intermediate points are required, a more effective approach is to use asymmetric crypto to authenticate distribution or exchange of a secret key for symmetric crypto – a successful check based on that key provides traffic origin verification as long as the key is kept secret by the participants.  Both TLS and IKE (for IPsec) are examples of this for endpoint checks.

In both cases, origin verification also requires replay detection mechanism as part of the security protocol to prevent an attacker from recording and resending traffic, e.g., as a denial of service attack on flow forwarding resources.

Thanks, --David

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, December 20, 2018 2:34 AM
To: Black, David; Grossman, Ethan A.; detnet@ietf.org<mailto:detnet@ietf.org>
Cc: ekr@rtfm.com<mailto:ekr@rtfm.com>
Subject: Re: [Detnet] DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic


[EXTERNAL EMAIL]
Hello David :

Asymmetric is a lot more expensive, I’m hearing, but could be very useful to ensure that the packets in a DetNet flow are from the proper source.
Say that the DetNet flow is associated with a keypair, and that the private key is available to the source of the flow whereas the public key is distributed with the flow information.
We should not preclude that should we? As long as the crypto time is bounded we should be OK.

All the best

pascal

From: detnet <detnet-bounces@ietf.org<mailto:detnet-bounces@ietf.org>> On Behalf Of Black, David
Sent: jeudi 20 décembre 2018 03:47
To: Grossman, Ethan A. <eagros@dolby.com<mailto:eagros@dolby.com>>; detnet@ietf.org<mailto:detnet@ietf.org>
Cc: ekr@rtfm.com<mailto:ekr@rtfm.com>
Subject: Re: [Detnet] DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic

> Good question, for example do such algorithms have deterministic execution times?

Generally, yes, to a first approximation, as the algorithms used to encrypt and verify traffic are usually symmetric crypto algorithms such as AES and SHA-2 which perform the same computation regardless of input.   Non-deterministic execution times are associated with asymmetric crypto algorithms (e.g., public key algorithms), which are not typically used on a packet-by-packet basis - they’re used for session setup, including key exchange, from which keys are derived for the symmetric algorithms.

Thanks, --David

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan A.
Sent: Wednesday, December 19, 2018 7:42 PM
To: detnet@ietf.org<mailto:detnet@ietf.org>
Cc: ekr@rtfm.com<mailto:ekr@rtfm.com>
Subject: [Detnet] DetNet Use Cases comment - time properties of cryptographic algorithms used to verify traffic


[EXTERNAL EMAIL]

Hi All,

In going over the remaining IESG review comments, there is this question on Sec 11.5 (Security). I don’t think it is worth holding up the Use Cases draft for, but it seems worth a conversation on the list.



Text from Section 11.5:

>      addition to arriving with the data content as intended, the data must

>      also arrive at the expected time.  This may present "new" security

>      challenges to implementers, and must be addressed accordingly.  There

>      are other security implications, including (but not limited to) the

>      change in attack surface presented by packet replication and

>      elimination.



Reviewer’s Comment:

Do these requirements impose new requirements on the cryptographic algorithms used to verify traffic?



Ethan’s thoughts:

Good question, for example do such algorithms have deterministic execution times? Is there a large spread between best- and worst-case execution times? Is this a topic for the Security draft? The Architecture draft? Or is this a more general matter of network (or network silicon) design/implementation/performance, and thus doesn’t get covered in DetNet drafts?
--------------------------------------------------