Re: DNSSEC and SSL
On Sun, 22 Aug 2010 21:57:27 +0200, Mans Nilsson mansa...@besserwisser.org said: MN The best option today is to run a full-service resolver on the host; The DNSSEC-Tools project has instrumented a large number of applications with an in-application validating resolver. Including OpenSSH (with a new auto-accept-keys option!), sendmail, postfix, libspf, thunderbird, lftp, wget, ncftp, ... -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/
Re: DNSSEC and SSL
On Sun, 22 Aug 2010, bmann...@vacation.karoshi.com wrote: On Sun, Aug 22, 2010 at 09:11:43AM -0400, ML wrote: Is a DNSSEC capable stub resolver not in the cards? yes it is. unbound was originally designed for that very niche. Unbound is a full service resolver not a stub resolver. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: NORTHEASTERLY 3 OR 4, INCREASING 5 TO 7, OCCASIONALLY GALE 8 IN SOUTH UTSIRE, BACKING NORTHWESTERLY LATER. MODERATE OR ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.
Re: DNSSEC and SSL
On Sun, 22 Aug 2010, Mans Nilsson wrote: OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND suite. Calling it from applications does however mean using new API calls; since the traditional resolver API is oblivious to DNSSEC. lwresd is in fact a full service resolver, though it is designed for forward-only usage. Although its man page says it is stripped-down, it is in fact just the normal named binary running in a mode with a simple canned configuration that gets its forwarders from /etc/resolv.conf. AIUI, lwresd was originally conceived to deal with the original IPv6 DNS support (A6 records and binary labels). It would need quite a lot of re-working in the lwres client library (and possibly also the lwres protocol) to provide proper DNSSEC support. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT: CYCLONIC, BECOMING SOUTHWEST, GALE 8 TO STORM 10, INCREASING VIOLENT STORM 11 FOR A TIME. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR.
Re: DNSSEC and SSL
On 23 aug 2010, at 16.35, Tony Finch wrote: Unbound is a full service resolver not a stub resolver. depending on configuration, unbound can be used as both a full service resolve and a stub. jakob
Re: DNSSEC and SSL
On 8/22/2010 3:57 PM, Mans Nilsson wrote: a DNSSEC capable stub resolver not in the cards? The best option today is to run a full-service resolver on the host; which is a tad heavy for most desktops, not to speak about the cache misses that would cause root server system load. The latter of course can be avoided by setting forwarders. OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND suite. Calling it from applications does however mean using new API calls; since the traditional resolver API is oblivious to DNSSEC. PowerDNS resolver. Very fast, very light. --Curtis
Re: DNSSEC and SSL
The fact hat Verisign kept the domain business and sold the CA business to Symantec tells which business they think is stronger. Rubens On Sat, Aug 21, 2010 at 10:00 PM, ML m...@kenweb.org wrote: Would a future with a ubiquitous DNSSEC deployment eliminate the market for commercial CAs? Would functioning DNSSEC + self signed certs be more secure/trustworthy than our current system of trusted CAs chosen by OS/browser developers?
Re: DNSSEC and SSL
The fact hat Verisign kept the domain business and sold the CA business to Symantec tells which business they think is stronger. FWIW, I remember being at a tech company some of you have heard of when the CEO announced we'd just sold one of the more profitable non-core units to help fund core product devpt. Someone in the audience pointed out it was probably our strongest (non-core) unit, why not sell one of the weaker ones? We wouldn't get a lot of money for a weak unit now would we? he answered. So, maybe yes, maybe no. But this reasoning alone doesn't settle it. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: DNSSEC and SSL
On 08/23/2010 08:03, Curtis Maurand wrote: PowerDNS resolver. Very fast, very light. For the purpose of DNSSEC support powerdns might not be the best choice. They are late to the game, and only added DNSSEC support reluctantly due to market pressure. There have been other good suggestions in this thread already, but as always evaluate all possible solutions for your particular use case(s). Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
Re: DNSSEC and SSL
On Sat, 21 Aug 2010, ML wrote: Would a future with a ubiquitous DNSSEC deployment eliminate the market for commercial CAs? No, but it might eliminate the cheapest certs that people might use. I'd like my personal server to have a self-signed cert with it's fingerprint handled via DNSSEC, because I don't want to pay a CA. Would functioning DNSSEC + self signed certs be more secure/trustworthy than our current system of trusted CAs chosen by OS/browser developers? No, because DNSSEC isn't secured all the way from the DNS server to the application, only to the resolver. Both systems have problems, I'd imagine the best security is when they work together. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: DNSSEC and SSL
On 22 aug 2010, at 03.00, ML wrote: Would a future with a ubiquitous DNSSEC deployment eliminate the market for commercial CAs? Would functioning DNSSEC + self signed certs be more secure/trustworthy than our current system of trusted CAs chosen by OS/browser developers? For DV (domain validation) certificates one can definitely make that claim, but for EV (extended validation) I would see certificate validation in DNSSEC as a complement to EV. DNSSEC and EV together looks like a promising combination. Disclaimer: I am co-author of http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns-00 (work in progress, see http://www.ietf.org/mailman/listinfo/keyassure for more information). jakob
Re: DNSSEC and SSL
On 8/22/2010 2:38 AM, Mikael Abrahamsson wrote: No, because DNSSEC isn't secured all the way from the DNS server to the application, only to the resolver. Both systems have problems, I'd imagine the best security is when they work together. Is a DNSSEC capable stub resolver not in the cards?
Re: DNSSEC and SSL
Subject: Re: DNSSEC and SSL Date: Sun, Aug 22, 2010 at 09:11:43AM -0400 Quoting ML (m...@kenweb.org): On 8/22/2010 2:38 AM, Mikael Abrahamsson wrote: No, because DNSSEC isn't secured all the way from the DNS server to the application, only to the resolver. Both systems have problems, I'd imagine the best security is when they work together. Is a DNSSEC capable stub resolver not in the cards? The best option today is to run a full-service resolver on the host; which is a tad heavy for most desktops, not to speak about the cache misses that would cause root server system load. The latter of course can be avoided by setting forwarders. OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND suite. Calling it from applications does however mean using new API calls; since the traditional resolver API is oblivious to DNSSEC. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 What PROGRAM are they watching? pgpJ6qsHvpwVd.pgp Description: PGP signature
Re: DNSSEC and SSL
On Sun, Aug 22, 2010 at 09:57:27PM +0200, Mans Nilsson wrote: Subject: Re: DNSSEC and SSL Date: Sun, Aug 22, 2010 at 09:11:43AM -0400 Quoting ML (m...@kenweb.org): On 8/22/2010 2:38 AM, Mikael Abrahamsson wrote: No, because DNSSEC isn't secured all the way from the DNS server to the application, only to the resolver. Both systems have problems, I'd imagine the best security is when they work together. Is a DNSSEC capable stub resolver not in the cards? The best option today is to run a full-service resolver on the host; which is a tad heavy for most desktops, not to speak about the cache misses that would cause root server system load. The latter of course can be avoided by setting forwarders. that assertion is unverified. i suspect that cache misses would not overload the system as it currently stands. (modulo a ramp up of DNSSEC capable stubs/full service IMRs). OTOH: A thicker stub resolver does indeed exist; lwresd in the BIND suite. Calling it from applications does however mean using new API calls; since the traditional resolver API is oblivious to DNSSEC. perhaps a review of lwresd/unbound would be worth a gander. --bill -- Mens Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 What PROGRAM are they watching?
Re: DNSSEC and SSL
On Sun, Aug 22, 2010 at 09:11:43AM -0400, ML wrote: On 8/22/2010 2:38 AM, Mikael Abrahamsson wrote: No, because DNSSEC isn't secured all the way from the DNS server to the application, only to the resolver. Both systems have problems, I'd imagine the best security is when they work together. Is a DNSSEC capable stub resolver not in the cards? yes it is. unbound was originally designed for that very niche. --bill
DNSSEC and SSL
Would a future with a ubiquitous DNSSEC deployment eliminate the market for commercial CAs? Would functioning DNSSEC + self signed certs be more secure/trustworthy than our current system of trusted CAs chosen by OS/browser developers?
Re: DNSSEC and SSL
On Sat, Aug 21, 2010 at 18:00, ML m...@kenweb.org wrote: Would a future with a ubiquitous DNSSEC deployment eliminate the market for commercial CAs? Would functioning DNSSEC + self signed certs be more secure/trustworthy than our current system of trusted CAs chosen by OS/browser developers? See Dan Kaminski's presentation at this years BlackHat Defcon for a proposal, and the prototype glue that provides a proof of concept. http://www.recursion.com/talks.html (I seem to recall the X.509/CA part starts about 3/4 of the way through the deck). That said, Dan does not suggest that everything a CA does is obsolete, there will still be a market for making sure that BankOfAmerica.com really is the bank you want to do business with (branding).
