[nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    > The reason was simply that content providers had woken up to the attack vector
    > of encryption keys to not be very good long-term, or that in multicast, the
    > encrpyption key had to be shared to multiple subscribers, so some subscribers that
    > where permitted to receive the content could extract and share the
    > encryption key

It's an interesting storey, but I don't think it applies directly as a use
case for NASR.

    > Not sure if any of this multicast example is of interested to be written down
    > in any part of NASR docs, let me know if it is. Else this was just meant as
    > an example of history in network based leakage prevention to prohibit
    > encryption key sharing or long-term key cracking as an attack vector.

    > The unicast equivalent of course is not to upload to-be-protected content to
    > publically accessible web-caches because that too would make dissemination of
    > that content plus key cracking easier.

I'm trying to imagine a nation-state actor that replaces a stream with their
own while the stream was passing through their borders.  That seems pretty
tenuous, but not ridiculous to me.  Particularly when satellites might be involved.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide