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

Stephen,

Please explain, how analytics of logged traffic pattern is "bogus" ?
Or how any of the WG doing KEM/KEX address this ? Such pattern
analytics is highly compressible given how it just needs to include pattern
header, length and timing, so it easily can be done at scale if/where there
is access to traffic on the path.

Your "bogus" argument seems especially strange to me when hundreds of millions
of tac payer money world wide are spent on quantum internet research, a good
amount specifically into quantum coupled links especially to prohibit
observability of traffic.

If you do trust that the KEM/KEX work will result in actually quantum safe
crypto, would you not rather want to see support for NASR as one of the
enabling technologies to attest to the existance of quantum safe secure paths
with cryptography ?

You can not do traffic pattern safe encryption end to end. That leaves
your header data maximum exposed, and it requires the most expensive amount
of filling data via something like IP-TFS if you want to hide payload patterns.

What really helps is per-link encryption, which is ideal and simple at
physical layer, but even at link layer such as MacSec, you do have perfect
end-to-end header protection, you do have AFAIK stuffing support to also hide
traffic patterns - which likely isn't needed because you eliminated the
headers to correlate packets to end-to-end flows. And if you go to IP-TFS you
have the same at L3. You may not have it hop-by-hop today, but even if it
is between PE in a backbone SP as part of a typical IPsec mesh setup,
then it does provide a significant gain against traffic pattern observability.

All those network/link layer encryption/obfuscation methods can easily 
be go to quantum safe crypto for their symmetric key negotiation in software
if there is sufficient customer demand, much easier so that upgrading billion of end hosts.

But that customer demand needs some better form of trut-but-verify against whever
makes the claim of such protection against observability. And NASR is exactly
this. Not only could it say "this link between two nodes is a physical
link with Macsec 256 bit AES, but sory... not yet quantum safe session negotiation".
Or this virtual link is an IPsec protected path across an SP cores, all int4ervening
nodes are in country CCC, and session negotiation is using quantum safe
negotiation proto YYY".

And of course equally if not more so important is simple observation of the
necessarily in-the-clear end-to-end traffic patterns purely on routers (needed
for forwarding). This is whee the rubber meets all the "lawful intercept" that
can be derived from knowing (or not knowin) vendor, firmware options, operator
and deployment country. And of course non-government but simply operator
observation of traffic patterns for commercial gains. 

Maybe i am just too imaginative by having been too often to Cisco Live twice yearly,
where one of the larger areas of partner booths have traditionally been various companies
doing traffic analytics based on Netflow/IPfix - a lot of that was simply based on traffic
batterns based on outer IP headers, correlating those to departments and then correlating
that to activites - gee, your shipping warehouse location ZZZ had double as much activity
during december this year than last year. Looks good for sales of product lines stored there.
Now let's imagine that companies main competitor - or countries main competitor has this type of
traffic statistics available.

Cheers
    Toerless

On Sat, Mar 15, 2025 at 02:22:42PM +0000, Stephen Farrell wrote:
> 
> (Also without expressing a broader opinion on NASR yet...)
> 
> On 15/03/2025 12:04, Michael Richardson wrote:
> > 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.
> 
> The place it makes sense to try address this attack is at the same
> place where the classical encryption is being done via the kinds of
> hybrid KEM/KEX work already well underway for TLS, SSH, OpenPGP, etc.
> 
> Trying to address this specific threat at a different layer from the
> classical encryption seems bogus to me - you'd never know whether or
> not you've solved the problem as the classic ciphertext might appear
> somewhere else to be recorded.
> 
> So this issue should be scratched as a justification in this context.
> 
> Cheers,
> S.
> 




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