[Cryptography] soft chewy center
much of the discussion these past few weeks seems to be centered on channel and container protection, secure paths, encrypted file systems, etc. much effort has gone into ensureing opaque environments for data to flow. and while interesting and perhaps useful, not a whole lot of effort seems to targeting the integrity of the data itself. wrapping the soft chewy middle with a hard candy shell can and does hide the fact that your core/data may be rotten. some years back, i was part of a debate on the relative value of crypto - and it was pointed out that for some sectors, crypto ensured _failure_ simply because processing the bits introduced latency. for these sectors, speed was paramount. think HFT or any sort of Flash Mob event where you want in/out as quickly as possible. crypto in and of itself is not a generator of value. Sprinkeling Security/Crypto pixie dust on -everything- can not be a good idea. Just my 0.02 lira. Jari and Stephen, please don't take the IETF there - its a wasteland. /bill ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On Sun, Aug 22, 2010 at 11:51:01AM -0400, Anne Lynn Wheeler wrote: On 08/22/2010 06:56 AM, Jakob Schlyter wrote: There are a lot of work going on in this area, including how to use secure DNS to associate the key that appears in a TLS server's certificate with the the intended domain name [1]. Adding HSTS to this mix does make sense and is something that is discussed, e.g. on the keyassure mailing list [2]. There is large vested interested in Certification Authority industry selling SSL domain name certificates. A secure DNS scenario is having a public key registered at the time the domain name is registered ... and then a different kind of TLS ... where the public key is returned in piggy-back with the domain name to ip-address mapping response. for the conservative - they may want to verify the DNSSEC trust chains for both the domain name and the IP address. e.g. is it the same EV cert at the end of both validation checks. --bill - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fw: Root Zone DNSSEC Deployment Technical Status Update
On Sat, Jul 17, 2010 at 10:41:10AM -0400, Paul Wouters wrote: On Fri, 16 Jul 2010, Taral wrote: Neat, but not (yet) useful... only these TLDs have DS records: The rest will follow soon. And it is not that you had to stop those TLD trust anchors just now. actually, soon is a relative term. Some have stated they are waiting for operational issues to settle before they proceed. could be a few months, could be a few years. Several are using old SHA-1 hashes... old ? :) really old. Paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
On Tue, Oct 20, 2009 at 09:20:04AM -0400, William Allen Simpson wrote: Nicolas Williams wrote: Getting DNSSEC deployed with sufficiently large KSKs should be priority #1. I agree. Let's get something deployed, as that will lead to testing. If 90 days for the 1024-bit ZSKs is too long, that can always be reduced, or the ZSK keylength be increased -- we too can squeeze factors of 10 from various places. In the early days of DNSSEC deployment the opportunities for causing damage by breaking a ZSK will be relatively meager. We have time to get this right; this issue does not strike me as urgent. One of the things that bother me with the latest presentation is that only dummy keys will be used. That makes no sense to me! We'll have folks that get used to hitting the Ignore key on their browsers http://nanog.org/meetings/nanog47/presentations/Lightning/Abley_light_N47.pdf the use of dummy keys in the first round is to test things like key rollover - the inital keys themselves are unable to be validated and state as much. Anyone who tries validation is -NOT- reading the key or the deployment plan. Thus, I'm not sure we have time to get this right. We need good keys, so that user processes can be tested. next phase. OTOH, will we be able to detect breaks? A clever attacker will use breaks in very subtle ways. A ZSK break would be bad, but something that could be dealt with, *if* we knew it'd happened. The potential difficulty of detecting attacks is probably the best reason for seeking stronger keys well ahead of time. Agreed. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
On Wed, Oct 14, 2009 at 06:24:06PM -0400, Perry E. Metzger wrote: Ekr has a very good blog posting on what seems like a bad security decision being made by Verisign on management of the DNS root key. http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html In summary, a decision is being made to use a short lived 1024 bit key for the signature because longer keys would result in excessively large DNS packets. However, such short keys are very likely crackable in short periods of time if the stakes are high enough -- and few keys in existence are this valuable. however - the VSGN proposal meets current NIST guidelines. --bill Perry -- Perry E. Metzger pe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Possibly questionable security decisions in DNS root management
On Wed, Oct 14, 2009 at 07:22:27PM -0400, Perry E. Metzger wrote: bmann...@vacation.karoshi.com writes: On Wed, Oct 14, 2009 at 06:24:06PM -0400, Perry E. Metzger wrote: Ekr has a very good blog posting on what seems like a bad security decision being made by Verisign on management of the DNS root key. http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html In summary, a decision is being made to use a short lived 1024 bit key for the signature because longer keys would result in excessively large DNS packets. However, such short keys are very likely crackable in short periods of time if the stakes are high enough -- and few keys in existence are this valuable. however - the VSGN proposal meets current NIST guidelines. That doesn't say anything about how good an idea it is, any more than an architect can make a building remain standing in an earthquake by invoking the construction code. We are the sort of people who write these sorts of guidelines, and if they're flawed, we can't use them as a justification for designs. (Well, a bureaucrat certainly can use such documents as a form of CYA, but we're discussing technology here, not means of evading blame.) The fact is, the DNS root key is one of the few instances where it is actually worth someone's time to crack a key because it provides enormous opportunities for mischief, especially if people start trusting it more because it is authenticated. Unlike your https session to view your calendar or the password for your home router, the secret involved here are worth an insane amount of money. er... there is the root key and there is the ROOT KEY. the zsk only has a 90 day validity period. ... meets the spec and -ought- to be good enough. that said, it is currently a -proposal- and if credible arguments can be made to modify the proposal, I'm persuaded that VSGN will do so. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: unintended?
On Fri, Nov 14, 2008 at 02:29:24PM -0700, Chad Perrin wrote: On Fri, Nov 14, 2008 at 01:26:29PM +, [EMAIL PROTECTED] wrote: (snicker) from the local firefox en-us.add-ons.mozilla.com:443 uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted. (Error code: sec_error_untrusted_issuer) What does Perspectives have to say? What installation of Firefox did you use? I don't have that problem when I visit: https://addons.mozilla.org/en-US/firefox/ Do you perhaps have some kind of malicious redirection going on there? -- Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ] perspectives is not installed. I've never taken the default and added a cert that was not in the firefox trusted list... (at least on a permanent basis) Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.2) Gecko/2008091618 Firefox/3.0.2 and yes, a redirect might be in play - except this happens w/ multiple, different caches (fm the house, work, panera, starbucks and even the cows end) --bill - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
unintended?
(snicker) from the local firefox en-us.add-ons.mozilla.com:443 uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted. (Error code: sec_error_untrusted_issuer) --bill - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How is DNSSEC
On Sat, Mar 22, 2008 at 10:59:18AM +, Ben Laurie wrote: [EMAIL PROTECTED] wrote: On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote: From time to time I hear that DNSSEC is working fine, and on examining the matter I find it is working fine except that Seems to me that if DNSSEC is actually working fine, I should be able to provide an authoritative public key for any domain name I control, and should be able to obtain such keys for other domain names, and use such keys for any purpose, not just those purposes envisaged in the DNSSEC specification. Can I? It is not apparent to me that I can. actually, the DNSSEC specification -used- to support keys for any purpose, and in theory you could use DNSSEC keys in that manner. However a bit of careful thought suggests that there is potential disconnect btwn the zone owner/admin who creates/distributes the keys as a token of the integrity and authenticity of the data in the DNS, and the owner/admin of the node to which the DNS data points. So far, so good. This disconnect doesn't seem to have done the CA industry any harm, though. The CA business -is- to serve as a notary They attest to the binding o fthe key to holder. To date, thats NOT what a zone admin does, he is attesting that its HIS key, that it is HIS record in HIS database. Just because he has sold the right to use to someone else, is still his database and his data. Unless of course Nominet (for example) is now going to allow client driven dynamic updates - where the clients are in complete control of their data. (thats closer to James, assertion that he owns/controls his domain name) Remember that while you may control your forward name (and not many people actually run their own DNS servers) it is less likely that you run your address maps - and for the paranoid, you would want to ensure the forward and reverse zones are signed and at the intersection, there is a common data element which you can use. Non sequiteur, plus I can't see why paranoia would prompt me to want to do this? What does it prove? The argument is, again, to James asserton that he owns his domain name. In point of fact, every node has at least two names in the DNS, the forward (which gets most of the attention) and the reverse - which is nearly always controled by your ISP. DNSSEC validation along one path in the DNS graph is reassuring (or so it is claimed). I posit that validation over two, generally non-overlapping administrative spheres of influence, in the DNS graph would give a higher level of assurance. Couple this with finding the identical x509 cert at the origin of the validation chain for both paths - and I think I have a much higher confidence that I am actually going to be sending packets to the right node. Also, PTR records are only supposed to point to primary domain names. Since it is common for hosts to have many names resolving to the same IP address, by definition most of these will not correspond to the reverse lookup. Er... Allow me the option o fdisbeleiving your assertion. PTR records can and do point to mutiple names. Some narrow implementations have assumed that there will only be a single data element and this myth - that PTRs only point to a single name - is and has been spread widely. To do what you want, want, you might consider using the CERT-rr, using the DNS to distribute host-specific keys/certs. And to ensure that the data in the DNS was not tampered with, using DNSSEC signed zones with CERT-rr's would not be a bad thing. In fact, thats what we are testing . Who is we and what exactly are you testing? We is USMIR, the registry for .UM - www.nic.um --bill Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [mm] How is DNSSEC
On Sat, Mar 22, 2008 at 02:46:40PM +, Ben Laurie wrote: [EMAIL PROTECTED] wrote: Er... Allow me the option o fdisbeleiving your assertion. PTR records can and do point to mutiple names. Some narrow implementations have assumed that there will only be a single data element and this myth - that PTRs only point to a single name - is and has been spread widely. You can disbelieve my assertion if you wish, but I am only quoting the RFC. RFC 1035, to be precise: Address nodes are used to hold pointers to primary host names in the normal domain space. (section 3.5. IN-ADDR.ARPA domain). So, the myth is in the scripture. ah... open to interpretation. what is a primary host name? --bill -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How is DNSSEC
On Fri, Mar 21, 2008 at 08:52:07AM +1000, James A. Donald wrote: From time to time I hear that DNSSEC is working fine, and on examining the matter I find it is working fine except that Seems to me that if DNSSEC is actually working fine, I should be able to provide an authoritative public key for any domain name I control, and should be able to obtain such keys for other domain names, and use such keys for any purpose, not just those purposes envisaged in the DNSSEC specification. Can I? It is not apparent to me that I can. actually, the DNSSEC specification -used- to support keys for any purpose, and in theory you could use DNSSEC keys in that manner. However a bit of careful thought suggests that there is potential disconnect btwn the zone owner/admin who creates/distributes the keys as a token of the integrity and authenticity of the data in the DNS, and the owner/admin of the node to which the DNS data points. Remember that while you may control your forward name (and not many people actually run their own DNS servers) it is less likely that you run your address maps - and for the paranoid, you would want to ensure the forward and reverse zones are signed and at the intersection, there is a common data element which you can use. To do what you want, want, you might consider using the CERT-rr, using the DNS to distribute host-specific keys/certs. And to ensure that the data in the DNS was not tampered with, using DNSSEC signed zones with CERT-rr's would not be a bad thing. In fact, thats what we are testing . - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Exponent 3 damage spreads...
On Sun, Sep 10, 2006 at 08:30:53AM +1000, James A. Donald wrote: -- Ben Laurie wrote: Subject: [dnsop] BIND and OpenSSL's RSA signature forging issue From: Ben Laurie [EMAIL PROTECTED] Date: Fri, 08 Sep 2006 11:40:44 +0100 To: DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment) [EMAIL PROTECTED], dnsop@lists.uoregon.edu To: DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment) [EMAIL PROTECTED], dnsop@lists.uoregon.edu I've just noticed that BIND is vulnerable to: http://www.openssl.org/news/secadv_20060905.txt Executive summary: RRSIGs can be forged if your RSA key has exponent 3, which is BIND's default. Note that the issue is in the resolver, not the server. Fix: Upgrade OpenSSL. Issue: Since I've been told often that most of the world won't upgrade resolvers, presumably most of the world will be vulnerable to this problem for a long time. Solution: Don't use exponent 3 anymore. This can, of course, be done server-side, where the responsible citizens live, allegedly. Side benefit: You all get to test emergency key roll! Start your motors, gentlemen! This seems to presuppose that Secure DNS is actually in use. I was unaware that this is the case. What is the penetration of Secure DNS? hard to tell... how many delegations are there? that said, RIPE has signed all their delegations and the SE delegation is signed. privately, i am aware of perhaps a dozen or so other delegations which are signed. one might also look to the ISC DLV registry to see which of those delegations are signed. --bill --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG fLselD6l8fdbF1p4sjg3RQ2GXi+NnQ//1CymnfKs 4+JAX1zwW3fSIStp6glgbAygK1zCuoMeiTigr4qmd - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A Note About Trust Anchor Key Distribution
nice paper. note that it claims this paper is being published to establish IPR claims. there is prior art in several vectors. you may wish to consider the following (although now expired) Internet Drafts: draft-ietf-dnsext-trustupdate-threshold-00 and a similar one authored by Mike StJohns. that cover the same basic ideas. at least one of these is being updated and revised. --bill manning - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
At 03:39 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: There are some other problems w/ using the DNS. No revolkation process. DNS caching third-party trust (DNS admins != delegation holder) Given high value /or low trust ... relying parties still have option of directly contacting root authority. And as outline, the root authority is also the root authority for the CA/PKIs. If you attack the root trust authority with false information then all subsequent trust operations flowing from that false information is suspect. Domain name system still has some exploits against the root database resulting in false information but since that is the root for both DNS as well as CA/PKIs generating SSL domain name certificates it is a common failure point for both infrastructures. It needs to be fixed, in order to improve trust on either the DNS side or the CA/PKI side (doesn't matter how thick you make the vault door if somebody forgot to complete the back wall on the vault). ok... does anyone else want to touch a secured DNS system that has some parts fo the tree fully signed? Its a way to get some emperical understanding of how interesting/hard it is to hammer the DNS into a PKI-like thing. www.rs.net has some information. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
