Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread 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

2017-11-29 Thread 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

2017-11-29 Thread 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

2017-11-29 Thread 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 
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 
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 
  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&u=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
> > qzTqItI

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread 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&u=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&u=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_74YdlLpwafEHJsWyJlsnxXxdlqbrgt
> uvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0Lh
> TmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__
> 1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHo
> xoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-
> J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4
> WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3C
> iwy38yneQ5QEbj

Re: Warning about posting via Google Groups

2017-11-29 Thread Kathleen Wilson via dev-security-policy 
On Monday, November 20, 2017 at 7:51:59 AM UTC-8, Gervase Markham wrote:
> Dear m.d.s.p.,
> 
> We appear to again have a problem with messages posted via the Google
> Groups web UI making it to all subscribers on the list:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1412993
> 
> Until that problem is resolved, if you wish to post to the list, please
> subscribe to the mailing list version or use the newsgroup gateway:
> https://www.mozilla.org/about/forums/#dev-security-policy
> 
> The Google Groups UI can still be used for referencing messages, and for
> reading the list.
> 
> Gerv



If any of you have recently posted to mozilla.dev.security.policy, and your 
message has not shown up in Google Groups, please forward your message to me 
with full headers.

The folks trying to debug this problem need the full email header for a failed 
message that is less than 8 days old. (all of the ones that I had previously 
provided are older than 8 days)

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

Re: test - please ignore this thread

2017-11-29 Thread Kathleen Wilson via dev-security-policy 
On Wednesday, November 29, 2017 at 1:39:54 PM UTC-8, Kathleen Wilson wrote:
> Please ignore this email thread.
> 
> In order for folks to debug the problem of posts to 
> mozilla.dev.security.policy not getting propagated to Google Groups, they 
> need email headers that are less than 8 days old.
> 
> Reference:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1412993
> 
> Thanks,
> Kathleen


Trying again...



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

test - please ignore this thread

2017-11-29 Thread Kathleen Wilson via dev-security-policy 
Please ignore this email thread.

In order for folks to debug the problem of posts to mozilla.dev.security.policy 
not getting propagated to Google Groups, they need email headers that are less 
than 8 days old.

Reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=1412993

Thanks,
Kathleen

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

Re: Mozilla RSA-PSS policy

2017-11-29 Thread Ryan Sleevi via dev-security-policy 
On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario  wrote:

> > The extent of the argument for flexibility, so far, has been OpenSSL's
> > behaviour to produce RSA-PSS signatures with a maximal salt length. These
> > same clients are also incapable of parsing RSA-PSS SPKIs (that only came
> > recently, AFAICT).
>
> yes, it can't handle RSA-PSS SPKI, but it can handle RSA-PSS in signatures,
> and my understanding is that we want the same kind of limitations for
> signatures and for SPKI - if only to limit the confusion
>

Correct, the behaviour of OpenSSL is to unfortunately take maximal
advantage of the unnecessary complexity of RFC 4055.

I do not feel that it is in the best interest of users or security to
interoperate with that decision.


> > This probability of encountering such signatures within
> > the Web PKI itself is substantially lower, due to the many requirements
> > around protection of keys and the ease (or more aptly, difficulty) in
> > integrating such libraries with such systems - but even still, can be
> > configured by the client (nominally, the value of -1 indicates saltLen ==
> > len(hash), while -2 indicates the maximal encoding)
>
> Web PKI, now - yes
> But the problem is that Microsoft CAs (for Active Directory) default to
> RSA-
> PSS signatures, which means that Firefox cannot be deployed on such
> internal
> networks.
> This does not help Firefox market share.
>

Let's be precise: My proposal does not change the status quo. It does not
improve the situation as deployed, I readily admit, but it does not make
the entire ecosystem worse because of it.

Further, let's not conflate Microsoft CA generated certificates - which is
what you're noting as the internal networks - with OpenSSL generated
certificates - which have no such data as to the extent of the problem.

Today's status quo: If you have deployed RSA-PSS certificates on your
network, browsers such as Chrome or Firefox, and systems such as macOS or
Android, do not accept such certificates. You need to replace such
certificates.
Tomorrow's status quo: If you have deployed RSA-PSS certificates on your
network, and they do not reflect a sensible security configuration,
browsers such as Chrome or Firefox, and systems such as macOS or Android,
do not accept such certificates. You'd need to replace such certificates -
but you would be able to do so with 'sensible' RSA-PSS configuration.


> and I'm not saying that it is not possible to create signatures with
> correct
> salt lengths with old OpenSSL - but it is not the default, so any kind of
> certificates that were created previously will likely use the default.
> That in
> turn means that it would require reprovisioning all certificates like that,
> not a task that is easy at scale, welcome or with any benefit from the PoV
> of
> users.
>

Again, I think this is an extremely poor argument for introducing global
complexity into the ecosystem, and known-dangerous anti-patterns into
libraries such as NSS.

That is, when I weigh the risk of a limited set of Enterprise users (which
we know is limited, given the above constraints and the lack of prevalence
of OpenSSL in the CA space), I do not feel that it is reasonable or
responsible to suggest that we must accept undue complexity because they
crapped the proverbial bed first by shipping a non-sensical configuration.


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


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

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.


> > and is itself related to the usage of the key, n

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread 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&u=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&u=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&u=https%3A%2F%2Fmisissued.com%2Fbatch%2F33%2F
> > 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

___
de

Re: Mozilla RSA-PSS policy

2017-11-29 Thread Hubert Kario via dev-security-policy 
On Wednesday, 29 November 2017 17:00:58 CET Ryan Sleevi wrote:
> On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy <
> 
> dev-security-policy@lists.mozilla.org> wrote:
> > Because I do not consider making the salt length rigid (one value allowed
> > for
> > every hash) to be of any value. If it is not rigid, it would be silly to
> > provide a correct encoding for every single possible valid encoding.
> 
> I do not consider making the salt length flexible to be of any value.
> Further, I point to the past issues with respect to flexibility - and to
> the many CVEs across a wide spectrum of clients, including NSS, with
> respect to decoding signature parameters, that such flexibility will be
> actively detrimental both to the implementation within Mozilla products and
> to the implementation within the broader Web PKI community.
>
> The extent of the argument for flexibility, so far, has been OpenSSL's
> behaviour to produce RSA-PSS signatures with a maximal salt length. These
> same clients are also incapable of parsing RSA-PSS SPKIs (that only came
> recently, AFAICT).

yes, it can't handle RSA-PSS SPKI, but it can handle RSA-PSS in signatures, 
and my understanding is that we want the same kind of limitations for 
signatures and for SPKI - if only to limit the confusion

> This probability of encountering such signatures within
> the Web PKI itself is substantially lower, due to the many requirements
> around protection of keys and the ease (or more aptly, difficulty) in
> integrating such libraries with such systems - but even still, can be
> configured by the client (nominally, the value of -1 indicates saltLen ==
> len(hash), while -2 indicates the maximal encoding)

Web PKI, now - yes
But the problem is that Microsoft CAs (for Active Directory) default to RSA-
PSS signatures, which means that Firefox cannot be deployed on such internal 
networks.
This does not help Firefox market share.

and I'm not saying that it is not possible to create signatures with correct 
salt lengths with old OpenSSL - but it is not the default, so any kind of 
certificates that were created previously will likely use the default. That in 
turn means that it would require reprovisioning all certificates like that, 
not a task that is easy at scale, welcome or with any benefit from the PoV of 
users.
 
> > > 1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5
> > > and
> > > RSA-PSS signatures with the same key?
> > 
> > depends on the circumstances
> > 
> > 
> > I consider RSA-PSS to be strictly more secure than PKCS#1 v1.5.
> > 
> > So if one already uses PKCS#1 v1.5 and adds RSA-PSS, it doesn't increase
> > the
> > security of the system, but it doesn't decrease it either.
> 
> 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

> If it is, then it either theorhetically or practically weakens the security
> of the system.
> If it's not, then there's no need to afford the flexibility.
> 
> > if one does use rsa-pss only (or has such intention), then use of pkcs#1
> > v1.5
> > with such key would lower the security of the system.
> 
> 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"?

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

> I propose it doesn't
> - which is where the need to express that intention introduces significant,
> and unnecessary, complexity.

I really don't think we're on the same page here...
 
> > > 2) Do you believe it represents a security risk to mix hash algorithms
> > > within RSA-PSS signatures with the same key?
> > 
> > like I said before, the problem is not that the key can be used with
> > sha-384
> > and sha-512 at the same time - that I don't see as a risk, at least not
> > now
> 
> Again, cross-algorithm attacks.
> 
> > Use of the key with sha-1 and sha-384 at the same time, yes, I do, and I
> > don't
> > think this should be allowed.
> 
> But that's not a risk to the key - that's a risk being proposed in which
> the client accepts SHA-1.
> 
> > Now, one may expect that SHA-256 will go the way of SHA-1, then having
> > ability
> > say "I won't use SHA-256", even when it is allowed by both policy and code
> > is
> > a value-add.
> 
> 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 C

Re: Mozilla RSA-PSS policy

2017-11-29 Thread Ryan Sleevi via dev-security-policy 
On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
>
> > The fact that this new NSS implementation does not properly validate the
> > well-formedness of these signatures is somewhat in conflict with your
> > statement:
> > ""it turned out to be a problem because a). it was the 90's, b).
> everybody
> > did
> > it like that, c). everybody assumed (not test) that security software was
> > written, well, securely..."""
> >
> > So are we to conclude that this is still a problem because everybody
> > assumes, but does not test, that NSS is written, well, securely?
>
> I definitely do not assume that, I just do not consider the issues we
> suspect
> to be there and issues we know about (and plan to fix in near future) to be
> blockers for shipping it, because RSA-PSS is in its infancy on the public
> 'net.
>
> I do think that they need to be resolved before TLS 1.3 is in its final
> state
> though.
>

My hope is that we'd prioritize bugs that affect security (SHA-1 in MGF1)
and stability (RSA-PSS laxness), especially if they're identified prior
to/within days of shipping.


>
> > This is similarly an example of a policy 'requiring' X, but this is not
> > required through code or, with your proposed policy, required through
> > policy.
>
> requirement that the certificates be DER encoded is part of X.509 standard,
> it's implicit
>

And yet it's so frequently been messed up that an entire section of
mozilla::pkix workarounds to address this.

The goal of policy is to learn from the mistakes of the past, to better
inform the future.

the policy doesn't state that the byte is 8 bits long or that 'a' is encoded
> using big endian octet of decimal value 97 either...
>

You're correct - but if CAs were frequently messing this up, or
requirements within similar sections, then I would just as ardently
advocate we include such in the policy.


> Because I do not consider making the salt length rigid (one value allowed
> for
> every hash) to be of any value. If it is not rigid, it would be silly to
> provide a correct encoding for every single possible valid encoding.
>

I do not consider making the salt length flexible to be of any value.
Further, I point to the past issues with respect to flexibility - and to
the many CVEs across a wide spectrum of clients, including NSS, with
respect to decoding signature parameters, that such flexibility will be
actively detrimental both to the implementation within Mozilla products and
to the implementation within the broader Web PKI community.

The extent of the argument for flexibility, so far, has been OpenSSL's
behaviour to produce RSA-PSS signatures with a maximal salt length. These
same clients are also incapable of parsing RSA-PSS SPKIs (that only came
recently, AFAICT). This probability of encountering such signatures within
the Web PKI itself is substantially lower, due to the many requirements
around protection of keys and the ease (or more aptly, difficulty) in
integrating such libraries with such systems - but even still, can be
configured by the client (nominally, the value of -1 indicates saltLen ==
len(hash), while -2 indicates the maximal encoding)


> > 1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5 and
> > RSA-PSS signatures with the same key?
>
> depends on the circumstances


> I consider RSA-PSS to be strictly more secure than PKCS#1 v1.5.
>
> So if one already uses PKCS#1 v1.5 and adds RSA-PSS, it doesn't increase
> the
> security of the system, but it doesn't decrease it either.
>

So are you stating you do not believe cross-algorithm attacks are relevant?
If it is, then it either theorhetically or practically weakens the security
of the system.
If it's not, then there's no need to afford the flexibility.


> if one does use rsa-pss only (or has such intention), then use of pkcs#1
> v1.5
> with such key would lower the security of the system.
>

Sure. But why does that intention - which cannot be technically enforced
and is itself related to the usage of the key, not the trust in the
signatures - need to be expressed in the certificate? I propose it doesn't
- which is where the need to express that intention introduces significant,
and unnecessary, complexity.


> > 2) Do you believe it represents a security risk to mix hash algorithms
> > within RSA-PSS signatures with the same key?
>
> like I said before, the problem is not that the key can be used with
> sha-384
> and sha-512 at the same time - that I don't see as a risk, at least not now
>

Again, cross-algorithm attacks.


> Use of the key with sha-1 and sha-384 at the same time, yes, I do, and I
> don't
> think this should be allowed.
>

But that's not a risk to the key - that's a risk being proposed in which
the client accepts SHA-1.


> Now, one may expect that SHA-256 will go the way of SHA-1, then having
> ability
> say "I won't use SHA-256", even when it is allowed by both policy and code
> is
> a value-add.
>

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Quirin Scheitle via dev-security-policy 
Hi Douglas,

thank you for your reply! I have posted a detailed reply at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1420766

Short version: We measure every 8 hours, and I believe the records you have 
seen existed for a short time around your issuance lookup. 

So this would be a false positive, based on the fact that an evaluator/auditor 
can only query so often and records may be changed multiple times between two 
measurements.

Kind regards
Quirin

> On 29. Nov 2017, at 12:26, douglas.beattie--- via dev-security-policy 
>  wrote:
> 
> 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

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

Re: Mozilla RSA-PSS policy

2017-11-29 Thread Hubert Kario via dev-security-policy 
On Tuesday, 28 November 2017 17:09:03 CET Ryan Sleevi wrote:
> On Tue, Nov 28, 2017 at 8:04 AM, Hubert Kario  wrote:
> > On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote:
> > > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario  wrote:
> > > > > So no, we should not assume well-meaning actors, and we should be
> > > > 
> > > > explicit
> > > > 
> > > > > about what the "intention" of the RFCs is, and whether they actually
> > > > > achieve that.
> > > > 
> > > > but we should achieve that by saying "do this", not "don't do this",
> > > > enumerating badness doesn't work - ask firewall people if you don't
> > > > believe
> > > > me.
> > > > 
> > > > Or did we add to policy that keys revoked because they may haven been
> > > > compromised (heartbleed) can't be reused? Ever? Even by a different
> > > > CA?
> > > 
> > > You've completely misframed my proposal. I'm enumerating a specific
> > > whitelist of what is permitted. Every other option, unless otherwise
> > > permitted, is restricted. I'm even going to the level of proposing a
> > > byte-for-byte comparison function such that there's not even a prosaic
> > > whitelist - it's such that the policy is black and white and transcends
> > > language barriers by expressing directly in the technology.
> > > 
> > > You're enumerating a blacklist - saying that all of the flexibility of
> > 
> > 4055
> > 
> > > is permitted (except for these specific combinations), but propose to
> > > enforce neither of those through code or policy.
> > 
> > where did I do that?
> > 
> > it's the second time you're putting words in my mouth, I really do not
> > appreciate that.
> 
> Hubert, while it's certainly not my intent to misrepresent your position, I
> think it's worth remarking that in your reply immediately prior, you
> highlighted that "but we should achieve that by saying 'Do this', not
> "don't do this", enumerating badness doesn't work". This was similarly
> putting words in my mouth - but, as I highlighted, it was a
> misunderstanding, and tried to clarify.

I provided a statement of my opinion, I didn't claim in it what your position 
was.

You provided a statement that read "You're [...] propose to enforce neither of 
those through code or policy". That's putting words in my mouth - words which 
are exact opposites of my stance on the issue.
 
> To your question, the following statements were made earlier in the thread:
> "" - issuing certificates may include RSA-PSS parameters in the Public Key
> Info
> Algorithm Identifier, it's recommended that the hash selected matches the
> security of the key
>  - signature hash and the hash used for mask generation must be the same
> both
> in public key parameters in certificate and in signature parameters
>  - the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and 64
> bytes for SHA-512""
> 
> And yet, in a follow-up, you replied
> 
> ""that would require hardcoding salt lengths, given their meaning in
> subjectPublicKeyInfo, I wouldn't be too happy about it
> 
> looking at OpenSSL behaviour, it would likely render all past signatures
> invalid and making signatures with already released software unnecessarily
> complex (OpenSSL defaults to as large salt as possible)"
> 
> I hope you can see how these two are in conflict - on the one hand, you
> suggest the policy should require X, but then suggest the implementation
> should not enforce X, because it would invalidate OpenSSL signatures.

they're not in conflict, the use of "at least" was deliberate in the first 
quote

> Similarly, with respect to the differences in our approaches, the framing
> you put forward is:
> ""for X.509 only DER is allowed, if the tags or values are not encoded with
> minimal number of bytes necessary, or with indeterminate length, it's not
> DER
> it's BER and that's strictly forbidden""
> 
> However, despite it being forbidden, the code contributed to NSS (and
> mentioned in your original post -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1400844) does not actually
> enforce this.

then that's a bug that needs to be fixed.

Ryan, I have at least half a dozen of bugs on my name in b.m.o complaining 
about wrong alert /descriptions/ being sent by NSS as response to malformed 
packets. You really think that I won't be so through with rsa-pss in 
certificates?

I already have bugs filed complaining of NSS allowing SHA-1 in MGF1 when sha-1 
is disabled through policy!

> The fact that this new NSS implementation does not properly validate the
> well-formedness of these signatures is somewhat in conflict with your
> statement:
> ""it turned out to be a problem because a). it was the 90's, b). everybody
> did
> it like that, c). everybody assumed (not test) that security software was
> written, well, securely..."""
> 
> So are we to conclude that this is still a problem because everybody
> assumes, but does not test, that NSS is written, well, securely?

I definitely do not assume that, I just do not consider the issues we sus

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread 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