[nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120

[Toerless Eckert <[e-mail]>]

Interesting, Junzhan, thanks

I think all the concepts of security for data at rest are useful to look at
as an adjacency and "steal" useful concepts. But likewise i would think
that keeping data at rest out of scope for NASR is one simple way to constrain
the scope.

What i think will be of interest is to figure out what the most simple modelling
of the different degrees of security is for NASR. "Secure Nodes" of course are
a key aspect to make NASR useful, aka: If you would create any form of signature
from a key pair thats easily accessed by hackers, then it's at best NAsR ;-)

In this context (trusted devices), there is definitely the interesting evolution
from "destroy the hardware" over "zero the data" to "store encrypted, delete the keys".
and each of these steps adds convenience, but increases also risk of new insecurities.

To avoid scope creep it would be good to figure out how we can call the maximum
amount of those details "problems of other people", but of course, as soon as
one thinks of operationalizing NASR, those topics can't be avoided. And the device
level requirements against a trustworthy NASR implementation are IMHO as important
as the on-the-wire ones. Typically that would worry me in the IETF because it's
full of on-the-wire-centric folks, but luckily there are also enough security people
to understand that we need to specify security requirements well to meet the
expected security requirements of a solution.

There was also an interesting side meeting at IETF120 about TPMs... 

Cheers
    Toerless


On Fri, Oct 04, 2024 at 08:38:02AM +0000, junzhang wrote:
> Dear Michael and Toerless,
>        
>            In the cloud computing area, there is a concept called assured deletion, that is, to give a proof that after the data is removed from the cloud, and no one else can access it again. One typical approach to realize it is 
>            (1) encrypt the data such that it is computationally prohibitive to decrypt the data without the decryption key, 
> then (2) store the encrypted data in the cloud while keeping the decryption key secure, 
> and finally (3) securely delete the encryption key.
>           
>                    https://cdn.stmarytx.edu/wp-content/uploads/2020/10/Cloud-Storage-Assured-Deletion-Considerations-and-Schemes.pdf
> 
>           Is it related to the avoidance of copying traffic that you have discussed?
>           Yours,
>                  Jun Zhang
> 
> -----Original Message-----
> From: Michael Richardson <[e-mail]> 
> Sent: Thursday, October 3, 2024 11:26 PM
> To: Toerless Eckert <[e-mail]>
> Cc: Liuchunchi(Peter) <[e-mail]>; =?us-ascii?B?PT91dGYtOD9CPzVZaVk2Ym1QNkw2Sj89?= <[e-mail]>; Meiling Chen <[e-mail]>; [e-mail]
> Subject: [nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120
> 
> 
> Toerless Eckert <[e-mail]> wrote:
>     > But avoidance of copying of traffic by undesired third parties if course a core
>     > benefit that NASR can provide. And those prior examples can provide examples of
>     > the attack vectors why that is undesirable. Even with todays easily available
>     > end-to-end encryption.
> 
> NASR can not provide any kind of avoidance of copying!
> (To do that you'd need quantum entangled links of the kind the QIRG is contemplating)
> 
> What NASR can do is provide assurance that when you have such links, that:
> a) there are no stealth routers in the path.
> b) that the two sides of each QIRG link are operating nominally.
> 
>     > But maybe much simpler: nation state actors have the means to extract and even decrypt
>     > end-to-end traffic. But if they can not see the traffic because it does not run across
>     > the paths desired by them, because they pass their network taps - then
>     > they can't do that.
> 
> yes.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 

-- 
---
[e-mail]