RE: Anomalous Certificate Issuances based on historic CAA records

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

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

RE: Anomalous Certificate Issuances based on historic CAA records

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

Re: Anomalous Certificate Issuances based on historic CAA records

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

RE: Anomalous Certificate Issuances based on historic CAA records

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

Re: Anomalous Certificate Issuances based on historic CAA records

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

Re: Anomalous Certificate Issuances based on historic CAA records

> 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

RE: Anomalous Certificate Issuances based on historic CAA records

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

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

Re: Anomalous Certificate Issuances based on historic CAA records

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

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

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

RE: Anomalous Certificate Issuances based on historic CAA records

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

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

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

Re: Anomalous Certificate Issuances based on historic CAA records

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

Re: Anomalous Certificate Issuances based on historic CAA records

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 >