资料

Shaping DNS Security with Curves

DNSCurve: Usable security for DNS

CurveDNS

注意,DNSCURVE提供点到点的安全,而非端到端;也就是说,能保证采用DNSCURVE通信的相邻两节点DNS查询/应答通信数据的加密、认证。

DNSCURVE

针对“NS”的公钥认证,维护成本较低;一个NS可以有多个公私钥对

挑战码+DH交换协商对称密钥,支持加密通信

客户端时间不准对解析结果无影响,抗重放攻击

不会降低外部探知整个域配置的难度

没有引入新RR,域名配置文件略微增大,主要是NS记录比以前长,可以继续用UDP

耗CPU的攻击威胁增大,每个包都要涉及加解密计算,否定缓存应答不需要特殊处理

放大攻击的风险较小

DNSSEC

针对“域”的公钥认证,维护成本较高

不支持加密通信

客户端时间不准可能导致新公钥认证的域名配置被判为错误,需要NTP严格校准时间,会有重放攻击的问题

NSEC/NSEC3会降低外部探知整个域配置的难度

引入新RR,域名配置文件显著变大,以后用TCP比较靠谱

耗CPU的攻击威胁增大,否定缓存应答需要特殊的临时计算

放大攻击的风险大增

注意

二者可结合使用,例如,解析some.test.com,用DNSSEC认证“.”与“com.”,到test.com的ns再开始用DNSCURVE

opendns支持DNSCURVE

draft

https://tools.ietf.org/html/draft-dempsky-dnscurve-01

加密算法

Cryptography in NaCl

c = aes(aes_key, src_data)

h = sha256(c)

s = rsa_client_private_sign(h)

key_s = rsa_server_public_encrypt(aes_key, h, s)

main_data = concat(key_s, c)

两种通信方案

Streamlined Format :解包,cryptbox 直接是原始DNS查询、应答包

TXT Format:解压TXT,把内容提取出来,跟header组装成DNS查询、应答包

过程

client : client public key, client_nonce, cryptbox query

server : 用 server private key 解密,用 client public key 验证

server :搞一个 server_nonce,附在 client_nonce 之后,在应答包里用server private加密传回去

client :解包,验nonce,验DATA

讨论

改动量比较大,保密性太好了,又比较耗资源,以致于没法让大家往下用。。。



blog comments powered by Disqus

Published

14 November 2011

Tags