[saag] Re: [nasr] 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.
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]