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

From: [email-masked]
Date: Mon, 01 Feb 2021 15:44:05 -0800

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/

---

From: "Ethan Grossman" <[email-masked]>
Date: Mon, 1 Feb 2021 15:55:02 -0800

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, February 1, 2021 3:44 PM
To: [email-masked]
Cc: [email-masked]
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:

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 2 Feb 2021 07:17:11 +0000

Thank Ethan and others.

The new text (as well as a former reply) addresses all my comments.

Regards

-éric

-----Original Message-----
From: Ethan Grossman <[email-masked]>
Organization: Coast Computer Design
Reply-To: "[email-masked]" <[email-masked]>
Date: Tuesday, 2 February 2021 at 00:55
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 'Yaron Sheffer' <[email-masked]>, 'Magnus Westerlund' <[email-masked]>, 'Murray Kucherawy' <[email-masked]>, 'Roman Danyliw' <[email-masked]>, 'Benjamin Kaduk' <[email-masked]>, "Rob Wilton (rwilton)" <[email-masked]>, 'Barry Leiba' <[email-masked]>, Eric Vyncke <[email-masked]>, 'Yaron Sheffer' <[email-masked]>
Subject: RE: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

    Hi All,

    Sincerely,

    -----Original Message-----
    From: detnet <[email-masked]> On Behalf Of [email-masked]
    Sent: Monday, February 1, 2021 3:44 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

    Abstract:

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 03 Feb 2021 20:57:51 +0200

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" <[email-masked]> wrote:

    Hi All,

    Sincerely,

    -----Original Message-----
    From: detnet <[email-masked]> On Behalf Of [email-masked]
    Sent: Monday, February 1, 2021 3:44 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

    Abstract:

---

From: "Ethan Grossman" <[email-masked]>
Date: Wed, 3 Feb 2021 11:17:21 -0800

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 <[email-masked]> 
Sent: Wednesday, February 3, 2021 10:58 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: 'Magnus Westerlund' <[email-masked]>; 'Murray Kucherawy' <[email-masked]>; 'Roman Danyliw' <[email-masked]>; 'Benjamin Kaduk' <[email-masked]>; 'Robert Wilton' <[email-masked]>; 'Barry Leiba' <[email-masked]>; 'Eric Vyncke (evyncke)' <[email-masked]>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

Thanks,
	Yaron

    Hi All,

    Sincerely,

    -----Original Message-----
    From: detnet <[email-masked]> On Behalf Of [email-masked]
    Sent: Monday, February 1, 2021 3:44 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

    Abstract:

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Feb 2021 20:13:11 -0800

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

---

From: "Ethan Grossman" <[email-masked]>
Date: Thu, 11 Feb 2021 14:39:59 -0800

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. 

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 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.  

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. 

END

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Wednesday, February 10, 2021 8:13 PM
To: Ethan Grossman <[email-masked]>
Cc: 'Yaron Sheffer' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; 'Magnus Westerlund' <[email-masked]>; 'Murray Kucherawy' <[email-masked]>; 'Roman Danyliw' <[email-masked]>; 'Robert Wilton' <[email-masked]>; 'Barry Leiba' <[email-masked]>; 'Eric Vyncke (evyncke)' <[email-masked]>
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:
> Cc: 'Magnus Westerlund' <[email-masked]>; 'Murray 
> Kucherawy' <[email-masked]>; 'Roman Danyliw' <[email-masked]>; 
> 'Benjamin Kaduk' <[email-masked]>; 'Robert Wilton' <[email-masked]>; 
> 'Barry Leiba' <[email-masked]>; 'Eric Vyncke (evyncke)' 
> <[email-masked]>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Feb 2021 15:29:13 -0800

Hi Ethan,

> 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 d…

Sorry!  The spec for rsa2048-sha256 is RFC 4432.

> 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

---

From: "Ethan Grossman" <[email-masked]>
Date: Thu, 11 Feb 2021 15:42:02 -0800

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 <[email-masked]> 
Sent: Thursday, February 11, 2021 3:29 PM
To: Ethan Grossman <[email-masked]>
Cc: 'Yaron Sheffer' <[email-masked]>; [email-masked];
[email-masked]; [email-masked]; 'Magnus Westerlund'
<[email-masked]>; 'Murray Kucherawy' <[email-masked]>;
'Roman Danyliw' <[email-masked]>; 'Robert Wilton' <[email-masked]>; 'Barry
Leiba' <[email-masked]>; 'Eric Vyncke (evyncke)'
<[email-masked]>
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:
> 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. 

> 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.

> 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

> Cc: 'Yaron Sheffer' <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]; 'Magnus Westerlund' 
> <[email-masked]>; 'Murray Kucherawy' 
> <[email-masked]>; 'Roman Danyliw' <[email-masked]>; 'Robert Wilton' 
> <[email-masked]>; 'Barry Leiba' <[email-masked]>; 'Eric 
> Vyncke (evyncke)' <[email-masked]>
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.)
> 
time.
> > 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? 
> > 'Benjamin Kaduk' <[email-masked]>; 'Robert Wilton' 
> > <[email-masked]>; 'Barry Leiba' <[email-masked]>; 'Eric
Vyncke (evyncke)'
> > 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.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 12 Feb 2021 09:58:59 +0200

Hi Ethan,

On the contrary. The current text is incorrect. It currently stands:

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" <[email-masked]> wrote:

    -----Original Message-----
    From: Benjamin Kaduk <[email-masked]> 
    Sent: Thursday, February 11, 2021 3:29 PM
    To: Ethan Grossman <[email-masked]>
    Cc: 'Yaron Sheffer' <[email-masked]>; [email-masked];
    [email-masked]; [email-masked]; 'Magnus Westerlund'
    <[email-masked]>; 'Murray Kucherawy' <[email-masked]>;
    'Roman Danyliw' <[email-masked]>; 'Robert Wilton' <[email-masked]>; 'Barry
    Leiba' <[email-masked]>; 'Eric Vyncke (evyncke)'
    <[email-masked]>
    Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

    Hi Ethan,

    -Ben

    time.
    Vyncke (evyncke)'

---

From: Ethan Grossman <[email-masked]>
Date: Fri, 12 Feb 2021 10:20:55 -0800

Hi Yaron and Ben,
Thank you so much for your help with this. First of all to Yaron I'm sorry
I wasn't clearer in my wording below - my intent with "leaving the text as
it is below" was not to use the draft 14 text (marked OLD below) but to use
my proposed text (marked NEW below); however, as Ben has pointed out, that
text is also flawed. Secondly, to Ben, my apologies - I somehow didn't
notice your additional inline replies beyond that first line, so I totally
missed that you had proposed new text there. So now we have two proposals:

Yaron:
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.

Ben:
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]).

At the risk of being slightly more verbose, I propose a hybrid of the two:

In the general case, cryptographic hygiene requires the generation of new
keys during the lifetime of an encrypted flow [ref ssh], and key generation
(or key exchange) requires additional computing time which must be
accounted for in the latency calculations for that flow.  For modern ECDH
(Elliptical Curve Diffie-Hellman) key-exchange operations (such as x25519
[ref]), these operations can be performed in (predictable) constant time,
though this is not universally true (such as for legacy RSA key exchange
[ref 4432]). Thus implementers should be aware of the time properties of
these algorithms and avoid those that make constant time implementation
difficult or impossible.

Is this OK with y'all?
Thanks again,
Ethan.

On Thu, Feb 11, 2021 at 11:59 PM Yaron Sheffer <[email-masked]>
wrote:

>    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
>
>     > Thanks for this info. Does my proposed text below correctly
> incorporate
>     your points?
>     >
> vague,
> which
> something
> new
> vague,
>     > >     We have submitted draft 14 of the DetNet Security
> Considerations
>     draft,
>     > >     which includes resolutions for all remaining AD review
> comments (as
>     noted in
>     > >     Specifically, this version addresses comments from Yaron
> Sheffer,
>     Magnus
>     > >     Westerlund, Murray Kucherawy, Eric Vyncke, Roman Danyliw,
> Benjamin
>     Kaduk,
>     > >     Thank you all for your reviews, and I hope we have addressed
> each of
>     your
>     > >     This draft is a work item of the Deterministic Networking WG
> of the
>     IETF.
>     > >
>     > >        guarantees to its data flows, such as extremely low data
> loss
>     rates
>     > >        This document addresses DetNet-specific security
> considerations
>     from
>     > >        relevant threats and attacks, and associations of threats
> versus
>     use
>     > >        cases and service properties.  Component-level
> considerations
>     include
>     > >        This document also addresses security considerations
> specific to
>     the
>     > >     Please note that it may take a couple of minutes from the time
> of
>     submission

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 12 Feb 2021 21:21:15 +0200

Sorry, I also missed Ben’s proposed text. Anyway, I’m OK with your text Ethan.

Thanks,

                Yaron

From: Ethan Grossman <[email-masked]>
Date: Friday, February 12, 2021 at 20:21
To: Yaron Sheffer <[email-masked]>, Benjamin Kaduk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Deborah Brungard <[email-masked]>, Magnus Westerlund <[email-masked]>, Murray Kucherawy <[email-masked]>, Roman Danyliw <[email-masked]>, Robert Wilton <[email-masked]>, Barry Leiba <[email-masked]>, "Eric Vyncke (evyncke)" <[email-masked]>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

Hi Yaron and Ben,

Thank you so much for your help with this. First of all to Yaron I'm sorry I wasn't clearer in my wording below - my intent with "leaving the text as it is below" was not to use the draft 14 text (marked OLD below) but to use my proposed text (marked NEW below); however, as Ben has pointed out, that text is also flawed. Secondly, to Ben, my apologies - I somehow didn't notice your additional inline replies beyond that first line, so I totally missed that you had proposed new text there. So now we have two proposals: 

Yaron: 

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.

Ben: 

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]).

In the general case, cryptographic hygiene requires the generation of new keys during the lifetime of an encrypted flow [ref ssh], and key generation (or key exchange) requires additional computing time which must be accounted for in the latency calculations for that flow.  For modern ECDH (Elliptical Curve Diffie-Hellman) key-exchange operations (such as x25519 [ref]), these operations can be performed in (predictable) constant time, though this is not universally true (such as for legacy RSA key exchange [ref 4432]). Thus implementers should be aware of the time properties of these algorithms and avoid those that make constant time implementation difficult or impossible. 

Is this OK with y'all? 

Thanks again,

Ethan. 

 

On Thu, Feb 11, 2021 at 11:59 PM Yaron Sheffer <[email-masked]> wrote:

Hi Ethan,

I suggest to change to:

Thanks,
        Yaron

    -----Original Message-----
    From: Benjamin Kaduk <[email-masked]> 
    Sent: Thursday, February 11, 2021 3:29 PM
    To: Ethan Grossman <[email-masked]>
    Cc: 'Yaron Sheffer' <[email-masked]>; [email-masked];
    [email-masked]; [email-masked]; 'Magnus Westerlund'
    <[email-masked]>; 'Murray Kucherawy' <[email-masked]>;
    'Roman Danyliw' <[email-masked]>; 'Robert Wilton' <[email-masked]>; 'Barry
    Leiba' <[email-masked]>; 'Eric Vyncke (evyncke)'
    <[email-masked]>
    Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

    Hi Ethan,

    -Ben

    time.
    Vyncke (evyncke)'

---

From: "Ethan Grossman" <[email-masked]>
Date: Mon, 22 Feb 2021 14:48:20 -0800

Hi Ben, Yaron, All,

I have published DetNet Security Considerations version 15, which contains the new Sec 7.5.1 text as discussed below: 

OLD (draft version 14)

   pairs.

NEW (draft version 15, current)

  In the general case, cryptographic hygiene requires the generation of

   new keys during the lifetime of an encrypted flow (e.g. see [RFC4253]

   section 9), and any such key generation (or key exchange) requires

   additional computing time which must be accounted for in the latency

   calculations for that flow.  For modern ECDH (Elliptical Curve

   Diffie-Hellman) key-exchange operations (such as x25519, see

   [RFC7748]) these operations can be performed in constant

   (predictable) time, however this is not universally true (for example

   for legacy RSA key exchange, [RFC4432]).  Thus implementers should be

   aware of the time properties of these algorithms and avoid algorithms

   that make constant-time implementation difficult or impossible.

END

As far as I know there are no other outstanding comments, so Ben if you are OK with this, and are ready to clear your DISCUSS, that should be the last step for the IESG review process (https://datatracker.ietf.org/doc/draft-ietf-detnet-security/ballot/ ). 

Thanks again for all of your help with this draft,

Ethan (Editor, DetNet Security Considerations draft)

From: Yaron Sheffer <[email-masked]> 
Sent: Friday, February 12, 2021 11:21 AM
To: Ethan Grossman <[email-masked]>; Benjamin Kaduk <[email-masked]>
Cc: [email-masked]; [email-masked]; Deborah Brungard <[email-masked]>; Magnus Westerlund <[email-masked]>; Murray Kucherawy <[email-masked]>; Roman Danyliw <[email-masked]>; Robert Wilton <[email-masked]>; Barry Leiba <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

Thanks,

                Yaron

From: Ethan Grossman <[email-masked] <mailto:[email-masked]> >
Date: Friday, February 12, 2021 at 20:21
To: Yaron Sheffer <[email-masked] <mailto:[email-masked]> >, Benjamin Kaduk <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, Deborah Brungard <[email-masked] <mailto:[email-masked]> >, Magnus Westerlund <[email-masked] <mailto:[email-masked]> >, Murray Kucherawy <[email-masked] <mailto:[email-masked]> >, Roman Danyliw <[email-masked] <mailto:[email-masked]> >, Robert Wilton <[email-masked] <mailto:[email-masked]> >, Barry Leiba <[email-masked] <mailto:[email-masked]> >, "Eric Vyncke (evyncke)" <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

Hi Yaron and Ben,

Yaron: 

Ben: 

Is this OK with y'all? 

Thanks again,

Ethan. 

 

On Thu, Feb 11, 2021 at 11:59 PM Yaron Sheffer <[email-masked] <mailto:[email-masked]> > wrote:

Hi Ethan,

I suggest to change to:

Thanks,
        Yaron

On 2/12/21, 01:42, "Ethan Grossman" <[email-masked] <mailto:[email-masked]> > wrote:

    -----Original Message-----
    From: Benjamin Kaduk <[email-masked] <mailto:[email-masked]> > 
    Sent: Thursday, February 11, 2021 3:29 PM
    To: Ethan Grossman <[email-masked] <mailto:[email-masked]> >
    Cc: 'Yaron Sheffer' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ;
    [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; 'Magnus Westerlund'
    <[email-masked] <mailto:[email-masked]> >; 'Murray Kucherawy' <[email-masked] <mailto:[email-masked]> >;
    'Roman Danyliw' <[email-masked] <mailto:[email-masked]> >; 'Robert Wilton' <[email-masked] <mailto:[email-masked]> >; 'Barry
    Leiba' <[email-masked] <mailto:[email-masked]> >; 'Eric Vyncke (evyncke)'
    <[email-masked] <mailto:[email-masked]> >
    Subject: Re: [Detnet] I-D Action: draft-ietf-detnet-security-14.txt

    Hi Ethan,

    -Ben

    > From: Benjamin Kaduk <[email-masked] <mailto:[email-masked]> >
    > To: Ethan Grossman <[email-masked] <mailto:[email-masked]> >
    > Cc: 'Yaron Sheffer' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; 
    > [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; 'Magnus Westerlund' 
    > <[email-masked] <mailto:[email-masked]> >; 'Murray Kucherawy' 
    > <[email-masked] <mailto:[email-masked]> >; 'Roman Danyliw' <[email-masked] <mailto:[email-masked]> >; 'Robert Wilton' 
    > <[email-masked] <mailto:[email-masked]> >; 'Barry Leiba' <[email-masked] <mailto:[email-masked]> >; 'Eric 
    > Vyncke (evyncke)' <[email-masked] <mailto:[email-masked]> >
    time.
    > > From: Yaron Sheffer <[email-masked] <mailto:[email-masked]> >
    > > To: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; 
    > > [email-masked] <mailto:[email-masked]> 
    > > Cc: 'Magnus Westerlund' <[email-masked] <mailto:[email-masked]> >; 'Murray 
    > > Kucherawy' <[email-masked] <mailto:[email-masked]> >; 'Roman Danyliw' <[email-masked] <mailto:[email-masked]> >; 
    > > 'Benjamin Kaduk' <[email-masked] <mailto:[email-masked]> >; 'Robert Wilton' 
    > > <[email-masked] <mailto:[email-masked]> >; 'Barry Leiba' <[email-masked] <mailto:[email-masked]> >; 'Eric
    Vyncke (evyncke)'
    > > <[email-masked] <mailto:[email-masked]> >
    > > 
    > > Thanks,
    > >         Yaron
    > > 
    > > On 2/2/21, 01:55, "Ethan Grossman" <[email-masked] <mailto:[email-masked]> > wrote:
    > > 
    > >     Hi All,
    > >     From: detnet <[email-masked] <mailto:[email-masked]> > On Behalf Of
    [email-masked] <mailto:[email-masked]> 
    > >     To: [email-masked] <mailto:[email-masked]> 
    > >     Cc: [email-masked] <mailto:[email-masked]> 
    > >     until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> .
    > > 
    > >     [email-masked] <mailto:[email-masked]>