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 
> make. Sorry.
>  What I mean was whether the applications need to do something
> different because there is an ID (versus there just being a plain-old 
> IPv6
> address). The IDs can be visible, either by being part of an IPv6 
> locator,
> 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.

Ok.

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

>>> 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 
>> for
>> 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
>> unprotected TCP/IP?

> If I recall correctly, the main concern is when attackers and nodes 
> move
> around.

> 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 
> IPsec
> or TLS. But this ability to cause damage is limited to the time period 
> while
> 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 
> short
> 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 
> concerned.

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 
> secured traffic
> can not be redirected, by reusing the keys or otherwise "layering" on 
> top of
> IPsec or TLS, then at least we would know that secured traffic could 
> never be
> redirected by an attacker. So security-wise we'd gain some and loose 
> some.

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 
>> IPsec/TLS
>> 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 
>> well
>> 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 
> taking the
> 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 
> difficulty
> 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.