Re: [stir] current draft charter

[Dan York <[e-mail]>]

Mike,


On 6/17/13 2:05 PM, "Michael Hammer" <[e-mail]> wrote:

>But, clarify one thing for me.  Does DNSSEC ensure both:
>-  that the uploading of information is authentic,

DNSSEC ensures that the information the recipient is retrieving from DNS
is the same information that was put into DNS by the entity operating the
DNS servers for that domain (and signing the records).  It provides an
integrity check on the data received in a DNS query.

It can make no assertions about the quality or authenticity of the data
that was uploaded into the DNS servers.  All it can say is that the data
you are receiving matches the data that was served by the DNS servers
(based on the cryptographic signatures).  If an attacker compromised the
DNS servers, including the ability to generate DNSSEC signatures, he or
she would be able to upload bogus data - but if this happens there are
probably larger issues for the operator of the servers to worry about.

In the STIR example, if we were to use DNS we would need to assume a
certain level of trust in the entities putting the phone numbers and
corresponding identities into the DNS.  As you mentioned this is probably
the CC numbering authority in many/most cases.

>-  attempts to read the data actually get to that secure entry?

DNSSEC has a concept of a "global chain of trust" that links the
individual records and their signatures up to an ultimate trust anchor,
which, in the case of public DNSSEC would be the root of the DNS.
Essentially, you have a DNSKEY record with your public key.  There is then
a Delegation Signer (DS) record in the parent zone that is a hash of the
DNSKEY[1]. This continues on up to the TLDs and to the root.

If STIR were to use DNS/DNSSEC, the entity (server, IP-PBX, SBC, endpoint,
whatever) performing the DNSSEC validation for the call would know that it
was reaching the secure entry because:

1. the info for the telephone number identifier (cert, text record,
whatever) would be cryptographically signed by the zone's public key
(carried in the matching RRSIG record).

2. the entity would be able to use the DS records to walk back up the
global chain of trust to be sure that it was using the correct key for
validation.

If either of these cases failed (a bad (or nonexistent) signature or an
inability to verify the chain of trust), the entity performing validation
would know that it had probably NOT been able to get to that secure entry.

Note that this assumes that DNSSEC would *always* be used so that a
nonexistent signature would also cause a warning.

Dan


[1] And yes, I'm simplifying this a bit for the purpose of illustration.
Those who want more gory details can see RFC 6781 -
http://tools.ietf.org/html/rfc6781

--
Dan York
Senior Content Strategist, Internet Society
[e-mail]  [phone]
Jabber: [e-mail]
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/