DNS fragmentation attack subverts DV, 5 public CAs vulnerable

[Hector Martin]

I figured this presentation might be of interest to this list:

https://i.blackhat.com/eu-18/Thu-Dec-6/eu-18-Heftrig-Off-Path-Attacks-Against-PKI.pdf

It seems they found 5 (unspecified) public CAs out of 17 tested were
vulnerable to this attack, which can be performed by an off-path attacker.

The TL;DR is you can force fragmentation by spoofing ICMP fragmentation
needed packets, and then cause the DNS answer to be split into two
fragments, one with all the actual anti-spoofing relevant information
(TXID, UDP source port, etc), and one with the actual DNS answer data of
interest. Then all you have to do is guess the IPID and keep the UDP
checksum valid, both of which are practical, and you can spoof the
second fragment with whatever you want.

Yet another reason to push for DNSSEC everywhere (and pervasive use of
CAA records to reduce attack surface). This is scary enough I think CAs
should be required to implement practical mitigations.

Thoughts?
--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

[Ryan Sleevi]

Is this new from the past discussion?
https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ

There's also other discussions, such as
https://groups.google.com/d/msg/mozilla.dev.security.policy/ydxiw3S3gSw/Q0CpD8zlBQAJ
,
https://groups.google.com/d/msg/mozilla.dev.security.policy/84lxLwhaHPQ/KSsjk-JVAwAJ
,
https://groups.google.com/d/msg/mozilla.dev.security.policy/2teeVLJ44RM/Yqk5GHSpCQAJ

I think we're at the stage where it's less about a call to abstract action,
and actually requires specific steps being taken, by CAs, to explore and
document solutions. Saying "push for DNSSEC" doesn't actually lead to
objective threat analysis' and their mitigations.

In this regard, Let's Encrypt seems to be the industry leader here - with
respect to
https://community.letsencrypt.org/t/validating-challenges-from-multiple-network-vantage-points/40955
and the aforementioned
https://community.letsencrypt.org/t/mitigating-dns-fragmentation-attack/74838

If other CAs are taking steps in this direction, and have public
documentation considering their analysis and design, that'd be extremely
useful to the community.

[Hector Martin 'marcan']

On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> Is this new from the past discussion?

I think what's new is someone actually tried this, and found 5 CAs that
are vulnerable and for which this attack works in practice.

> https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ

Looking back, this attack is also documented in the paper linked in that
thread, but unfortunately it's not open access. I get the feeling this
may be why that discussion didn't really proceed further in that thread.
I certainly missed it.

The paper does list the vulnerable CAs, which are:

> • COMODO, InstantSSL, NetworkSolutions, SSL.com: these CAs
> use the same MX email server mcmail1.mcr.colo.comodo.net
> which uses the same caching DNS resolver. The results from our
> cache overwriting methods indicates that the DNS resolver software
> is New BIND 9.x with DNSSEC-validation.
> • Thawte, GeoTrust, RapidSSL: use the same MX server and
> resolution platform.
> • StartCom4
> , StartSSL: both use the same email server and the
> same DNS resolver.
> • SwissSign: uses New BIND 9.x

> I think we're at the stage where it's less about a call to abstract action,
> and actually requires specific steps being taken, by CAs, to explore and
> document solutions. Saying "push for DNSSEC" doesn't actually lead to
> objective threat analysis' and their mitigations.

My last paragraph was intended as two separate statements; DNSSEC solves
this problem but we can't magically flip a switch and make everyone do
that (heck, my own TLD's registrar still doesn't support it, and yes,
I've been pestering them about it). Given that, I think CAs should be
required to implement practical mitigations against this particular
attack, and I'm hoping that by pointing this out we can start a
discussion about what those mitigations should look like :-)

As you've noted, Let's Encrypt seems to be leading on this front. It
would be interesting to see if any other CAs can document their approach
to mitigating this issue, if any.

--
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub

[Leo Grove]

On Tuesday, December 11, 2018 at 11:27:52 AM UTC-6, Hector Martin 'marcan' wrote:
> On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> > Is this new from the past discussion?
>
> I think what's new is someone actually tried this, and found 5 CAs that
> are vulnerable and for which this attack works in practice.
>
> > https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ
>
> Looking back, this attack is also documented in the paper linked in that
> thread, but unfortunately it's not open access. I get the feeling this
> may be why that discussion didn't really proceed further in that thread.
> I certainly missed it.
>
> The paper does list the vulnerable CAs, which are:
>
> > • COMODO, InstantSSL, NetworkSolutions, SSL.com: these CAs
> > use the same MX email server mcmail1.mcr.colo.comodo.net
> > which uses the same caching DNS resolver. The results from our
> > cache overwriting methods indicates that the DNS resolver software
> > is New BIND 9.x with DNSSEC-validation.

I want to clarify that the only DNS mappings to Comodo from SSL.com are crl and crt CNAMEs for UserTrust issued SSL.com SubCAs operated and maintained wholly by Sectigo.

The SSL.com Root CA, which is operated and maintained by SSL.com, does not have any dependency on the Comodo/Sectigo DNS and therefore should not be listed as one of the vulnerable CAs.

Regards,

Leo Grove
SSL.com

[Wayne Thayer]

On Tue, Dec 11, 2018 at 10:27 AM Hector Martin 'marcan' via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> > Is this new from the past discussion?
>
> I think what's new is someone actually tried this, and found 5 CAs that
> are vulnerable and for which this attack works in practice.
>
> >
> https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ
>
> Looking back, this attack is also documented in the paper linked in that
> thread, but unfortunately it's not open access. I get the feeling this
> may be why that discussion didn't really proceed further in that thread.
> I certainly missed it.
>
> The paper does list the vulnerable CAs, which are:
>
> > • COMODO, InstantSSL, NetworkSolutions, SSL.com: these CAs
> > use the same MX email server mcmail1.mcr.colo.comodo.net
> > which uses the same caching DNS resolver. The results from our
> > cache overwriting methods indicates that the DNS resolver software
> > is New BIND 9.x with DNSSEC-validation.

> > • Thawte, GeoTrust, RapidSSL: use the same MX server and
> > resolution platform.
> > • StartCom4
> > , StartSSL: both use the same email server and the
> > same DNS resolver.
> > • SwissSign: uses New BIND 9.x
>
> > I think we're at the stage where it's less about a call to abstract
> action,
> > and actually requires specific steps being taken, by CAs, to explore and
> > document solutions. Saying "push for DNSSEC" doesn't actually lead to
> > objective threat analysis' and their mitigations.
>
> My last paragraph was intended as two separate statements; DNSSEC solves
> this problem but we can't magically flip a switch and make everyone do
> that (heck, my own TLD's registrar still doesn't support it, and yes,
> I've been pestering them about it). Given that, I think CAs should be
> required to implement practical mitigations against this particular
> attack, and I'm hoping that by pointing this out we can start a
> discussion about what those mitigations should look like :-)
>
> As you've noted, Let's Encrypt seems to be leading on this front. It
> would be interesting to see if any other CAs can document their approach
> to mitigating this issue, if any.
>

> I think it;s worth calling out that Let's Encrypt has implemented what
appears to be a relatively simple mitigation:
https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945

I am also interested to know if other CAs are considering this or other
mitigations (e.g. multi-perspective validation) for this attack.

[Rob Stradling]

On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:
<snip>

> I think it;s worth calling out that Let's Encrypt has implemented what
> appears to be a relatively simple mitigation:
> https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945

Sectigo implemented this same mitigation about a month ago.

> I am also interested to know if other CAs are considering this or other
> mitigations (e.g. multi-perspective validation) for this attack.

Multi-perspective validation is something we've started to think about too.

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

[Ryan Sleevi]

On Tue, Dec 18, 2018 at 7:41 AM Rob Stradling <r...@sectigo.com> wrote:

> On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:
> <snip>
> > I think it;s worth calling out that Let's Encrypt has implemented what
> > appears to be a relatively simple mitigation:
> >
> https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945
>
> Sectigo implemented this same mitigation about a month ago.
>

Like Let's Encrypt, is there any data Sectigo can share regarding the
impact it has had on operations? Or has it been so negligible as to not
notice?

It's rather encouraging to hear another CA has deployed this, seemingly
successfully, and having data that shows the impact helps make informed
decisions about whether attempting to mandate through policy - whether
Mozilla or the CA/Browser Forum - would have any negative effects, given
the positive effects it seems to have.

[Tim Hollebeek]

The problem is that the attackers get to choose the CA they use, so
multi-perspective validation doesn't provide any benefits unless everyone
has to do it.

I brought it up several times at the validation working group and as a
discussion topic at the Shanghai face to face, but unfortunately there
doesn't seem to be much enthusiasm for requiring it.

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
On
> Behalf Of Rob Stradling via dev-security-policy
> Sent: Tuesday, December 18, 2018 7:42 AM
> To: Wayne Thayer <wth...@mozilla.com>
> Cc: Ryan Sleevi <ry...@sleevi.com>; mar...@marcan.st; mozilla-dev-security-
> policy <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable
>
> On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:
> <snip>
> > I think it;s worth calling out that Let's Encrypt has implemented what
> > appears to be a relatively simple mitigation:
> > https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-b
> > ytes/77945
>
> Sectigo implemented this same mitigation about a month ago.
>

> > I am also interested to know if other CAs are considering this or
> > other mitigations (e.g. multi-perspective validation) for this attack.
>
> Multi-perspective validation is something we've started to think about
too.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

On Tue, Dec 18, 2018 at 1:53 PM Tim Hollebeek <tim.ho...@digicert.com>
wrote:

> The problem is that the attackers get to choose the CA they use, so
> multi-perspective validation doesn't provide any benefits unless everyone
> has to do it.
>
> I brought it up several times at the validation working group and as a
> discussion topic at the Shanghai face to face, but unfortunately there
> doesn't seem to be much enthusiasm for requiring it.
>

I think it's great that you're focused on the end-goal, and I certainly
share your perspective on the security properties.

However, I think you're overlooking that the reason that there is not much
enthusiasm for it is precisely because mandating something, without
implementation experience, tends to lend itself to CAs having trouble
deploying. That's not to suggest there's an oppositon to mandate - when
push comes to shove, ultimately users' security needs to take precedence -
but that it's both irresponsible and premature to propose mandating it (or
forming a committee on mandating it, or a committee to discuss the
requirements a mandate would have, etc) before there's been any progress on
what works or doesn't work.

As a result, knowing that organizations like Sectigo and Let's Encrypt are
either actively working on it or assigning resources to think about it in
the context of their system IS encouraging, and suggests that we do have a
path forward, once we've gathered meaningful feedback.

I know that some CAs feel browsers "rush in" on things, and even I feel odd
pushing back against you on requiring it, but I think that if we want to
have this provide any value, then in addition to, and prior to, mandating
it, we need to actually write down what it means, have a think about how it
works, and how to attack it. And it sounds like Sectigo and Let's Encrypt
have begun that step, and I hope that any other CAs participating or
following the list are doing the same and can commit to it.

[Rob Stradling]

On 18/12/2018 16:41, Ryan Sleevi wrote:

> On Tue, Dec 18, 2018 at 7:41 AM Rob Stradling wrote:
> On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:
> <snip>
> > I think it;s worth calling out that Let's Encrypt has implemented
> what
> > appears to be a relatively simple mitigation:
> >
> https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945
>
> Sectigo implemented this same mitigation about a month ago.
>
>

> Like Let's Encrypt, is there any data Sectigo can share regarding the
> impact it has had on operations? Or has it been so negligible as to not
> notice?

Hi Ryan. We've not noticed any difference.

> It's rather encouraging to hear another CA has deployed this, seemingly
> successfully, and having data that shows the impact helps make informed
> decisions about whether attempting to mandate through policy - whether
> Mozilla or the CA/Browser Forum - would have any negative effects, given
> the positive effects it seems to have.