Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


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

[Discuss] free SSL certs from the EFF



"Edward Ned Harvey (blu)" <blu at nedharvey.com> writes:

>> From: Derek Atkins [mailto:warlord at MIT.EDU]
>> 
>> "Edward Ned Harvey (blu)" <blu at nedharvey.com> writes:
>> >
>> > Based on my understanding of DNSSEC, it doesn't add security except in
>> > esoteric edge cases.  Because your client doesn't have any point of
>> > trust - if your client queries DNS, there's no way for your client to
>> 
>> This is a false assumption..  Clients can (and are) populated with the
>> well-known Root Zone KSK which is used to verify the root-zone ZSK which
>> in turn signs the TLDs.  So properly configured clients can indeed have
>> a point of trust.  It's effectively the same level of trust you can put
>> into your "root CA list" that also must be populated on the clients.
>
> My point is: Let's suppose I am Firefox (or something) and I create a
> query to resolve "www.google.com."  I don't know if the response to
> that query is supposed to be signed, and I don't have any point of
> trust that I can ask, to reliably determine if the response to this
> query is supposed to be signed.  When I receive the response, if it

I'm sorry, but you are incorrect.  You absolutely know this, because:

1) the root zone is signed with a known key, and
2) most of the TLDs are signed (in particular .com is definitely signed)

So, when you walk down the tree from the root to .com to google.com,
.com will tell you "yes, google.com is signed, and here is the key you
can use to verify their zone".  So viola, you know, authoritatively AND
securely, that google.com is signed.  Which means you should expect
www.google.com to be signed.  If you get an unsigned response from
google.com then you need to also receive a signed message (NSEC) that
says "this is an unsigned portion of this zone", which tells you again
(authoritatively and securely) that you should NOT expect a signed
response.

Of course, all this requires Firefox itself to process DNSsec.

> happens to be signed and passes the verification process, then great!
> Also, if I receive a response that is signed and fails validation,
> then great!  I have a conclusive answer that it's corrupt.  But if I
> receive an unsigned response - I have to just accept it and assume
> it's valid.  Nothing else I can do.  This means, even if google *did*
> sign their response, any intermediate malicious router could simply
> strip the security from the DNS response, mangle it maliciously, and
> serve it to me.  Since the DNS client doesn't have any way to know for
> sure that *this* DNS response was supposed to be signed, it will
> happily accept the insecure (and possibly tampered) response.

No, it wont accept it.  That's the whole point of DNSsec.  If the
resolver is expecting something to be signed and the signatures get
stripped off, then it's not accepted.

> The only way to provide true security would be to somehow inform a DNS
> client, without the possibility of tampering, information that *this*
> DNS query is supposed to be signed, so the client may reject it if
> it's not signed, or if the signature is incorrect or by an untrusted
> authority.  This is absolutely a solvable problem, by any one of
> several possible techniques, but I have not yet read anything
> proposing a solution in this area.

Then you have not read the DNSsec specs.  It absolutely solves this
problem, because the root zone *IS* signed, and has been for a few
years.

> As far as I know, right now, DNSSEC only provides *optional* security
> for normal queries, but if you manage a domain, then you can configure
> your DNS servers to communicate with each other and require DNSSEC
> when communicating with each other.  In other words, you the admin who
> has control over your domain, can dictate and configure your servers
> to require your own DNS servers to use DNSSEC when communicating
> amongst each other (and reject anything that isn't signed), but I'm
> not aware of anything that extends this requirement to regular DNS
> clients.

It's optional, yes, but it's authoritatively optional.  Your parent zone
can authoritatively and securely relay whether your zone is signed or
not.

Of course, yes, this requires the client to be DNSsec aware.  A
non-DNSsec client must trust its resolver implicitly to perform DNSsec
checks.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org