[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: identifiers and security
On 29-jun-04, at 14:04, Erik Nordmark wrote:
and whether those IDs are visible to the applications.
Ah, but that's a very different issue. I think by definition the
identifiers are visible to the application.
My choice of "visible" doesn't capture the distinction I wanted to
What I mean was whether the applications need to do something
different because there is an ID (versus there just being a plain-old
address). The IDs can be visible, either by being part of an IPv6
or by some new mechanism by which the application can ask the stack
for the ID,
but that wasn't the point I was trying to make.
Taking NOID as an example of with no new ID namespace, the amount of
work (in the form of DNS lookups in forward and reverse maps)
will also result in stronger association between FQDNs and locators
than we have today.
Even if we assume DNSSEC?
Assume DNSSEC for the baseline (current Internet), for NOID, or for
when comparing them?
Compare NOID without DNSSEC with DNSSEC without NOID. I think the
latter provides stronger FQDN -> address and address -> FQDN
information although you are right that this isn't the same as FQDN <->
I've received pushback from folks that I wouldn't characterize as
security geeks, that this would be too weak.
I don't think this is universally true. Certainly, this is too weak
TLS or IPsec sessions that can now be broken by an attacker, unlike
before. But why would this be too weak for talking to Google over
If I recall correctly, the main concern is when attackers and nodes
In today's if an attacker is on the path it can cause damage to the
communication if the communication isn't protected with something like
or TLS. But this ability to cause damage is limited to the time period
the attacker is on the path.
If we add some multihoming signaling whereby an attacker, which was on
the path (e.g., by being on the same WiFi subnet as the victim) for a
time period, can cause damage by essentially using the state creation
as a way to preserve it's on-path'ness forever, then folks are
And justifyably so. But wouldn't it be possible to address this in
other ways? Such as having per-direction or even per-session state
rather than per-address?
But what you brought to the table is that if we can ensure that
can not be redirected, by reusing the keys or otherwise "layering" on
IPsec or TLS, then at least we would know that secured traffic could
redirected by an attacker. So security-wise we'd gain some and loose
I think if the redirection problem by attackers that are on-path
temporarily is limited to individual unprotected sessions, we are not
materially worse off than today as the same attacker could break the
sessions today also, and redirecting an unprotected session presumably
isn't worse than breaking it as the contents aren't secret.
I'm thinking more along the line of violating layers and modify
such that the wedge or modified IP can obtain keys that are exchanged
by modified IPsec/TLS. Something like putting the secret instructions
for the messager in the locked briefcase he's carrying. This works
except for the first trip of course...
This sounds tricky.
I guess I don't know enough how the TLS keys (and which
keys; is there some master key used to generate the RC4 key?, etc)
can be exported from TLS.
I don't know the specs by heart but the way I understand it is that you
have a public/private keypair for at least one end of the connection.
This key pair is used to create a session key which is subsequently
used for encryption. The same key or maybe a different one is used for
authentication. TLS works with blocks that may span several TCP
segments. Since there is significant housekeeping, I'm assuming it
would be possible to define a new message type that can be exchanged
between the two hosts without getting in the way of existing operation
(negotiation or data transfer). All that would need to happen here is
for each side to announce a session key that can be used for
multihoming to the other side. Since this information is encrypted,
signed and delivered over reliable transport, there isn't much more to
it. It would of course also be possible to use TLS's own session key,
but that's probably dangerous as it may more easily leak and that key
is subject to renegotiation.
FWIW Doing the insecure signaling protocol for managing the contexts
is something I can do; a version of such a spec can be created by
NOID spec and removing the places where it verifies things in the DNS.
Saying it is layered above IPsec is also easy to say, but the
is exploring the interaction with IPsec and IKE, as well as TLS.
Right. What did you think about my IPsec/TLS/DNS musings? This would
provide pretty much the above using unmodified NOID. The IPsec/TLS
stuff doesn't get easier this way but it's more modular and it also has
other benefits (can do TLS when the DNS is down, at least in theory) so
it may be easier to get off the ground.