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

Eric Rescorla <[email protected]> wrote:
    >    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.

Here, limited domain might mean all the banks in Europe.
Or all the German government web sites, plus all the residential end-points
in Germany.
There is existing regulation in Switzerland and Germany (separately) about this.

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

This is not a limited domain in the sense that many of the DC people speak of.

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

It's not just about encryption.
That's one aspect.
(Believe me: "Why doesn't a VPN solve the problem" is the first question I
have asked, and have repeatedly asked)

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

The remote attestation is about understanding that the link-layer encryption
is actually occuring.  That the firmware in the routers have not been
compromised, not been mis-configured, etc.

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

Contracts don't help without some way to check for cheating.
Trust but verify.

We can send auditors out to verify that the fiber really is in the place that
the ISP said it was, but how can we know the traffic is really in *that* fibre?
(Look at the traffic?  But macsec ideally makes that impossible)
And one fibre is not enough; we want diversity of paths to get resiliency, so
while random audits are important, they aren't by themselves enough.
[Since there is redundancy, the auditor can't test that the traffic is in
that fibre, but cutting it and observing that it breaks things]

The contract is what enables the customer to collect all the results of this
process.

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

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

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmfWWlcACgkQlUzhVv38
QpCcgggAoaqiwCkXK9M1mkrO1m370kwGJJbiBEnzC3so3HnRc/hcbgBrqDpUqZjp
X6GIPkm8gaIlj1nDckHa7okWEvH4g95KyqcwRfEXrqYNu/aXRWVGApRQOQt25SYK
ac29XfqQMjB7VQsvsPHcSgW0Zd3xIaqNKIJI6vgT1X2L7DTIkkZBaVuF4IgdNUo+
xYakyjTJn3ohxi0qCf/4dCuxJO19rsEyWjO+6uIjkXwZ2HnYp9ffFzk6cFxOpCtw
pPrDMWccIkUwozDpM1REDH9v81+RZaGma52VBDJaFoWg8UtoArHYLQfq4f7AXHgv
rriinB5YK6Bvkhb25Ggeca+QG2Lzvg==
=265t
-----END PGP SIGNATURE-----