IdenTrust Missing Thumbprints In Some Annual Audit Reports

2019-10-11 Thread IdenTrust Inc via dev-security-policy
We created this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1588213
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DNS records and delegation

2019-10-11 Thread Ryan Sleevi via dev-security-policy
On Fri, Oct 11, 2019 at 3:14 PM Doug Beattie 
wrote:

> Ryan,
>
> Are you recommending that:
> a) we need a new domain validation method that describes this, or
> b)  those CAs that want to play with fire can go ahead and do that based on
> their own individual security analysis, or
> c) we need a clear policy/guideline in the BRs or root program that MUST be
> followed when the CAs (maybe other entities) are updating DNS with random
> values?
>
> I'm pretty sure I know the answer (none of the above).
>

I'm suggesting the BRs forbid this (and the other examples) from being done
by CAs today, so (b) is not an option. This is the same as the BRs
forbidding a CA from, say, using the serial number in a certificate they
issue to act as a 'continuous authorization' for issuance.

I'm totally open for a discussion about (a)/(c) - done correctly, it would
allow us to achieve the ideal property, that:
1) We constantly go back to the DNS as the source of truth. For example, we
could remove the reuse of validation data entirely here / reduce it to
something small (like 5 minutes).
2) The domain name owner can voluntarily decide to make a continual
authorization to a CA /for their account/, just like they can make a
continual authorization to their hosting provider or other authorized entity

There are a variety of challenges that could cause things to go wrong. We'd
need to address those. They might be insurmountable, but it's worth
discussing. This seems like potentially something suited for the IETF ACME
WG, especially for the nuances of the security properties and ensuring wide
review, not just among CAs and a few browsers.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: DNS records and delegation

2019-10-11 Thread Doug Beattie via dev-security-policy
Ryan,

Are you recommending that:
a) we need a new domain validation method that describes this, or 
b)  those CAs that want to play with fire can go ahead and do that based on
their own individual security analysis, or
c) we need a clear policy/guideline in the BRs or root program that MUST be
followed when the CAs (maybe other entities) are updating DNS with random
values?  

I'm pretty sure I know the answer (none of the above).



-Original Message-
From: dev-security-policy  On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Friday, October 11, 2019 2:40 PM
To: Clint Wilson 
Cc: Ryan Sleevi ; mozilla-dev-security-policy
; Jeremy Rowley

Subject: Re: DNS records and delegation

On Fri, Oct 11, 2019 at 2:10 PM Clint Wilson  wrote:

> Apologies, but this isn't entirely clear to me. I'm guessing (hoping) 
> my misunderstanding centers around a difference between the Applicant 
> fully delegating DNS to the CA vs the Applicant only configuring a 
> single CNAME record? If the Applicant has configured 
> _validation.sleevi.example 3600 IN CNAME .ca.example then 
> the CA wouldn't be able to use any other  value to complete 
> the full lookup to include the TXT record, without the Applicant 
> directly changing the CNAME value.
>
> However, if the CA is fully managing this DNS, and therefore able to 
> independently reconfigure:
> _validation.sleevi.example 3600 IN CNAME .ca.example to 
> _validation.sleevi.example 3600 IN CNAME 
> .ca.example
> that's clearly a very different story.
> Is it correct to think of these as two different scenarios? In my 
> mind, the first scenario is the one I'm most interested in.
>

It's my fault for not being clearer of the example.

You can think of  as an ID computed from the domain being
requested - e.g. "sleevi.example" - rather than the account doing the
requesting (the Applicant).

In that scenario, when Evil Hacker, the Applicant, requests a cert for
sleevi.example, the CA doesn't look at the Applicant-ID. They look to see if
the domain - e.g. sleevi.example - is one that is signed up to use their
service. If so, they modify the records, and now Evil Hacker has access.

I tried to clarify this later on, that it's possible to design around; for
example, by using .ca.example. This is closer to what AWS
does.

There are /still/ risks with that approach though, in terms of greater
centralization of risk. Using the AWS example, if you wanted to get a
malicious cert for sleevi.example, you'd either need to compromise my DNS
provider, my DNS registrar, or my AWS account. Using the 
example, with the CA hosting, you'd either need to compromise my DNS
provider, my DNS registrar, or... well, the CA's systems.

Allowing the CA to do this sort of flow creates real challenges, because
they're the only ones that can issue certs. For example, the CA could refuse
to use that TXT method for anyone who doesn't point to them (e.g.
who uses AWS instead of the CA). It might seem odd to suggest that CAs might
refuse issuance, but we see it all the time. After all, the whole reason we
have so many trusted CAs is because there are a number (particularly the
European CAs) that want to refuse issuance on grounds of who is applying or
how they're applying (e.g. ETSI EN 319 411-et-al forbidding automation
entirely!). So we know CAs can try to lock folks in, and we also know that
CAs' incentives, around user/account security, are not necessarily the same
as might exist with a third-party provider like AWS.

I realize that seems like I'm suggesting a lot of ill-intent. I'm simply
trying to threat-model both the systemic weaknesses and the economic
incentives. If we allow the CAs to do this, it seems like we'd need even
stronger rules regarding Subscriber/CA authentication and identification,
and that... would likely be controversial and complex, to say the least ;)


Would there be a benefit to something like having  (or
>  as discussed further below) published in CAA as well? i.e.
> the Applicant publishes a whitelist of valid  values to 
> be used in this type of validation-delegation-schema? I haven't 
> thought this through fully, but it seems like it could help with 
> explicitly codifying the requirements, especially if the CAA record is 
> published at sleevi.example?
>

That's functionally what AWS is doing - it's using  instead of
 as the binding, and pushing that in the hop.


> This would suggest that we don't want the CA doing it, because the CA 
> is
>> not the Applicant, and the goal of 3.2.2.4 is to make sure the 
>> Applicant can demonstrate control.
>>
>> Another way of looking at this is imagining the following?
>> - Do we think it's allowed by the BRs for the domain operator to set 
>> their MX to be the CA, so the CA can auto-answer their own emails 
>> sent under 3.2.2.4.4.?
>>
> - Do we think it's allowed by the BRs for the domain operator to give 
> the
>> CA FTP/SSH/file upload access to /.well-known/pki-validation, so that 
>> the CA can place the answer file 

Re: DNS records and delegation

2019-10-11 Thread Ryan Sleevi via dev-security-policy
On Fri, Oct 11, 2019 at 2:10 PM Clint Wilson  wrote:

> Apologies, but this isn't entirely clear to me. I'm guessing (hoping) my
> misunderstanding centers around a difference between the Applicant fully
> delegating DNS to the CA vs the Applicant only configuring a single CNAME
> record? If the Applicant has configured
> _validation.sleevi.example 3600 IN CNAME .ca.example
> then the CA wouldn't be able to use any other  value to
> complete the full lookup to include the TXT record, without the Applicant
> directly changing the CNAME value.
>
> However, if the CA is fully managing this DNS, and therefore able to
> independently reconfigure:
> _validation.sleevi.example 3600 IN CNAME .ca.example
> to
> _validation.sleevi.example 3600 IN CNAME
> .ca.example
> that's clearly a very different story.
> Is it correct to think of these as two different scenarios? In my mind,
> the first scenario is the one I'm most interested in.
>

It's my fault for not being clearer of the example.

You can think of  as an ID computed from the domain being
requested - e.g. "sleevi.example" - rather than the account doing the
requesting (the Applicant).

In that scenario, when Evil Hacker, the Applicant, requests a cert for
sleevi.example, the CA doesn't look at the Applicant-ID. They look to see
if the domain - e.g. sleevi.example - is one that is signed up to use their
service. If so, they modify the records, and now Evil Hacker has access.

I tried to clarify this later on, that it's possible to design around; for
example, by using .ca.example. This is closer to what AWS
does.

There are /still/ risks with that approach though, in terms of greater
centralization of risk. Using the AWS example, if you wanted to get a
malicious cert for sleevi.example, you'd either need to compromise my DNS
provider, my DNS registrar, or my AWS account. Using the 
example, with the CA hosting, you'd either need to compromise my DNS
provider, my DNS registrar, or... well, the CA's systems.

Allowing the CA to do this sort of flow creates real challenges, because
they're the only ones that can issue certs. For example, the CA could
refuse to use that TXT method for anyone who doesn't point to them (e.g.
who uses AWS instead of the CA). It might seem odd to suggest that CAs
might refuse issuance, but we see it all the time. After all, the whole
reason we have so many trusted CAs is because there are a number
(particularly the European CAs) that want to refuse issuance on grounds of
who is applying or how they're applying (e.g. ETSI EN 319 411-et-al
forbidding automation entirely!). So we know CAs can try to lock folks in,
and we also know that CAs' incentives, around user/account security, are
not necessarily the same as might exist with a third-party provider like
AWS.

I realize that seems like I'm suggesting a lot of ill-intent. I'm simply
trying to threat-model both the systemic weaknesses and the economic
incentives. If we allow the CAs to do this, it seems like we'd need even
stronger rules regarding Subscriber/CA authentication and identification,
and that... would likely be controversial and complex, to say the least ;)


Would there be a benefit to something like having  (or
>  as discussed further below) published in CAA as well? i.e.
> the Applicant publishes a whitelist of valid  values to be
> used in this type of validation-delegation-schema? I haven't thought this
> through fully, but it seems like it could help with explicitly codifying
> the requirements, especially if the CAA record is published at
> sleevi.example?
>

That's functionally what AWS is doing - it's using  instead
of  as the binding, and pushing that in the hop.


> This would suggest that we don't want the CA doing it, because the CA is
>> not the Applicant, and the goal of 3.2.2.4 is to make sure the Applicant
>> can demonstrate control.
>>
>> Another way of looking at this is imagining the following?
>> - Do we think it's allowed by the BRs for the domain operator to set their
>> MX to be the CA, so the CA can auto-answer their own emails sent under
>> 3.2.2.4.4.?
>>
> - Do we think it's allowed by the BRs for the domain operator to give the
>> CA FTP/SSH/file upload access to /.well-known/pki-validation, so that the
>> CA can place the answer file on the server, and then request it as the CA,
>> under 3.2.2.4.6?
>> - Do we think it's allowed by the BRs for the domain owner to set an email
>> of domain-id@ca.example using 3.2.2.4.13 / 3.2.2.4.14, and allowing the
>> CA
>> to self-acknowledge that e-mail?
>>
>> I seem to recall that there is a provision in the BRs that would prohibit
>> this, at least in that none of the above (in the CA-controlled example)
>> are
>> demonstrating the Applicant themselves has control. And we certainly know
>> from the above example that it could go quite poorly if naively
>> implemented, so that's probably the right thing.
>>
>
> Agreed with the conclusion, though I can't find a clear statement to this
> effect so it remains 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-10-11 Thread Paul Walsh via dev-security-policy
Everything I have ever said on this thread can now be found in one article:

https://casecurity.org/2019/10/10/the-insecure-elephant-in-the-room/

This was by invitation of the CA Security Council a few months ago.

I have never worked for a CA and I have never had any reason to say anything in 
favor of CA’s or EV certificates. This is important to say because some people 
will automatically assume that I’m on one side of this debate. 

A few people asked me off-list for my “white paper”. I don’t have one. But this 
has more than 5,000 words and will likely be turned into one - if I can find 
someone to clean it up and make it better. 

Thanks,
Paul

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


Re: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-10-11 Thread Paul Walsh via dev-security-policy
I’ve replied for the record even though you say this is your last post on this 
particular thread, or to me. I’m good with that as I don’t think you care about 
what anything anyone says outside the browser vendor world anyway. 

> On Oct 9, 2019, at 5:09 PM, Ryan Sleevi  wrote:
> 
> 
> 
> On Wed, Oct 9, 2019 at 7:17 PM Paul Walsh  > wrote:
> We can all agree that almost no user knows the difference between a site with 
> a DV cert and a site with an EV cert. I personally came to that conclusion 
> years ago. I wanted data, so I asked more than 3,000 people. Almost everyone 
> assumed the padlock represents identity/safety. 
> 
> If you read the research linked, you'll find it specifically addresses this, 
> and points to the fact that positive security indicators lead to inaccurate 
> conclusions like this, whether EV or DV, and thus important to remove them to 
> assure folks do not make attribution errors.

[PW] Our data with 85,000 active users proves otherwise. And you’ve done 
nothing to counter anything I actually said. I can’t find any product screen 
shots that users used when researching ***new*** visual indicators for website 
identity. Research on EV/DV is completely meaningless as we’ve already 
established that browser implementation was poor at best.

> 
> Since the you later glibly joke about taking your e-mails as a post and 
> publishing as a PDF and calling it peer reviewed, I think it's reasonable to 
> conclude you didn't actually read the links, nor look at the publication 
> venues, or that you don't recognize and/or respect them as leading scientific 
> and academic conferences at the forefront of the space and industry you 
> participate in.

Generally, I question everything that Google has to say about anything in 
relation to privacy and security - so there is a lack of respect in regards to 
motives. But that doesn’t mean I don’t read them. And it doesn’t mean I don’t 
have friends who work for Google. My comment about me PDF’ing something was me 
making fun of myself - it had nothing to do with my opinions about other 
people’s work. I’m not an academic. I never even went to university, so my 
writing skills aren’t as good as anyone who actually writes papers like the 
ones you referenced. What I write is based on real world use cases - not 
theory-based research. They are very different and both are important. 

>  
> I can cite research for search annotation through a browser add-on (2007). It 
> was formally endorsed by the W3C Semantic Web Education and Outreach Program 
> as one of the most compelling implementations of the Semantic Web. But it’s 
> out of date and doesn’t answer the right questions. But here it is 
> https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ 
> 
> 
> Thanks. This helps confirm that it was not peer reviewed research, but a 
> marketing case study, completed in 2007.

[PW] This one in particular was reviewed in great detail by all of the W3C 
Semantic Web Education & Outreach participants. They reviewed and voted that it 
was “one of the most compelling implementations of the Semantic Web”. Segala 
and its work was then used as a use case for the W3C POWDER initiative, which 
formally replaced PICS in 2009. But it’s all very old and out of date - that 
was the point I was actually trying to make. 

https://www.w3.org/blog/SWEO/ 
>  
>> Do you have any peer-reviewed data to support your beliefs? It seemed like 
>> the only data shared was from vendors marketing solutions in this space, 
>> although perhaps it was overlooked.
> 
> [PW] Perhaps you did overlook it - hard to say as you didn’t reply to the 
> thread that contained the data. 
> 
> Apologies, the volume of the mail you write, versus the new data provided, 
> makes it difficult. Since I must have missed it, it might be useful to 
> provide specific links to your message, or better yet, specific links to the 
> data that has undergone the similar level of scientific rigor and 
> well-respected peer-review.

[PW]  You’re right about my messages - but it’s because people are asking me 
the same questions that have already been answered - but rather than say that, 
I prefer to reply. If you want “peer-review” evidence please stop referencing 
Google and reference companies that aren’t biased and who actually have other 
stakeholders and users best interests in mind. Unless there were non-Google 
employees involved, in which case I would apologize. 

>  
> [PW] Why haven’t you provided any insight to suggest why I’m wrong, instead 
> of asserting that I haven’t provided evidence to back up my assertions? 
> 
> https://twitter.com/krelnik/status/472046082135162881 
> 
> 
> If you review the links provided, you will see that the claims made in your 
> prior e-mail are directly, and easily, contradicted, as being both 

Re: DNS records and delegation

2019-10-11 Thread Cynthia Revström via dev-security-policy
Hello,

I just want to add that Let's Encrypt also allows for this (at least if I
understand what you correctly)

This following is from https://letsencrypt.org/docs/challenge-types/
> Since Let’s Encrypt follows the DNS standards when looking up TXT records
for DNS-01 validation, you can use CNAME records or NS records to delegate
answering the challenge to other DNS zones. This can be used to delegate
the _acme-challenge subdomain to a validation-specific server or zone. It
can also be used if your DNS provider is slow to update, and you want to
delegate to a quicker-updating server.

Now you don't delegate it to Let's Encrypt, however you can delegate it to
a hosting provider or similar, which seems to be about the same as what AWS
is doing if I understand you correctly.

- Cynthia Revström

On Fri, Oct 11, 2019 at 7:32 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Oct 10, 2019 at 11:42 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Question, is there any prohibition against demonstration of domain
> control
> > being delegated to a third party or even the CA itself? I don't think so,
> > but figured we've discussed differences in interpretation a lot lately so
> > wanted to see if people agreed.
> >
>
> Huge thanks for bringing this up early :) Definitely the example for all
> CAs :)
>
> That said, you probably could have worded better, "demonstration of domain
> control being delegated to a third party" is... probably not the best way
> of framing ;)
>
>
> > I mean, the obvious issue is the customer.com domain would need to want
> > to delegate this domain.com. But if you had a pretty non-technical
> person
> > operating the DNS, they could set it to the domain.com name and leave
> > their DNS settings forever.
> >
> > This looks allowed under the BRs, but should it be? Or is it like key
> > escrow - okay if a reseller does it (but frowned upon). Totally not cool
> if
> > the CA does it.
> >
>
> This is definitely a good way of looking at it!
>
> I'm familiar with at least one CA using an approach like this - Amazon
> Trust Services, with
> https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html
> .
> There's subtlety here, though, which is why I like how you drew the
> comparison to key escrow.
>
> On first glance, it seems Amazon Trust Services is issuing certificates to
> Amazon Web Services, both (through a complex structure) Affiliates, on
> behalf of the user. And so it might seem that the user is pointing their
> DNS to the CA, and that's how it's working.
>
> However, when you look through the CCADB disclosures, along with the
> certificates actually issued, it's clearer that the user is pointing those
> records to Amazon Web Services, but the actual issuing CA is DigiCert (as
> disclosed at https://www.amazontrust.com/repository/ ). It's also the case
> that, if you look at how things are setup, the domain holder isn't the one
> applying for the certificate - it's Amazon Web Services applying for the
> certificate (i.e. they are the Applicant, not the domain owner), and AWS
> configuring their own DNS records to contain a random value, to demonstrate
> to the CA (DigiCert) that AWS, the Applicant, is authorized for the domain.
>
> It's a really elegant solution, but it turns out it's not a "CA
> self-dealing" kind of thing, which would have been useful as an example if
> it was already allowed.
>
> Now let's discuss how this idea could all go wrong, because it teases out a
> little why the question of who is Applicant is relevant and important to
> understanding.
>
> Let's imagine that I setup the following (and I'm going to butcher this
> pseudo-code, so bear with me)
> _validation.sleevi.example 3600 IN CNAME .ca.example
> .ca.example 1 IN CNAME .random.ca.example
> .random.ca.example 1 IN TXT "{the CA challenge goes here}"
>
> Now, whenever the CA receives a request to validate "sleevi.example", they
> map that to a domain-id. They then update the CNAME, and the TXT record, to
> match the CA-defined challenge value. Then, they issue a TXT record lookup
> for _validation.sleevi.example, get the challenge value back, and huzzah,
> the cert is authorized!
>
> But there's a small problem with this. Who was the Applicant requesting
> sleevi.example? From the CA's perspective, how does it distinguish me, the
> legit domain holder, from 'evil hacker'? In the Amazon case, AWS is the
> Applicant, and AWS is the one doing this fancy DNS stuff, so it's clear -
> only AWS can do this, and they're who the user delegated to.
>
> However, if the "party doing this domain dance" is != "the applicant", then
> a lot can go wrong here, because they might do the dance for two different
> applicants. The easiest example would be if the CA, for every CSR it
> received, regardless of the Applicant, it updated the  for
> sleevi.example - at that point, anyone in the world could get a cert for my