[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
the KEY debate
[ post by non-subscriber. with the massive amount of spam, it is easy to
miss and therefore delete mis-posts. so fix subscription addresses! ]
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Loomis," == Loomis, Rip <GILBERT.R.LOOMIS@saic.com> writes:
Loomis> First, I agree with Matt's recommendation to take the
Loomis> discussion to namedroppers...but as another way to state what
Loomis> Matt already stated quite well above, it's not that having
Loomis> lots of non-DNSSEC info in KEY records "breaks DNSSEC". It's
Loomis> that having to sort through all the possible cruft at the top
Loomis> of a zone and look for the "right" key causes the DNSSEC
Loomis> signature verification process to take too long. There's not
Loomis> much IMHO that can realistically be done to engineer either
Loomis> the software or the protocol to fix this...other than limiting
Loomis> the KEY record as that I-D discusses, and using APPKEY or
Loomis> something similar to store the non-DNS application keys.
Loomis> If anyone sees any holes in my summary above...ask me on
Loomis> namedroppers.
Let's be clear.
Some people who are not application developers, and who have no deployed
code, want to obsolete KEY EVERYWHERE for non-DNS use because they think that
it might cause problems if put at the apex of a zone.
Who wants to put non-DNS KEY records at the apex of a zone?
What application needs it there?
1) IPsec. nope, needed with host records or reverse records.
2) SSH/telnet. nope, same requirements as IPsec.
3) HTTPS. maybe for supporting "example.com" as an alias for
www.example.com, but due to HTTPS limitations, would
require a seperate IP address from www.example.com
(so that the server could use the proper certificate)
A major hassle, and it is unlikely that this is going
to matter as long as we do web certificates with X.509
CAs.
4) SMTP. Put an MX record there. Use the KEY record attached to
the MX record, and authenticate the server. You might
think that you want to authenticate the zone's key, not
the server's key. Well, that doesn't work, because you
don't know which of potentially many MX servers you will
talk to. You could give them all the same private key,
but that would be a mistake, given that for best
reliability, you want the MXs in different places, run
by different people.
So, we are left with someone who wants to do:
"ssh example.com"
rather than
"ssh host1.example.com"
Of course, they might put 100 A records at "example.com". Will DNSSEC deal
with this? Will it be cause the signature verification process to take too long?
Massey/Rose write:
>differences in more detail. Combining these very different types
>of keys into a single sub-typed resource record adds unnecessary
>complexity and increases the potential for implementation and deployment
>errors. Limited experimental deployment has shown that application
>keys stored in KEY records are problematic.
Also, they write:
>The following table summarizes some of the differences between DNSSEC
>keys and Application keys:
>
> 1. They serve different purposes.
>
> 2. They are managed by different administrators.
>
> 3. They are authenticated according to different rules.
>
> 4. Nameservers use different rules when including them in responses.
>
> 5. Resolvers process them in different ways.
>
> 6. Faults/key compromises have different consequences.
#1 is confused about the purpose of DNS. DNS serves to map names into things
that the network layer can use to connect with.
DNS is to permit people to type "telnet host1.example.com" and have it
work. In an age of SECURITY, that means that we all of the network blobs
required to make that connection.
These are *not* APPLICATION keys because "telnet" is not an application, it
is a session layer protocol. Emacs is an application. Word is an application.
#2 is also confused when it comes to IPsec and SSH keys.
IP addresses are FREQUENTLY managed by the same people who manage the hosts
that they are assigned to. Even when protocols like DHCP is used to assign IP
addresses, we have demonstrated that making the link to the public key can be
done at the same time. There are two WGs that want to leverage this kind of
thing.
They further list #3 - that keys would be exchanged with the parent zone.
DS gets rid of that, so this comment is moot.
#4 is a concern - but, you MAY NOT deprecate a facility without having
provided a replacement facility. The SRV and NAPTR suggestions are
unacceptable, as they introduce yet another round trip. There are only two
methods which will work:
1) special names. "ipsec.example.com" - might as well use KEY.
2) a RR for each application.
Claim #5 is totally confused. They keep saying how application keys must not
be used to authenticate data. They then go on to explain how writing
application is "hard" because we might have to do DNSSEC ourselves. Not only
do want to do that, but we *insist* on doing it.
Claim #6 is again totally confused. Where does it say that application keys
are used to authenticate DNS data?
In general, we regard this draft as a denial of service attack on the effort
to secure the Internet.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPUwQJIqHRg3pndX9AQFpAAQAyJdloYAEknW4sd+SjXesiUxkVyTk+sEY
FBY2LpBQreagS4rF2heLT3GxY+nnt7I6n2okOlPVcdiKveglAZ3Crz6W8LsB/vYf
6LXnNh9QpHqyJ2g7UF8EByPNjL8+NgC1ofmd3IBftXyLTo7y9sw6VbfxihXBXV+M
fPEJHcKBWS4=
=cDY3
-----END PGP SIGNATURE-----
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>