[saag] 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]