Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)

[Paul Wouters <[e-mail]>]

On Thu, 25 Feb 2010, Nikos Mavrogiannopoulos wrote:

>> Ssh without secure public key distribution mechanism is not really
>> secure cryptographically.
>>
>> In general, public key cryptography is scure only if public key
>> distribution is secure.
>
> Well as far as I know ssh works pretty well today and this model can be
> easy made verifiable (i.e. secure as you say) by the administrator
> verifying the keys of upstream.

It already is, using DNSSEC.

dig +dnssec -t sshfp www.xelerance.org

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1

;; ANSWER SECTION:
www.xelerance.org.	7200	IN	SSHFP	1 1 F79BDD2C882A9AC575198D507DE89D9B38145F00
www.xelerance.org.	7200	IN	SSHFP	2 1 B0B26D4895F3628AA721DAA0DB1B8236AFF02BF2
www.xelerance.org.	7200	IN	RRSIG	SSHFP 5 3 7200 20100306233849 20100220075947 58970 xelerance.org. HgME4vnp12/NhZKRUP7YVrSs6aXPeUvaWSoZ1FIS1Mk/8o9qIQgSb8k3 nC9LiQ8HjwGgVf7T2fSywvvW2KrlnFg8geJPSuMPEFXA41eXLUcmHHxr YQNfxkNnoJPz1iayk9tPjhKtfGwQuoL+hWiGUpnnjBKKU8hiCww4UjN4 yMo=


And from "man ssh_config":

      VerifyHostKeyDNS
              Specifies whether to verify the remote key using DNS and SSHFP
              resource records.  If this option is set to “yes”, the client
              will implicitly trust keys that match a secure fingerprint from
              DNS.  Insecure fingerprints will be handled as if this option was
              set to “ask”.  If this option is set to “ask”, information on
              fingerprint match will be displayed, but the user will still need
              to confirm new host keys according to the StrictHostKeyChecking
              option.  The argument must be “yes”, “no”, or “ask”.  The default
              is “no”.  Note that this option applies to protocol version 2
              only.

              See also VERIFYING HOST KEYS in ssh(1).

Paul