RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Paul Wouters via dev-security-policy]

On Mon, 30 Apr 2018, Tim Hollebeek wrote:


What about the cases we discussed where there is DNSSEC, but only for a
subtree?


I don't know what that means? You mean a trust island not chained to the
root? If so, then yes, that is a zone without DNSSEC since it is missing
a DS in its parent (or grand parent, etc)

But again, using a proper validating DNS server will handle all that for
you.

Paul
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Quirin Scheitle via dev-security-policy]

I think a reasonable approach is to consider a domain having deployed DNSSEC 
when there is a DS record at the parent zone (*). 

Missing DS record => No DNSSEC. 
Existing DS record => Require valid DNSSEC signatures

(*) More precisely, a chain of DS records through all the parent zones down to 
the currently evaluated DNS name.
I.e., a subtree deploying DNSSEC without a proper chain to the ICANN root 
through parent zone DS records would be considered not deploying DNSSEC.

Kind regards
Quirin

> On 30. Apr 2018, at 17:10, Tim Hollebeek via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> 
> What about the cases we discussed where there is DNSSEC, but only for a
> subtree?
> Or do you consider that "not DNSSEC" ?
> 
> -Tim
> 
>> -Original Message-
>> From: Paul Wouters [mailto:p...@nohats.ca]
>> Sent: Monday, April 30, 2018 11:07 AM
>> To: Tim Hollebeek <tim.holleb...@digicert.com>
>> Cc: mozilla-dev-security-policy
> <mozilla-dev-security-pol...@lists.mozilla.org>
>> Subject: RE: "multiple perspective validations" - AW: Regional BGP hijack
> of
>> Amazon DNS infrastructure
>> 
>> On Mon, 30 Apr 2018, Tim Hollebeek via dev-security-policy wrote:
>> 
>>>> I don't think this opinion is in conflict with the suggestion that we
>>>> required DNSSEC validation on CAA records when (however rarely) it is
>>>> deployed. I added this as
>>>> https://github.com/mozilla/pkipolicy/issues/133
>>> 
>>> One of the things that could help quite a bit is to only require
>>> DNSSEC validation when DNSSEC is deployed CORRECTLY, as opposed to
>>> some partial or broken deployment.  It's generally broken or
>>> incomplete DNSSEC deployments that cause all the problems.
>>> 
>>> Getting the rules for this right might be complicated, though.
>> 
>> It's also wrong. You can't soft-fail on that and you don't want to be in
> the
>> business of trying to figure out what is a sysadmin failure and what is an
> actual
>> attack.
>> 
>> The only somehwat valid soft-fail could come from recently expired RRSIGs,
> but
>> validating DNS resolvers like unbound already build in a margin of a few
> hours,
>> and I think you should not to anything special during CAA verification
> other
>> then using a validating resolver.
>> 
>> Paul
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Tim Hollebeek via dev-security-policy]

What about the cases we discussed where there is DNSSEC, but only for a
subtree?
Or do you consider that "not DNSSEC" ?

-Tim

> -Original Message-
> From: Paul Wouters [mailto:p...@nohats.ca]
> Sent: Monday, April 30, 2018 11:07 AM
> To: Tim Hollebeek <tim.holleb...@digicert.com>
> Cc: mozilla-dev-security-policy
<mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: RE: "multiple perspective validations" - AW: Regional BGP hijack
of
> Amazon DNS infrastructure
> 
> On Mon, 30 Apr 2018, Tim Hollebeek via dev-security-policy wrote:
> 
> >> I don't think this opinion is in conflict with the suggestion that we
> >> required DNSSEC validation on CAA records when (however rarely) it is
> >> deployed. I added this as
> >> https://github.com/mozilla/pkipolicy/issues/133
> >
> > One of the things that could help quite a bit is to only require
> > DNSSEC validation when DNSSEC is deployed CORRECTLY, as opposed to
> > some partial or broken deployment.  It's generally broken or
> > incomplete DNSSEC deployments that cause all the problems.
> >
> > Getting the rules for this right might be complicated, though.
> 
> It's also wrong. You can't soft-fail on that and you don't want to be in
the
> business of trying to figure out what is a sysadmin failure and what is an
actual
> attack.
> 
> The only somehwat valid soft-fail could come from recently expired RRSIGs,
but
> validating DNS resolvers like unbound already build in a margin of a few
hours,
> and I think you should not to anything special during CAA verification
other
> then using a validating resolver.
> 
> Paul


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Paul Wouters via dev-security-policy]

On Mon, 30 Apr 2018, Tim Hollebeek via dev-security-policy wrote:


I don't think this opinion is in conflict with the suggestion that we
required
DNSSEC validation on CAA records when (however rarely) it is deployed. I
added this as https://github.com/mozilla/pkipolicy/issues/133


One of the things that could help quite a bit is to only require DNSSEC
validation
when DNSSEC is deployed CORRECTLY, as opposed to some partial or broken
deployment.  It's generally broken or incomplete DNSSEC deployments that
cause all the problems.

Getting the rules for this right might be complicated, though.


It's also wrong. You can't soft-fail on that and you don't want to be in
the business of trying to figure out what is a sysadmin failure and what
is an actual attack.

The only somehwat valid soft-fail could come from recently expired
RRSIGs, but validating DNS resolvers like unbound already build in a
margin of a few hours, and I think you should not to anything special
during CAA verification other then using a validating resolver.

Paul
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Tim Hollebeek via dev-security-policy]

> I don't think this opinion is in conflict with the suggestion that we 
> required
> DNSSEC validation on CAA records when (however rarely) it is deployed. I
> added this as https://github.com/mozilla/pkipolicy/issues/133

One of the things that could help quite a bit is to only require DNSSEC 
validation
when DNSSEC is deployed CORRECTLY, as opposed to some partial or broken
deployment.  It's generally broken or incomplete DNSSEC deployments that
cause all the problems.

Getting the rules for this right might be complicated, though.

-Tim


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Wayne Thayer via dev-security-policy]

On Thu, Apr 26, 2018 at 6:59 AM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, April 26, 2018 at 11:45:15 AM UTC, Tim Hollebeek wrote:
> > > > which is why in the near future we can hopefully use RDAP over TLS
> > > > (RFC
> > > > 7481) instead of WHOIS, and of course since the near past, DNSSEC :)
> > >
> > > I agree moving away from WHOIS to RDAP over TLS is a good low hanging
> fruit
> > > mitigator once it is viable.
> >
> > My opinion is it is viable now, and the time to transition to optionally
> authenticated RDAP over TLS is now.  It solves pretty much all the problems
> we are currently having in a straightforward, standards-based way.
> >
> > The only opposition I've seem comes from people who seem to want to
> promote alternative models that destroy the WHOIS ecosystem, leading to
> proprietary distribution and monetization of WHOIS data.
> >
> > I can see why that is attractive to some people, but I don’t think it's
> best for everyone.
> >
> > I also agree that DNSSEC is a lost cause, though I understand why Paul
> doesn't want to give up   I've wanted to see it succeed for basically my
> entire career, but it seems to be making about as much progress as fusion
> energy.
> >
>
I don't think this opinion is in conflict with the suggestion that we
required DNSSEC validation on CAA records when (however rarely) it is
deployed. I added this as https://github.com/mozilla/pkipolicy/issues/133


> > -Tim
>
> Moving to RDAP does not solve "all the problems we are currently having"
> in that it does not do anything for DCV which is what I think this thread
> was about (e.g. BGP implications for DCV).
>
> I agree that these are two different issues. I added
https://github.com/mozilla/pkipolicy/issues/134 to track the proposal to
require CAs to perform domain validations from multiple network
perspectives. I do suspect this will be difficult to define in a policy.

That said, if in fact, RDAP is viable today I agree we should deprecate the
> use of WhoIs and mandate use of RDAP in the associated scenarios.
>
> I began work on a CAB Forum ballot that adds explicit BR support for RDAP.
I could be wrong, but I doubt that RDAP deployment is far enough along that
we can deprecate WHOIS.

I will also raise the first two issues with the CAB Forum because I think
they are better addressed in the BRs than in Mozilla policy.

Ryan Hurst
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Ryan Hurst via dev-security-policy]

On Thursday, April 26, 2018 at 11:45:15 AM UTC, Tim Hollebeek wrote:
> > > which is why in the near future we can hopefully use RDAP over TLS
> > > (RFC
> > > 7481) instead of WHOIS, and of course since the near past, DNSSEC :)
> > 
> > I agree moving away from WHOIS to RDAP over TLS is a good low hanging fruit
> > mitigator once it is viable.
> 
> My opinion is it is viable now, and the time to transition to optionally 
> authenticated RDAP over TLS is now.  It solves pretty much all the problems 
> we are currently having in a straightforward, standards-based way.  
> 
> The only opposition I've seem comes from people who seem to want to promote 
> alternative models that destroy the WHOIS ecosystem, leading to proprietary 
> distribution and monetization of WHOIS data.
> 
> I can see why that is attractive to some people, but I don’t think it's best 
> for everyone.
> 
> I also agree that DNSSEC is a lost cause, though I understand why Paul 
> doesn't want to give up   I've wanted to see it succeed for basically my 
> entire career, but it seems to be making about as much progress as fusion 
> energy.
> 
> -Tim

Moving to RDAP does not solve "all the problems we are currently having" in 
that it does not do anything for DCV which is what I think this thread was 
about (e.g. BGP implications for DCV).

That said, if in fact, RDAP is viable today I agree we should deprecate the use 
of WhoIs and mandate use of RDAP in the associated scenarios.

Ryan Hurst
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Tim Hollebeek via dev-security-policy]

> > which is why in the near future we can hopefully use RDAP over TLS
> > (RFC
> > 7481) instead of WHOIS, and of course since the near past, DNSSEC :)
> 
> I agree moving away from WHOIS to RDAP over TLS is a good low hanging fruit
> mitigator once it is viable.

My opinion is it is viable now, and the time to transition to optionally 
authenticated RDAP over TLS is now.  It solves pretty much all the problems we 
are currently having in a straightforward, standards-based way.  

The only opposition I've seem comes from people who seem to want to promote 
alternative models that destroy the WHOIS ecosystem, leading to proprietary 
distribution and monetization of WHOIS data.

I can see why that is attractive to some people, but I don’t think it's best 
for everyone.

I also agree that DNSSEC is a lost cause, though I understand why Paul doesn't 
want to give up   I've wanted to see it succeed for basically my entire 
career, but it seems to be making about as much progress as fusion energy.

-Tim


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Ryan Hurst via dev-security-policy]

On Wednesday, April 25, 2018 at 3:48:07 PM UTC+2, Paul Wouters wrote:
> On Wed, 25 Apr 2018, Ryan Hurst via dev-security-policy wrote:
> 
> > Multiple perspectives is useful when relying on any insecure third-party 
> > resource; for example DNS or Whois.
> >
> > This is different than requiring multiple validations of different types; 
> > an attacker that is able to manipulate the DNS validation at the IP layer 
> > is also likely going to be able to do the same for HTTP and Whois.
> 
> which is why in the near future we can hopefully use RDAP over TLS (RFC
> 7481) instead of WHOIS, and of course since the near past, DNSSEC :)
> 
> I'm not sure how useful it would be to have multiple network points for
> ACME testing - it will just lead to the attackers doing more then one
> BGP hijack at once. In the end, that's a numbers game with a bunch of
> race conditions. But hey, it might lead to actual BGP security getting
> deployed :)
> 
> Paul

I agree moving away from WHOIS to RDAP over TLS is a good low hanging fruit 
mitigator once it is viable.

Having been responsible for a very popular/mainstream DNS server and worked on 
implementing/deploying DNSSEC in enterprises I am of the opinion this is a lost 
cause and do not have the patience or energy to try to engage in all the 
reasons why this is not a viable solution.

As for multi-perspective domain control validation and the idea that an 
attacker who can attack one perspective can attack all perspectives, that may 
be true but the larger your quorum set is the harder that becomes. The goal is 
not to make it impossible to cheat is not realistic, the goal is to raise the 
bar so that cheating is meaningfully harder.

Ryan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Ryan Sleevi via dev-security-policy]

On Wed, Apr 25, 2018 at 7:28 AM, Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan!
>
> The "multiple perspective validations" is an interesting idea. Did you
> think about combining it with CAA checking? I could imagine having a new
> tag, e.g. "allowedMethods", in which the legitimate owner of  a domain can
> specify the set of allowed methods to validate his domain. As an example
> the value "(3.2.2.4.1 AND 3.2.2.4.5) OR 3.2.2.4.9" in the new
> "allowedMethods" tag could mean, that a certificate may only be issued, if
> two validations acc. 3.2.2.4.1 and 3.2.2.4.1 were successful or if one
> validation acc. 3.2.2.4.9 was successful. Any other method of validation
> would be not allowed. I see here the benefit, that the owner of a domain
> can choose how to verify according his business needs and select the
> appropriate level of security for his domains.
>

I'm not really sure this is related to any of the problems at hand - that
is, for example, DNSSEC or CAA has zero impact on the set of problems
raised. I'm saddened, but not surprised, to see those discussions derail
otherwise useful conversations.

The discussion of using CAA to restrict validation methods is one that has
been floated in the CA/Browser Forum several times now - along with a
method of disclosing the validation method used within a certificate, so
that both site operators and the community can ensure correctness. In the
past, some members with adamantly and vocally opposed to such improvements,
but hopefully, such opposition is in the decline.

As a practical matter, I'm suspect about needing to introduce a complex
combinatorial syntax. The complexity and risk such a system imposes is
likely not worth the cost, especially when such concerns can be mitigated
through other methods (for example, limiting the set of CAs that can issue
for your domain, and then entering in side-agreements with them). The
proposals for restricting validation methods are precisely to allow
flexibility in CA choice, while allowing a baseline of security methods
that are valid.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Jakob Bohm via dev-security-policy]

On 25/04/2018 18:01, Quirin Scheitle wrote:

Hi Jakob,


As someone who has actually /removed/ DNSSEC from some domains after it
caused serious ripling failures, the brokenness of DNSSEC does not come
from how often DNSSEC fails to validate valid requests but from how
easily DNSSEC can crash a domain, making it too risky to deploy.
Requiring DNSSEC validation for processing of CAA records *does not* mean that 
domains need to deploy DNSSEC.


This is not about whether or not domains should deploy DNSSEC.
Domains are are their own right to decide whether or not they see DNSSEC fit 
for their environment.

We are saying that those domains having decided to deploy DNSSEC should get the 
additional benefits that DNSSEC provides.



Thanks, your wording was a bit vague.

I fully agree that CAs should do DNSSEC checking for when resolving any 
DNSSEC protected CAA records, and I think they should also do that for

all other DNSSEC protected DNS records used in validation, including
customer DNS records (e.g. for ACME DNS validation), indirectly used
customer DNS records (e.g. A records for tested web servers, MX+A
records of tested mail servers) and non-customer DNS records (e.g. DNS
records of whois servers, DNS records for downloading any 3rd party
blocklists).



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Matthew Hardeman via dev-security-policy]

On Wed, Apr 25, 2018 at 11:01 AM, Quirin Scheitle via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
>
> This is not about whether or not domains should deploy DNSSEC.
> Domains are are their own right to decide whether or not they see DNSSEC
> fit for their environment.
>
> We are saying that those domains having decided to deploy DNSSEC should
> get the additional benefits that DNSSEC provides.
>
> I don’t know how to say this any more clearly.
> CAA protection would still exist for all domains.
> Those domains that have decided to deploy DNSSEC would get the additional
> benefits that DNSSEC provides.
>

This really can not be overemphasized.  No one is suggesting that domain
holders be forced to implement DNSSEC.

What is being suggested is that ALL CAs be forced to abide formal DNSSEC
validation for those domains which have deployed DNSSEC as demonstrated by
presence of DS records deployed on the domain's label at the TLD name
servers.

Regarding the likelihood of DNSSEC implementation causing problems when
implemented, this is evidently a small enough problem that one of the
largest (or maybe the largest) retail ISPs in the USA formally validates
DNSSEC records on their customer facing recursive DNS servers.  Comcast
subscribers with default router/configuration will not resolve a DNS query
on a domain with DNSSEC implemented and for which there exists a DNSSEC
error of any critical sort.

That alone should be sufficient support for the notion that DNSSEC can be
deployed in a sufficiently stable manner that third parties may rely upon
it where enabled.

Furthermore, as was pointed out, Let's Encrypt and quite a number of other
CAs are already enforcing DNSSEC validation on CAA queries.  I suspect it's
not a significant cause of failures.

If we can just get CAA record checking to require DNSSEC validation and
then make one further change -- allowing CAA to further restrict acceptable
DV methods, domain holders will finally have a reasonable way to secure
against other parties achieving certificate acquisition for their domain
assets.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Quirin Scheitle via dev-security-policy]

Hi Jakob,

> As someone who has actually /removed/ DNSSEC from some domains after it
> caused serious ripling failures, the brokenness of DNSSEC does not come
> from how often DNSSEC fails to validate valid requests but from how
> easily DNSSEC can crash a domain, making it too risky to deploy.
> Requiring DNSSEC validation for processing of CAA records *does not* mean 
> that domains need to deploy DNSSEC.

This is not about whether or not domains should deploy DNSSEC. 
Domains are are their own right to decide whether or not they see DNSSEC fit 
for their environment.

We are saying that those domains having decided to deploy DNSSEC should get the 
additional benefits that DNSSEC provides.


>> Requiring DNSSEC validation for processing of CAA records *does not* mean 
>> that domains need to deploy DNSSEC.
> 
> 5. Denying CAA protection to those who cannot (in practice) deploy
>  DNSSEC only makes security worse, not better.
> 

I don’t know how to say this any more clearly. 
CAA protection would still exist for all domains. 
Those domains that have decided to deploy DNSSEC would get the additional 
benefits that DNSSEC provides.

Kind regards
Quirin
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Jakob Bohm via dev-security-policy]

On 25/04/2018 17:06, Quirin Scheitle wrote:



On 25. Apr 2018, at 16:11, Matthew Hardeman via dev-security-policy 
 wrote:

With the right combination of DNSSEC validation, CAA records as utilized today, 
 […]


Hi all,

I have advertised making DNSSEC validation mandatory for CAA before, bot have 
not been met by enthusiasm.
Main concerns were that there would be too many validation errors, or that 
DNSSEC is broken in general. (cf. related twitter “conversation” including  
Matthew and me [A]).

I agree that requiring DNSSEC validation for CAA would be an important first 
step to provide domain owners strong assurance of at least the CAA step.
Later, CAA can be extended to control more details about the issuance process 
[I have laid out couple in [B]].

Requiring DNSSEC validation for processing of CAA records *does not* mean that 
domains need to deploy DNSSEC.
It means that those domains that deploy DNSSEC (through a DS record at the 
parent zone) must deploy it correctly to pass CAA processing and hence obtain a 
certificate.
In other words, those domains deciding to deploy DNSSEC will be guaranteed its 
benefits.

Various facts indicate that the number of broken DNSSEC deployments is small:
[1] Let’sEncrypt apparently validates DNSSEC for validation
[2] Major public resolvers return SERVFAIL on broken DNSSEC setups (I 
know of 8.8.8.8, and assume quad9, quad1 as well)
[3] A corpus of recent scientific studies that reports validation 
errors far below 1% of signed domains [B,C,D]

[1] and [2] suggest that conducting DNSSEC validation does not cause harm at a 
large scale, hence the broken domains found by scientific studies [3] might 
actually not even be in use.



As someone who has actually /removed/ DNSSEC from some domains after it
caused serious ripling failures, the brokenness of DNSSEC does not come
from how often DNSSEC fails to validate valid requests but from how
easily DNSSEC can crash a domain, making it too risky to deploy.

Specifically:

1. DNSSEC treats expired signatures as mandatory failure even if no
  non-expired signatures exist.  Thus if the domain holder forgets to
  renew signatures, the entire domain crashes.  Such forgetfulness is
  more likely to occur in non-active periods, where the domain holder
  isn't (for example) ordering new certificates.

2. There is no system in place (e.g. at registrars) to notify domain
  holders that their DNSSEC signatures are about to expire.  Thus the
  first they might learn of it is when something breaks badly.  This is
  in contrast to e.g. expiring paid certificates, where CAs are often
  happy to send out reminders to renew.

3. If the DNSSEC private keys are stored in a secure offline system,
  each renewal of signatures by those keys require at least one manual
  intervention (transporting the signature from the off-line system to
  something online).  This increases the risk of situation 1 happening.

4. Therefore, for any domain holder that values uptime, use of DNSSEC is
  often a non-option, just like some other "recent" security standards
  that are similarly unforgiving.

5. Denying CAA protection to those who cannot (in practice) deploy
  DNSSEC only makes security worse, not better.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Quirin Scheitle via dev-security-policy]

> On 25. Apr 2018, at 16:11, Matthew Hardeman via dev-security-policy 
>  wrote:
> 
> With the right combination of DNSSEC validation, CAA records as utilized 
> today,  […]

Hi all,

I have advertised making DNSSEC validation mandatory for CAA before, bot have 
not been met by enthusiasm. 
Main concerns were that there would be too many validation errors, or that 
DNSSEC is broken in general. (cf. related twitter “conversation” including  
Matthew and me [A]).

I agree that requiring DNSSEC validation for CAA would be an important first 
step to provide domain owners strong assurance of at least the CAA step. 
Later, CAA can be extended to control more details about the issuance process 
[I have laid out couple in [B]]. 

Requiring DNSSEC validation for processing of CAA records *does not* mean that 
domains need to deploy DNSSEC. 
It means that those domains that deploy DNSSEC (through a DS record at the 
parent zone) must deploy it correctly to pass CAA processing and hence obtain a 
certificate. 
In other words, those domains deciding to deploy DNSSEC will be guaranteed its 
benefits.

Various facts indicate that the number of broken DNSSEC deployments is small:
[1] Let’sEncrypt apparently validates DNSSEC for validation
[2] Major public resolvers return SERVFAIL on broken DNSSEC setups (I 
know of 8.8.8.8, and assume quad9, quad1 as well)
[3] A corpus of recent scientific studies that reports validation 
errors far below 1% of signed domains [B,C,D]

[1] and [2] suggest that conducting DNSSEC validation does not cause harm at a 
large scale, hence the broken domains found by scientific studies [3] might 
actually not even be in use. 

Kind regards
Quirin

[A] https://twitter.com/_quirins/status/95865245085696?s=11
[B] https://caastudy.github.io
[C] https://www.usenix.org/node/203653
[D] 
https://www.semanticscholar.org/paper/Economic-Incentives-on-DNSSEC-Deployment%3A-Time-to-Le-Rijswijk-Deij/8a0cd805e9cafc4198da4120823686042a024420
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Matthew Hardeman via dev-security-policy]

>
> Multiple perspectives is useful when relying on any insecure third-party
> resource; for example DNS or Whois.
>
> This is different than requiring multiple validations of different types;
> an attacker that is able to manipulate the DNS validation at the IP layer
> is also likely going to be able to do the same for HTTP and Whois.
>

To Mr. Buschart's point, combining DNSSEC with an enhancement to CAA in
which the CAA responses can cause an opt-in limit to acceptable validation
methods, a scheme combining those elements would be the first mechanism for
a domain holder to ensure that CA issuance authorization (in the domain
validation scope) would be able to be, upon the domain holder's initiative,
locked to a mechanism that provides for cryptographic assertions from the
root zone down.  With the right combination of DNSSEC validation, CAA
records as utilized today, and an enhancement to CAA for locking down to
particular validation methodologies, domain holders can be handed a strong
tool to prevent the sorts of issuance to bad actors who can utilize a BGP
hijack today to meet the validation needs.

There's an extension to CAA in this spirit described here (this one is
specific to ACME methods):

https://tools.ietf.org/html/draft-ietf-acme-caa-03

To my knowledge, no one is implementing this as yet, but I'd love to see it
happen.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Matthew Hardeman via dev-security-policy]

On Wed, Apr 25, 2018 at 8:47 AM, Paul Wouters via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> BGP hijack at once. In the end, that's a numbers game with a bunch of
> race conditions. But hey, it might lead to actual BGP security getting
> deployed :)
>

I'm an in-the-wild BGP and peering practitioner and have been for quite a
while.  I've assisted numerous ISPs of various sizes in such matters.  I'm
not proud of the state of network interconnection, but I can say with all
seriousness that if you care about the integrity of DNS based domain
validation, DNSSEC integrity validation is the more achievable mitigation
for hijacked DNS infrastructure.  Actual BGP security is probably never
coming for all sorts of commercial incentives reasons.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Paul Wouters via dev-security-policy]

On Wed, 25 Apr 2018, Ryan Hurst via dev-security-policy wrote:


Multiple perspectives is useful when relying on any insecure third-party 
resource; for example DNS or Whois.

This is different than requiring multiple validations of different types; an 
attacker that is able to manipulate the DNS validation at the IP layer is also 
likely going to be able to do the same for HTTP and Whois.


which is why in the near future we can hopefully use RDAP over TLS (RFC
7481) instead of WHOIS, and of course since the near past, DNSSEC :)

I'm not sure how useful it would be to have multiple network points for
ACME testing - it will just lead to the attackers doing more then one
BGP hijack at once. In the end, that's a numbers game with a bunch of
race conditions. But hey, it might lead to actual BGP security getting
deployed :)

Paul
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Ryan Hurst via dev-security-policy]

On Wednesday, April 25, 2018 at 1:28:43 PM UTC+2, Buschart, Rufus wrote:
> Hi Ryan!
> 
> The "multiple perspective validations" is an interesting idea. Did you think 
> about combining it with CAA checking? I could imagine having a new tag, e.g. 
> "allowedMethods", in which the legitimate owner of  a domain can specify the 
> set of allowed methods to validate his domain. As an example the value 
> "(3.2.2.4.1 AND 3.2.2.4.5) OR 3.2.2.4.9" in the new "allowedMethods" tag 
> could mean, that a certificate may only be issued, if two validations acc. 
> 3.2.2.4.1 and 3.2.2.4.1 were successful or if one validation acc. 3.2.2.4.9 
> was successful. Any other method of validation would be not allowed. I see 
> here the benefit, that the owner of a domain can choose how to verify 
> according his business needs and select the appropriate level of security for 
> his domains.
> 
> With best regards,
> Rufus Buschart
> 

Multiple perspectives is useful when relying on any insecure third-party 
resource; for example DNS or Whois. 

This is different than requiring multiple validations of different types; an 
attacker that is able to manipulate the DNS validation at the IP layer is also 
likely going to be able to do the same for HTTP and Whois.

Ryan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy