Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
In message [EMAIL PROTECTED], Simon Josefsson writes: Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I can pretty much guarantee that the IETF will never standardize that, except possibly in conjunction with authenticated dhcp. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
At 11:49 PM 06/29/2003 +0200, Simon Josefsson wrote: No, I believe only one of the following situations can occur: * Your laptop see and uses the name yahoo.com, and the DNS server translate them into yahoo.com.attackersdomain.com. If your laptop knows the DNSSEC root key, the attacker cannot spoof yahoo.com since it doesn't know the yahoo.com key. This attack is essentially a man-in-the-middle attack between you and your recursive DNS server. That doesn't happen. (Well, it could, but as you point out, it's not a successful attack methodology, because DNSSEC was designed to correctly take care of this.) * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I agree with you and Steve that this would be a Really Bad Idea. The only way to make it secure is to use an authenticated DHCP, which means you have to put authentication keys in somehow, plus you need a reasonable response for handling authentication failures, which means you need a user interface as well. It's also the wrong scope, since the DNSSEC is global information, not connection-oriented information, so it's not really DHCP's job. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC NOT
Bill Stewart [EMAIL PROTECTED] writes: * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. It can be a useful feature, but it does not circumvent DNSSEC in any way, that I can see. DNSSEC see yahoo.com.attackersdomain.com and can verify that the IP addresses for that host are the one that the owner of the y.c.a.c domain publishes, and that is what DNSSEC delivers. The bad judgement I referred to was if your software, after DNSSEC verification, confuses yahoo.com with yahoo.com.attackersdomain.com. Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I agree with you and Steve that this would be a Really Bad Idea. The only way to make it secure is to use an authenticated DHCP, which means you have to put authentication keys in somehow, plus you need a reasonable response for handling authentication failures, which means you need a user interface as well. It's also the wrong scope, since the DNSSEC is global information, not connection-oriented information, so it's not really DHCP's job. I think it is simpler to have the DNSSEC root key installed with the DNSSEC software. If someone can replace the root key in that distribution channel, they could also modify your DNSSEC software, so you are no worse off. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
(Fwd) IPsec interoperability testing event
FYI ( from http://www.cenorm.be/isss/newsletter/ ): --- Forwarded message follows --- ETSI interoperability testing event for IPsec on 21-25 July 2003 The European Telecommunications Standards Institute's (ETSI) Plugtests service is mounting its first interoperability testing event for IPsec, the increasingly popular security protocol which aims to protect information exchanges at the Internet Protocol (IP) layer. Companies involved in IPsec implementation and providers of Public Key Infrastructures (PKI) will meet at ETSI headquarters in Sophia Antipolis in the South of France, from 21-25 July 2003, to improve interoperability between their implementations. By bringing together engineers from competing organizations in a multi-vendor environment, this event will provide an invaluable opportunity to identify and rectify any interoperability problems before products hit the market place. IPsec's potential contribution to the security of the information infrastructure is now widely recognized, and its development has recently been attracting considerable interest globally as the use of IP in company networks and for sensitive applications increases. Defined by the Internet Engineering Task Force (IETF), its various security services include the guarantee of authenticity and confidentiality of data. The deadline for registration is 6 July 2003. Further information about this event is available at: www.etsi.org/plugtests/home.htm --- End of forwarded message --- --- Dipl.-Inform. Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-461, Fax +49 721 6105-455 E-Mail [EMAIL PROTECTED], http://www.secorvo.de --- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC NOT
On Mon, 30 Jun 2003, Simon Josefsson wrote: Bill Stewart [EMAIL PROTECTED] writes: * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. It can be a useful feature, but it does not circumvent DNSSEC in any way, that I can see. DNSSEC see yahoo.com.attackersdomain.com and can verify that the IP addresses for that host are the one that the owner of the y.c.a.c domain publishes, and that is what DNSSEC delivers. The bad judgement I referred to was if your software, after DNSSEC verification, confuses yahoo.com with yahoo.com.attackersdomain.com. I think that the problem would be somewhat ameliorated if there were a DNS cache on the laptop itself. It would still use DNS servers, but if it got a different IP number for the same address, it should notify someone. This can happen without an attack going on, if the legitimate addressee's DNS record changes because the IP address of that service actually changes - but with sites like Yahoo, Paypal, etc, they've got a lot of infrastructure and momentum there. Those IP addresses don't change on a whim. And those are the major targets for a DNS spoof. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC NOT
In message [EMAIL PROTECTED], Simon Josefsson writes: Bill Stewart [EMAIL PROTECTED] writes: * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. It can be a useful feature, but it does not circumvent DNSSEC in any way, that I can see. DNSSEC see yahoo.com.attackersdomain.com and can verify that the IP addresses for that host are the one that the owner of the y.c.a.c domain publishes, and that is what DNSSEC delivers. The bad judgement I referred to was if your software, after DNSSEC verification, confuses yahoo.com with yahoo.com.attackersdomain.com. It's also not a new problem -- see RFC 1535. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Simon Josefsson writes: Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I can pretty much guarantee that the IETF will never standardize that, except possibly in conjunction with authenticated dhcp. Would this be the DHCP working group that on at least 2 occasions when I was there, insisted that secure DHCP wouldn't require a secret, since DHCP isn't supposed to require configuration? And all I was proposing at the time was username, challenge, MD5-hash response (very CHAP-like). They can configure ARP addresses for security, but having both the user and administrator configure a per host secret was apparently out of the question. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC NOT
Once upon a time, bear sent Kevin a note that said... I think that the problem would be somewhat ameliorated if there were a DNS cache on the laptop itself. It would still use DNS servers, but if it got a different IP number for the same address, it should notify someone. Win2k and WinXP have a cache for the resolver. To show it, type 'ipconfig /displaydns' in a command prompt. To clear it (which is a good troubleshooting tactic) us 'ipconfig /flushdns' K -- In Vino Veritas http://userguide.mozdev.org http://astroturfgarden.com/~ktneely - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: pubkeys for p and g
also sprach Arnold G. Reinhold [EMAIL PROTECTED] [2003.06.29.0424 +0200]: I am not sure I understand. How does this relate to my question? Where does the other factor come from? I got the impression, and maybe I misunderstood, that you were viewing a product of two primes aA, where a was the private part= and A was the public part. That is not how RSA works. The produce aA is the public key. Either factor can be the private part. Oh, I get it. No, that was my bad. aA and bB are simply the private/Public keypairs for A and B. Yeah, yeah, I know. Algebra is always haunting me... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] invalid PGP subkeys? use subkeys.pgp.net as keyserver! our destiny exercises its influence over us even when, as yet, we have not learned its nature; it is our future that lays down the law of our today. - friedrich nietzsche pgp0.pgp Description: PGP signature
Re: Mozilla tool to self-verify HTTPS site
Ian Grigg wrote: Tying the certificate into the core crypto protocol seems to be a poor design choice; outsourcing any certification to a higher layer seems to work much better out in the field. I'll reserve judgement about the significance of SSLBar, but I couldn't agree more with the above point. The only way to use non-X.509 certs with TLS 1.0 is by rather clunkily extending the ciphersuites to also identify some kind of certificate type. IMO, this fact has significantly contributed to the lack of adoption of PGP, SPKI, and alternative PKIs on the Internet. TLS's new extension mechanism can help address this (see draft-ietf-tls-openpgp-keys), but it'll be a while before extension support is common. M. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
On Fri, Jun 27, 2003 at 12:56:24AM +1000, Mister Lee wrote: Regarding the usefulness of SSLbar itself, its immediate purpose was fingerprint display, as a (theoretically) easy means of checking a cert's validity yourself, rather than relying on a third party signing. That list of officially sanctioned CAs that comes with browsers just keeps getting longer and longer. I don't know who the hell any of those organizations are, or what their policies are... Anyway, SSLbar could be made much more useful if I were to have it (somehow) cache fingerprints or certs, and a flag to indicate whether the user has validated them. Implementing this requires further investigation however, and I've just been pointed at this list and it's archive, so I have some more reading to do :) Maybe this is a stupid question, but exactly how are you supposed to use this information to verify a cert? I've done an informal survey of a few financial institutions whose sites use SSL, and the number of them that were able to provide me with a fingerprint over the phone was exactly zero. -- - Adam - Adam Fields, Managing Partner, [EMAIL PROTECTED] Surgam, Inc. is a technology consulting firm with strong background in delivering scalable and robust enterprise web and IT applications. http://www.adamfields.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
