电子邮件中DANE生态系统的纵向综合研究

主要问题

• 背景和地位：这篇论文研究了什么问题，处于该领域什么地位（相对之前工作有什么区别）

• idea和设计：基于什么核心idea展开，怎么设计的系统（包括哪几部分、各自的作用是什么）

• 实现细节：实现上解决的挑战性问题、解决方法

• 实验结果：哪些实验结果，各自表明了什么

• 总结：这篇论文的主要贡献是什么，有什么启发

参考blog

PKI技术

DNSSEC原理与部署情况–段海新

Abstract

Introduction

对于协议的依赖/采用

• 采用的是TLS（Transport layer Security）协议，并且加上PKI(Public Key Infrastructure 公钥基础设施)
• )

可以根据上面图片以及introduction的内容看到根CA要具有自签名证书

• 过程存在的问题：证书的验证过程仍然依赖于CAs（那么这些是否都是可信的）

Background

• 目的：概述DNS、DNSSEC以及DANE并且理解是怎么协同工作来保证电子邮件的传输安全的

  

DNS

DNS维护着域名和关联值之间的记录，比如mail服务器（MX）和IPv4地址（A）之间的关联，但是DNS很容易遭受DNS攻击，比如DNS缓存中毒、DNS劫持等等，可参考之前的blog，所以引入了DNSSEC（DNS安全扩展）

DNSSEC

DNSSEC要解决的问题以及DNSSEC的原理

DNSSEC的雏形，使用非对称加密，这样不用引入CA，可以通过数字签名来实现

新加入的记录类型

• DNSKEY 包含在DNSSEC中用的公钥
• RRSIG：服务器用私钥对于RR记录上的加密
• DS：DNSKEY的哈希，可以构建信任链

DANE

• 是一种Internet security协议，允许证书被绑定到域名上面

• 引入了额外的记录类型：TLSA（特定位置存储，端口号，协议，基础域名的组合）

• TLSA记录的组成：证书的使用、选择器、匹配类型以及证书关联数据，DNSSEC可以用来保证TLSA记录的完整性和真实性

DANE&SMTP

• SMTP采用的是明文传输，在刚开始阶段引入了STARTTLS来进行加密传输，但是有可能遭到降级风险，因为在SMTP最开始阶段，接收邮件服务器（TLS server端）会纯文本形式发送”STRATTLS”来表明支持STARTTLS，来将不安全连接转化为安全连接

  

  降级风险图示，是发生在SMTP建立连接的阶段，通过MITM攻击来实现

  

• 而引入DANE协议后的SMTP传输相比于前面的更加安全，我认为这是通过将CA绑定到域名并且存储在DNS server上面从而避免了在刚开始SMTP连接建立阶段时邮件发送方服务器和邮件接收方服务器的”公开商议”，我认为是能够不再像上面一样容易遭受MITM攻击的

  图示

  

• DANE如何与DNSSEC以及STARTTLS一起工作，图示

  

  • 通过DNSSEC链验证来保证TLSA记录的真实性以及完整性，每个RRSIG都是一个记录集通过DNSKEY的签名/加密（比如TLSAs），DS由子区域上传。在DNSSEC链验证之后，邮件发送方服务器（先发送TLS req，之后接受certificate）通过接受来自邮件接收方服务器（TLS服务器）的certificate来进行验证TLSA记录，如果验证通过，则进行TLS连接的建立

• DANE只有在所有的实体都正常运行时才能够执行正确的功能

分析提纲

DANE部署情况及对应研究

• 通过分析电子邮件服务器的配置来研究电子邮件应用当中的DANE PKI部署情况

  对于TLD（Top level Domain，顶级域名）中TLSA记录进行统计（因为在进行DANE协议应用的时候，一定会用到TLSA记录，可以来作为部署情况的衡量标准）

  

纵向研究（随时间的变化）

• 数据集

  通过关注权威DNS服务器来实现大规模的纵向测量

  选择了.com，.net和.org三个TLD因为是最大的顶级通用域，而选择.nl和.se两个国家域是因为显示了DNSSEC部署的比例高

  获取数据的方式：首先提取SOA、DNSKEY记录以及对应RRSIG和MX记录

• DANE的流行程度

  关注点为：至少为MX记录（SMTP相关）提供/发布了一个TLSA记录的二级域名的数量，图解

  

  数据图如下

  

  observation

  • MX记录和TLSA记录都在稳步增长
  • 发现在两个国家域名DNSSEC部署比例上面较高，这是由于注册中心的财政激励
  • 电子邮件托管服务在SMTP DANE的部署中扮演着重要的角色

• 注意

  仅通过分析TLSA记录无法判断这些域是否正确的部署了DANE，还需要观察TLSA记录是否被正确签名、是否支持STARTTLS来提交证书、证书与TLSA记录是否一致，之后会对是否正确运行DANE进行更详细的检查

DANE management分析

• 研究目标：具有MX和TLSA记录的域是否采取了必要的步骤来正确的支持DANE，并且理解具有MX和TLSA记录的域是如何deploy and operate DANE的

• 数据集/数据来源

  • MX记录中显示的邮件服务器所提供的所有的证书

  • 以及相应的TLSA记录

  • 从发布TLSA记录的邮件服务器中获取证书的方法

    从之前的数据集中获取所有的MX和TLSA记录

    之后开发一个measurement SMTP客户端，通关建立SMTP连接来连接到MX记录对应的电子邮件服务器。之后向电子邮件服务器发送STARTTLS来进行请求，从而获得证书并且每小时获取/刷新

• missing component

  • 检查发布TLSA记录的域是否也发布所有必须的DNSSEC记录以及是否支持STARTTLS，根据图片可以看到80%的TLSA都是已签名的（用DNSSEC中存储的公钥对应的私钥加密），也就是具有RRSIG记录

  • 之后开始考虑MX记录上的电子邮件服务器（一般是接收电子邮件服务器），可以得到因为无法通过STARTTLS连接的已建立SMTP连接的比例，也就是说TLS server端并不支持STARTTLS，平均故障率为0.2%，而由于缺少DS记录而导致故障的比例为20%

  • 所以，DANE正确部署失败的主要原因是由于缺少DS记录

客户端DANE支持（电子邮件服务提供商）

具体分析过程如下：

最后在验证过程中，如果我们的server端没有收到错误配置的测试子域的电子邮件，就意味着电子邮件服务提供山已经正确验证了错误配置的子域，并且决定不发送电子邮件

现在已经能够粗略的了解到那些电子邮件服务提供商能够正确支持DANE，但是之后仍要进行对于协议来进行细致分析，判断哪些协议能够被支持，哪些不被支持，所以要测试每一个协议

4种流行的SMTP软件对于STARTTLS和DANE支持的实验结果

10中流行的DNS软件实现对于DNSSEC和DANE(TLSA记录的实验结果)

Conclusion