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: Regional BGP hijack of Amazon DNS infrastructure

[Matthew Hardeman via dev-security-policy]

On Wed, Apr 25, 2018 at 1:44 PM, Santhan Raj via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> I did see the (ridiculously silly) self-signed certificate that was used,
> but the skeptic in me keeps questioning the timeline of this attack and
> recent multiple cert issuances,
>  - a self-signed cert created on 2018-03-23 and observed by Censys on
> 2018-03-29 (https://censys.io/certificates/4f151e2efd755fb1b9a4d50fa6db2a
> f0008dff02ffbef8178be54f9db6e86d75) I assume this is the cert used in the
> attack from the screenshots
>

That is what I have understood to be the case.


> - the self-signed cert was created exactly a year after the Amazon
> certificate was issued
> - the self-signed cert was used in an attack the day when/after the Amazon
> DV cert expired (April 23rd 2018)
>

My belief is that that was coincidence, if the date of the attack is
significant, it was at or closely before days in which more CAs would begin
CT logging  of all their certificate issuances.

- additionally, and this may have nothing to do with the attack, 3 distinct
> EV certs issued to myetherwallet.com by Digicert and Comodo on 2018-03-30
> and 2018-03-31, even though the existing EV cert (issued by Digicert) was
> still valid
> - https://crt.sh/?id=370369641
> - https://crt.sh/?id=371216075
> - https://crt.sh/?id=378737050


These three are not weird.  They were all obviously acquired in near time
to each other and there is a rational explanation.

If EV certificate is important to you and if you're a professional in these
matters, it is not unlikely that you would purchase redundant certificates
from two different CAs with entirely different trust hierarchies.  This
ensures that you already have in-hand a new TLS certificate in case either
CA has a loss of trust issue, etc.  The two from Digicert reflect two
different key lengths.  They requested both a 2048-bit version of the
certificate as well as a 4096 bit version of the certificate.

As EV certificates can take some time to acquire, it is not uncommon for a
professional to have multiple simultaneous certificate instances in-hand so
that another certificate is already on hand to replace the one that has a
problem.  (Key compromise of operating certificate, CA distrust, revocation
by CA for reasons, etc.)


>
>
> Again, I'm obviously speculating and all this could be coincidence and
> business as usual, but if I were writing this crime novel, the plot
> wouldn't be "1-2 days of attack to steal $150K" but "a year of silent
> attack to steal $17M and get caught due to an expired cert". Why would
> anyone with $17M want to go through all this trouble to steal just another
> $150K?
>

There's the question everyone wants answers to.  The attacker demonstrated
some sophistication.  No one has suggested any significant part of that
Ethereum came from any prior compromise of MyEtherWallet.com.  I myself
wonder if the attack on myetherwallet.com was a "bonus" or side-job,
designed to be the publicly acknowledged reason for the attack and to stop
people digging further.  The question which remains is what else might the
attackers have done -- and who was or will be impacted -- during the two
hour window they opened.

It is on that basis I am especially interested to know what DNS validation
attempts were attempted across the various CAs during that time period
which relied upon responses to queries sent to any destination within the
set of impacted prefixes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require CAs to support problem reports via email

[Wayne Thayer via dev-security-policy]

On Fri, Apr 20, 2018 at 12:33 PM, Wayne Thayer  wrote:

> At this point we have a few choices:
>
> 1. Do nothing about requiring email as a problem reporting mechanism.
> Instead, take on the related issues of disclosure of the reporting
> mechanism and receipt confirmation in Mozilla policy, via the CAB Forum, or
> both.
> 2. Go ahead with the proposal to require email, but allow CAs to require
> some special, but standardized identifier be placed in the message that
> they can filter on. For example, CAs could ignore messages sent to their
> problem reporting address unless the subject contains the phrase "problem
> report".
> 3. Develop some new problem reporting mechanism that solves the problems
> with email and forms. For example, we could require CAs to accept problem
> reports posted to this list, but build in some additional time in which to
> "receive" the report by reading list messages. Or we could require CAs to
> accept problem reports via Bugzilla. We already see problems being reported
> via these mechanisms and require CAs to monitor both of them, just not on a
> 24x7 basis.
>
> The first option ('do nothing') is currently in the lead, so I would
> especially like to hear from anyone who wants to argue for a different
> solution.
>
>
This discussion has resulted in no agreed-upon changes to the Mozilla
policy. I will close the issue on GitHub [1], and I also plan to propose a
CAB Forum ballot that includes the requirement for CAs to disclose their
problem reporting mechanism in section 1.5.2 of their CPS.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/98
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Regional BGP hijack of Amazon DNS infrastructure

[Nick Lamb via dev-security-policy]

On Wed, 25 Apr 2018 09:42:43 -0700 (PDT)
Santhan Raj via dev-security-policy
 wrote:

> What is interesting to me is the DV certificate that Amazon had
> issued for myetherwallet.com (https://crt.sh/?id=108721338) and this
> certificate expired on Apr 23rd 2018. 
> 
> Could it be that the attackers were using this cert all along in
> place of a EV cert? ___

I have not been able to view this link for some reason. However I can
say that I've seen screenshots alleged to be of the Cert Viewer on a
Windows PC connected to the attacker site, and it's hilariously bogus,
it's a self-signed certificate with CA:TRUE set, and the site's name as
Common Name, it looks like if somebody with no previous exposure to the
Web PKI tried to make a certificate based on some random blog post or
old Youtube tutorial. e.g.

https://twitter.com/GossiTheDog/status/988785871188045825

There's no way this was ever valid, anywhere. If it's what was actually
used (and I have no reason to believe it wasn't) the attackers relied
upon the Dancing Pig effect to get their job done.

Maybe we're actually lucky they didn't get a newer tutorial that taught
them to use ACME.


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

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Wayne Thayer via dev-security-policy]

On Wed, Apr 25, 2018 at 8:01 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 20/04/2018 21:59, Wayne Thayer wrote:
>
>> On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> I believe the wording "insecure electronic channels" leaves a lot of space
>>> for interpretation. In corporate PKIs for email encryption it is quite
>>> common to transfer centrally generated email encryption p12-files to
>>> mobile
>>> device management systems, email encryption gateways or directly to
>>> mobile
>>> devices using a wide variety of 'electronic channels'. From the proposed
>>> wording it doesn't seem to be clear which of those channels are
>>> 'insecure'
>>> and which not. Even if not that common, the same applies for email
>>> signature p12-files for e.g. email signature on mail gateways or mobile
>>> devices. Most of the mobile devices out in the field neither support
>>> hardware token, key-pair-generation in the mailer software nor
>>> installation
>>> of downloaded p12-files (prohibited by app sandboxing).
>>>
>>> Maybe it would be possible to restrict the new wording to the EKU
>>> kp-ServerAuth first and have a detailed discussion about email-encryption
>>> and user authentication with more interested parties in the next months?
>>>
>>>
>> Again, this is not new wording. It's already a requirement:
>> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practic
>> es#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
>>
>> Having said that, could we instead be more specific by replacing "insecure
>> electronic channels" with "unencrypted email"? Limiting the scope of this
>> statement to id-kp-serverAuth is meaningless since we forbid CA key
>> generation for server certificates.
>>
>>
> That would allow unencrypted HTTP, unencrypted FTP, unencrypted TFTP
> etc. etc.  It would also allow 40 bit encrypted connections (they are
> insecure but unencrypted).  The list of insecure electronic channels is
> infinite.
>
> The original intent appears to have been to forbid using email to transmit
PKCS#12 files because it includes the following bullet [1]:
* The distribution channels used (e.g. unencrypted email) may not be
adequately secured.

The original phrase "insecure electronic channels" does encompass more but
is also vague enough to be easily misinterpreted.

Perhaps the phrase "unencrypted electronic channels" is a better solution?
I would welcome other suggestions.

[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_
Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Regional BGP hijack of Amazon DNS infrastructure

[Matthew Hardeman via dev-security-policy]

Also, during the period of the attack, they were using a self-signed
certificate.

As yet there's no public evidence that they achieved issuance of any
certificate.  There is some question as to whether they could have.

On Wed, Apr 25, 2018 at 12:32 PM, Matthew Hardeman 
wrote:

> I seriously doubt that.
>
> MyEtherWallet.com is/was hosted on Amazon CloudFront, and I believe the
> private keys for those certs stay locked at Amazon.  That was likely the
> starter cert that MyEtherWallet.com first went with before securing an EV
> cert.
>
> On Wed, Apr 25, 2018 at 11:42 AM, Santhan Raj via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Wednesday, April 25, 2018 at 1:57:28 AM UTC-7, Ryan Hurst wrote:
>> > On Tuesday, April 24, 2018 at 5:29:05 PM UTC+2, Matthew Hardeman wrote:
>> > > This story is still breaking, but early indications are that:
>> > >
>> > > 1.  An attacker at AS10297 (or a customer thereof) announced several
>> more
>> > > specific subsets of some Amazon DNS infrastructure prefixes:
>> > >
>> > > 205.251.192-.195.0/24 205.251.197.0/24 205.251.199.0/24
>> > >
>> > > 2.  It appears that AS10297 via peering arrangement with Google got
>> > > Google's infrastructure to buy (accept) the hijacked advertisements.
>> > >
>> > > 3.  It has been suggested that at least one of the any cast 8.8.8.8
>> > > resolvers performed resolutions of some zones via the hijacked
>> targets.
>> > >
>> > > It seems prudent for CAs to look into this deeper and scrutinize any
>> domain
>> > > validations reliant in DNS from any of those ranges this morning.
>> >
>> > This is an example of why ALL CA's should either already be doing
>> multi-perspective domain control validation or be working towards that in
>> the very near future.
>> >
>> > These types of attacks are far from new, we had discussions about them
>> back in the early 2000s while at Microsoft and I know we were not the only
>> ones. One of the earlier papers I recall discussing this topic was from the
>> late 08 timeframe from CMU - https://www.cs.cmu.edu/~dga/pa
>> pers/perspectives-usenix2008/
>> >
>> > The most recent work on this I am aware of is the Princeton paper from
>> last year: http://www.cs.princeton.edu/~jrex/papers/bamboozle18.pdf
>> >
>> > As the approved validation mechanisms are cleaned up and hopefully
>> reduced to a limited few with known security properties the natural next
>> step is to require those that utilize these methods to also use multiple
>> perspective validations to mitigate this class of risk.
>> >
>> > Ryan Hurst (personal)
>>
>> What is interesting to me is the DV certificate that Amazon had issued
>> for myetherwallet.com (https://crt.sh/?id=108721338) and this
>> certificate expired on Apr 23rd 2018.
>>
>> Could it be that the attackers were using this cert all along in place of
>> a EV cert?
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Wayne Thayer via dev-security-policy]

On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi  wrote:

> I'm not sure I underestand the use case. I'm hoping that they can clarify
> more.
>
> Pedro - can you explain more about why this is important?

That is, it would seem valuable as part of the technical constraint
> exercise to ensure the EKUs are restsricted. This is particularly true due
> to how nameConstraints work - they are blacklists (effectively), rather
> than whitelists, which means that combined with EKUs, they can be used for
> unconstrained purposes.
>
> Similar to the discussions regarding nameConstraints and name types, this
> has the effect of discouraging the introduction of new EKUs, as such
> intermediates would be unconstrained for these potential new and novel EKU
> use cases.
>
> Ryan - can you explain this concern in more detail? If, for instance, the
srvName type was added for TLS certificates, new intermediates would be
required to constrain that name type due to the "fail open" nature of name
constraints. If a single intermediate contained both the serverAuth and
emailProtection EKUs, how does that make the situation worse? Is it just
that now all of the S/MIME certificates issued under the intermediate  must
also expire or be replaced so that the old intermediate (without a
constraint on srvName) can be revoked?

On Mon, Apr 23, 2018 at 3:42 PM, Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Sun, Apr 22, 2018 at 2:56 PM, pfuentes69--- via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > I think you should consider an an exception Issuing CAs including Name
>> > Constraints. This would keep allowing root signing services for
>> corporate
>> > CAs without forcing multiple CAs.
>> >
>>
>> Thank you for the suggestion. It seems reasonable to me. If no one
>> objects,
>> I will move the proposed language to section 5.3.2 so that it applies only
>> to unconstrained intermediates.
>>
>> - Wayne
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Regional BGP hijack of Amazon DNS infrastructure

[Santhan Raj via dev-security-policy]

On Wednesday, April 25, 2018 at 1:57:28 AM UTC-7, Ryan Hurst wrote:
> On Tuesday, April 24, 2018 at 5:29:05 PM UTC+2, Matthew Hardeman wrote:
> > This story is still breaking, but early indications are that:
> > 
> > 1.  An attacker at AS10297 (or a customer thereof) announced several more
> > specific subsets of some Amazon DNS infrastructure prefixes:
> > 
> > 205.251.192-.195.0/24 205.251.197.0/24 205.251.199.0/24
> > 
> > 2.  It appears that AS10297 via peering arrangement with Google got
> > Google's infrastructure to buy (accept) the hijacked advertisements.
> > 
> > 3.  It has been suggested that at least one of the any cast 8.8.8.8
> > resolvers performed resolutions of some zones via the hijacked targets.
> > 
> > It seems prudent for CAs to look into this deeper and scrutinize any domain
> > validations reliant in DNS from any of those ranges this morning.
> 
> This is an example of why ALL CA's should either already be doing 
> multi-perspective domain control validation or be working towards that in the 
> very near future.
> 
> These types of attacks are far from new, we had discussions about them back 
> in the early 2000s while at Microsoft and I know we were not the only ones. 
> One of the earlier papers I recall discussing this topic was from the late 08 
> timeframe from CMU - 
> https://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008/
> 
> The most recent work on this I am aware of is the Princeton paper from last 
> year: http://www.cs.princeton.edu/~jrex/papers/bamboozle18.pdf
> 
> As the approved validation mechanisms are cleaned up and hopefully reduced to 
> a limited few with known security properties the natural next step is to 
> require those that utilize these methods to also use multiple perspective 
> validations to mitigate this class of risk.
> 
> Ryan Hurst (personal)

What is interesting to me is the DV certificate that Amazon had issued for 
myetherwallet.com (https://crt.sh/?id=108721338) and this certificate expired 
on Apr 23rd 2018. 

Could it be that the attackers were using this cert all along in place of a EV 
cert?
___
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: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

[Jakob Bohm via dev-security-policy]

On 20/04/2018 21:59, Wayne Thayer wrote:

On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


I believe the wording "insecure electronic channels" leaves a lot of space
for interpretation. In corporate PKIs for email encryption it is quite
common to transfer centrally generated email encryption p12-files to mobile
device management systems, email encryption gateways or directly to mobile
devices using a wide variety of 'electronic channels'. From the proposed
wording it doesn't seem to be clear which of those channels are 'insecure'
and which not. Even if not that common, the same applies for email
signature p12-files for e.g. email signature on mail gateways or mobile
devices. Most of the mobile devices out in the field neither support
hardware token, key-pair-generation in the mailer software nor installation
of downloaded p12-files (prohibited by app sandboxing).

Maybe it would be possible to restrict the new wording to the EKU
kp-ServerAuth first and have a detailed discussion about email-encryption
and user authentication with more interested parties in the next months?



Again, this is not new wording. It's already a requirement:
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files

Having said that, could we instead be more specific by replacing "insecure
electronic channels" with "unencrypted email"? Limiting the scope of this
statement to id-kp-serverAuth is meaningless since we forbid CA key
generation for server certificates.



That would allow unencrypted HTTP, unencrypted FTP, unencrypted TFTP
etc. etc.  It would also allow 40 bit encrypted connections (they are
insecure but unencrypted).  The list of insecure electronic channels is
infinite.


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]

>
> 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

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

[Buschart, Rufus via dev-security-policy]

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

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322


> -Ursprüngliche Nachricht-
> Von: dev-security-policy
> [mailto:dev-security-policy-bounces+rufus.buschart=siemens.com@lists.m
> ozilla.org] Im Auftrag von Ryan Hurst via dev-security-policy
> Gesendet: Mittwoch, 25. April 2018 10:57
> An: mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: Regional BGP hijack of Amazon DNS infrastructure
> 
> On Tuesday, April 24, 2018 at 5:29:05 PM UTC+2, Matthew Hardeman wrote:
> > This story is still breaking, but early indications are that:
> >
> > 1.  An attacker at AS10297 (or a customer thereof) announced several 
> > more specific subsets of some Amazon DNS infrastructure prefixes:
> >
> > 205.251.192-.195.0/24 205.251.197.0/24 205.251.199.0/24
> >
> > 2.  It appears that AS10297 via peering arrangement with Google got 
> > Google's infrastructure to buy (accept) the hijacked advertisements.
> >
> > 3.  It has been suggested that at least one of the any cast 8.8.8.8 
> > resolvers performed resolutions of some zones via the hijacked targets.
> >
> > It seems prudent for CAs to look into this deeper and scrutinize any 
> > domain validations reliant in DNS from any of those ranges this morning.
> 
> This is an example of why ALL CA's should either already be doing 
> multi-perspective domain control validation or be working towards that in the 
> very near future.
> 
> These types of attacks are far from new, we had discussions about them 
> back in the early 2000s while at Microsoft and I know we were not the 
> only ones. One of the earlier papers I recall discussing this topic 
> was from the late 08 timeframe from CMU - 
> https://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008/
> 
> The most recent work on this I am aware of is the Princeton paper from last 
> year:
> http://www.cs.princeton.edu/~jrex/papers/bamboozle18.pdf
> 
> As the approved validation mechanisms are cleaned up and hopefully 
> reduced to a limited few with known security properties the natural next step 
> is to require those that utilize these methods to also use multiple 
> perspective validations to mitigate this class of risk.
> 
> Ryan Hurst (personal)
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Regional BGP hijack of Amazon DNS infrastructure

[Ryan Hurst via dev-security-policy]

On Tuesday, April 24, 2018 at 5:29:05 PM UTC+2, Matthew Hardeman wrote:
> This story is still breaking, but early indications are that:
> 
> 1.  An attacker at AS10297 (or a customer thereof) announced several more
> specific subsets of some Amazon DNS infrastructure prefixes:
> 
> 205.251.192-.195.0/24 205.251.197.0/24 205.251.199.0/24
> 
> 2.  It appears that AS10297 via peering arrangement with Google got
> Google's infrastructure to buy (accept) the hijacked advertisements.
> 
> 3.  It has been suggested that at least one of the any cast 8.8.8.8
> resolvers performed resolutions of some zones via the hijacked targets.
> 
> It seems prudent for CAs to look into this deeper and scrutinize any domain
> validations reliant in DNS from any of those ranges this morning.

This is an example of why ALL CA's should either already be doing 
multi-perspective domain control validation or be working towards that in the 
very near future.

These types of attacks are far from new, we had discussions about them back in 
the early 2000s while at Microsoft and I know we were not the only ones. One of 
the earlier papers I recall discussing this topic was from the late 08 
timeframe from CMU - https://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008/

The most recent work on this I am aware of is the Princeton paper from last 
year: http://www.cs.princeton.edu/~jrex/papers/bamboozle18.pdf

As the approved validation mechanisms are cleaned up and hopefully reduced to a 
limited few with known security properties the natural next step is to require 
those that utilize these methods to also use multiple perspective validations 
to mitigate this class of risk.

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