Re: [stir] current draft charter

[Michael Hammer <[e-mail]>]

Thanks for that clarification.

The crux still seems to be the linking of a domain node to an E.164
delegation node point.
So, DNSSEC would require ENUM style domain structure to some level.
Note, that will lead to the usual root wars.
Possible, but likely need to get everyone on the same tree.

Mike


-----Original Message-----
From: Dan York [mailto:[e-mail]] 
Sent: Monday, June 17, 2013 3:55 PM
To: Michael Hammer; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [stir] current draft charter

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/