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

Thanks, Eric

I know we talked about a lot more reasons for NASR than what you
refer to, bu i hadn't checked th architecture draft for a while, and
indeed, it does not mention others:

Regulatory or subscriber requirements against the path used by traffic

  - Permissible countries/regions of transit (EU, USA&friend, ...)
  - Permissible network equipment vendors or operators (e.g.: trust in integrity)
  - required certifications of network equipment on path
    (including any type of software version or bug-fix attesttions)
  - "Greenness" of path equipment / path power-sources

Reasons for the attestation of any of these path properties may include
  - political or commercial policies 
  - marketing/value goals ("greenness")
  - reliability expectation
  - confidentiality expectations

So, the reasons for NASR IMHO are much broader than just the confidentiality
aspects that is included right now and that you are discussing.

Maybe the authors could amend the introduction text of the architecture draft
with something like the above to make it easier to understand the broader scope of
applicability.

Now, as to the specific concerns re. confidentiality.

I remember even back in ?2010 or the like that DPI implementations in routers for
encrypted traffic where able to analyze traffic patterns without decryption to
determine wide range of session details. Including back then different
type of video conferences of otherwise all-encrypted RTF sessions purely by
simple traffic-train pattern analysis. A couple years laters, researchers
did the same thing and thought it was new. And now its revived with the term
AI.

Meanwhile, the NSA must have been chuckling over the commercial world reinventing "attacks",
which they themselves must have implemented for decades, because the whole defense,
if not federal security architectures where much earlier already protecting against
such attacks, including aggregated IPsec VPN boxes such as HAIPE, but also L1 encryption
on top of any non-trusted physical link, such that no traffic patterns whatsoever
could be read from it (i remember having seen such link encryption devices even in
the early 90th). This degree of protection against observation interestingly was
only brought up to an L3 standard track solution recently through RFC9347. Aka:
creating CBR IPsec tunnels by adding filler data.

So... No! end-to-end encryption ala TLS is not sufficient alone, or else all of
the above would not exist. But many of the aforementioned mechanisms from other
market segments do not fly equally well in the context of commercial use cases,
so NASR is also for the confidentiality argument a very interesting new option that
we as the IETF should be happy to experiment with, and maybe it will turn out to be
a great addition to the world of security mechanisms.

This is just off the top of my head. I think i can come up with more confidentiality
example where NASR should be able to help - if need be.

Cheers
    Toerless

On Fri, Mar 14, 2025 at 09:40:28AM -0700, Eric Rescorla wrote:
> 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.

> -- 
> nasr mailing list -- [email protected]
> To unsubscribe send an email to [email protected]


-- 
---
[email protected]

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