[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications?

Erik;

So, let's assume that we were talking about an imaginary IP network
where secure DNS were deployed and a pair of hosts were actually
using it for their forward and reverse domains.

Then,  there is no reason to make some part of address of a host
a hash of host's public key, as the host can simply put its full
public key in DNS.

Then, the pair of hosts can and will exchange a session key with
which the communication, including parts for multihoming control,
is secured.


Yes, but this implies doing a full key exchange to form the session keys
for every pair of hosts that communicate.
That might be acceptable if those hosts want cryptographical strength
integrity and/or confidentiality,

Urrr, what, are you saying, "acceptable"?

Apparently, you don't know that secure DNS is *EXPENSIVE*.

It take more computation to retrieve information from secure DNS, or
anything with hierarchical CAs, than to exchange a session
key for cryptographical strength integrity and/or confidentiality.

but feels like a lot of resources to
spend for the off-chance that during their communication one or both
of them will need to use different locators.

Huh?

"exchange a session key" for cryptographical strength integrity
and/or confidentiality at the beginning of communication means
that a shared secret session key is exchanged helped by public
key cryptography.

After that, cryptographical computaions are secrete key ones and
are inexpensive.

Your argument also assumes that all hosts will be in the DNS so that they
have a FQDN under which they can store their public key.

It is *YOUR* assumption.

That isn't the case in IPv4 today and I haven't seen a strong driver for
this changing with IPv6. Thus


Thus, even though you use public key cryptography with keys
authenticated by plain DNS, it is as secure as just believe
plain DNS.

I think it is important to enable multihoming
support when only one end of the communication has information in the DNS.
I haven't seen a proposal for how to do this using public keys stored
in the DNS. If you have one please explain it.

See above.

It is easy to have a proposal using public keys.

However, that your proposal use public keys wrongly does not mean
your proposal has reasonable security.

Still, you may argue that DoS of telling wrong locators should be
possible. But, you are wrong because MITM can issue as much DoS
as he wants regardless of security mechanism used. DoS by MITM,
agaist which cookies does not work, is fatally efficient, if
public key (that is, *EXPENSIVE*) cryptography is used.

DoS from MiTM isn't the main DoS concern in the threats draft.

That is a problem of your draft.

where the redirection capability inherent in multihoming

Wrong.

could potentially
be used to redirect large, sustained packet flows to a 3rd party.
See the draft for details.

See previous mails on how it can be done with DNS without M6.

The other DoS concern is about opportunities potentially created by
the multihoming mechanisms themselves; creating state or doing large amounts
of processing on an initial packet for instance.

An elementary fact on security is that DoS is so eacy.

That you happen to find a way of DoS attack for M6 does not mean
that similar attack is not possible for other protocols.

For example, secure DNS is subject to similar DoS attacks.

Finally, as a set of locators of a host can be securely obtained
from secure DNS that there is no need to dynamically authenticate
the set, which is the fundamental difference between MIPv6 and M6.


As the NOID draft discusses, if you want to use the DNS for verification,
one actually has to verify not only that the node/fdqn claims to use a locator,
but also that the locator points back at the fqdn.


And it is identical to reverse-then-forward look up of DNS for
verification widely used today with no M6 specific issues.

Unlike secure DNS, it is easy, useful, inexpensive, reliable
and proven to work.

Masataka Ohta

PS

Learn elementary security.