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

On Fri, Mar 14, 2025 at 12:17 PM Toerless Eckert <[email protected]> wrote:

> Thanks, Eric
>
>
> 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
>

Sure. I alluded to this in my message "as a response to some policy
requirements"


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

Yes, I'm of course aware that protocols are vulnerable to traffic analysis
attacks,
and I agree that this is a setting in which lower layer encryption is
helpful in
that it helps conceal patterns in individual flows by aggregating them with
other flows. It's not a complete solution as the various distinguishing
attacks on Tor show, and I think we clearly need some anti-traffic analysis
techniques that live at the end-to-end layer but I agree that lower layer
encryption is valuable.

However, as I said in my original email, I have two concerns with the
presentation
in this document:

- The list of reasons that this document offers for why it is needed goes
  far beyond traffic analysis, including a number of issues (e.g., PQ),
where
  I don't think the reasoning above holds.

- The fix being offered here is effectively to individually secure every
link in the
  network, which is plainly very challenging. Coupled with the point above,
  it leaves the impression that the proponents think we should *not* address
  issues at the end-to-end layer but instead try to secure the entire
network
  fabric. I think this is backwards: we should do as much as possible at the
  end-to-end (or close to it) level so you don't have to trust the network
fabric,
  even as we *also* harden the network fabric.

-Ekr

However, the




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

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