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 
Cc: Wayne Thayer ; r...@sleevi.com; 
douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Paul 
Wouters ; Ben Laurie ; Jeremy Rowley 

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  > 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  >
Cc: r...@sleevi.com  ; douglas.beat...@gmail.com 
 ; 
mozilla-dev-security-pol...@lists.mozilla.org 
 ; Paul Wouters 
 >; Ben Laurie  >; Jeremy Rowley  >
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 

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 
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 
> *Cc:* r...@sleevi.com; douglas.beat...@gmail.com;
> mozilla-dev-security-pol...@lists.mozilla.org; Paul Wouters <
> p...@nohats.ca>; Ben Laurie ; 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 
Cc: r...@sleevi.com; douglas.beat...@gmail.com; 
mozilla-dev-security-pol...@lists.mozilla.org; Paul Wouters ; 
Ben Laurie ; Jeremy Rowley 
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 
 > 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: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario  wrote:

> On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote:
> > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario 
> wrote:
> > > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> > > vulnerable to attacks like the Bleichenbacher, if it is not usable with
> > > PKCS#1
> > > v1.5 it's not vulnerable in practice to such attacks
> >
> > A certificate does not produce signatures - a key does.
> > A certificate carries signatures, but only relevant to verifiers.
>
> and verifiers are who enforces if the signatures are sane
> and for verifiers only the certificate is visible, not private key
> and certificate for the user of the key is essentially a blob, not
> something
> he or she can edit, so it is a commitment (even for CA, as that self signed
> one is no longer in control of it)
>
> > Your reference to Bleichenbacher again makes it unclear if you're
> > expressing a concern about the protection of the private key or the
> quality
> > of the signatures, or whether you're conflating with ciphersuite
> > negotiation and encryption.
>
> key with rsaEncryption SPKI can be used for both signatures and encryption,
> key with RSA-PSS SPKI can't be used for encryption if at least one party is
> standards compliant
>
> and the only way the other party can tell if the key is a rsa or a rsa-pss
> key
> is by looking at the certificate
>
> so if the _private_ key is rsa or rsa-pss type is of purely philosophical
> concern
>

Then I think this is an incredibly convoluted concern.

If I'm understanding correctly - and I hope you can correct me if I'm not -
the view is that it is valuable to limit a public key via an unnecessary
complex encoding scheme so that it does not get used for encryption (in
what protocol? Obviously not X.509 - so presumably certificates) so that it
is robust against CCA like Bleichenbacher?

It feels like I just spewed out words writing that out, because it does not
seem like it fits a consistent or coherent threat model, and so surely I
must be missing something.

It does feel like again the argument is The CA/EE should say 'I won't do X'
so that a client won't accept a signature if the CA does X, except it
doesn't change the security properties at all if the CA/EE does actually do
X, and the only places it does affect the security properties are either
already addressed (e.g. digitalSignature EKU) or themselves not protected
by the proposed mechanism.

This doesn't make sense. It's not good policy.


>
> > No, such CAs do exist, and we haven't revoked such trust. Your statement
> is
> > empirically false.
> >
> > That's why I'm trying to be explicit in the policy here - that the policy
> > is about the keys, not the certificates.
>
> but the private keys are invisible and they should be invisible to anyone
> but
> the owner! the only way to check if they are used according to their
> intention
> is to look at the corresponding certificate!
>

I thought I already demonstrated that this was false, because the statement
of capability is n capabilities to 1 key, and who makes those statements is
not the private key.

And that intention can be expressed through means other than the inanity of
RFC 4055 to begin with, or that intention is an unnecessary option imposed
on clients to satisfy the whims of the signature producer, and we should
favor clients over producers.


> it's fully an implementation's detail whether implementation stores the
> rsa-
> pss params with the private key or derives them from associated
> certificate -
> it doesn't matter
>

And this is where I disagree - the fact that deriving them from the
associated certificate imposes a significant cost upon clients is something
to be concerned about and worthy of prohibition. There's no need to
outsource the implementation cost upon the ecosystem for what can and
ostensibly should be the CA's ability to control.


> > > I don't think that it's the act of making the signature that weakens
> the
> > > key
> >
> > Great, then we don't need to restrict keys.
>
> that's cherry picking and taking sentences out of context...
>

I don't think it is.

There has been a constant conflation between a desire to:
1) Ensure that a sufficient level of security is afforded all clients
against known risks
2) Allow producers flexibility to implement their arbitrary security
policies

I disagree that 2 should be a consideration, unless it comes without client
cost. In the case of RFC 4055, it comes with substantial client cost (as
already demonstrated by the missteps made by NSS, past and present), and so
such flexibility is unreasonably complex. We've also seemingly reached
agreement that, with respect to 1, it's either a matter of client policy
(to accept or reject a given 'weak' signature) or that it's a matter of
cross-algorithm attacks (which we've agreed doesn't undermine security)

So 1 doesn't apply, 2 is too costly, and clients 

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote:
> On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario  wrote:
> > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> > vulnerable to attacks like the Bleichenbacher, if it is not usable with
> > PKCS#1
> > v1.5 it's not vulnerable in practice to such attacks
> 
> A certificate does not produce signatures - a key does.
> A certificate carries signatures, but only relevant to verifiers.

and verifiers are who enforces if the signatures are sane
and for verifiers only the certificate is visible, not private key
and certificate for the user of the key is essentially a blob, not something 
he or she can edit, so it is a commitment (even for CA, as that self signed 
one is no longer in control of it)

> Your reference to Bleichenbacher again makes it unclear if you're
> expressing a concern about the protection of the private key or the quality
> of the signatures, or whether you're conflating with ciphersuite
> negotiation and encryption.

key with rsaEncryption SPKI can be used for both signatures and encryption, 
key with RSA-PSS SPKI can't be used for encryption if at least one party is 
standards compliant

and the only way the other party can tell if the key is a rsa or a rsa-pss key 
is by looking at the certificate

so if the _private_ key is rsa or rsa-pss type is of purely philosophical 
concern

> > > It does not do prevent such a signature from being created - that's what
> > 
> > I
> > 
> > > mean.
> > 
> > now you're being silly
> > 
> > the Mozilla policy doesn't prohibit the CA from making a service that will
> > perform RSA private key operation on arbitrary strings either but we would
> > still revoke trust from CA that would do such a thing, because just the
> > fact
> > that such a service _could_ have been used maliciously (to sign arbitrary
> > certificates) is enough to distrust it!
> 
> No, such CAs do exist, and we haven't revoked such trust. Your statement is
> empirically false.
> 
> That's why I'm trying to be explicit in the policy here - that the policy
> is about the keys, not the certificates.

but the private keys are invisible and they should be invisible to anyone but 
the owner! the only way to check if they are used according to their intention 
is to look at the corresponding certificate!

it's fully an implementation's detail whether implementation stores the rsa-
pss params with the private key or derives them from associated certificate - 
it doesn't matter

> > I don't think that it's the act of making the signature that weakens the
> > key
> 
> Great, then we don't need to restrict keys.

that's cherry picking and taking sentences out of context...

> > > I understand - but I'm saying that what we're discussing fundamentally
> > > relates to the key.
> > > 
> > > If a CA was technically constrained to .com, said they would never issue
> > > for something not .com, but then issued for .org, it's absolutely
> > > grounds
> > > for concern.
> > > If it doesn't matter whether a CA issues for .com or .org, and they
> > 
> > simply
> > 
> > > choose to only issue for .com, then it doesn't make sense to require
> > > clients to support the CA's expression of intent if doing so introduces
> > > security risk to clients (and it does) and complexity risk.
> > 
> > so where's the bug that removes support for that in Firefox? Will we get
> > it in
> > before the next ESR? /s
> 
> You've again misunderstood the argument. But I'm not sure that there's much
> value in continuing - I've attempted to get you to either outline the value
> proposition or to outline the risks.

the only risk you're bringing up again and again is a nebulous "but it's hard 
to do, so we may make mistakes"

guess what: that's the case for all of crypto, all of network protocols, 
that's why we repeat the mantra of "don't implement crypto yourself", it's 
silly to bring it up in the first place

> We've danced around on semantic games,

And how am I supposed to answer to that without invoking an ad hominem?

> but we've identified that there is no risk in comingling these hash
> algorithms,

no, there is risk, we just can't quantify it

> that the only risk in being strict relates to a single software
> product with an unknown (but understandably miniscule, by virtue of no bugs
> being filed) number of extant certificates, while we have a profound
> opportunity to do the Right Thing based on lessons repeatedly learned.

that's about RSA-PSS parameters in SPKI or about RSA-PSS OID in SPKI?

> > you're arguing that machine readable CA policy is a _bad thing_ ?
> 
> 
> Yes, when the method of expressing that policy is unnecessary complex,
> burdensome, and error prone for both clients and servers.

I already said I'm ok with the hardcoded encoding of the RSA-PSS params, with 
salt sizes assigned to hash sizes, and I started by saying that I'm ok with 
forbidding RSA-PSS params in EE certificate SPKI, that's not 

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 
Cc: douglas.beat...@gmail.com;
mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley

Subject: Re: Anomalous Certificate Issuances based on historic CAA records

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


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: Mozilla RSA-PSS policy

[Ryan Sleevi via dev-security-policy]

On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario  wrote:

> if the certificate is usable with PKCS#1 v1.5 signatures, it makes it
> vulnerable to attacks like the Bleichenbacher, if it is not usable with
> PKCS#1
> v1.5 it's not vulnerable in practice to such attacks
>

A certificate does not produce signatures - a key does.
A certificate carries signatures, but only relevant to verifiers.

Your reference to Bleichenbacher again makes it unclear if you're
expressing a concern about the protection of the private key or the quality
of the signatures, or whether you're conflating with ciphersuite
negotiation and encryption.


> > It does not do prevent such a signature from being created - that's what
> I
> > mean.
>
> now you're being silly
>
> the Mozilla policy doesn't prohibit the CA from making a service that will
> perform RSA private key operation on arbitrary strings either but we would
> still revoke trust from CA that would do such a thing, because just the
> fact
> that such a service _could_ have been used maliciously (to sign arbitrary
> certificates) is enough to distrust it!
>

No, such CAs do exist, and we haven't revoked such trust. Your statement is
empirically false.

That's why I'm trying to be explicit in the policy here - that the policy
is about the keys, not the certificates.


> I don't think that it's the act of making the signature that weakens the
> key
>

Great, then we don't need to restrict keys.


> If I generate a certificate has RSA-PSS SPKI I won't be able to use it for
> PKCS#1 v1.5 signatures - no widely deployed server will use it like that
> and
> no widely deployed client will accept such use. So a chance that a key
> will be
> abused like that and will remain abused like that is negligible.
>
> and that's the whole point - defence in depth - to make it another hurdle
> to
> jump through if you want to do something stupid
>

That's an argument often made for unnecessary complexity - or more aptly,
the benefits of such defense in depth needs to be weighed against how that
cost is distributed. In the case of RSA-PSS, because of the inanity of RFC
4055, that cost is distributed unevenly - it places the burden of such
complexity upon the clients, which have repeatedly lead to exploits (and
again, NSS has itself been vulnerable to this several times, or deftly
avoided it due to Brian Smith's keen rejection of unnecessary complexity).

It is a joint we don't need, and whose oiling will be needless toil.

It also adds complexity to the CA ecosystem, for CAs who are unfortunately
incapable of complying with the RFCs unless their hands are held and they
are carefully guided down the happy path. To the extent those CAs should
not be trusted is easy to say, but as shown time and time again, it's hard
to express "You must be this competent to ride" in an objective policy, and
even harder to address the situation where the CA is trusted and then let's
all the competent staff go.


>
> > I understand - but I'm saying that what we're discussing fundamentally
> > relates to the key.
> >
> > If a CA was technically constrained to .com, said they would never issue
> > for something not .com, but then issued for .org, it's absolutely grounds
> > for concern.
> > If it doesn't matter whether a CA issues for .com or .org, and they
> simply
> > choose to only issue for .com, then it doesn't make sense to require
> > clients to support the CA's expression of intent if doing so introduces
> > security risk to clients (and it does) and complexity risk.
>
> so where's the bug that removes support for that in Firefox? Will we get
> it in
> before the next ESR? /s
>

You've again misunderstood the argument. But I'm not sure that there's much
value in continuing - I've attempted to get you to either outline the value
proposition or to outline the risks. We've danced around on semantic games,
but we've identified that there is no risk in comingling these hash
algorithms, that the only risk in being strict relates to a single software
product with an unknown (but understandably miniscule, by virtue of no bugs
being filed) number of extant certificates, while we have a profound
opportunity to do the Right Thing based on lessons repeatedly learned.

you're arguing that machine readable CA policy is a _bad thing_ ?
>

Yes, when the method of expressing that policy is unnecessary complex,
burdensome, and error prone for both clients and servers.

RFC 4055 is a bad RFC. It is a host of unnecessary joints and unnecessary
complexity that does not, in practice, add any modicum of 'future
compatibility' as it tried to do, does not in practice reduce any risks (as
it tried to do), and does not provide any tangible value over a sane
expression of that via policy.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla RSA-PSS policy

[Hubert Kario via dev-security-policy]

On Wednesday, 29 November 2017 21:59:39 CET Ryan Sleevi wrote:
> On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario  wrote:
> > > So are you stating you do not believe cross-algorithm attacks are
> > 
> > relevant?
> > 
> > No, I don't believe that cross-algorithm attacks from RSA-PSS to PKCS#1
> > v1.5
> > are likely.
> > 
> > I do consider users of PKCS#1 v1.5 to be vulnerable to attacks that can be
> > leveraged against both PKCS#1 v1.5 and RSA-PSS
> 
> I'm really not sure how to parse your response. I'm not sure if your "No"
> is your answer - as in you don't believe they're relevant - or "No" as you
> disagreeing with my framing of the question and that "Yes", you do believe
> they're relevant, despite them not being likely.
> 
> I'm further not sure how to parse your remark about "users of PKCS#1 v1.5"
> - as to whether you mean the signers or the verifiers.

if the certificate is usable with PKCS#1 v1.5 signatures, it makes it 
vulnerable to attacks like the Bleichenbacher, if it is not usable with PKCS#1 
v1.5 it's not vulnerable in practice to such attacks
 
> > > Sure. But why does that intention - which cannot be technically enforced
> > 
> > RSA-PSS OID in SPKI does exactly that, what do you mean "cannot be
> > technically
> > enforced"?
> 
> It does not do prevent such a signature from being created - that's what I
> mean.

now you're being silly

the Mozilla policy doesn't prohibit the CA from making a service that will 
perform RSA private key operation on arbitrary strings either but we would 
still revoke trust from CA that would do such a thing, because just the fact 
that such a service _could_ have been used maliciously (to sign arbitrary 
certificates) is enough to distrust it!

> If it doesn't prevent such a signature, and the act of signing weakens the
> key itself, then such a constraint is pointless.
> If it simply indicates to a client "Don't accept this signature", but the
> act of signing weakens the key still, then such a constraint is pointless.
> If it does not weaken the key, then indicating to the client such a
> constraint is pointless, because any client that encounters such a
> signature has proof that the CA has failed to abide by the policy of their
> key - and if so, everything used with that key should be rightfully called
> into question, and no 'damage mitigation' has been achieved.

I don't think that it's the act of making the signature that weakens the key

If I generate a certificate has RSA-PSS SPKI I won't be able to use it for 
PKCS#1 v1.5 signatures - no widely deployed server will use it like that and 
no widely deployed client will accept such use. So a chance that a key will be 
abused like that and will remain abused like that is negligible.

and that's the whole point - defence in depth - to make it another hurdle to 
jump through if you want to do something stupid

> > > and is itself related to the usage of the key, not the trust in the
> > > signatures - need to be expressed in the certificate?
> > 
> > If the certificates has SPKI with RSA-PSS id, that means exactly that -
> > never
> > trust PKCS#1 v1.5 signatures made with this key.
> 
> Yes. And expressing that is pointless (see above).
>
> > > I disagree. I don't believe there's value in the expression of that from
> > > the CA within the certificate, for the reasons I previously mentioned -
> > > that intention can be subverted if the CA is willing to use SHA-1 or
> > > SHA-256 when they declared they will not, or if the CA is not willing,
> > 
> > then
> > 
> > > it's introducing unnecessary complexity into the client ecosystem for
> > > limited benefits.
> > 
> > If the RSA-PSS parameters in SPKI say SHA-256, SHA-1 signature made with
> > such
> > certificates never was and never will be valid. So creating SHA-1
> > signatures
> > is useless from point of view of legitimate CA.
> > 
> > It's like having technically constrained CA limited to .com domain and
> > issuing
> > certificate for .org domain - no valid PKIX implementation will trust
> > them.
> 
> I understand - but I'm saying that what we're discussing fundamentally
> relates to the key.
> 
> If a CA was technically constrained to .com, said they would never issue
> for something not .com, but then issued for .org, it's absolutely grounds
> for concern.
> If it doesn't matter whether a CA issues for .com or .org, and they simply
> choose to only issue for .com, then it doesn't make sense to require
> clients to support the CA's expression of intent if doing so introduces
> security risk to clients (and it does) and complexity risk.

so where's the bug that removes support for that in Firefox? Will we get it in 
before the next ESR? /s

> > > The extent of which this provides value is to allow a CA who, bearing a
> > > certificate whose public key is constrained to SHA-384, and upon being
> > > presented a SHA-256 certificate signed by the associated private key, to
> > > claim "That's not misissuance, because I said 

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