Re: [Discuss] free SSL certs from the EFF
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Bill Horne On 12/7/2014 2:57 PM, Richard Pieri wrote: A few days ago Ed posited that we'll get there someday. Truth is, we've been there for some time. With DNSCurve and DNSCrypt we have exactly the kinds of encrypted DNS service that he called for. Why haven't they been widely adopted? I figure it's a Paul Vixie, yes! DJB, no! issue. More likely, an Oh my aching back! The IT crew wants more money again! issue. :-( There's no reason the IT people should need any money to do DNSSEC. It's just like https; no reason not to do it. Takes a few minutes to set up - and I'm not sure if you have to pay somebody for a key or something. It's also relatively new. Based on the other thread DNSSEC, it sounds like RFC 3597 since 2003 is necessary in order for DNSSEC not to be broken by old relays. I wish I could say I didn't know of any 11-year old relays in the field. Effectively, it all began in 2010 - so it's only the last 4 years that there's any hope of this being useful to end clients. Right now, godaddy charges a premium to support DNSSEC. Namecheap doesn't yet support it. Route53 doesn't support it. So why isn't it more popular yet? That question is pretty solidly answered now... Not to mention, endpoints don't generally support it yet. Based on everything I've read and written in the last couple of weeks on this, I think the world is ready to start seeing DNSSEC deployed and supported more. So please continue making noise and demanding it from your registrars and dns providers! (Both your registrar and your dns provider must support it.) ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On Mon, Dec 08, 2014 at 11:40:14AM +, Edward Ned Harvey (blu) wrote: I wish I could say I didn't know of any 11-year old relays in the field. If you have this, you almost certainly have far worse problems than DNSSEC working or not. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/5/2014 10:59 AM, Richard Pieri wrote: On 12/4/2014 11:42 PM, John Abreau wrote: On the other hand, if you accept the bad guy's poisoned DNS data: Long story short: Joe is screwed either way. Or I am depending on who takes the fall. If someone is reprimanded or fired or even killed because a security system is working as designed? That's a terrible system. No offense, but Joe might not have a choice: the hotel wants him to click on a user agreement, and so the box they've bought will intercept every DNS call and redirect it to their consent page before allowing Joe to connect to the net. I can't say if that's going to happen at Starbucks or [whereever], but it might. I don't know if that agreement gives the hotel/mega-corp permission to monitor emails as well as collect the click list, but MITM attacks require Joe to agree to accept an invalid certificate at some point, and it's possible to disable his ability to do so. End-to-end email encryption would prevent any monitoring of the email, and a corporate VPN would obviate the problem altogether. Some companies avoid the issue altogether by entering fixed IP addresses in VPN scripts - the only matching key is/should be at the VPN box/server, so there's no loss of flexibility, and IP addresses are cheap enough if the company wants to provide a backup. In any case, Joe's logs will verify that he made the attempt. Of course, theory and practice often differ in security, and we've all met mister JustDoItOrYou'reFired who likes to tell us to break the rules, but that isn't a technical problem. A well designed security suite will give Joe the option of sending his reports by encrypting them first with a few key clicks. FWIW. YMMV. Bill Horne -- E. William Horne 339-364-8487 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/7/2014 2:02 PM, Bill Horne wrote: Of course, theory and practice often differ in security, and we've all met mister JustDoItOrYou'reFired who likes to tell us to break the rules, but that isn't a technical problem. A well designed security suite will give Joe the option of sending his reports by encrypting them first with a few key clicks. Therein lies what I consider to be the most egregious flaw in DNSSEC from an end user's perspective: no choice. Joe has no choice but to use it and accept that he can't work at all when it comes under attack assuming DNSSEC is being enforced which is contrary to DNSSEC mandatory requirements but that's a tangent. I'm not saying that DNSSEC is flawed (well, I think it is, but that's another tangent). I'm saying that DNSSEC is not an end user's tool and that you're going to experience serious problems if you try to use it as one. In my opinion, a well-designed -- that is, well-designed for end users -- secure DNS system should provide reliable, authenticated answers despite attacks made against the system. DNSSEC does not do this. It doesn't try because, like I wrote way back at the start of all this, it's a last hop issue that lies outside of the scope of DNSSEC. A few days ago Ed posited that we'll get there someday. Truth is, we've been there for some time. With DNSCurve and DNSCrypt we have exactly the kinds of encrypted DNS service that he called for. Why haven't they been widely adopted? I figure it's a Paul Vixie, yes! DJB, no! issue. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/7/2014 2:57 PM, Richard Pieri wrote: A few days ago Ed posited that we'll get there someday. Truth is, we've been there for some time. With DNSCurve and DNSCrypt we have exactly the kinds of encrypted DNS service that he called for. Why haven't they been widely adopted? I figure it's a Paul Vixie, yes! DJB, no! issue. More likely, an Oh my aching back! The IT crew wants more money again! issue. :-( In the past, I've worked with and suffered under some managers whose view of security was that it didn't matter as long as _/they/_ couldn't be blamed for a failure. I'm sorry to say that they were usually correct. Bill -- E. William Horne 339-364-8487 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/04/2014 11:42 PM, John Abreau wrote: On Thu, Dec 4, 2014 at 1:00 PM, Richard Pieri richard.pi...@gmail.com wrote: On 12/4/2014 12:15 PM, Joe Polcari wrote: To me, that's a good reason for things to stop working. For certain values of good I suppose. Good news: your email wasn't hacked. Bad news: you're fired for failing to submit your reports on time. On the other hand, if you accept the bad guy's poisoned DNS data: Good news: you feel secure because you sent out your reports on time. Bad news: They were sent to the bad guy's mail server, so you're still fired for failing to submit your reports on time to your employer's mail server. Worse news: the DNS misdirection enabled a MITM attack that captured your credentials, and your credentials are used to hack into the company and cause a data breach. Then they have a real reason to fire you (has anyone actually been fired for not submitting reports on time?). I know the example wasn't meant to be taken literally, but the point is that typically it is far worse to allow your credentials to be compromised than it is to have delays in doing your job. Obviously the degree to which this is true varies from job to job, but the point remains that if you're ignoring authenticity with respect to what machines you are talking to, you can't be sure you are actually doing your job. So that is why DoS should always be the preferred failure mode when authenticity can't be verified. Matt ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
John Hall johnhall...@gmail.com writes: I had not heard of DANE (DNS based authentication of named entities). I found found rfc-6698 in a search .. not sure if anyone mentioned it yet. https://datatracker.ietf.org/doc/rfc6698/ I didn't mention DANE, but it is indeed one of the additional things I was going to mention. Along with TLSA. Leveraging DNSSEC one can provide authoritative bindings to other infrastructure and let clients know that they should be using TLS and which certs or CAs they should be using for it. -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 warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/4/2014 11:42 PM, John Abreau wrote: On the other hand, if you accept the bad guy's poisoned DNS data: Long story short: Joe is screwed either way. Or I am depending on who takes the fall. If someone is reprimanded or fired or even killed because a security system is working as designed? That's a terrible system. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On Fri, Dec 05, 2014 at 10:59:27AM -0500, Richard Pieri wrote: On 12/4/2014 11:42 PM, John Abreau wrote: On the other hand, if you accept the bad guy's poisoned DNS data: Long story short: Joe is screwed either way. Or I am depending on who takes the fall. If someone is reprimanded or fired or even killed because a security system is working as designed? That's a terrible system. No, that's a terrible manager. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Richard Pieri richard.pi...@gmail.com writes: On 12/3/2014 10:52 AM, Derek Atkins wrote: Actually, it was designed to protect against that. I sat in the IETF meetings where that was explicitly discussed. If an intermediary strips the DNSSEC records out then a resolver expecting DNSSEC will force a validation error. Which results in a denial of service for clients if DNSSEC is enforced. That's not protecting users; that's dumping them into black holes. Some say DoS, some say protected. If someone is trying to poison my DNS Cache I'd rather ignore them and blackhole than accept their attack and go to the wrong place. Besides, DNS allows me to go ask multiple sources for information. If I'm expecting a DNSSEC response and don't get it, I know that I need to go ask somewhere else. That's a FEATURE, not a bug. If I'm sitting in a hotel room behind a broken middleware box then I know, for sure, that the middleware is breaking me; I can turn off validation at that point (or decide never to stay at that hotel again -- or both!) Well, it sort of does, but it's not easy. But this is why they use ZSKs. The Root Zone KSK is mightily protected. So, too, allegedly, were the keys at DigiNotar. I have no idea what the DigiNotar security practices were. I *DO* know exactly what ICANN's practices are (and I even know at least one key-holder personally). -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 warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Richard Pieri richard.pi...@gmail.com writes: On 12/3/2014 4:08 PM, Matthew Gillen wrote: The second issue was that DNSSEC has a built-in way to MITM it, where an intermediary could strip out the info that indicated that a given domain had DNSSEC records (the claim was this was forced for compatibility). I think Derek refuted that, and I have to believe that what Richard claimed would defeat the whole purpose of DNSSEC. Correct. Either you enforce DNSSEC and drop yourself into a black hole when a script kiddie plays games with UDP packets or you configure your security aware resolver to treat unsigned and stripped DNS answers as valid anyway. The former is not protection; it's locking your computer in a safe filled with concrete and dumping it down the Marianas Trench. The latter, well, what's the point of DNSSEC if you're going to ignore it? A script kiddie is only going to be able to send forged additional responses, but not necessarily block the *real* responses or modify them enroute. So yes, I still want to ignore the unsigned responses in this scenario because the real responses *WILL* eventually get through. Besides, with random ports and random TIDs a script kiddie has much less of a chance of getting through. Yes, there are broken middleware boxes (most often in hotels) that can intercept and manipulate DNS. Personally I'd like to know when that's happening to me, and DNSSEC can absolutely tell me that. Then I can make a conscious choice of what to do with that information (including opening myself up to attack). Eventually those middleboxes will go away -- they've already been going away slowly. Either way, DNSSEC really is pointless for end users. Bzzt. You keep coming back to pointless for end users mantra when in reality it was absolutely designed to help end users. You're welcome to continue to think that to yourself (there's no such thing as a thought police, yet) but please stop spreading your FUD around as fact. It's not helping anyone. Many people have already pointed out many ways that it helps end users. I can list many more if you wish, but if you're not going to listen it's not worth my time, I have real security work to get back to. -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 warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/4/2014 10:35 AM, Derek Atkins wrote: If I'm sitting in a hotel room behind a broken middleware box then I know, for sure, that the middleware is breaking me; I can turn off validation at that point So, DNSSEC validation is something that needs to be turned off in order to use DNS in the kinds of environments where DNSSEC validation would be most desirable. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On Thu, Dec 04, 2014 at 11:01:49AM -0500, Richard Pieri wrote: On 12/4/2014 10:35 AM, Derek Atkins wrote: If I'm sitting in a hotel room behind a broken middleware box then I know, for sure, that the middleware is breaking me; I can turn off validation at that point So, DNSSEC validation is something that needs to be turned off in order to use DNS in the kinds of environments where DNSSEC validation would be most desirable. Come on man, this statement is very obviously false. It only needs to be turned off in very specific, very limited circumstances, namely when you MUST do whatever you're doing RIGHT NOW, AND you can't find a reasonable alternative, like doing your work from a starbucks (or other hotspot or whatever) across the street, AND the consequences of not doing it RIGHT NOW are worse than the risk of getting hacked... ..which is like, never. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Derek already addressed that argument in the message you replied to, but you ignored that part of the message. As Derek said, if you're not going to listen, it's not worth his time. On Thu, Dec 4, 2014 at 11:01 AM, Richard Pieri richard.pi...@gmail.com wrote: On 12/4/2014 10:35 AM, Derek Atkins wrote: If I'm sitting in a hotel room behind a broken middleware box then I know, for sure, that the middleware is breaking me; I can turn off validation at that point So, DNSSEC validation is something that needs to be turned off in order to use DNS in the kinds of environments where DNSSEC validation would be most desirable. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss -- John Abreau / Executive Director, Boston Linux Unix Email: abre...@gmail.com / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6 PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23 C2D0 E885 E17C 9200 63C6 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/4/2014 11:36 AM, Derek Martin wrote: Come on man, this statement is very obviously false. It only needs to be turned off in very specific, very limited circumstances, namely when you MUST do whatever you're doing RIGHT NOW, AND you can't find a reasonable alternative, like doing your work from a starbucks (or other hotspot or whatever) across the street, AND the consequences of not doing it RIGHT NOW are worse than the risk of getting hacked... ..which is like, never. Sure, I get that. Joe Average, on the other hand, probably doesn't care about that. He cares that his month-end report is due in 5 minutes and his mail hangs every time he presses send. DNSSEC validation may be protecting him from getting his mail hacked but it's doing so by preventing him from getting any of his work done. I call that a case of the cure being worse than the illness. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
To me, that's a good reason for things to stop working. -Original Message- From: discuss-bounces+joe=polcari@blu.org [mailto:discuss-bounces+joe=polcari@blu.org] On Behalf Of Richard Pieri Sent: Thursday, December 04, 2014 12:00 PM To: discuss@blu.org Subject: Re: [Discuss] free SSL certs from the EFF On 12/4/2014 11:36 AM, Derek Martin wrote: Come on man, this statement is very obviously false. It only needs to be turned off in very specific, very limited circumstances, namely when you MUST do whatever you're doing RIGHT NOW, AND you can't find a reasonable alternative, like doing your work from a starbucks (or other hotspot or whatever) across the street, AND the consequences of not doing it RIGHT NOW are worse than the risk of getting hacked... ..which is like, never. Sure, I get that. Joe Average, on the other hand, probably doesn't care about that. He cares that his month-end report is due in 5 minutes and his mail hangs every time he presses send. DNSSEC validation may be protecting him from getting his mail hacked but it's doing so by preventing him from getting any of his work done. I call that a case of the cure being worse than the illness. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
I had not heard of DANE (DNS based authentication of named entities). I found found rfc-6698 in a search .. not sure if anyone mentioned it yet. https://datatracker.ietf.org/doc/rfc6698/ On Thu, Dec 4, 2014 at 12:15 PM, Joe Polcari j...@polcari.com wrote: To me, that's a good reason for things to stop working. -Original Message- From: discuss-bounces+joe=polcari@blu.org [mailto:discuss-bounces+joe=polcari@blu.org] On Behalf Of Richard Pieri Sent: Thursday, December 04, 2014 12:00 PM To: discuss@blu.org Subject: Re: [Discuss] free SSL certs from the EFF On 12/4/2014 11:36 AM, Derek Martin wrote: Come on man, this statement is very obviously false. It only needs to be turned off in very specific, very limited circumstances, namely when you MUST do whatever you're doing RIGHT NOW, AND you can't find a reasonable alternative, like doing your work from a starbucks (or other hotspot or whatever) across the street, AND the consequences of not doing it RIGHT NOW are worse than the risk of getting hacked... ..which is like, never. Sure, I get that. Joe Average, on the other hand, probably doesn't care about that. He cares that his month-end report is due in 5 minutes and his mail hangs every time he presses send. DNSSEC validation may be protecting him from getting his mail hacked but it's doing so by preventing him from getting any of his work done. I call that a case of the cure being worse than the illness. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/4/2014 12:15 PM, Joe Polcari wrote: To me, that's a good reason for things to stop working. For certain values of good I suppose. Good news: your email wasn't hacked. Bad news: you're fired for failing to submit your reports on time. On 12/4/2014 12:36 PM, John Hall wrote: I had not heard of DANE (DNS based authentication of named entities). I found found rfc-6698 in a search .. not sure if anyone mentioned it yet. https://datatracker.ietf.org/doc/rfc6698/ I think Firefox 34 takes note of it. It's a digital signature from a host's TLS key added to that host's DNS records which you can use instead of following the X.509 trust chain to verify the certificate. Which is to say, it shifts trust away from certificate authorities like VeriSign to top-level DNS registrars like VeriSign. And it has the same failure modes and lack of failure mitigation that DNSSEC has. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
More like Bad news: you have to find somewhere else to connect to the net if you're going to get fired for not doing so. -Original Message- From: discuss-bounces+joe=polcari@blu.org [mailto:discuss-bounces+joe=polcari@blu.org] On Behalf Of Richard Pieri Sent: Thursday, December 04, 2014 1:01 PM To: discuss@blu.org Subject: Re: [Discuss] free SSL certs from the EFF On 12/4/2014 12:15 PM, Joe Polcari wrote: To me, that's a good reason for things to stop working. For certain values of good I suppose. Good news: your email wasn't hacked. Bad news: you're fired for failing to submit your reports on time. On 12/4/2014 12:36 PM, John Hall wrote: I had not heard of DANE (DNS based authentication of named entities). I found found rfc-6698 in a search .. not sure if anyone mentioned it yet. https://datatracker.ietf.org/doc/rfc6698/ I think Firefox 34 takes note of it. It's a digital signature from a host's TLS key added to that host's DNS records which you can use instead of following the X.509 trust chain to verify the certificate. Which is to say, it shifts trust away from certificate authorities like VeriSign to top-level DNS registrars like VeriSign. And it has the same failure modes and lack of failure mitigation that DNSSEC has. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/4/2014 1:25 PM, Joe Polcari wrote: More like Bad news: you have to find somewhere else to connect to the net if you're going to get fired for not doing so. I don't know where you've been but saying that to anyone wouldn't fly anywhere that I've worked. I'd be the one looking for a new job, not Joe who was inconvenienced by the security system. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Derek Atkins Richard Pieri richard.pi...@gmail.com writes: Which results in a denial of service for clients if DNSSEC is enforced. That's not protecting users; that's dumping them into black holes. Some say DoS, some say protected. If someone is trying to poison my DNS Cache I'd rather ignore them and blackhole than accept their attack and go to the wrong place. Besides, DNS allows me to go ask multiple sources for information. +1 The correct behavior is to refuse to use corrupted data, and probably retry the query to get good data. If an intermediary router wants to cause a DoS, then stripping security would be the stupidest way possible to execute such an attack - rather than just dropping the packet. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On Thu, Dec 4, 2014 at 1:00 PM, Richard Pieri richard.pi...@gmail.com wrote: On 12/4/2014 12:15 PM, Joe Polcari wrote: To me, that's a good reason for things to stop working. For certain values of good I suppose. Good news: your email wasn't hacked. Bad news: you're fired for failing to submit your reports on time. On the other hand, if you accept the bad guy's poisoned DNS data: Good news: you feel secure because you sent out your reports on time. Bad news: They were sent to the bad guy's mail server, so you're still fired for failing to submit your reports on time to your employer's mail server. -- John Abreau / Executive Director, Boston Linux Unix Email j...@blu.org / WWW http://www.abreau.net / PGP-Key-ID 0x920063C6 PGP-Key-Fingerprint A5AD 6BE1 FEFE 8E4F 5C23 C2D0 E885 E17C 9200 63C6 ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Edward Ned Harvey (blu) b...@nedharvey.com writes: From: Derek Atkins [mailto:warl...@mit.edu] And you've already violated rule #1: You must trust your resolver. That's the point we've been talking about. I forget who said in this thread, that DNSSEC only provides security up to the last hop, not including the endpoint. And I say that's not (necessarily) true! It is unavoidable that people will travel; they will connect to the internet in coffee shops and hotels. It is not reasonable or realistic to expect them to trust their DNS resolver implicitly. You cannot trust the resolver, unless you are your own resolver, or the resolver relays security information to you which you're able to validate for yourself. It is unscalable for everybody to be their own Okay, I think I see the problem here. You are conflating multiple different DNS services: * resolver * recursive resolver * nameserver * caching nameserver These are, technically, *different* DNS services. Yes, historically they are often combined into a single process (e.g. BIND's named), or split into a small stub (e.g. libc's libresolv) and a (possibly caching) nameserver. But there is nothing that requires them to be co-located or even co-implemented. Indeed, there is nothing that says that the resolver must trust the nameserver (caching or otherwise). There is absolutely nothing preventing libresolv from performing DNSsec without running named or some other local caching nameserver. I.e., there is absolutely nothing preventing an end system from performing DNSsec without trusting the (caching) nameserver it uses. This includes not trusting the DNS nameserver provided by DHCP. All you need is a local resolver that implements DNSsec checks and uses the provided DNS nameserver(s) for lookup and caching of RRsets. resolver - breaking the distributed nature of DNS. So really, the only scalable solution is to provide security information to the endpoints. Unfortunately, it's also unrealistic to expect all the dumb linksys routers and comcast internet connections of the world to be upgraded in any timely manner to support relaying security information to endpoints. Yes it's possible for smart endpoints to query DNS providers as dictated by DHCP, and become their own secure resolvers if and only if the dumb DNS server failed to relay security information - but this starts out at the point of being currently unscalable. Actually, most dumb routers like that *WILL* forward DNSsec RRs just fine; it's really the obnoxious middleboxes (e.g. in hotels) that break it. We'll probably get there someday, just obviously not right now. -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 warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Richard, Richard Pieri richard.pi...@gmail.com writes: Derek, According to the DNSSEC specs, if there is no RRSIG record in the lookup answer then a properly behaved resolver will treat it as unsigned. Backwards compatibility with so-called insecure DNS is an explicit requirement of DNSSEC. So, what happens when a malicious actor inserts filters at an intermediary resolver or router that strip RRSIG records from DNS answers? Which RFC states this? I'm quite familiar with 4033 et al, (and even moreso with their predecessors, 2535 et al). Granted, I did stop following the specs somewhere around the NSEC3 discussions, but it was certainly the case that a DNSSEC-aware resolver would always know whether to expect signed data. I.e., if there is no DS record for the zone then a DNSSEC-aware resolver knows it's not a signed zone. If there IS a DS record for the zone and then a query does not return an RRSIG or NSEC then there's a problem (verification failure). Obviously a non-DNSSEC-aware resolver doesn't care. DNSSEC was never intended to protect you against that. It was designed to protect high-level caches -- root zones, ISP's, big data players, private networks, and the like -- from cache poisoning. That's it. Any benefits that might trickle down to you are incidental. Actually, it was designed to protect against that. I sat in the IETF meetings where that was explicitly discussed. If an intermediary strips the DNSSEC records out then a resolver expecting DNSSEC will force a validation error. Never mind that DNSSEC has no means of rolling over the root KSKs. If a root is compromised then the whole domain hierarchy is compromised and there currently is no way to fix that other than disabling DNSSEC for the hierarchy or accepting loss of service for everything under that root. Well, it sort of does, but it's not easy. But this is why they use ZSKs. The Root Zone KSK is mightily protected. -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 warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/3/2014 10:52 AM, Derek Atkins wrote: Actually, it was designed to protect against that. I sat in the IETF meetings where that was explicitly discussed. If an intermediary strips the DNSSEC records out then a resolver expecting DNSSEC will force a validation error. Which results in a denial of service for clients if DNSSEC is enforced. That's not protecting users; that's dumping them into black holes. Well, it sort of does, but it's not easy. But this is why they use ZSKs. The Root Zone KSK is mightily protected. So, too, allegedly, were the keys at DigiNotar. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/03/2014 11:20 AM, Richard Pieri wrote: On 12/3/2014 10:52 AM, Derek Atkins wrote: Actually, it was designed to protect against that. I sat in the IETF meetings where that was explicitly discussed. If an intermediary strips the DNSSEC records out then a resolver expecting DNSSEC will force a validation error. Which results in a denial of service for clients if DNSSEC is enforced. That's not protecting users; that's dumping them into black holes. I think that comment misses the point. DoS is typically an acceptable response to man-in-the-middle attacks; it is worse to make me think I have a secure connection to GMail than it is to just refuse connection entirely. Likewise, I would rather have DNS not work at all than have it hijacked (because the hijacker is almost certainly going to redirect me away from where I'm wanting to go anyway). I started the discussion about DNSSEC because I was saying you could use that, along with some special TXT entry in your domain's zone to have a verifiable way to identify who an /appropriate/ CA for a given domain is (and thereby not have to throw away all of the X509 system). There are two potential flaws, one that I identified, and one that R. Pieri brought up (which I think but I'm not sure that Derek refuted). The first flaw is DNSSEC to end clients. There are two solutions to this: 1) run a caching name server locally and only use that (easy) 2) have application specific hooks to do the appropriate lookups (for instance, this firefox extension, while out of maintenance, seemed to do sort of what I wanted: https://addons.mozilla.org/en-US/firefox/addon/extended-dnssec-validator/ ; also worth noting is that this plugin seemed to require some auxillary software installed, but that may have been just because DNSSEC stuff wasn't built-in to libdns at the time) The second issue was that DNSSEC has a built-in way to MITM it, where an intermediary could strip out the info that indicated that a given domain had DNSSEC records (the claim was this was forced for compatibility). I think Derek refuted that, and I have to believe that what Richard claimed would defeat the whole purpose of DNSSEC. Matt ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/03/2014 04:08 PM, Matthew Gillen wrote: 2) have application specific hooks to do the appropriate lookups (for instance, this firefox extension, while out of maintenance, seemed to do sort of what I wanted: https://addons.mozilla.org/en-US/firefox/addon/extended-dnssec-validator/ ; also worth noting is that this plugin seemed to require some auxillary software installed, but that may have been just because DNSSEC stuff wasn't built-in to libdns at the time) This was the link I meant to send: http://www.nlnetlabs.nl/projects/drill/drill_extension.html Still out of maintenance (i.e. doesn't work with modern firefox). ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/3/2014 4:08 PM, Matthew Gillen wrote: The first flaw is DNSSEC to end clients. There are two solutions to this: That's not a flaw in DNSSEC. It's an expectation that is outside of the scope of DNSSEC. The second issue was that DNSSEC has a built-in way to MITM it, where an intermediary could strip out the info that indicated that a given domain had DNSSEC records (the claim was this was forced for compatibility). I think Derek refuted that, and I have to believe that what Richard claimed would defeat the whole purpose of DNSSEC. Correct. Either you enforce DNSSEC and drop yourself into a black hole when a script kiddie plays games with UDP packets or you configure your security aware resolver to treat unsigned and stripped DNS answers as valid anyway. The former is not protection; it's locking your computer in a safe filled with concrete and dumping it down the Marianas Trench. The latter, well, what's the point of DNSSEC if you're going to ignore it? Either way, DNSSEC really is pointless for end users. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Bill Bogstad As far as I can tell, the problem with DNSSEC isn't with the underlying protocols/processes; it is the chicken and egg deployment problem. As Ed Harvey discusses in a different message, not all zones are signed. This causes lots of problems. There are lots of possible ways to solve the problem. A really obvious one would be to create a secure DNS service, which is functionally equivalent to regular DNS, except that all query responses must be signed, and that includes signing the NX_DOMAIN response, which would then give the client the ability to verifiably determine whether or not a secure response should have existed for a particular query. That is, unless a malicious DNS root server provides maliciously crafted responses. Another way would be to mandate that all DNS must be secure by some deadline. By brute force and legal intervention, forcibly obsolete insecure DNS. Another solution would be to simply require all non-DNS communications use SSL/TLS. For example, you don't have to worry about hacked up DNS, if you're using https://blahblah. Because if the DNS response is invalid, your https protocol is going to detect an invalid server cert. And there are some other possibilities as well. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/2/2014 7:59 AM, Bill Bogstad wrote: You know what, I hate security. Never mind... Now you understand why I've been going on about tossing X.509 PKI out with the rest of the garbage. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Edward Ned Harvey (blu) b...@nedharvey.com writes: From: Derek Atkins [mailto:warl...@mit.edu] Edward Ned Harvey (blu) b...@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 warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Richard Pieri richard.pi...@gmail.com writes: On 12/1/2014 1:42 PM, Derek Atkins wrote: I think it depends very much on your definition of Secure. You are correct that DNSsec does not provide any confidentiality services. However it does indeed protect the data integrity from interloping intermediaries and provide authenticated DNS Data. No, it doesn't. It only prevents cache poisoning when DNSSEC is enforced on your resolvers. If you do not enforce DNSSEC on your resolvers then your resolvers will accept any unsigned RRs including those that have had the RRSIG records stripped by malicious intermediaries. Well, duh.. And if you don't check the validity of your TLS certs then you can be MITM'ed too. Of course DNSsec requires a DNSsec-aware resolver; it cannot protect someone who doesn't want to be protected. You can put a lock on your front door but it doesn't do any good if you don't actually lock it!! But you're looking at the wrong issue; DNSsec-capable resolvers exist and have existed for years. In fact I would bet your current Linux host has a DNSsec-capable resolver. It might not be turned on by default, but they are definitely out there. -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 warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
From: Derek Atkins [mailto:warl...@mit.edu] 1) the root zone is signed with a known key, and 2) most of the TLDs are signed (in particular .com is definitely signed) When you first connected to the network, DHCP told you to use some DNS server. When firefox, or anything else in your OS queries that DNS server to resolve some name, you do not receive the response from the TLD. You just get a response to your query, and not all the subsequent queries that were necessary in order to resolve your query. Better yet, your OS itself caches the response, so once again, FF makes some query, and doesn't get a signed response. This may be a shortcoming of implementation, but if so, that doesn't make it any less relevant, because neither your OS name caching daemon, nor the upstream caching server are doing the right thing and the world is a *long* way off from having all the dumb Linksys routers upgraded to the point of DNS security being effectively universally deployed. These are yet another two possible solutions to the problem - Don't use caching DNS servers; every client must query the TLD directly and do all its own resolving. Or, globally adopt a new standard where the caching DNS server gives your client not only the response you requested, but the entire signed chain... But these solutions very definitely do not exist as globally universally standard deployed solutions today. Today, FF queries for www.google.com, and the query is handled by whatever DNS server was doled out to the client via DHCP, and the DNS server response is only going to be the final result of the query, which could have been mangled in transit. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Edward Ned Harvey (blu) b...@nedharvey.com writes: From: Derek Atkins [mailto:warl...@mit.edu] 1) the root zone is signed with a known key, and 2) most of the TLDs are signed (in particular .com is definitely signed) When you first connected to the network, DHCP told you to use some DNS server. When firefox, or anything else in your OS queries that DNS server to resolve some name, you do not receive the response from the TLD. You just get a response to your query, and not all the subsequent queries that were necessary in order to resolve your query. Better yet, your OS itself caches the response, so once again, FF makes some query, and doesn't get a signed response. And you've already violated rule #1: You must trust your resolver. In general this implies running your own DNSsec-aware recursive resolver on your client (or on some other trusted host). It does mean that, in general, you should not blindly trust the DNS servers provided by DHCP. In my experience you fix this by running your own local caching name server on your laptop. That service can go off to the DNS server provided by DHCP, or it can go out to the servers on the net. Part of the design of DNSsec is that it can be proxied. This may be a shortcoming of implementation, but if so, that doesn't make it any less relevant, because neither your OS name caching daemon, nor the upstream caching server are doing the right thing and the world is a *long* way off from having all the dumb Linksys routers upgraded to the point of DNS security being effectively universally deployed. I'm not sure what you mean by your OS name caching daemon ... are [not] doing the right thing? These are yet another two possible solutions to the problem - Don't use caching DNS servers; every client must query the TLD directly and do all its own resolving. Or, globally adopt a new standard where the caching DNS server gives your client not only the response you requested, but the entire signed chain... But these solutions very definitely do not exist as globally universally standard deployed solutions today. Today, FF queries for www.google.com, and the query is handled by whatever DNS server was doled out to the client via DHCP, and the DNS server response is only going to be the final result of the query, which could have been mangled in transit. There are two other ways to handle this: 1) Run a local caching nameserver on your system, or 2) Run a DNSsec-aware resolver on your system which uses the local DNS proxy as its cache. The only real difference between my #1 and #2 is where the cache is stored. The resolver still needs to query for everything up to the root, which it can receive from the cache. The cache doesn't need to be trusted if you reverify every time, so what you get from #1 is the ability to trust the cached data. I'll note that Firefox could implement #2. -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 warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Derek, According to the DNSSEC specs, if there is no RRSIG record in the lookup answer then a properly behaved resolver will treat it as unsigned. Backwards compatibility with so-called insecure DNS is an explicit requirement of DNSSEC. So, what happens when a malicious actor inserts filters at an intermediary resolver or router that strip RRSIG records from DNS answers? DNSSEC was never intended to protect you against that. It was designed to protect high-level caches -- root zones, ISP's, big data players, private networks, and the like -- from cache poisoning. That's it. Any benefits that might trickle down to you are incidental. Never mind that DNSSEC has no means of rolling over the root KSKs. If a root is compromised then the whole domain hierarchy is compromised and there currently is no way to fix that other than disabling DNSSEC for the hierarchy or accepting loss of service for everything under that root. Aside: It's DNSSEC. It is not DNSsec, nor DNS-SEC, nor dns-sec, nor DNS-sec, nor is it any variant that is not DNSSEC. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
From: Derek Atkins [mailto:warl...@mit.edu] And you've already violated rule #1: You must trust your resolver. That's the point we've been talking about. I forget who said in this thread, that DNSSEC only provides security up to the last hop, not including the endpoint. It is unavoidable that people will travel; they will connect to the internet in coffee shops and hotels. It is not reasonable or realistic to expect them to trust their DNS resolver implicitly. You cannot trust the resolver, unless you are your own resolver, or the resolver relays security information to you which you're able to validate for yourself. It is unscalable for everybody to be their own resolver - breaking the distributed nature of DNS. So really, the only scalable solution is to provide security information to the endpoints. Unfortunately, it's also unrealistic to expect all the dumb linksys routers and comcast internet connections of the world to be upgraded in any timely manner to support relaying security information to endpoints. Yes it's possible for smart endpoints to query DNS providers as dictated by DHCP, and become their own secure resolvers if and only if the dumb DNS server failed to relay security information - but this starts out at the point o f being currently unscalable. We'll probably get there someday, just obviously not right now. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Edward Ned Harvey (blu) b...@nedharvey.com writes: From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Matthew Gillen This is not without new attack vectors: you can only trust DNS responses as far as DNS-SEC goes, which unfortunately ends one-hop before end-systems (unless you run your own DNS server and force everything on your home network to use that; which I do but don't know how common that is). 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. know *this* response is authentic for your domain. In theory, you could start using x509 certs to sign your DNS but then there's the chicken and egg problem. I don't see any way to make DNS actually secure, except to completely scrap all of DNS in favor of a new secure DNS. Which could literally be regular DNS with TLS on it, but the point is, as long as you try to make clients compatible with *both* the secure and insecure DNS, then attacking the secure DNS is trivial. You just block secure DNS and cause the client to fallback to insecure DNS, or you just substitute whatever malicious DNS response you want, knowing that the client accepts insecure DNS responses. There is no defense. I think it depends very much on your definition of Secure. You are correct that DNSsec does not provide any confidentiality services. However it does indeed protect the data integrity from interloping intermediaries and provide authenticated DNS Data. Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss -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 warl...@mit.eduPGP key available ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
From: Derek Atkins [mailto:warl...@mit.edu] Edward Ned Harvey (blu) b...@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 (an d 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. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 12/1/2014 1:42 PM, Derek Atkins wrote: I think it depends very much on your definition of Secure. You are correct that DNSsec does not provide any confidentiality services. However it does indeed protect the data integrity from interloping intermediaries and provide authenticated DNS Data. No, it doesn't. It only prevents cache poisoning when DNSSEC is enforced on your resolvers. If you do not enforce DNSSEC on your resolvers then your resolvers will accept any unsigned RRs including those that have had the RRSIG records stripped by malicious intermediaries. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 11/19/14 11:34 AM, Richard Pieri wrote: Each automated step in a process is an avenue for bad actors to abuse the process. A friend of mine used to remind me by defining a system you define the methods for abuse -- MCT Michael C Tiernan. http://www.linkedin.com/in/mtiernan Non Impediti Ratione Cogatationis Women and cats will do as they please, and men and dogs should relax and get used to the idea. -Robert A. Heinlein ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Matthew Gillen This is not without new attack vectors: you can only trust DNS responses as far as DNS-SEC goes, which unfortunately ends one-hop before end-systems (unless you run your own DNS server and force everything on your home network to use that; which I do but don't know how common that is). 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 know *this* response is authentic for your domain. In theory, you could start using x509 certs to sign your DNS but then there's the chicken and egg problem. I don't see any way to make DNS actually secure, except to completely scrap all of DNS in favor of a new secure DNS. Which could literally be regular DNS with TLS on it, but the point is, as long as you try to make clients compatible with *both* the secure and insecure DNS, then attacking the secure DNS is trivial. You just block secure DNS and cause the client to fallback to insecure DNS, or you just substitute whatever malicious DNS response you want, knowing that the client accepts insecure DNS responses. There is no defense. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 11/25/2014 06:28 AM, Edward Ned Harvey (blu) wrote: From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss- bounces+blu=nedharvey@blu.org] On Behalf Of Matthew Gillen This is not without new attack vectors: you can only trust DNS responses as far as DNS-SEC goes, which unfortunately ends one-hop before end-systems (unless you run your own DNS server and force everything on your home network to use that; which I do but don't know how common that is). 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 - That's what I meant when I said it ends one hop before end-systems. if your client queries DNS, there's no way for your client to know *this* response is authentic for your domain. I won't put the quoted part below in my own words: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions By checking the digital signature, a DNS resolver is able to check if the information is identical (i.e. unmodified and complete) to the information published by the zone owner and served on an authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect any data published in the DNS, including text records (TXT), mail exchange records (MX), and can be used to bootstrap other security systems that publish references to cryptographic certificates stored in the DNS such as Certificate Records (CERT records, RFC 4398), SSH fingerprints (SSHFP, RFC 4255), IPSec public keys (IPSECKEY, RFC 4025), and TLS Trust Anchors (TLSA, RFC 6698). If it can be used for SSH fingerprints and IPSec public keys, it can be used for CA certs... Matt ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 11/25/2014 6:28 AM, Edward Ned Harvey (blu) wrote: Based on my understanding of DNSSEC, it doesn't add security except in esoteric edge cases. DNSSEC exists to solve one problem: cache poisoning. It does so by digitally signing entire zones. That's not security; it's authenticity. If you're expecting security from DNSSEC then your expectations have already been shattered. As an aside, I don't consider cache poisoning to be an edge case. DNSCurve authenticates and encrypts DNS traffic using strong, fast crypto. So far, OpenDNS is the only major adopter. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On Tue, Nov 25, 2014 at 10:15:51AM -0500, Richard Pieri wrote: On 11/25/2014 6:28 AM, Edward Ned Harvey (blu) wrote: Based on my understanding of DNSSEC, it doesn't add security except in esoteric edge cases. DNSSEC exists to solve one problem: cache poisoning. It does so by digitally signing entire zones. That's not security; it's authenticity. Authentication is one aspect of security (it is famously one of the three A's of security, the other two being authorization and auditability), so sure, yes, it is security. It is not COMPLETE security... but complete security is a fairy tale. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
...but complete security is a fairy tale... VMS? ducks away quickly --- Steven Santos Director Simply Circus, Inc. 86 Los Angeles Street Newton, MA 02458 P: 617-527-0667 F: 617-934-1870 E: ste...@simplycircus.com On Tue, Nov 25, 2014 at 1:40 PM, Derek Martin inva...@pizzashack.org wrote: On Tue, Nov 25, 2014 at 10:15:51AM -0500, Richard Pieri wrote: On 11/25/2014 6:28 AM, Edward Ned Harvey (blu) wrote: Based on my understanding of DNSSEC, it doesn't add security except in esoteric edge cases. DNSSEC exists to solve one problem: cache poisoning. It does so by digitally signing entire zones. That's not security; it's authenticity. Authentication is one aspect of security (it is famously one of the three A's of security, the other two being authorization and auditability), so sure, yes, it is security. It is not COMPLETE security... but complete security is a fairy tale. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Related to the discussion of how X509 is broken and various hacks to make it work: What I would really like to see is a scheme adopted like SPF for mail: a TXT DNS entry for your domain that has the CA (or a fingerprint for the CA, or maybe the whole public cert). That way you can be unequivocal about who the valid CA for your domain is. To me that would solve the biggest problem with the set of 'trusted' CAs issue. This is not without new attack vectors: you can only trust DNS responses as far as DNS-SEC goes, which unfortunately ends one-hop before end-systems (unless you run your own DNS server and force everything on your home network to use that; which I do but don't know how common that is). Matt ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On 11/24/2014 1:52 PM, Matthew Gillen wrote: What I would really like to see is a scheme adopted like SPF for mail: a TXT DNS entry for your domain that has the CA (or a fingerprint for the CA, or maybe the whole public cert). That way you can be unequivocal about who the valid CA for your domain is. This doesn't solve the problem. All it does is shift your trust chain from a certificate authority to a DNS registrar. And maybe not that much if your DNS registrar is also your CA. -- Rich P. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
From: Tom Metro [mailto:tmetro+...@gmail.com] I explained to them the site had nothing to do with financial transactions, to which they responded: Thanks for that. I had no idea - as you said - the policy isn't exactly spelled out clearly. I even downloaded the *big* policy document, and while of course I didn't read the whole thing (hundreds of pages) I did read the section about permitted uses and got no hint about anything like this. Yes. Plus pretty much every cert I've requested from StartCom has prompted one of their support people to email requesting additional identifying information. That's a bummer. It's supposed to be random about 1 in 20. Which coincides with my experience. However I'm pretty sure there's another factor happening - because my friend whose name is Ohiomoba gets constantly screened too. It looks like the main value they're talking about in that article is the ACME automated process for identity validation (... and automated installation). I wonder if existing CA's like startssl would be unable to easily adopt a new automated process like that, because of the fact that they're a CA they must stick to their existing documented processes. I would assume that if StartCom sees this new effort as adhering to the same philosophy that led them to offer free certs themselves, that they'd adopt the protocol to make their service equally easy to use. I contacted startssl support and asked them if they could offer an automated process like what Let's Encrypt is going to offer, and also asked if they are bound to the existing process by virtue of the fact that they're a CA. They didn't give me a clear answer on the first part - I expect they'll respond by either doing it or issuing a statement describing why not. But they did confirm they're able to change their own policies when they want to, so there isn't an obstacle to adopting an automated process, if they think it's something they want to pursue. What's less clear is whether StartCom will be motivated enough to invest in the work needed to adopt the new protocol. I don't get the impression that they've invested much in their infrastructure lately. Their site seems hardly changed in many years. I take the unchanging website as a sign of simply they're a CA. ;-) Every CA I know of has a crappy website that hardly ever changes (or hardly ever changes for the better.) Having Mozilla in their corner already gets them a big chunk of the market. With Google's initiative to get HTTPS used everywhere, it seems likely they would get on board with Chrome. I don't think Microsoft or Apple would have any strong reason to reject this idea. Oh - This is something I know and I forget other people don't. So I apologize for not making it more clear before. Look at the list of CA's on Mozilla's list, and look at their process for accepting CA's (and read that link about Honest Achmed, which is hilarious https://bugzilla.mozilla.org/show_bug.cgi?id=647959 ) Look at Apple's list and process. Look at Microsoft. Google... Mozilla and Apple are basically the sluts of CA's. They take any damn thing from anybody. It's scary when Microsoft is the gold standard that others should strive to achieve. They have at least a reasonably restrictive process, and a reasonably restrictive list of CA's. Google doesn't maintain a list. They rely on the underlying OS. Linux also doesn't maintain one - but obviously somebody who's got a package in every standard linux distribution *does* maintain a list. I didn't look into who it is or anything. I'm guessing it's distribution-specific. Probably Red Hat and Debian actually maintain their own separate lists (just a guess). ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
On Wed, Nov 19, 2014 at 11:34:19AM -0500, Richard Pieri wrote: On 11/19/2014 2:34 AM, Tom Metro wrote: All the automation does make you wonder whether it is going to be easier to game the system. I don't wonder. Each automated step in a process is an avenue for bad actors to abuse the process. NB: automation includes human workers following a script. I would amend that last statement to say MAY include--I certainly have had my share of involvement with procedures read from scripts, where the people following them used their brains to make intelligent decisions with vastly varying degrees of success. Some are quite excellent. The trouble is those people are usually recognized as such and promoted to positions where using their brains provides more value. This is right and good... at least for them. It does not bode so well for you. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. ___ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
Re: [Discuss] free SSL certs from the EFF
Edward Ned Harvey (blu) wrote: Tom Metro wrote: ...if the host name even sounds like a site that might sell things (e-commerce), they won't issue a cert. Huh? I use them for numerous companies, including e-commerce. Where'd you hear that? Directly from them when I applied for a cert. Here: https://www.startssl.com/?app=39 It says: The StartSSL Free (Class 1) digital certificates...provide modest assurances and are meant to secure personal web sites, public forums or web mail. And when I applied for a cert for a domain with shop in the name, even though it had no e-commerce, they rejected it with: Thank you for requesting a digital certificate with us. However Class 1 certificates are not meant to be used for commercial activities or financial transactions according to our policy. For this purpose please consider upgrading to Class 2 or higher verification level. They're documentation could state this limitation more clearly. I explained to them the site had nothing to do with financial transactions, to which they responded: Unfortunately we can't control for which exact purpose you are/will be using the certificates. The rejection has been triggered by the 'shop' key word at your domain which is not allowed at Class 1 Free certificates. Financial institutions and e-commerce web sites must upgrade to a validated level. Thank you for your understanding. So basically if you sound like a store, you're out of luck. If you don't sound like a store, you can use the cert for whatever you want. Automation at its finest. (Not sure why they bother to have humans sending out and responding to the notices if they aren't empowered to override the automation.) if I've been accidentally slipping through the cracks all these years. Yes, you have. But EFF isn't stopping with merely making the certs free. You still have to jump though a few hoops with StartCom, and it sounds like EFF wants to add more automation to the issuing process to make it faster/trivial to add SSL to a site. I think when you say you have to jump through a few hoops with startssl, you just mean you have to receive the validation email(s) and either figure out how to generate your own CSR, or trust them to generate the private key for you. And then you download the cert and install it into apache (or whatever.) Yes. Plus pretty much every cert I've requested from StartCom has prompted one of their support people to email requesting additional identifying information. Whereas these guys have the tool that basically automates all that process. Yes. They say it takes 1-3 hours. For me, it takes about 10 minutes, but maybe I'm just good at it. 10 minutes seems perfectly realistic if you are already familiar with the procedure, have already set up an account with the CA, and are already familiar with the installation procedure on your web server. Provision a cert from Comodo through Dreamhost's panel, and the process similarly takes only about 10 minutes due to their automation and hand-holding. They say their goal is 15-30 seconds, which is unrealistic. Probably. That apparently excludes setting up an account at the CA (which I'm guessing is still necessary) and installing their tool on your web server. As you observed, they seem to be leaving out some setup overhead. (Side note) Historically, I've always thought, you need to generate your own CSR in order to keep your private key private. But more recently I'm thinking, This is the CA we're talking about. So what if they have the private key. If they're going to attack you, you're screwed even if they don't have the private key - because they can perform a validated MITM attack, which is only a little more hassle for them. (End Side Note) True. Unless the client is taking extra steps to detect a cert change, and even then who would suspect a new cert from the same CA as the original one they fingerprinted? However, if the CA is sloppier about handling your private keys than they are about securing your own, it potentially expands your attack surface. For example, your private key might reside on one of the CA's web servers as they process your request, even if the actual signing happens on a more secured back-end machine. That web server could get compromised, leaking your private key to a third party. It looks like the main value they're talking about in that article is the ACME automated process for identity validation (... and automated installation). I wonder if existing CA's like startssl would be unable to easily adopt a new automated process like that, because of the fact that they're a CA they must stick to their existing documented processes. I would assume that if StartCom sees this new effort as adhering to the same philosophy that led them to offer free certs themselves, that they'd adopt the protocol to make their service equally easy to use. What's less clear is whether StartCom will be
