Re: Anomalous Certificate Issuances based on historic CAA records

[Gervase Markham via dev-security-policy]

On 30/11/17 14:52, Ryan Sleevi wrote:
> I think that, as CAA deployment becomes common, this pattern will be
> not-uncommon. I would hope we don't sound false alarms when it does.

After a little time (as it does seem some bugs are still being shaken
out), I am considering having Mozilla adopt a policy either of:

a) not accepting CAA violation reports from people other than the owners
of the domain in question; or

b) automatically believing the CA if they post a log which shows their
view of the DNS at the time of issuance.

We could start with b), but if CAs get a high load of reports still, we
could move to a).

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

RE: Anomalous Certificate Issuances based on historic CAA records

[Jeremy Rowley via dev-security-policy]

I think we can be more transparent about CAA records without requiring CT. I 
don’t have a solution, but more transparency about processing CAA records 
couldn’t hurt.

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, November 30, 2017 3:12 PM
To: Tim Hollebeek <tim.holleb...@digicert.com>
Cc: Wayne Thayer <wtha...@mozilla.com>; r...@sleevi.com; 
douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Paul 
Wouters <p...@nohats.ca>; Ben Laurie <b...@google.com>; Jeremy Rowley 
<jeremy.row...@digicert.com>
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

 

Right, and to my point:


Each transparency mechanism has to be specific to the problem it's trying to 
solve. CT is not a magic cureall for transparency - it's specific to, well, 
certificates, and more generally, TLS web certificates.

 

For things like S/MIME, you have "Key Transparency" (based on COINKS)

For things like binaries, you have "Binary Transparency"

For things like DNSSEC authority records, you could have "DNSSEC transparency"

 

It would be a mistake to think CT is some cureall, just like it would be a 
mistake to think "blockchain" suddenly solves all problems. The design of the 
technology, and its assumptions about the ecosystem, are relevant.

 

The general problem of any *Transparency system is you need a way to 
authenticate the data that is logged to some extent, and you need a way to 
independently verify or evaluate that data. Certificates provide both 
signatures and trust chains, so you get both. The constraints around privacy of 
S/MIME certificates (which are unique to them) lend themselves to a different 
technical solution, like Key Transparency.

 

As it relates to DNS, DNS sans-DNSSEC has no way to authenticate the data. So 
either your authentication is to introduce TTPs that can log the data (whether 
it's the Log or some multi-perspective contractually trusted third-party) or 
you need to find a way to sign the data (which DNSSEC is). Yet all that does is 
create a merkle hash tree - the system for ensuring and validating consistency 
and accuracy of that is also going to depend on the specific case.

 

I agree that the fact that a certificate must be disclosed to a log, and that 
logs are independent of CAs, make it very easy and appealing to suggest that 
logs should serve as the counterbalance to CAs. That's neither the design nor 
the goal - logs are meant to be neutral record-keepers with no trust afforded 
to them - with monitors/auditors/clients keeping them honest, and anyone (not 
just CAs) being able to ask them to record the facts.

 

There's obviously a gray area right now because of spec violations being things 
you want to log, but you also don't want to normalize - and CT Policy Days 
discussions around that continue to be interesting. But as it relates to CAA 
Transparency, it's both confusing the purpose of CAA (a machine readable 
expression of intent) and CT (no TTPs)

 

On Thu, Nov 30, 2017 at 4:16 PM, Tim Hollebeek <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> > wrote:

Wayne, your last point is closest to my thinking, and I whole-heartedly agree 
there may be better solutions.  My suggestion was that if CAA transparency is a 
desired thing, and it is clear that at least a few people think it is worth 
considering, it’s probably better to do it with existing transparency 
mechanisms instead of making up new ones.

 

There’s a lot of CAA debugging going on in private right now, and there isn’t 
necessarily an a priori reason why it has to be private.

 

-Tim

 

From: Wayne Thayer [mailto:wtha...@mozilla.com <mailto:wtha...@mozilla.com> ] 
Sent: Thursday, November 30, 2017 2:07 PM
To: Tim Hollebeek <tim.holleb...@digicert.com 
<mailto:tim.holleb...@digicert.com> >
Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; douglas.beat...@gmail.com 
<mailto:douglas.beat...@gmail.com> ; 
mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; Paul Wouters 
<p...@nohats.ca <mailto:p...@nohats.ca> >; Ben Laurie <b...@google.com 
<mailto:b...@google.com> >; Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

 

What problem(s) are you trying to solve?

 

- Subscribers already (or soon will) have CT logs and monitors available to 
detect mis-issued certs. They don't need CAA Transparency.

 

- This thread started as a discussion over possible mis-issuance that was 
determined to be false positives. As has been stated, without DNSSEC there is 
no such thing as a coherent view of DNS and Ryan described a legitimate example 
where a domain owner may consciously update CAA records briefly to permit 
issuance. It's unclear 

Re: Anomalous Certificate Issuances based on historic CAA records

[Ryan Sleevi via dev-security-policy]

Right, and to my point:

Each transparency mechanism has to be specific to the problem it's trying
to solve. CT is not a magic cureall for transparency - it's specific to,
well, certificates, and more generally, TLS web certificates.

For things like S/MIME, you have "Key Transparency" (based on COINKS)
For things like binaries, you have "Binary Transparency"
For things like DNSSEC authority records, you could have "DNSSEC
transparency"

It would be a mistake to think CT is some cureall, just like it would be a
mistake to think "blockchain" suddenly solves all problems. The design of
the technology, and its assumptions about the ecosystem, are relevant.

The general problem of any *Transparency system is you need a way to
authenticate the data that is logged to some extent, and you need a way to
independently verify or evaluate that data. Certificates provide both
signatures and trust chains, so you get both. The constraints around
privacy of S/MIME certificates (which are unique to them) lend themselves
to a different technical solution, like Key Transparency.

As it relates to DNS, DNS sans-DNSSEC has no way to authenticate the data.
So either your authentication is to introduce TTPs that can log the data
(whether it's the Log or some multi-perspective contractually trusted
third-party) or you need to find a way to sign the data (which DNSSEC is).
Yet all that does is create a merkle hash tree - the system for ensuring
and validating consistency and accuracy of that is also going to depend on
the specific case.

I agree that the fact that a certificate must be disclosed to a log, and
that logs are independent of CAs, make it very easy and appealing to
suggest that logs should serve as the counterbalance to CAs. That's neither
the design nor the goal - logs are meant to be neutral record-keepers with
no trust afforded to them - with monitors/auditors/clients keeping them
honest, and anyone (not just CAs) being able to ask them to record the
facts.

There's obviously a gray area right now because of spec violations being
things you want to log, but you also don't want to normalize - and CT
Policy Days discussions around that continue to be interesting. But as it
relates to CAA Transparency, it's both confusing the purpose of CAA (a
machine readable expression of intent) and CT (no TTPs)

On Thu, Nov 30, 2017 at 4:16 PM, Tim Hollebeek <tim.holleb...@digicert.com>
wrote:

> Wayne, your last point is closest to my thinking, and I whole-heartedly
> agree there may be better solutions.  My suggestion was that if CAA
> transparency is a desired thing, and it is clear that at least a few people
> think it is worth considering, it’s probably better to do it with existing
> transparency mechanisms instead of making up new ones.
>
>
>
> There’s a lot of CAA debugging going on in private right now, and there
> isn’t necessarily an a priori reason why it has to be private.
>
>
>
> -Tim
>
>
>
> *From:* Wayne Thayer [mailto:wtha...@mozilla.com]
> *Sent:* Thursday, November 30, 2017 2:07 PM
> *To:* Tim Hollebeek <tim.holleb...@digicert.com>
> *Cc:* r...@sleevi.com; douglas.beat...@gmail.com;
> mozilla-dev-security-pol...@lists.mozilla.org; Paul Wouters <
> p...@nohats.ca>; Ben Laurie <b...@google.com>; Jeremy Rowley <
> jeremy.row...@digicert.com>
> *Subject:* Re: Anomalous Certificate Issuances based on historic CAA
> records
>
>
>
> What problem(s) are you trying to solve?
>
>
>
> - Subscribers already (or soon will) have CT logs and monitors available
> to detect mis-issued certs. They don't need CAA Transparency.
>
>
>
> - This thread started as a discussion over possible mis-issuance that was
> determined to be false positives. As has been stated, without DNSSEC there
> is no such thing as a coherent view of DNS and Ryan described a legitimate
> example where a domain owner may consciously update CAA records briefly to
> permit issuance. It's unclear to me how CAA Transparency could solve this
> problem and thus provide a mechanism to confirm mis-issuance, if that is
> the goal.
>
>
>
> - The goal of reducing the risk of mis-issuance from well-behaved CAs who
> have bad or manipulated CAA data seems most worthwhile to me. To Ryan's
> point (I think), there may be better ways of achieving this one such as
> requiring CAs to "gossip" CAA records, or requiring CAA checks be performed
> from multiple network locations.
>
>
>
> Wayne
>
>
>
> On Thu, Nov 30, 2017 at 2:00 PM, Tim Hollebeek via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> I think there’s value in publicly logging things even if that isn’t the
> basis for trust.  So I disagree that what I wrote boils down to what I
> didn’t write.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Anomalous Certificate Issuances based on historic CAA records

[Tim Hollebeek via dev-security-policy]

Paul,

Improving CAA by moving it to a protocol other than DNS is certainly worth
considering, going forward.

With respect to people using proper DNS libraries and not inventing their
own CNAME / DNAME handling, the problem was that RFC 6844 accidentally
specified semantics for CNAME / DNAME that were not the standard semantics!
Even the erratum discussed extensively last spring still isn't fully
compliant with the relevant RFCs.

About half of the CAA problems encountered could have been avoided if RFC
6844 had simply said "When doing CAA lookups, CNAME MUST be handled as
specified in RFC 2181, and DNAME MUST be handled as specified in RFC 6672",
without trying to explicitly include them in the lookup algorithm. 

-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: Anomalous Certificate Issuances based on historic CAA records

[Quirin Scheitle via dev-security-policy]

Hi all,

just 2 quick comments:

> On 30. Nov 2017, at 22:06, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> This thread started as a discussion over possible mis-issuance that was
> determined to be false positives

We had reported 18 anomalies, of which my current (quick) count is 7 confirmed, 
9 pending, and 2 false positives. 
I do not think these numbers support a statement that the evaluator role is 
determined to create false positives.

> On 30. Nov 2017, at 21:12, Tim Hollebeek via dev-security-policy 
>  wrote:
> 
> So it turns out DNSSEC solves CAA problems for almost nobody, because almost
> nobody uses DNSSEC.  And given the serious flaws both in DNSSEC itself and
> exiting DNSSEC implementations, it is unlikely to be part of any solution to
> the current problems CAA is facing

Of ~115k CAA-enabled base domains, we currently see 12% using DNSSEC. 
Of these 12%, ~1% (a count of ~130) have invalid signatures. 

I think those 12% would like to have the benefits of DNSSEC for CAA. 

We are writing up a report about out investigations that has numbers on most of 
the questions discussed. 
I will be happy to share it here it that would not be considered spam. 

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

RE: Anomalous Certificate Issuances based on historic CAA records

[Paul Wouters via dev-security-policy]

On Thu, 30 Nov 2017, Tim Hollebeek via dev-security-policy wrote:

[somewhat off topic, you can safely hit delete now]


So it turns out DNSSEC solves CAA problems for almost nobody, because almost
nobody uses DNSSEC.


The only people who need to use CAA are the CA's. They can surely manage
to fire up a validating DNS resolver. I'm sure there are more BR's that
"almost nobody uses" because there is no need for everyone to use it but
CA's. If you talk about domain holders not being able to run DNSSEC,
that's a pretty lame excuse too, when we have many Registrars and
Hosters who run millions of DNSSEC secured zones. I feel this argument
is similar to "hosting your own email service is too hard". If it is,
there are excellent commercial alternatives available.


And given the serious flaws both in DNSSEC itself and exiting DNSSEC 
implementations


For one, I'm not aware of "serious flaws in DNSSEC". As for wanting
something to die because of bad implementations, can I suggest starting
with ASN.1 and X.509, then move to crypto primitives and TLS ? :)


The presence of DNSSEC in the BR policy
for handling DNS failures, in hindsight, was probably a mistake, and


Trusting unauthenticated data from the network should really be a no-op,
from a princple point of view. Making any security decisions based on
"some blob from the network that anyone could have modified without
detecting" is just madness.


Right now, the only thing it is really accomplishing is preventing certificate
issuance to customers whose DNS infrastructure is flaky, misconfigured, or
unreliable.


Seems like the kind of people who should be given a certificate award
for excellence :P


Longer term, DNS over HTTPS is probably a more useful path
forward than DNSSEC for CAA, but unfortunately that is still in it's
infancy.


Not really, because that only offers transport security and not data
integrity. A compromised nameserver should not be able to fake the lack
of CAA record for a domain that uses secure offline DNSSEC signing.


The problem DNSSEC checks for CAA was intended to solve was the fact that it
is certainly possible that a well-resourced attacker can manipulate the DNS
responses that the CA sees as part of its CAA checks.  A better mitigation,
perhaps, is for multiple parties to publicly attest in a verifiable way as
to what the state of DNS was at/near the time of issuance with respect to
the relevant CAA records.


Then why not simply cut out the DNS middle man, and give domains another
way to advertise this information. What about RDAP ? What about an EPP
"CA lock" similar to a "Registrar lock" ?


Of course, to avoid some of the extremely interesting experiences the
industry has had with CAA


Maybe people should use proper dns libraries and not invent their own
CNAME / DNAME handling :)

Paul

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

Re: Anomalous Certificate Issuances based on historic CAA records

[Paul Wouters via dev-security-policy]

On Thu, 30 Nov 2017, Wayne Thayer wrote:

[cut CC: list, assuming we're all on the list]


- Subscribers already (or soon will) have CT logs and monitors available to 
detect mis-issued certs. They don't need CAA Transparency.


It's not for subscribers, but for CA's.

Transparency is nice, but it does not _prevent_ misissue. The goal of
CAA is to prevent misissue.

We don't need a CAA Transparency log, because the only thing that needs
logging is the DNSSEC chain of the CAA record or lack thereof at the
time of issue. And only the issuing CA needs this information in case
they need to defend that there was no CAA record preventing them from
issuing at the time. Of course, you could still stuff it in some
transparency log if you want, but it is pretty useless for endusers.

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

Re: Anomalous Certificate Issuances based on historic CAA records

[Quirin Scheitle via dev-security-policy]

> On 30. Nov 2017, at 15:52, Ryan Sleevi  wrote:
> 
>> On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy 
>>  wrote:
>> Similar to the GlobalSign discussion, it is well possible that the domain 
>> briefly disabled their CAA records when you did the check — and re-enabled 
>> them later.
>> 
> I think that, as CAA deployment becomes common, this pattern will be 
> not-uncommon. I would hope we don't sound false alarms when it does.
> 

Hi Ryan,

thank you for your e-mail, I hear your concern. 

We did apply tight filtering before raising any cases, and urge any other 
evaluators to do so as well. 
We reported cases to CAs/this forum that seemed to hint at issues in CAA 
validation at CAs, such as the wildcard/nonwildcard mix.
We also don’t see our reports as “alarms”, but as cases that might warrant a 
closer look.

Domain records may change on short notice, and we carefully differentiated and 
analyzed each case. 
Consistently setting “issue ;”, for example, lets one expect that a domain will 
change that for issuance.
Consistently reporting a set of CAs not including the issuing CA — not so much. 
If you have the capability to change CAA records at each issuance, why maintain 
a set of non-issuing CAs in your CAA records?
Combined with configurations that can trigger corner cases (such as the 
wildcard/non-wildcard mix), we weighed these as worth reporting at that time.
Having learned that the latter cases happen as well, we will be even more 
sceptical for these going forward.

I honestly believe that we applied the maximum diligence that can be expected 
from an external evaluator, based on data that, depending on domain and time, 
was based on 8-hour or even 4-hour scan intervals *at issuance time*. 

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

RE: Anomalous Certificate Issuances based on historic CAA records

[Tim Hollebeek via dev-security-policy]

Wayne, your last point is closest to my thinking, and I whole-heartedly agree 
there may be better solutions.  My suggestion was that if CAA transparency is a 
desired thing, and it is clear that at least a few people think it is worth 
considering, it’s probably better to do it with existing transparency 
mechanisms instead of making up new ones.

 

There’s a lot of CAA debugging going on in private right now, and there isn’t 
necessarily an a priori reason why it has to be private.

 

-Tim

 

From: Wayne Thayer [mailto:wtha...@mozilla.com] 
Sent: Thursday, November 30, 2017 2:07 PM
To: Tim Hollebeek <tim.holleb...@digicert.com>
Cc: r...@sleevi.com; douglas.beat...@gmail.com; 
mozilla-dev-security-pol...@lists.mozilla.org; Paul Wouters <p...@nohats.ca>; 
Ben Laurie <b...@google.com>; Jeremy Rowley <jeremy.row...@digicert.com>
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

 

What problem(s) are you trying to solve?

 

- Subscribers already (or soon will) have CT logs and monitors available to 
detect mis-issued certs. They don't need CAA Transparency.

 

- This thread started as a discussion over possible mis-issuance that was 
determined to be false positives. As has been stated, without DNSSEC there is 
no such thing as a coherent view of DNS and Ryan described a legitimate example 
where a domain owner may consciously update CAA records briefly to permit 
issuance. It's unclear to me how CAA Transparency could solve this problem and 
thus provide a mechanism to confirm mis-issuance, if that is the goal.

 

- The goal of reducing the risk of mis-issuance from well-behaved CAs who have 
bad or manipulated CAA data seems most worthwhile to me. To Ryan's point (I 
think), there may be better ways of achieving this one such as requiring CAs to 
"gossip" CAA records, or requiring CAA checks be performed from multiple 
network locations.

 

Wayne

 

On Thu, Nov 30, 2017 at 2:00 PM, Tim Hollebeek via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

I think there’s value in publicly logging things even if that isn’t the basis 
for trust.  So I disagree that what I wrote boils down to what I didn’t write.



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: Anomalous Certificate Issuances based on historic CAA records

[Wayne Thayer via dev-security-policy]

What problem(s) are you trying to solve?

- Subscribers already (or soon will) have CT logs and monitors available to
detect mis-issued certs. They don't need CAA Transparency.

- This thread started as a discussion over possible mis-issuance that was
determined to be false positives. As has been stated, without DNSSEC there
is no such thing as a coherent view of DNS and Ryan described a legitimate
example where a domain owner may consciously update CAA records briefly to
permit issuance. It's unclear to me how CAA Transparency could solve this
problem and thus provide a mechanism to confirm mis-issuance, if that is
the goal.

- The goal of reducing the risk of mis-issuance from well-behaved CAs who
have bad or manipulated CAA data seems most worthwhile to me. To Ryan's
point (I think), there may be better ways of achieving this one such as
requiring CAs to "gossip" CAA records, or requiring CAA checks be performed
from multiple network locations.

Wayne

On Thu, Nov 30, 2017 at 2:00 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think there’s value in publicly logging things even if that isn’t the
> basis for trust.  So I disagree that what I wrote boils down to what I
> didn’t write.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Anomalous Certificate Issuances based on historic CAA records

[Ryan Sleevi via dev-security-policy]

On Thu, Nov 30, 2017 at 3:12 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The problem DNSSEC checks for CAA was intended to solve was the fact that
> it
> is certainly possible that a well-resourced attacker can manipulate the DNS
> responses that the CA sees as part of its CAA checks.  A better mitigation,
> perhaps, is for multiple parties to publicly attest in a verifiable way as
> to what the state of DNS was at/near the time of issuance with respect to
> the relevant CAA records.  This leads to the idea that perhaps it's worth
> exploring enhancing existing CT logging servers to do CAA checks and log
> what they see.  That's probably easier than setting up an entirely separate
> infrastructure for CAA transparency.  CT servers could even communicate
> back
> to CAs the results they see to assist in detecting and identifying both
> malicious and non-malicious discrepancies between the CA's own checks and
> what the CT log is seeing.  "Thanks for the pre-cert.  We see a CAA record
> at X.Y.Z.Z.Y that doesn't include you.  Do you really want to issue?"
> There
> are legitimate concerns that giving even more work to CT log servers might
> put even more burden and expense onto those who are running CT log servers,
> but that can probably be figured out.
>

While I understand the intent of the suggestion, it basically boils down to:
- To solve independently verifying CAA, we need Trusted Third Parties
- We have CT logs (which are not meant to be TTPs)
- We should make logs TTPs so we don't have to spin up new TTP
infrastructure

The goal of CT from the get go has been that logs do not need to be TTPs,
and that this is achieved by the cryptographic properties of the design
combined with the ecosystem mitigations to detect any deviance. This is not
possible with a CAA-in-CT, because CT is fundamentally not designed to
provide cryptographic attestations about the statement of CAA (if we had
such attestations, the CA could provide them anyways).

So I don't think we can get away from the notion that if we want CAA to be
an independently-verified aspect, then you need either TTPs (and CT logs
are by design not TTPs, and should not be made TTPs) or you need to solve
the cryptographic verifiability (in which case, you don't need CT logs to
do this).

Of course, I think this is all conditioned on whether CAA's value is
somehow tied to the independently-verified. I don't believe that it is, no
more than we're requiring cryptographic proofs of CA's validation of OV/EV
documents or chains of custody from the QGIS and QIIS' used to validate
that data. Instead, CAA serves as a machine-readable expression of policy
intent, no different than having http://domain.com/.well-known/caa in some
machine readable form. Our primary benefit of having it expressed in DNS
(versus that HTTP-based file) is that we can leverage DNSSEC as a bootstrap
for trust when it's available (despite all of its warts - and cryptographic
issues) and it more easily aligns with CA's existing practices of DNS-based
validation.

It may be surprising to hear me suggesting that we expect something of CAs
without having it independently verified - but I think there's substantial
value to be afforded applicants/subscribers, and I'm deeply worried when
the suggestions we have to date are to introduce more TTPs, make explicitly
non-TTPs into TTPs, or to add unreliable reporting mechanisms that might
otherwise drive up the costs of a sensible risk mitigation technology.

I think for those that want to serve in a CAA Auditor role have the iodef
mechanism as a way of reporting potential strangeness in such a way that
the burden shifts to the applicant, but also that their ability to
recognize (or reject) such information is the most scalable solution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Anomalous Certificate Issuances based on historic CAA records

[Tim Hollebeek via dev-security-policy]

So it turns out DNSSEC solves CAA problems for almost nobody, because almost
nobody uses DNSSEC.  And given the serious flaws both in DNSSEC itself and
exiting DNSSEC implementations, it is unlikely to be part of any solution to
the current problems CAA is facing.  The presence of DNSSEC in the BR policy
for handling DNS failures, in hindsight, was probably a mistake, and
certainly deserved a lot more scrutiny than it got (Gerv tossed it out as a
possible compromise during CABF F2F discussion, and everyone sort of
shrugged and put it in because it seemed reasonable at the time).  Right
now, the only thing it is really accomplishing is preventing certificate
issuance to customers whose DNS infrastructure is flaky, misconfigured, or
unreliable.  Longer term, DNS over HTTPS is probably a more useful path
forward than DNSSEC for CAA, but unfortunately that is still in it's
infancy.

One of the things that has become very clear over the last year is that the
idea that the idea that there is a single, globally coherent state for what
DNS says at any particular time is more of a myth than a reality.  I'm sure
that most people familiar with DNS were already well aware of that, but it
has been entertaining seeing that almost every possible DNS failure mode
happens in practice with disturbing frequency.

The problem DNSSEC checks for CAA was intended to solve was the fact that it
is certainly possible that a well-resourced attacker can manipulate the DNS
responses that the CA sees as part of its CAA checks.  A better mitigation,
perhaps, is for multiple parties to publicly attest in a verifiable way as
to what the state of DNS was at/near the time of issuance with respect to
the relevant CAA records.  This leads to the idea that perhaps it's worth
exploring enhancing existing CT logging servers to do CAA checks and log
what they see.  That's probably easier than setting up an entirely separate
infrastructure for CAA transparency.  CT servers could even communicate back
to CAs the results they see to assist in detecting and identifying both
malicious and non-malicious discrepancies between the CA's own checks and
what the CT log is seeing.  "Thanks for the pre-cert.  We see a CAA record
at X.Y.Z.Z.Y that doesn't include you.  Do you really want to issue?"  There
are legitimate concerns that giving even more work to CT log servers might
put even more burden and expense onto those who are running CT log servers,
but that can probably be figured out.

Of course, to avoid some of the extremely interesting experiences the
industry has had with CAA, any "improved" version of CAA needs to be much
more clear about the proper handling of error conditions, discrepancies in
DNS responses, handling of malformed CAA records, and so on.  DNS is a
complicated beast, and any specification that exclusively contains
statements of the form "Let CAA(X) be the CAA record at DNS node X" is
oversimplified to the point where implementing it in practice will cause
problems.

-Tim

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+tim.hollebeek=digicert.com@lists.mozilla
.org] On Behalf Of Ben Laurie via dev-security-policy
Sent: Wednesday, November 29, 2017 3:37 PM
To: Paul Wouters <p...@nohats.ca>
Cc: douglas.beat...@gmail.com;
mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley
<jeremy.row...@digicert.com>
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

On 29 November 2017 at 22:33, Paul Wouters <p...@nohats.ca> wrote:

>
>
> > On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > This whole conversation makes me wonder if CAA Transparency should 
> > be a thing.
>
> That is a very hard problem, especially for non-DNSSEC signed ones.
>

Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear chain
of responsibility for keys, and that is relatively easy to build on.
___
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: Anomalous Certificate Issuances based on historic CAA records

[Ryan Sleevi via dev-security-policy]

On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Similar to the GlobalSign discussion, it is well possible that the domain
> briefly disabled their CAA records when you did the check — and re-enabled
> them later.
>

I think that, as CAA deployment becomes common, this pattern will be
not-uncommon. I would hope we don't sound false alarms when it does.

This is pretty explicitly spelled out in the CAA RFC:
   CAA records MAY be used by Certificate Evaluators as a possible
   indicator of a security policy violation.  Such use SHOULD take
   account of the possibility that published CAA records changed between
   the time a certificate was issued and the time at which the
   certificate was observed by the Certificate Evaluator.

That said, the role of evaluators is less so in reporting to the CAs, but
as noted within the CAA RFC:
   iodef  :  Specifies a URL to which an issuer MAY report
  certificate issue requests that are inconsistent with the issuer's
  Certification Practices or Certificate Policy, or that a
  Certificate Evaluator may use to report observation of a possible
  policy violation.  The Incident Object Description Exchange Format
  (IODEF) format is used [RFC5070].


This is because the only party who can ascertain intent unambiguously here
is the subscriber. Independent parties such as evaluators lack the context
both from the POV of the Applicant and the CA to identify misissuance, and
unless we (incorrectly, I would argue) want to require that CAA records be
'sticky' and 'globally observed' for some time before issuing a cert, then
this pattern will be a regular part of operation.

For example, an organization that wants to ensure that all certificates are
directed through a central purchasing team would, rather than place the
name of that CA in their CAA record (although they could), potentially
place themselves in their record, and then make the changes whenever they
need to renew, replace, or issue certificates - for the duration of the
issuance request.

I agree that it's early in the CAA deployment story, that we're likely to
see and continue to see bugs as CA's (finally, after years of discussion)
familiarize themselves with it and their implementation, and I agree, it's
unfortunate that some extent of these edge cases are not well tested or
testable. But I'm also wanting to make sure that we don't prematurely
increase the perceived cost of CAA such that it would rightfully make an
argument that the cost outweighs the benefits - from things like false
positive reporting.

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

Re: Anomalous Certificate Issuances based on historic CAA records

[Quirin Scheitle via dev-security-policy]

Hi Jeremy,

thank you for sharing that log! The associated bug is here: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1420861

I do not know how to parse all the details in the log, but I guess the line 

> 2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : 
> CAAInput : [trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : 
> CAADNSRecords : [ ]

means that you have seen an NODATA (empty) reply at 2017-09-13 05:25:09 in an 
unknown(but at this point irrelevant) timezone. 
Similar to the GlobalSign discussion, it is well possible that the domain 
briefly disabled their CAA records when you did the check — and re-enabled them 
later.
A quirk in the lookup process would probably trigger some kind of 
timeout/unreachable log.

The consistency displayed in our scans [1] and the fact that this error class 
(wildcard/non-wildcard) seems to have affected several cases made this case 
look suspicious, so I had raised it. 
I am very happy to accept your reply and classify this as a false positive. I 
also thinks it is a very positive example that CAs can and do provide log 
excerpts for such cases.

Regarding the “CAA Transparency” discussion: Yes, I would welcome this and be 
happy to support designing it. 
I do not think it requires DNSSEC, just storing the relevant DNS replies in 
wire format by the CAs would be a great start.

Kind regards
Quirin

[1]
2017-09-12:trnava-vuc.sk.  86400   IN  CAA 0 issuewild "thawte.com"
2017-09-12:trnava-vuc.sk.  86400   IN  CAA 0 issue ";"
2017-09-13:trnava-vuc.sk.  86400   IN  CAA 0 issuewild "thawte.com"
2017-09-13:trnava-vuc.sk.  86400   IN  CAA 0 issue ";"
2017-09-14:trnava-vuc.sk.  86360   IN  CAA 0 issuewild "thawte.com"
2017-09-14:trnava-vuc.sk.  86360   IN  CAA 0 issue ";"


> On 29. Nov 2017, at 21:44, Jeremy Rowley via dev-security-policy 
>  wrote:
> 
> The Thawte records aren't showing any CAA record preventing wildcards either. 
> 
> Here's the Thawte CAA record logs for the domain:
> 
> 2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 257 
> result: 4 lookupTimeout: 500
> 2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService - Looking for alias for: trnava-vuc.sk
> 2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 5 
> result: 4 lookupTimeout: 750
> 2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : 
> CAAInput : [trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : 
> CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
> trnava-vuc.sk is: 1
> 2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : 
> CAAInput : [*.trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : 
> CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO  
> c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
> *.trnava-vuc.sk is: 2



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: Anomalous Certificate Issuances based on historic CAA records

[Nick Lamb via dev-security-policy]

On Wed, 29 Nov 2017 22:37:08 +
Ben Laurie via dev-security-policy
 wrote:

> Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear
> chain of responsibility for keys, and that is relatively easy to
> build on.

For DNSSEC a CA could (and I would hope that they do) collect enough
records to show that the CAA result they relied on was authentic after
the fact.

It is in the nature of a distributed system like DNS that it would be
possible that this was not the _only_ authentic result available on the
network at the time of issuance, and the CA has no way to know of any
other results that are inconsistent with issuance once they have one
which is consistent.

Of course the existence of contradictory authentic results SHOULD not
be ordinarily the case for a well-managed domain but we know it
happens, and it would be even more likely for test systems although
they should have the know-how to control this.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Anomalous Certificate Issuances based on historic CAA records

[Ben Laurie via dev-security-policy]

On 29 November 2017 at 22:33, Paul Wouters  wrote:

>
>
> > On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > This whole conversation makes me wonder if CAA Transparency should be a
> > thing.
>
> That is a very hard problem, especially for non-DNSSEC signed ones.
>

Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear
chain of responsibility for keys, and that is relatively easy to build on.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Anomalous Certificate Issuances based on historic CAA records

[Paul Wouters via dev-security-policy]

> On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy 
>  wrote:
> 
> This whole conversation makes me wonder if CAA Transparency should be a
> thing.

That is a very hard problem, especially for non-DNSSEC signed ones.

Paul

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

RE: Anomalous Certificate Issuances based on historic CAA records

[Jeremy Rowley via dev-security-policy]

Yes, CAA transparency should exist. Right now CAA is only a point-in-time check 
by the CA with no way to verify what the CA saw or what was processed. This was 
one of the limitations raised during the discussions about adoption. Without 
some transparency, the reliance is on the CA to ensure the CAA record checking 
is properly done and not useful to subscribers. Despite the lack of 
transparency, CAA checking is still useful as it can help a CA prevent 
unauthorized issuance, even if the prevention/CAA record check results aren’t 
publicly available. CAA is a useful tool for CAs but could be a more useful 
tools for researchers if there was a good way to make the record check results 
more publicly available.  

 

Jeremy

From: Ben Laurie [mailto:b...@google.com] 
Sent: Wednesday, November 29, 2017 3:01 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

 

This whole conversation makes me wonder if CAA Transparency should be a thing.

 

On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

The Thawte records aren't showing any CAA record preventing wildcards either.

Here's the Thawte CAA record logs for the domain:

2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk 
<http://trnava-vuc.sk>  type: 257 result: 4 lookupTimeout: 500
2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Looking for alias for: trnava-vuc.sk 
<http://trnava-vuc.sk> 
2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk 
<http://trnava-vuc.sk>  type: 5 result: 4 lookupTimeout: 750
2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput 
: [trnava-vuc.sk <http://trnava-vuc.sk> ] : CAAMatchMessage : [CAA record not 
found] : CAADNSRecords : [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
trnava-vuc.sk <http://trnava-vuc.sk>  is: 1
2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput 
: [*.trnava-vuc.sk <http://trnava-vuc.sk> ] : CAAMatchMessage : [CAA record not 
found] : CAADNSRecords : [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO  
c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
*.trnava-vuc.sk <http://trnava-vuc.sk>  is: 2

Jeremy
-Original Message-
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley 
<mailto:dev-security-policy-bounces%2Bjeremy.rowley> 
=digicert@lists.mozilla.org <mailto:digicert@lists.mozilla.org> ] On 
Behalf Of douglas.beattie--- via dev-security-policy
Sent: Wednesday, November 29, 2017 4:27 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> 
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

Hi Quirin,

I'm curious about how you recorded the historical information from DNS, can you 
explain how this was requested and logged?

We logged the data used for issuance of the GlobalSign certificate at the time 
of issuance and it's different from what you recorded.

We logged that there was no “issuewild” entry and that "digicert.com 
<http://digicert.com> ", "globalsign.com <http://globalsign.com> ", 
"letsencrypt.org <http://letsencrypt.org> " and "rapidssl.com 
<http://rapidssl.com> " are all defined as “issue” at time of issuance.

Doug

On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> Hi Quirin,
>
> Thank you for your work on this topic. I would be grateful if you
> could file Bugzilla bugs in the Misissuance component as follows,
> giving your evidence of misissuance:
>
> On 22/11/17 23:50, Quirin Scheitle wrote:
> > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > Batch: 
> > https://clicktime.symantec.com/a/1/4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN

Re: Anomalous Certificate Issuances based on historic CAA records

[Ben Laurie via dev-security-policy]

This whole conversation makes me wonder if CAA Transparency should be a
thing.

On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The Thawte records aren't showing any CAA record preventing wildcards
> either.
>
> Here's the Thawte CAA record logs for the domain:
>
> 2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Lookup domain: trnava-vuc.sk type: 257 result: 4 lookupTimeout: 500
> 2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Looking for alias for: trnava-vuc.sk
> 2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Lookup domain: trnava-vuc.sk type: 5 result: 4 lookupTimeout: 750
> 2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - CAAResponse: CAAMatchCode : [32] : CAAInput : [trnava-vuc.sk] :
> CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Time taken in seconds for CAA check of trnava-vuc.sk is: 1
> 2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - CAAResponse: CAAMatchCode : [32] : CAAInput : [*.trnava-vuc.sk] :
> CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO  
> c.s.s.r.service.CAAV2CheckService
> - Time taken in seconds for CAA check of *.trnava-vuc.sk is: 2
>
> Jeremy
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of
> douglas.beattie--- via dev-security-policy
> Sent: Wednesday, November 29, 2017 4:27 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Anomalous Certificate Issuances based on historic CAA records
>
> Hi Quirin,
>
> I'm curious about how you recorded the historical information from DNS,
> can you explain how this was requested and logged?
>
> We logged the data used for issuance of the GlobalSign certificate at the
> time of issuance and it's different from what you recorded.
>
> We logged that there was no “issuewild” entry and that "digicert.com", "
> globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as
> “issue” at time of issuance.
>
> Doug
>
> On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> > Hi Quirin,
> >
> > Thank you for your work on this topic. I would be grateful if you
> > could file Bugzilla bugs in the Misissuance component as follows,
> > giving your evidence of misissuance:
> >
> > On 22/11/17 23:50, Quirin Scheitle wrote:
> > > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > > Batch: https://clicktime.symantec.com/a/1/
> 4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_
> 82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_
> 74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-
> IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_
> 4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD
> 8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_
> 01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_
> 6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-
> D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SB
> e=https%3A%2F%2Fmisissued.com%2Fbatch%2F32%2F
> > > Description: best confer
> > > https://clicktime.symantec.com/a/1/bRWz8YI8GaFJN5p0wMSlE_HKuFXeSpidx
> > > EosAdBNIhw=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTF
> > > qzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1B
> > > sUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noA
> > > PAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8
> > > H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt
> > > 1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjh
> > > fxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF
> > > 6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe=https%3A%2F%2Fgroups.google
> > > .com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FO9HZPMvHMY8%2FHtXR8S-
> > > 1AAAJ
> >
> > One bug per CA, please.
> >
> > > 4) Apparent non-evaluation of CAA records
> > > Batch: https://clicktime.symantec.com/a/1/ZSn0R3LPoUJA--
> jAELl6kXSjRsrKYmYOKsgQn5Gve1U=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-
> CSz6VnLpr

RE: Anomalous Certificate Issuances based on historic CAA records

[Jeremy Rowley via dev-security-policy]

The Thawte records aren't showing any CAA record preventing wildcards either. 

Here's the Thawte CAA record logs for the domain:

2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 257 
result: 4 lookupTimeout: 500
2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Looking for alias for: trnava-vuc.sk
2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 5 
result: 4 lookupTimeout: 750
2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput 
: [trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : 
[ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
trnava-vuc.sk is: 1
2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO  
c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput 
: [*.trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : CAADNSRecords 
: [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO  
c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of 
*.trnava-vuc.sk is: 2

Jeremy
-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of douglas.beattie--- via dev-security-policy
Sent: Wednesday, November 29, 2017 4:27 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

Hi Quirin,

I'm curious about how you recorded the historical information from DNS, can you 
explain how this was requested and logged?

We logged the data used for issuance of the GlobalSign certificate at the time 
of issuance and it's different from what you recorded.

We logged that there was no “issuewild” entry and that "digicert.com", 
"globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as 
“issue” at time of issuance.

Doug

On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> Hi Quirin,
> 
> Thank you for your work on this topic. I would be grateful if you 
> could file Bugzilla bugs in the Misissuance component as follows, 
> giving your evidence of misissuance:
> 
> On 22/11/17 23:50, Quirin Scheitle wrote:
> > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > Batch: 
> > https://clicktime.symantec.com/a/1/4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe=https%3A%2F%2Fmisissued.com%2Fbatch%2F32%2F
> > Description: best confer 
> > https://clicktime.symantec.com/a/1/bRWz8YI8GaFJN5p0wMSlE_HKuFXeSpidx
> > EosAdBNIhw=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTF
> > qzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1B
> > sUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noA
> > PAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8
> > H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt
> > 1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjh
> > fxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF
> > 6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe=https%3A%2F%2Fgroups.google
> > .com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FO9HZPMvHMY8%2FHtXR8S-
> > 1AAAJ
> 
> One bug per CA, please.
> 
> > 4) Apparent non-evaluation of CAA records
> > Batch: 
> > https://clicktime.symantec.com/a/1/ZSn0R3LPoUJA--jAELl6kXSjRsrKYmYOKsgQn5Gve1U=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe=https%3A%2F%2Fmisissued.com%2Fbatch%2F33%2F
> > Description: These cases appear as pretty straight-forward that they 
> > should not have been issued, but
> 

Re: Anomalous Certificate Issuances based on historic CAA records

[douglas.beattie--- via dev-security-policy]

Hi Quirin,

I'm curious about how you recorded the historical information from DNS, can you 
explain how this was requested and logged?

We logged the data used for issuance of the GlobalSign certificate at the time 
of issuance and it's different from what you recorded.

We logged that there was no “issuewild” entry and that "digicert.com", 
"globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as 
“issue” at time of issuance.

Doug

On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> Hi Quirin,
> 
> Thank you for your work on this topic. I would be grateful if you could
> file Bugzilla bugs in the Misissuance component as follows, giving your
> evidence of misissuance:
> 
> On 22/11/17 23:50, Quirin Scheitle wrote:
> > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > Batch: https://misissued.com/batch/32/
> > Description: best confer 
> > https://groups.google.com/d/msg/mozilla.dev.security.policy/O9HZPMvHMY8/HtXR8S-1AAAJ
> 
> One bug per CA, please.
> 
> > 4) Apparent non-evaluation of CAA records
> > Batch: https://misissued.com/batch/33/
> > Description: These cases appear as pretty straight-forward that they 
> > should not have been issued, but
> > there might be good explanations
> 
> One bug for the two Comodo certs, one for the Camerfirma cert.
> 
> Thank you,
> 
> Gerv

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