Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

Benjamin Kaduk <kaduk@mit.edu> Thu, 11 February 2021 04:13 UTC

Return-Path: <kaduk@mit.edu>
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 684043A110F; Wed, 10 Feb 2021 20:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 L4RfbRetRfkr; Wed, 10 Feb 2021 20:13:32 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5E6AB3A110E; Wed, 10 Feb 2021 20:13:31 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 11B4DBuM008814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Feb 2021 23:13:15 -0500
Date: Wed, 10 Feb 2021 20:13:11 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Ethan Grossman <ethan@ieee.org>
Cc: 'Yaron Sheffer' <yaronf.ietf@gmail.com>, detnet@ietf.org, detnet-chairs@ietf.org, db3546@att.com, 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, 'Murray Kucherawy' <superuser@gmail.com>, 'Roman Danyliw' <rdd@cert.org>, 'Robert Wilton' <rwilton@cisco.com>, 'Barry Leiba' <barryleiba@computer.org>, "'Eric Vyncke (evyncke)'" <evyncke@cisco.com>
Message-ID: <20210211041311.GU21@kduck.mit.edu>
References: <161222304516.19756.17029275227155031152@ietfa.amsl.com> <01a501d6f8f5$a8ff54f0$fafdfed0$@ieee.org> <B9C7692F-705C-46F1-BA80-DA9B56F72024@gmail.com> <005001d6fa61$32e46950$98ad3bf0$@ieee.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <005001d6fa61$32e46950$98ad3bf0$@ieee.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/lI3Dh_v8uiFvS6M1H0sbMPZ9c1Q>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt
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: Thu, 11 Feb 2021 04:13:35 -0000

Interestingly enough, I can, but only as a result of doing AD review of a
different document yesterday!

The point is a good one to raise, as it is definitely unusual to be doing
ephemeral RSA key generation for key update on a live connection.

That said, I believe that SSH provides an "rsa2048-sha256" key exchange
method wherein the server sends an RSA public key and the client encrypts
some material to that key.  The guidance in that document is a little
vague, saying that it's safest to generate a new key each time, but
allowing for some unspecified level of reuse.  Per
https://tools.ietf.org/html/rfc4253#section-9, key update of a live
connection basically just uses the same mechanisms as initial key exchange,
which thus might include generating a fresh ephemeral RSA key.

(I don't believe that IPsec/IKEv2 has ever supported such a mechanism, and
I'm not very familiar with the details of what MACsec does, but I don't
expect it to have anything like this either.)

My understanding matches Yaron's that one of the myriad benefits of (e.g.)
x25519 ECDH key exchange is that it's super-easy to implement in constant
time.

-Ben

On Wed, Feb 03, 2021 at 11:17:21AM -0800, Ethan Grossman wrote:
> Thanks Yaron, glad to hear it. Regarding the RSA key pair question, perhaps Benjamin Kaduk could provide us some thoughts on this, since he did have comments around that section? Benjamin? 
> Ethan.
> 
> -----Original Message-----
> From: Yaron Sheffer <yaronf.ietf@gmail.com> 
> Sent: Wednesday, February 3, 2021 10:58 AM
> To: ethan@ieee.org; detnet@ietf.org; detnet-chairs@ietf.org; db3546@att.com
> Cc: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>; 'Murray Kucherawy' <superuser@gmail.com>; 'Roman Danyliw' <rdd@cert.org>; 'Benjamin Kaduk' <kaduk@mit.edu>; 'Robert Wilton' <rwilton@cisco.com>; 'Barry Leiba' <barryleiba@computer.org>; 'Eric Vyncke (evyncke)' <evyncke@cisco.com>
> Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt
> 
> Thank you, this is a lot better!
> 
> A quick comment: in Sec. 7.5.1 you mention RSA key pairs. I'm not familiar with cases where RSA key pairs are generated on the fly as part of a key exchange protocol. And AFAIK (someone might want to correct me here) the more common, more modern ECDH operations can be performed in constant time.
> 
> Thanks,
> 	Yaron
> 
> On 2/2/21, 01:55, "Ethan Grossman" <ethan@ieee.org> wrote:
> 
>     Hi All,
>     We have submitted draft 14 of the DetNet Security Considerations draft,
>     which includes resolutions for all remaining AD review comments (as noted in
>     my previous emails with the per-reviewer dispositions). 
>     Specifically, this version addresses comments from Yaron Sheffer, Magnus
>     Westerlund, Murray Kucherawy, Eric Vyncke, Roman Danyliw, Benjamin Kaduk,
>     Robert Wilton, and Barry Leiba.
> 
>     Thank you all for your reviews, and I hope we have addressed each of your
>     comments to your satisfaction - if you have any further comments,
>     suggestions or corrections please don't hesitate to let us know. 
> 
>     Sincerely,
>     Ethan (as Editor, DetNet Security Considerations draft)
> 
>     -----Original Message-----
>     From: detnet <detnet-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
>     Sent: Monday, February 1, 2021 3:44 PM
>     To: i-d-announce@ietf.org
>     Cc: detnet@ietf.org
>     Subject: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt
> 
> 
>     A New Internet-Draft is available from the on-line Internet-Drafts
>     directories.
>     This draft is a work item of the Deterministic Networking WG of the IETF.
> 
>             Title           : Deterministic Networking (DetNet) Security
>     Considerations
>             Authors         : Ethan Grossman
>                               Tal Mizrahi
>                               Andrew  J. Hacker
>     	Filename        : draft-ietf-detnet-security-14.txt
>     	Pages           : 59
>     	Date            : 2021-02-01
> 
>     Abstract:
>        A DetNet (deterministic network) provides specific performance
>        guarantees to its data flows, such as extremely low data loss rates
>        and bounded latency (including bounded latency variation, i.e.
>        "jitter").  As a result, securing a DetNet requires that in addition
>        to the best practice security measures taken for any mission-critical
>        network, additional security measures may be needed to secure the
>        intended operation of these novel service properties.
> 
>        This document addresses DetNet-specific security considerations from
>        the perspectives of both the DetNet system-level designer and
>        component designer.  System considerations include a taxonomy of
>        relevant threats and attacks, and associations of threats versus use
>        cases and service properties.  Component-level considerations include
>        ingress filtering and packet arrival time violation detection.
> 
>        This document also addresses security considerations specific to the
>        IP and MPLS data plane technologies, thereby complementing the
>        Security Considerations sections of those documents.
> 
> 
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-detnet-security/
> 
>     There are also htmlized versions available at:
>     https://tools.ietf.org/html/draft-ietf-detnet-security-14
>     https://datatracker.ietf.org/doc/html/draft-ietf-detnet-security-14
> 
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-security-14
> 
> 
>     Please note that it may take a couple of minutes from the time of submission
>     until the htmlized version and diff are available at tools.ietf.org.
> 
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
> 
> 
>     _______________________________________________
>     detnet mailing list
>     detnet@ietf.org
>     https://www.ietf.org/mailman/listinfo/detnet
> 
> 
> 
>