[saag] Re: Initial thoughts on NASR

On 3/14/2025 9:40 AM, 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.

One big issue with the architecture document is that it does not assume 
end-to-end encryption. This seems weird, given that close to 90% of the 
traffic is encrypted. This document would be much stronger if it focused 
on the threats that are not mitigated by end-to-end encryption, and 
specifically on the subset of these threats that might be better 
mitigated by protecting the network path. I think these boil down to:

* analyzing metadata that is outside the scope of end-to-end encryption, 
such as which IP address contacts what other address and when,

* using analysis of patterns of encrypted traffic to identify the nature 
of the communication between two endpoints and make guesses about the 
content

* denial of service attacks of end-to-end encrypted communication by 
on-path agents.

Having some kind of "trusted path" does indeed reduce the attack 
surface. Of course, it does not eliminate any of the attacks listed 
above. It only reduce them to "only the elements that I trust can 
perform these attacks". There is no one-size-fits-all there -- in 
practice, the list of elements that the end users have to trust is 
controlled by the network provider. (Cue legal intercept, semi-legal 
monitoring of communication, etc.) Still, having some guarantee that the 
traffic between a broker in Chicago and a bank in New York will not be 
routed through a wiretap office in Koenigsberg does have some obvious 
value. The architecture should focus on providing that kind of value.

-- Christian Huitema

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