Re: Is cryptography where security took the wrong branch?
> >certificate requests coming into a CA/PKI can be digitally signed, the > >CA/PKI can retrieve the authoritative authentication public key (for the > >domain name ownership) from the domain name infrastructure and > >authenticate the request eliminating all the identification gorp (and > >also done w/o the use of certificates). > > > >misc. additional recent musings: > >http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model > >(At least I hope it's new) Not particularly new. This was/is the promise of DNSSEC. early work, the TBDS and FMESHD projects. Current IETF work, OE and IPSECKEY. > The problem is that the domain name infrastructure has a database of domain > name owners but no real good infrastructure ... Not entirely. The reverse maps are a well defined infrastructure space. > Of course, the bottom line is if the domain name infrastructure has a > real-time database of public keys for authentication purposes in part > for use by the CA/PKI industry for authenticating SSL domain name > certificate requests for use in authentication operations the use > of the domain name infrastructure's authentication public keys don't have > to just be restricted to authentication use by the CA/PKI industry. In > fact, domain name infrastructure authentication public keys could be used > to effectively for authentication operations that actually subsume the SSL > domain name certificates authentication operations. There are some other problems w/ using the DNS. No revolkation process. DNS caching third-party trust (DNS admins != delegation holder) > > -- > Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ > Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm > > > > - > 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: 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]
Re: Is cryptography where security took the wrong branch?
> > At 09:57 AM 9/10/2003 -0700, [EMAIL PROTECTED] wrote: > > 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. > > My assertion is 1) DNS integrity issues have to be addressed as part of > generalized DNS trust issues regardless of any use for trusted > distribution of information that may include public keys. 2) because domain > name infrastructure is the root authority for CA/PKI SSL domain name > certificates, there is a suggestion that public keys be registered as part > of domain name registration (to fix trust issues in domain infrastructure > on behalf of the CA/PKI industry). Being able to trust DNS ... and having > registered public keys means that existing DNS information > distribution operation can turn itno trusted distribution of public keys > (aka existing DNS infrastructure supports distribution of any information > that happens to be registered). Nice collection of URLs. Ack both your assertions. RS.NET is a testbed that is being used to validate the accuray of those assertions and explore the operational and social impact with the deployment of a DNS that can respond with information which can be independently verified for accuracy. --bill - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Did American slaves use steganography?
> http://news.nationalgeographic.com/news/2004/02/0205_040205_slavequilts.html > > CCH IRA award, Reading Rainbow Book : Sweet Clara and the Freedom Quilt by D.Hopkinson Childrens Book of the Month Selection. Published 1993 --bill - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
thats pretty much DNSSEC, now eleven years old. or - presuming DNS is fine w/o integrity checks, one should look at the rational for the creation of the CERT (x509) resource record back in 1999 and documented in RFC 2538. > > > > yahoo draft internet standard for using DNS as a public key server > http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt > misc past news refs: > http://docs.yahoo.com/docs/pr/release1143.html > http://blogs.ittoolbox.com/linux/technologist/archives/000241.asp > http://www.computerweekly.com/Article127082.htm > http://zdnet.com.com/2100-1104_2-5164279.html > http://www.ecommercetimes.com/perl/story/32995.html > - 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: 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 , "(DNSSEC deployment)" > > <[EMAIL PROTECTED]>, dnsop@lists.uoregon.edu > > > > To: > > DNSEXT WG , "(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: 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: 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]
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: 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]
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: 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: 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: 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
[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: [Cryptography] soft chewy center
On Tue, Sep 10, 2013 at 07:05:40PM -0400, Perry E. Metzger wrote: > On Tue, 10 Sep 2013 21:58:28 + bmann...@vacation.karoshi.com > wrote: > > 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. > > The latency cost of a stream cipher implemented in hardware can be as > little as the time it takes a single XOR gate to operate -- which is > to say, low even by the standards of my friends who do high frequency > trading (many of whom do, in fact, claim to encrypt most of their > communications). latency effect should, as you state, be a factor in which tool gets used. for the HFT crowd, i'm fairly confident they are talking about channel protection - they have a fairly simple and easily scoped topology. > Certainly crypto is not the only (or even most important) way to make > systems secure. In breaking in to a system, implementation bugs are > where you look, not cracking cipher keys. However, latency qua > latency seems like a poor reason to avoid encrypting your traffic. It > might, of course, be a reason to avoid certain architectural > decisions in how you use the crypto -- a public key operation per > packet would clearly add unacceptable latency in many > applications. agreed. > > > Perry > -- > Perry E. Metzger pe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
