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

On Sat, Mar 15, 2025 at 5:04 AM Michael Richardson <[email protected]>
wrote:
> 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:

These certainly are real threats, but NASR seems like an incredibly
heavyweight way to address them, if it does so at all. Just to make
sure we're on the same page, I want to note the following text from
the charter:

   The working group will initially focus on a simple service path in
   limited domains under a single administrative control. The working
   group will then focus on a simple service path spanning a few
   number of domains that have business relationship, in order to help
   coordinate, connect and deliver a consistent connectivity
   service. Applying NASR to large groups of domains such as the
   Internet is not seen as viable and useful use case.


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

Clearly, DDoS is an issue, but it's typically an issue when your
endpoint (e.g., a server) is reached over the public Internet, which
is something the charter explicitly rules out of scope. I agree
ACLs are clunky in the case of the public Internet, but if we're
just restricting ourselves to specific peers, as NASR does, then
the problem seems far simpler.


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

As Stephen says, the right place to deal with CRQC is at the existing
security protocol layer.

The traffic analysis piece is more interesting I don't disagree that
it's helpful to encrypt at the link layer, but I'm not really
persuaded this is the kind of real-time *attestation* problem contemplated
by NASR; how often are people going to refuse to send traffic at all
if it's not link-layer encrypted?


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

This is of course a real issue, but isn't it better solved with contractual
mechanisms?


-Ekr

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