[saag] Re: [nasr] Re: Initial thoughts on NASR

Hi Eric,
Please see inline.


From: Eric Rescorla
Date: 2025-03-17 23:29
To: Liuchunchi(Peter)
CC: [email protected]; IETF SAAG
Subject: [nasr] Re: Initial thoughts on NASR


On Sat, Mar 15, 2025 at 8:24 PM Liuchunchi(Peter) <[email protected]> wrote:
Hi Eric, 
 
> The basic assumption behind the design of these protocols
> protocol needs to provide security even when the attacker completely
> controls the network (see RFC 3552 S 3).
 
Remote attestation and secure boots on *some* network devices changed this assumption: There *are* certain routers that will *not* be completely controlled by the attacker. 

I don't agree that this changes that assumption, for several reasons:

1. Remote attestation is of some value, but I think the history of physical attacks on hardware security shows pretty clearly the difficulty of securing a device under the physical control of a sophisticated attacker. I don't think it's a sound conclusion that an attested device has not compromised the device.
[Meiling]Let's not fall into the trap of perfect solutions, secure a device under the physical control of a sophisticated attacker is indeed very difficult, but the cost of such attacks is very high. At least an attested device can eliminate known risks, and we do not pursue absolute security or trust, furthermore,  trust is actually a choice.

2. Even if we do think there are secure network elements, traffic will often run over insecure channels and so we should design our protocols as if the network was totally insecure (this is what 3552 says)


-Ekr


And (one of) the point of NASR is to prioritize use of these devices, so to achieve visibility and forwarding security.


 
We never suggest end-to-end layer encryption is not important and/or not used (sorry for not explicitly pointing it out in the architecture, I will add it, I assume it is a necessity everywhere). We suggest for compliance/green requirements, some visibility/verification of data flow on the network layer might be necessary, and that is where NASR comes in.  
 
 
> it's not clear why
> controlling this risk requires controlling *routing* rather than
> controlling which middleboxes are authorized.
 
It is about visibility of network security attributes, and verifiability of compliance to such attributes (is the actual data flow on this path with pre-agreed security attributes).
 
Peter
 
From: Eric Rescorla <[email protected]> 
Sent: 2025年3月15日 0:40
To: [email protected]; IETF SAAG <[email protected]>
Subject: [nasr] Initial thoughts on NASR
 
I've had an opportunity to review the NASR documents and it's left
with me with some concerns about scope and threat/trust model. I'd
like to start with the motivation at the top of
draft-liu-nasr-architecture:

   Path-agnostic traffic signing and encryption has been the primary
   method to ensure data confidentiality, integrity and authenticity
   today.  However, with the increasing amount of attacks, and
   vulnerabilities, new emerging threats are imposing requirements that
   go beyond the data security currently provided.  Vulnerable factors
   include:

   *  Unauthorized data duplication, caused by

      -  Routing/forwarding detour to unintended devices or areas

      -  Insecure network devices or unauthorized root access

      -  Middlebox decryption/inspection

   *  Capture-now-decrypt-later attacks, caused by

      -  Exploitation of vulnerable cryptographic engineering

      -  Post-Quantum attacks

   *  Pattern or behavioral analysis, etc.


I agree that these are real threats, but it's not clear to me that the
proposed mechanisms is the way to address them.

For the moment, I'd like to talk about the client/server and
peer-to-peer use cases that are common in IETF protocols, such as
HTTP, POP/IMAP, WebRTC, SSH, etc. [0] As stated in the text above, the
standard approach to securing this kind of communication is to use
some channel security mechanism that encrypts the traffic and
authenticates one or more of the endpoints, as with TLS, IPsec, QUIC,
SSH, etc. The basic assumption behind the design of these protocols
protocol needs to provide security even when the attacker completely
controls the network (see RFC 3552 S 3).

My concern reading this list is that the implicit problem argument
seems to be that these channel security mechanisms are not providing
the security protections that they are supposed to provide and
so therefore we need to instead provide a trusted path *between*
the endpoints. For instance, consider the first bullet:

   *  Unauthorized data duplication, caused by

      -  Routing/forwarding detour to unintended devices or areas

      -  Insecure network devices or unauthorized root access

      -  Middlebox decryption/inspection

If our channel security protocols are doing their job, then it
shouldn't matter if the network devices have access to the protected
traffic because it's not useful to them. Middlebox decryption is a
slightly different case, but -- again, assuming our protocols are
working correctly -- middleboxes should not be able to decrypt traffic
without the knowledge of the endpoint, so it's not clear why
controlling this risk requires controlling *routing* rather than
controlling which middleboxes are authorized.

Similar comments apply to the remainder of this list: the way we
intend to protect against quantum computers is to add PQC to our
protocols; if we want to protect against behavioral analysis we need
our protocols to resist it.

This is not to say that there is not some value in preventing
attackers from having access to encrypted traffic, but I think this
really needs to be viewed as a defense in depth measure -- and perhaps
as a response to some policy requirements -- rather than as a primary
security measure as is implied in this document: to the extent to
which our protocols are vulnerable to the listed threats, then we need
to address that by fixing the protocols, not by hoping we can
secure the entire network. Even if our objective was to protect all
the links, the strongest way to do that is to encrypt the traffic,
rather than hoping you can physically secure every device and every
kilometer of cable, which brings us back to needing strong
cryptographic protocols.

-Ekr



[0] As a nit, these protocols usually do not "sign" traffic.

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]