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



> 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 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.

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.

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.



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