Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt
Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 12 February 2021 07:59 UTC
Return-Path: <yaronf.ietf@gmail.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 BCBED3A133D; Thu, 11 Feb 2021 23:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.507
X-Spam-Level:
X-Spam-Status: No, score=-0.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.591, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 MYWamThgKzjL; Thu, 11 Feb 2021 23:59:03 -0800 (PST)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511383A133C; Thu, 11 Feb 2021 23:59:03 -0800 (PST)
Received: by mail-wr1-x436.google.com with SMTP id l12so6862868wry.2; Thu, 11 Feb 2021 23:59:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=64EOFuYKirFd72XZi0lw2SR8EIJOh+BMK9dcjs4uwfk=; b=sl8bNruZK2lN9J6dr6dle0Ap74WXGdjrEnJBWxPWQ9HUP8nenmEjHx6xPC2fJlMf5i Ur4U0VRuNaDKJQLwtkkiWhv+Zs/083wr+xUHv74dGIyYqKtU9AO2CHrB2Co5WnU5U+2S csC2KPViOglzssg9e9kgYuZH4F16U7b6KnrASjmUBR6bMulTVil6G+sS/FDbZHCBPRE3 Hka4q/C5DQAz1J/enySwHXAZf8dUqVz+4aiUJniCOdMTX+MjRvUiwSdmgb4vs5cGOCn1 jTCLZejGrqdI6A0BUMcwYoj8Q6PscyzbwOK/YFlbVkaQfvBcB2xA50Qmx0ugPnk53RFO Jdcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=64EOFuYKirFd72XZi0lw2SR8EIJOh+BMK9dcjs4uwfk=; b=bgvTpgAiu+P/A0PIo2ny/Z2OXvk3sUWxiM2THNA60tee/SWrV7SGYfILVT3EIyO8+1 /SJkOj4Ue86ibrznN33IqoTuBN+veOzEfP66K1B/w7qcP/N3/Or7q3lP5VW9TYEF9j7E oUKpHYF3zu2NsG7SpVubIvZiEj80+IVltiZO/+cPDj9z9bIhB5ffzEqjF81FnS34Pyy5 Gk1OLn/zFz/i9TaO7XyPLu0eJ26Qv5O/OmvRQLJ/+RxxiWRJKVBpErj2Opb3SRcTAn0M fcCv8skHWR69LwVXZUjBeJsnsvbwFJlK93hYNom0CcHAyDWDOJWEHxT7hnG+mMDX4qiL 8A8Q==
X-Gm-Message-State: AOAM530HovEHQ5jHYcus5l3BZaWcw6QPapcAW/UKNSKO6KPEhq9y4kfi fuKDAz3tRDpsopWOG+Lwn7Y=
X-Google-Smtp-Source: ABdhPJxW3/+b/vovAHlNhLBe0h0iEq6yGM9Ks8Lggh/xqgsHpXrszpFtxE59/4f8HhC+CZl9mwCZbg==
X-Received: by 2002:adf:dcc2:: with SMTP id x2mr1863593wrm.178.1613116741703; Thu, 11 Feb 2021 23:59:01 -0800 (PST)
Received: from [192.168.68.105] (bzq-79-183-113-247.red.bezeqint.net. [79.183.113.247]) by smtp.gmail.com with ESMTPSA id y16sm4810338wrw.46.2021.02.11.23.59.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Feb 2021 23:59:01 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.45.21011103
Date: Fri, 12 Feb 2021 09:58:59 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: ethan@ieee.org, 'Benjamin Kaduk' <kaduk@mit.edu>
CC: 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: <2FE43E6C-71B4-484D-9F5F-CB3F36D3AE73@gmail.com>
Thread-Topic: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt
References: <161222304516.19756.17029275227155031152@ietfa.amsl.com> <01a501d6f8f5$a8ff54f0$fafdfed0$@ieee.org> <B9C7692F-705C-46F1-BA80-DA9B56F72024@gmail.com> <005001d6fa61$32e46950$98ad3bf0$@ieee.org> <20210211041311.GU21@kduck.mit.edu> <003301d700c6$d51385b0$7f3a9110$@ieee.org> <20210211232913.GJ21@kduck.mit.edu> <003d01d700cf$7ffee340$7ffca9c0$@ieee.org>
In-Reply-To: <003d01d700cf$7ffee340$7ffca9c0$@ieee.org>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/IOE9F_mjOZI2rCDN6TeWCSblRWQ>
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: Fri, 12 Feb 2021 07:59:06 -0000
Hi Ethan, On the contrary. The current text is incorrect. It currently stands: If crypto keys are to be regenerated over the duration of the flow then the time required to accomplish this must be accounted for in the latency calculations. Unfortunately, key generation is a cryptographic operation that is frequently not possible to implement in constant time, most notably (though not exclusively) for RSA key pairs. I suggest to change to: If crypto keys are to be regenerated over the duration of the flow then the time required to accomplish this must be accounted for in the latency calculations. Implementers should take care to use constant-time operations for key generation. This is normally afforded by most common key exchange protocols (e.g. those based on ECDH exchanges). Implementers should avoid the rare cases (RSA ref and specific SSH kex method here) that make constant time implementation difficult or impossible. Thanks, Yaron On 2/12/21, 01:42, "Ethan Grossman" <ethan@ieee.org> wrote: Thanks Ben, I did find RFC 4432, but all I can see that it says around this is "This may be a transient key generated solely for this SSH connection, or it may be re-used for several connections." It doesn't say anything about being "safest to generate a key each time" so I figured that wasn't the right reference. Anyway I don't mean to be pedantic about this, I'm just trying to make the most out of the material that you've given me. If it isn't worth pursuing, I'm OK with leaving the text as it is below, if you and Yaron are OK with that. Thanks again for your help... Ethan. -----Original Message----- From: Benjamin Kaduk <kaduk@mit.edu> Sent: Thursday, February 11, 2021 3:29 PM 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> Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt Hi Ethan, On Thu, Feb 11, 2021 at 02:39:59PM -0800, Ethan Grossman wrote: > Hi Ben and Yaron, > Thanks for this info. Does my proposed text below correctly incorporate your points? > > Regarding Ben's statement "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." I can't seem to find the RFC for that reference - I got as close as https://tools.ietf.org/id/draft-ietf-curdle-ssh-kex-sha2-09.html (section 3.29) but no closer. If you could point me in the right direction I could update my text. Sorry! The spec for rsa2048-sha256 is RFC 4432. > Thanks, > Ethan. > > OLD: > If crypto keys are to be regenerated over the duration of the flow > then the time required to accomplish this must be accounted for in > the latency calculations. Unfortunately, key generation is a > cryptographic operation that is frequently not possible to implement > in constant time, most notably (though not exclusively) for RSA key > pairs. > > NEW: > When protocols such as IPsec/IKEv2 and MACsec are used, keys are > typically only generated when a flow is instantiated, so the time I think I may have written sloppily to give you this impression, but it's not the case (at least for IPsec/IKEv2) -- IKEv2 will periodically re-key a connection after some amount of traffic. It's just that IKEv2 only has Diffie-Hellman or similar types of key exchange, so unpredictable RSA key generation times are not a factor for IKEv2 re-key. > required for key generation does not impact the latency of packets > within a flow. However, depending on the use case, it may be desirable > to regenerate fresh (ephemeral) RSA keys during the flow, for example > based on a time period or amount of data sent. For example, for SSH, > [ref to > https://tools.ietf.org/html/rfc4253#section-9 ]) recommends that "keys > be changed after each gigabyte of transmitted data or after each hour > of connection time, whichever comes sooner". That same reference > describes the SSH process for key re-exchange, which is essentially > the same mechanism as for initial key exchange. It also seems like this paragraph is starting to get pretty long and it's not clear that it's adding enough value to justify that length. IIUC the key point is just that rekeying during a connection is a normal and recommended operation, with the need to account for the delay introduced by key generation being pushed off to the following paragraph. Generating RSA keys is only noteworthy for its non-constant-time-ness, which is not actually mentioned here, so mentioning RSA keygen seems to be not doing much for us. > If the keys are to be regenerated over the duration of a flow then the > time required to accomplish this must be accounted for in the latency > calculations for that flow. Fortunately, modern ECDH (Elliptical > Curve > Diffie-Hellman) operations (such as x25519, e.g. see [ref to > https://tools.ietf.org/html/rfc7748] ) can be performed in constant time. (Maybe say explicitly that since it's constant time that it can be reliably corrected for?) > END I think my proposal would be to stick closer to the original, with something like: In the general case cryptographic hygeine requires the generation of new keys during the lifetime of an encrypted flow [ref ssh], and key generation (or key exchange) takes additional time that must be accounted for in the latency calculations for that flow. For modern ECDH key-exchange operations (such as x25519 [ref]), the operation can be performed in (predictable) constant time, though this is not universally true (such as for legacy RSA key exchange [ref 4432]). -Ben > -----Original Message----- > From: Benjamin Kaduk <kaduk@mit.edu> > Sent: Wednesday, February 10, 2021 8:13 PM > 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> > Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt > > 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 > > > >
- [Detnet] I-D Action: draft-ietf-detnet-security-1… internet-drafts
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Ethan Grossman
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Eric Vyncke (evyncke)
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Yaron Sheffer
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Ethan Grossman
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Benjamin Kaduk
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Ethan Grossman
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Benjamin Kaduk
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Ethan Grossman
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Yaron Sheffer
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Ethan Grossman
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Yaron Sheffer
- Re: [Detnet] I-D Action: draft-ietf-detnet-securi… Ethan Grossman