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

Michael Richardson <[email protected]> Sat, 15 Mar 2025 19:04:06 +0700
Newsgroups	gmane.ietf.saag
Message-ID	<605369.1742040246@dyas>
I don't have the brain cells to absorb EKRs review right now; I'll come back
to it.  Probably, I'm agreeing with Christian here.

Christian Huitema <[email protected]> wrote:
    > 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

I just wanted to say that NASR deals in part with threats that *singly* (is
that the opposite to mutual?) authenticated end-to-end encryption does not
solve.  So it's not that we are ignoring it, it's that "everything" is TLS
encrypted, but it's not enough.   That includes:

1) Distributed Denial of service attacks that occur *within* TLS/HTTPS.
   So you want to limit your attack surface by limiting who can connect.
   Why not a really big ACL?  And the answer is because it is probably
   unmaintainable, even assuming we could do maintain it, would our sources
   of input be useful?

2) Capture Now, Decrypt after the CRQC concerns.  Some of this might be FUD,
   but some of the concern is real.  Some of this has made into national
   regulators.  Yes, this includes Traffic Analysis attacks.
   So keep the "bad guys" from collecting the traffic in the first place.

3) Performance, latency, and resilience guarantees.
   For instance, if I buy two redundant paths, how can I know that they don't
   share a router or fiber bundle somewhere?

(I think that if we had more mutual TLS, that there are some things that could
be better solved that way)

My understanding is that there are some bits of critial infrastructure
control which are still running over private leased lines (even if they put
IP inside it),  and they would like to stop doing that.  They see some
advantages in *resiliency* of public networks, because they can more easily
diversity their supply chain.  (Networks can be resilient and redundant in
their architecture, but usually not in the people-side of the  management)

    > * 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.

Yes, I think that these are all concerns.

    > 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.

Just keeping this for emphasis.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 487 B)