Re: [DNSOP] [dnsext] DNS vulnerabilities
Derek Atkins wrote: >> However, Snowden taught us that we must avoid any fancy >> cryptography strongly promoted by NIST, including all the >> EC related ones, which may be documented somewhere. > > It is unclear to me that ECC as a generic technology is bad, although > any specific curves creates by NIST/NSA are certainly suspect. My feeling is that NIST has been promoting EC, in general, unnaturally. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
Nicholas Weaver writes: > On Nov 1, 2013, at 7:57 AM, Derek Atkins wrote: >> It is unclear to me that ECC as a generic technology is bad, although >> any specific curves creates by NIST/NSA are certainly suspect. >> >> Having said that, Dual-EC-DRBG is a Random Number Generator, not a Hash, >> Public Key, or Cipher algorithm, and we don't use it in DNS for >> anything, AFAIK. > > > Random Number Generators are used to generate the key material, since > bare entropy is often not enough, so you use your entropy pool to seed > a pRNG. Bind, for example, ends up using OpenSSL. Fair enough, but I consider key generation "outside the DNS protocol". Named isn't generating the key(s), you use tools to do that. So yes, those tools need an RNG. > Certified versions of OpenSSL do have Dual_EC_DRBG, although its not > by default (or is it?). It historically has been present; I do not know if it's the default RNG or not. > The threat is probably a lot less, however, since everything else > signed in DNSSEC-land is deterministic, and even if Dual_EC_DRBG was > used, hopefully the raw stream doesn't leak (the backdoor requires > seeing some of the random output to make it predictable). This was my point. > Nicholas Weaver it is a tale, told by an idiot, -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
Masataka Ohta writes: > Hi, Hosnieh, > >> Do you think it will be relevant to this document or it can be >> another informational document only discuss about the >> vulnerabilities of cryptographic algorithms? > > As I said, it is a known vulnerability. That is, we don't > need a generic new document very much. > > However, Snowden taught us that we must avoid any fancy > cryptography strongly promoted by NIST, including all the > EC related ones, which may be documented somewhere. It is unclear to me that ECC as a generic technology is bad, although any specific curves creates by NIST/NSA are certainly suspect. Having said that, Dual-EC-DRBG is a Random Number Generator, not a Hash, Public Key, or Cipher algorithm, and we don't use it in DNS for anything, AFAIK. > Masataka Ohta -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
On Nov 1, 2013, at 7:57 AM, Derek Atkins wrote: > It is unclear to me that ECC as a generic technology is bad, although > any specific curves creates by NIST/NSA are certainly suspect. > > Having said that, Dual-EC-DRBG is a Random Number Generator, not a Hash, > Public Key, or Cipher algorithm, and we don't use it in DNS for > anything, AFAIK. Random Number Generators are used to generate the key material, since bare entropy is often not enough, so you use your entropy pool to seed a pRNG. Bind, for example, ends up using OpenSSL. Certified versions of OpenSSL do have Dual_EC_DRBG, although its not by default (or is it?). The threat is probably a lot less, however, since everything else signed in DNSSEC-land is deterministic, and even if Dual_EC_DRBG was used, hopefully the raw stream doesn't leak (the backdoor requires seeing some of the random output to make it predictable). -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] DNS vulnerabilities
> On 1 Nov 2013, at 06:35, Evan Hunt wrote: > >> On Fri, Nov 01, 2013 at 03:29:12PM +0900, Masataka Ohta wrote: >> TLS is another PKI and is inherently insecure as CAs can be >> compromised. > > True, but Tony's quorum-based approach could be made exhaustive enough > that the adversary would have to have compromised *every* CA. If they > can do that, I'm not sure any realistic defense is possible anyway. Right. At the moment the code is just trying different host names. This deals with compromised server certs OK, but is not enough for compromised CA certs. So the quorum needs to be counted in terms of different CAs. The usual way for TLS MitM attacks to work is by installing a malicious cert in the user's CA store. I think I have heard of malware doing this, and TLS interceptors usually require corporations to enforce self-abuse of this kind on their desktop systems. In this situation the attacker can trivially fool tlsdate. But not if you check that you got the time from several different hosts authenticated by different CAs. The next question is how feasible it would be for an adversary to mount a Sybil attack on your CA store. That probably requires complete pwnage at which point getting the right time is the least of your problems. Tony. -- f.anthony.n.finchhttp://dotat.at/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
