Re: Online exposed keys database

[Ryan Hurst via dev-security-policy]

On Tuesday, December 18, 2018 at 2:44:22 AM UTC-8, Matt Palmer wrote:
> Hi all,
> 
> I'd like to make everyone aware of a service I've just stood up, called
> pwnedkeys.com.  It's intended to serve as a clearinghouse of known-exposed
> private keys, so that services that accept public keys from external
> entities (such as -- relevant to mdsp's interests -- CAs) can make one call
> to get a fairly authoritative answer to the question "has the private key
> I'm being asked to interact with in some way been exposed?".
> 
> It's currently loaded with great piles of Debian weak keys (from multiple
> architectures, etc), as well as some keys I've picked up at various times. 
> I'm also developing scrapers for various sites where keys routinely get
> dropped.
> 
> The eventual intention is to be able to go from "private key is on The
> Public Internet somewhere" to "shows up in pwnedkeys.com" automatically and
> in double-quick time.
> 
> I know there are a number of very clever people on this list who have found
> and extracted keys from more esoteric places than Google search, and I'd be
> really interested in talking to you (privately, I'd imagine) about getting
> specimens of those keys to add to the database.
> 
> I'd also welcome comments from anyone about the query API, the attestation
> format, the documentation, or anything else vaguely relevant to the service. 
> Probably best to take that off-list, though.
> 
> I do have plans to develop a PR against (the AWS Labs') certlint to cause it
> to query the API, so there's no need for anyone to get deep into that unless
> they're feeling especially frisky.  Other linting tools will *probably* have
> to do their own development, as my Go skills are... rudimentary at best,
> shall we say.  I'd be happy to give guidance or any other necessary help to
> anyone looking at building those, though.
> 
> Finally, if any CAs are interested in integrating the pwnedkeys database
> into their issuance pipelines, I'd love to discuss how we can work together.
> 
> Thanks,
> - Matt

This is great. I purchased keycompromise.com ages ago to build something just 
like this. Im very glad to see you took the time to make this.

My first thought is by using SPKI you have limited the service unnecessarily to 
X.509 related keys, I imagined something like this covering PGP, JWT as well as 
other formats. It would be nice to see the scope increased accordingly.

It would be ideal if it were possible to download the database also, the 
latency of the use of a third-party service while issuing certs is potentially 
too much for a CA to eat at issuance time; something that could optionally be 
used on-prem wouldn't leak affiliation and address this.

As long as its limited to X.509, or at least as long as it supports it and uses 
SPKI, it would be interesting to have the website use PKIjs to let you browse 
to a cert, csr or key and the SPKI calculated for you. Happy to help with that 
if your interested.

Personally I prefer https://api.pwnedkeys.com/v1/ to 
https://v1.pwnedkeys.com/.

I see your using JWS; I had been planning on building mine on top of Trillian 
(https://github.com/google/trillian) so you could have an auditable low trust 
mechanism to do this. Let me know if your interested in that and I would be 
happy to help there.

Anyways thanks for doing this.

Ryan Hurst
(personal)


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

Re: Underscore characters

[Peter Bowen via dev-security-policy]

On Tue, Dec 18, 2018 at 6:52 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ballot 202 failed. I’m not sure how it’s relevant other than to indicate
> there was definite disagreement about whether underscores were permitted or
> not. As previously mentioned, I didn’t consider underscore characters
> prohibited until the ballot was proposed eliminating them in Oct. I know
> the general Mozilla population disagrees but, right or wrong, that’s the
> root cause of it all. I can explain my reasoning again here, but I doubt it
> materially alters the conversation and outcome.
>

I agree that Jeremy that the situation with underscores was unclear prior
to the ballot in October.  Three years ago when I was writing certlint, my
very first public commit has the comment:
# Allow RFC defying '*' and '_'

I honestly haven't been pay a lot of attention to the CA/Browser Forum
recently.  Given the rationale for getting rid of underscores is RFC
compliance, did the ballot also disallow asterisks?  They are also not
allowed by the "preferred name syntax", as specified by Section 3.5 of
[RFC1034]  and as modified
by Section 2.1 of 
 [RFC1123] .

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

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

Yeah – I’ll be providing an accurate incident report (working on gathering all 
the information). The incident report assumes we don’t revoke of course. 
Revocation is still on the table. However, I wanted to start the conversation 
with everything I know so far:



1) ~2200 certs 

2) Roughly 15 companies
3) Only one has publicly chimed in so far on the Mozilla thread (still hoping 
more will…)

4) Revocation of all certs will occur by May 1, 2019, depending on how the 
discussion here goes.   
5) The common thread is that the Jan 15th deadline falls in the blackout window 
of most orgs. They generally come off it between Jan 15-Feb 15. They can’t 
replace the cert or change the domain so the 30 day cert option doesn’t help.

6) We provided notice as soon as the ballot passed. We blocked issuance prior 
to that date, but we’d hoped that the certs could remain valid until 
expiration. We had trouble with our BI providing the information so some 
notices went out later than I’d hoped. I’ll find the exact date on when all 
notices were complete.

 

Ballot 202 failed. I’m not sure how it’s relevant other than to indicate there 
was definite disagreement about whether underscores were permitted or not. As 
previously mentioned, I didn’t consider underscore characters prohibited until 
the ballot was proposed eliminating them in Oct. I know the general Mozilla 
population disagrees but, right or wrong, that’s the root cause of it all. I 
can explain my reasoning again here, but I doubt it materially alters the 
conversation and outcome. 

 

From: Ryan Sleevi  
Sent: Tuesday, December 18, 2018 7:35 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: Underscore characters

 

Jeremy,

 

It seems like any answer for what it "might" look like if a CA violated the BRs 
in a particular way is going to be predicated on what the incident report says. 
In the case of a hypothetical like this, it seems like the hypothetical 
incident report would discuss what is planned or proposed, and should a CA go 
forward with such an intentional violation, the 'actual' incident report would 
equally consider how accurate that was.

 

Recall that the approach to incident reporting is not punitive - it's to make 
sure that we're addressing systemic gaps and issues, that we've understood the 
issues, and have the available data to assess the impact, risk, and any 
patterns of issues. The incident reporting template is one way to provide that 
data in a structured way and to gather feedback.

 

I think a minimum next step is to move from the abstract discussion to the 
concrete: imagine you went forward on Jan 15 and had to file an incident 
report. Write the report like that. Include the timeframes, affected 
certificates, impact, root causes, remediation plans, etc. Having a complete 
presentation of what the discussion is about seems critical to having that 
discussion, because it would be unreasonable to expect information to trickle 
in and new customers or use cases added as the discussion progresses.

 

Thus there's a balance to be struck: Treating each hypothetical as a "separate" 
incident report runs the risk of being considered in isolation, ignoring both 
the systemic gaps and the cumulative risk. At the same time, treating it as a 
"singular" incident report tries to paint all problems in the same stroke, and 
can overlook distinct systemic issues. Both cases run the risk of "scope 
creep", which is constantly adding or expanding the scope, which is as well 
received in legitimate incident reports as it is hypothetical (which is to say: 
not well). Perhaps the best analogy is to that of subordinate CAs: each time a 
subordinate has an issue, that's an incident report, and a pattern of issues at 
distinct subordinates is equally a concerning issue for the parent CA. You 
don't want to loop all distinct subordinates into one issue, but you also don't 
want to lose sight of the systemic issues with the parent.

 

Beyond that framing and execution, it seems useful to suggest that any timeline 
about underscores should at least acknowledge Ballot 202 in June 2017 and 
any/all steps the CA took leading up to and following SC12. 

 

None of this is radically new or should be surprising: DigiCert and other CAs 
have already had similar conversations in discussing other matters of BR 
compliance and revocation. All of these have become part of the CA's record of 
incidents. When the CA proposes extending revocation timelines, a discussion of 
the facts, risks, scope, and patterns play a core part in any discussion in 
determining the short term acceptability of the proposal, and unquestionably 
all factor in to any long-term discussions that may later happen.

 

The one last closing thought is that I think we're in the waning days for when 
such hypothetical issues or concrete delay proposals can or should be 
discussed. Given the many discussions that have been had regarding revocation - 
regarding 

Re: Underscore characters

[Ryan Sleevi via dev-security-policy]

Jeremy,

It seems like any answer for what it "might" look like if a CA violated the
BRs in a particular way is going to be predicated on what the incident
report says. In the case of a hypothetical like this, it seems like the
hypothetical incident report would discuss what is planned or proposed, and
should a CA go forward with such an intentional violation, the 'actual'
incident report would equally consider how accurate that was.

Recall that the approach to incident reporting is not punitive - it's to
make sure that we're addressing systemic gaps and issues, that we've
understood the issues, and have the available data to assess the impact,
risk, and any patterns of issues. The incident reporting template is one
way to provide that data in a structured way and to gather feedback.

I think a minimum next step is to move from the abstract discussion to the
concrete: imagine you went forward on Jan 15 and had to file an incident
report. Write the report like that. Include the timeframes, affected
certificates, impact, root causes, remediation plans, etc. Having a
complete presentation of what the discussion is about seems critical to
having that discussion, because it would be unreasonable to expect
information to trickle in and new customers or use cases added as the
discussion progresses.

Thus there's a balance to be struck: Treating each hypothetical as a
"separate" incident report runs the risk of being considered in isolation,
ignoring both the systemic gaps and the cumulative risk. At the same time,
treating it as a "singular" incident report tries to paint all problems in
the same stroke, and can overlook distinct systemic issues. Both cases run
the risk of "scope creep", which is constantly adding or expanding the
scope, which is as well received in legitimate incident reports as it is
hypothetical (which is to say: not well). Perhaps the best analogy is to
that of subordinate CAs: each time a subordinate has an issue, that's an
incident report, and a pattern of issues at distinct subordinates is
equally a concerning issue for the parent CA. You don't want to loop all
distinct subordinates into one issue, but you also don't want to lose sight
of the systemic issues with the parent.

Beyond that framing and execution, it seems useful to suggest that any
timeline about underscores should at least acknowledge Ballot 202 in June
2017 and any/all steps the CA took leading up to and following SC12.

None of this is radically new or should be surprising: DigiCert and other
CAs have already had similar conversations in discussing other matters of
BR compliance and revocation. All of these have become part of the CA's
record of incidents. When the CA proposes extending revocation timelines, a
discussion of the facts, risks, scope, and patterns play a core part in any
discussion in determining the short term acceptability of the proposal, and
unquestionably all factor in to any long-term discussions that may later
happen.

The one last closing thought is that I think we're in the waning days for
when such hypothetical issues or concrete delay proposals can or should be
discussed. Given the many discussions that have been had regarding
revocation - regarding technical non-compliance, compromised keys, weak
validation, etc - the argument that "replacing a cert is hard" is not
really going to be acceptable anymore without demonstration about what
steps are being taken by CAs and Subscribers to mitigate that risk (such as
automation) and communicate expectations (such as in Subscriber Agreements
or Terms of Sale). I don't think we want to go through 2019, and certainly
not come out of it, having the same conversations we've been having in
2018. The best way to prevent that is for CAs to take clear steps to work
to resolve these issues with their customers, so that it never becomes an
issue for them, or their CA, in the first place. CAs that aren't able to
demonstrate steps towards that in future discussions are unlikely to be
looked upon too favorably if there are future incident reports.

On Tue, Dec 18, 2018 at 5:43 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The total number of certs impacted is about 2200. Just more info.
>
> -Original Message-
> From: dev-security-policy 
> On
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Tuesday, December 18, 2018 3:28 PM
> To: mozilla-dev-security-policy
> 
> Subject: Underscore characters
>
> We're looking at the feasibility of replacing the certificates with
> underscore characters by Jan 15th. Revoking all of the certificates will
> cause pretty bad outages. We're prepared to revoke them but would like to
> discuss (before the date) what should happen if we don't revoke. There are
> about 15 customers (which I can't disclose the names yet but am working on
> the list of certs). The number of certificates range between 1700-100
> certificates per customer.
>
>
>
> The primary reason for this is 

Re: CA Communication: Underscores in dNSNames

[Wayne Thayer via dev-security-policy]

On Tue, Dec 18, 2018 at 3:47 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Removing the "underscore mandatory" and "specific name X_Y mandatory"
> rules
> from deployed systems without introducing security holes takes more than
> the
> 1 month they have given that the annual Thanksgiving-to-NewYears lockdown
> has been mentioned in other global issues.  (In fact this is the first
> subscriber/RP interfering BR effective date hitting the Xmas season since
> the SHA-1 deprecation).
>
> The only thing that's required by 15-Jan is that existing certificates
containing underscores need to be replaced with new ones with the same
dNSNames. The deadline for updating systems to remove dependencies on
underscores in certificates is 30-April.

The 15-Jan deadline was negotiated with holiday change freezes in mind. The
assumption was that these freezes end in early January, providing
sufficient time to perform a routine certificate replacement. While I
understand that the replacement is not necessarily as simple as it should
be for all affected systems, and in other cases it's simple but there are
lots of certificates to replace, I think this is really just highlighting
the lack of agility in existing enterprise systems that use
publicly-trusted certificates. Hopefully this "huge mess" will spur
improvements over time.

I am also struggling with the argument that "revoking these certificates
will cause a massive outage, but we can't replace them due to our change
freeze." Given this position, I sincerely hope that no severe zero-days are
released during the holidays.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Communication: Underscores in dNSNames

[Jakob Bohm via dev-security-policy]

On 18/12/2018 18:15, Ryan Sleevi wrote:
> On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> On 10/12/2018 18:09, Ryan Sleevi wrote:
>>> On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
 Hello!

 It would be helpful, if the CA/B or Mozilla could publish a document on
 its web pages to which we can redirect our customers, if they have
 technical questions about this underscore issue. Right now, I can only
>> tell
 them, that they are forbidden because the ballot to explicitly allow
>> them
 failed, but not really why. Especially since the first result in Google
>> for
 "underscore domain name" is a StackOverflow article (
 https://stackoverflow.com/a/2183140/1426535) stating that it is
 technically perfectly okay and also RFC 5280 says "These characters
 [underscore and at-sign] often appear in Internet addresses.  Such
 addresses  MUST be encoded using an ASN.1 type that supports them."

>>>
>>> There's definitely been a lot of back and forth on this topic. It's
>> unclear
>>> if you're looking for a clearer statement about why they're forbidden or
>>> where they're forbidden.
>>>
>>
>> It is clear that Rufus is looking for a link to the deprecation ballot,
>> rather than the old (failed) non-deprecation ballot.
>>
> 
> Thanks for sharing your interpretation. I don't think that is an accurate
> summary, but it's useful to understand your perspective and how you
> interpret things.
> 

Well he wanted that or another _single document_ that affected parties 
can read, rather than trying to dig through the RFCs and mailing lists 
themselves.

> 
>>> If the question is where they are forbidden,
>>> https://tools.ietf.org/html/rfc5280#section-4.2.1.6
>>>
>>>  When the subjectAltName extension contains a domain name system
  label, the domain name MUST be stored in the dNSName (an IA5String).
  The name MUST be in the "preferred name syntax", as specified by
  Section 3.5 of [RFC1034] and as modified by Section 2.1 of
  [RFC1123].  Note that while uppercase and lowercase letters are
  allowed in domain names, no significance is attached to the case.
>> In
  addition, while the string " " is a legal domain name,
>> subjectAltName
  extensions with a dNSName of " " MUST NOT be used.  Finally, the use
  of the DNS representation for Internet mail addresses
  (subscriber.example.com instead of subscri...@example.com) MUST NOT
  be used; such identities are to be encoded as rfc822Name.  Rules for
  encoding internationalized domain names are specified in Section
>> 7.2.
>>>
>>
>> The huge mess comes from the fact that this requirement of not
>> using the underscore character (which is actually used in some
>> RFC-specified DNS names labels, though for special purposes) was
>> buried in a complicated reference to two old RFCs, each of which
>> in turn describe that particular restriction in a complicated and
>> indirect way.
>>
> 
> I find your summary interesting. I presume, then, that you feel that the
> need to use DNS is buried in complicated references to old RFCs, much as it
> would be how HTTP works or, for that matter, how ASN.1 works. It's
> certainly true that, as we build complex systems, we stand on the shoulder
> of giants, and as we build code and systems, we layer them. I think it's
> rather misguided and ignorant to suggest that, because a document is
> referenced by another document, it somehow becomes complicated, or that the
> age matters. Were that the case, we'd presume the Baseline Requirements
> would include everything from the IP specification to the ASN.1
> specification, and everything in between, and then lament at how anyone is
> supposed to understand or maintain the salient bits of this 10,000 page
> document.
> 

The simple fact that the leading experts on the subject disagreed on 
the issue shows that the outcome wasn't obvious (the opposite outcome 
would not have been obvious either).

It's the classic question if corner case behavior of a piece of code is a 
feature or a bug, except it was English-language documents, not C-language 
code.

The wording and structure of RFC5280 (and its predecessor RFC2459) is such 
that it appears to state an encoding of DNS names, not a restriction to 
ARPANET host names.  For a subscriber or relying party developing and 
deploying a system like the one described by pilgrim2223, everything after 
the 2nd paragraph of 4.2.1.6 would look like ASN.1/DER encoding details to 
be handled by the 3rd party TLS library, and such a subscriber would probably 
believe it when both a Google search and their CA tells them it is A-OK.

Removing the "underscore mandatory" and "specific name X_Y mandatory" rules 
from deployed systems without introducing security holes takes 

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

The total number of certs impacted is about 2200. Just more info.

-Original Message-
From: dev-security-policy  On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, December 18, 2018 3:28 PM
To: mozilla-dev-security-policy

Subject: Underscore characters

We're looking at the feasibility of replacing the certificates with
underscore characters by Jan 15th. Revoking all of the certificates will
cause pretty bad outages. We're prepared to revoke them but would like to
discuss (before the date) what should happen if we don't revoke. There are
about 15 customers (which I can't disclose the names yet but am working on
the list of certs). The number of certificates range between 1700-100
certificates per customer. 

 

The primary reason for this is every one of these organization are in a
holiday blackout.  The blackout periods end between Jan 12-Feb 15. Can we
start this discussion now on what this means? I'll provide certificate lists
as I have a timeline on when they plan on replacing.

 

Jeremy

 



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: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of December 2018 Audit Reminder Emails
Date: Tue, 18 Dec 2018 20:00:20 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   TrustCor RootCert CA-2
   TrustCor RootCert CA-1
   TrustCor ECA-1
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221175

Audit Statement Date: 2017-12-15
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221176

BR Audit Statement Date: 2017-12-15
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   EE Certification Centre Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://sk.ee/upload/files/AA2017112401_Audit%20Attestation_final.pdf

Audit Statement Date: 2017-11-24
BR Audit: 
https://sk.ee/upload/files/AA2017112401_Audit%20Attestation_final.pdf

BR Audit Statement Date: 2017-11-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Certigna
   Certigna Root CA
Standard Audit: 
https://bug1265683.bmoattachments.org/attachment.cgi?id=8947405

Audit Statement Date: 2018-01-12
BR Audit: https://bug1265683.bmoattachments.org/attachment.cgi?id=8947405
BR Audit Statement Date: 2018-01-12
CA Comments: null



Mozilla: Overdue Audit Statements
Root Certificates:
   Certinomis - Root CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug937589.bmoattachments.org/attachment.cgi?id=8898169

Audit Statement Date: 2017-07-24
BR Audit: https://bug937589.bmoattachments.org/attachment.cgi?id=8898169
BR Audit Statement Date: 2017-07-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Microsec e-Szigno Root CA 2009**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017121401_Browser_Audit_Attestation_s.pdf

Audit Statement Date: 2017-12-14
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017121402_Browser_Audit_Attestation_s.pdf

BR Audit Statement Date: 2017-12-14
CA Comments: null



Mozilla: Overdue Audit Statements
Root Certificates:
   Class 2 Primary CA**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590

Audit Statement Date: 2017-07-24
BR Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8916590
BR Audit Statement Date: 2017-07-24
CA Comments: https://bugzilla.mozilla.org/show_bug.cgi?id=1465629



Mozilla: Audit Reminder
Root Certificates:
   SwissSign Gold CA - G2**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017113001_Browser_Audit_Attestation_s.pdf

Audit Statement Date: 2017-11-30
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017113001_Browser_Audit_Attestation_s.pdf

BR Audit Statement Date: 2017-11-30
EV Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/de/AA2017113001_Browser_Audit_Attestation_s.pdf

EV Audit Statement Date: 2017-11-30
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Secure Global CA**
   SecureTrust CA**
   XRamp Global Certification Authority**

** Audit Case in the Common CA Database is under review for this root 
certificate.


Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221135

Audit Statement Date: 2017-11-17
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221136

BR Audit Statement Date: 2017-11-17
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221137

EV Audit Statement Date: 2017-11-17
CA Comments: null




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

Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

[Ryan Sleevi via dev-security-policy]

On Tue, Dec 18, 2018 at 1:53 PM Tim Hollebeek 
wrote:

> The problem is that the attackers get to choose the CA they use, so
> multi-perspective validation doesn't provide any benefits unless everyone
> has to do it.
>
> I brought it up several times at the validation working group and as a
> discussion topic at the Shanghai face to face, but unfortunately there
> doesn't seem to be much enthusiasm for requiring it.
>

I think it's great that you're focused on the end-goal, and I certainly
share your perspective on the security properties.

However, I think you're overlooking that the reason that there is not much
enthusiasm for it is precisely because mandating something, without
implementation experience, tends to lend itself to CAs having trouble
deploying. That's not to suggest there's an oppositon to mandate - when
push comes to shove, ultimately users' security needs to take precedence -
but that it's both irresponsible and premature to propose mandating it (or
forming a committee on mandating it, or a committee to discuss the
requirements a mandate would have, etc) before there's been any progress on
what works or doesn't work.

As a result, knowing that organizations like Sectigo and Let's Encrypt are
either actively working on it or assigning resources to think about it in
the context of their system IS encouraging, and suggests that we do have a
path forward, once we've gathered meaningful feedback.

I know that some CAs feel browsers "rush in" on things, and even I feel odd
pushing back against you on requiring it, but I think that if we want to
have this provide any value, then in addition to, and prior to, mandating
it, we need to actually write down what it means, have a think about how it
works, and how to attack it. And it sounds like Sectigo and Let's Encrypt
have begun that step, and I hope that any other CAs participating or
following the list are doing the same and can commit to it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

[Tim Hollebeek via dev-security-policy]

The problem is that the attackers get to choose the CA they use, so
multi-perspective validation doesn't provide any benefits unless everyone
has to do it.

I brought it up several times at the validation working group and as a
discussion topic at the Shanghai face to face, but unfortunately there
doesn't seem to be much enthusiasm for requiring it.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Rob Stradling via dev-security-policy
> Sent: Tuesday, December 18, 2018 7:42 AM
> To: Wayne Thayer 
> Cc: Ryan Sleevi ; mar...@marcan.st; mozilla-dev-security-
> policy 
> Subject: Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable
> 
> On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:
> 
> > I think it;s worth calling out that Let's Encrypt has implemented what
> > appears to be a relatively simple mitigation:
> > https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-b
> > ytes/77945
> 
> Sectigo implemented this same mitigation about a month ago.
> 
> > I am also interested to know if other CAs are considering this or
> > other mitigations (e.g. multi-perspective validation) for this attack.
> 
> Multi-perspective validation is something we've started to think about
too.
> 
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
> 
> ___
> 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: CA Communication: Underscores in dNSNames

[Ryan Sleevi via dev-security-policy]

On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 10/12/2018 18:09, Ryan Sleevi wrote:
> > On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> Hello!
> >>
> >> It would be helpful, if the CA/B or Mozilla could publish a document on
> >> its web pages to which we can redirect our customers, if they have
> >> technical questions about this underscore issue. Right now, I can only
> tell
> >> them, that they are forbidden because the ballot to explicitly allow
> them
> >> failed, but not really why. Especially since the first result in Google
> for
> >> "underscore domain name" is a StackOverflow article (
> >> https://stackoverflow.com/a/2183140/1426535) stating that it is
> >> technically perfectly okay and also RFC 5280 says "These characters
> >> [underscore and at-sign] often appear in Internet addresses.  Such
> >> addresses  MUST be encoded using an ASN.1 type that supports them."
> >>
> >
> > There's definitely been a lot of back and forth on this topic. It's
> unclear
> > if you're looking for a clearer statement about why they're forbidden or
> > where they're forbidden.
> >
>
> It is clear that Rufus is looking for a link to the deprecation ballot,
> rather than the old (failed) non-deprecation ballot.
>

Thanks for sharing your interpretation. I don't think that is an accurate
summary, but it's useful to understand your perspective and how you
interpret things.


> > If the question is where they are forbidden,
> > https://tools.ietf.org/html/rfc5280#section-4.2.1.6
> >
> > When the subjectAltName extension contains a domain name system
> >> label, the domain name MUST be stored in the dNSName (an IA5String).
> >> The name MUST be in the "preferred name syntax", as specified by
> >> Section 3.5 of [RFC1034] and as modified by Section 2.1 of
> >> [RFC1123].  Note that while uppercase and lowercase letters are
> >> allowed in domain names, no significance is attached to the case.
> In
> >> addition, while the string " " is a legal domain name,
> subjectAltName
> >> extensions with a dNSName of " " MUST NOT be used.  Finally, the use
> >> of the DNS representation for Internet mail addresses
> >> (subscriber.example.com instead of subscri...@example.com) MUST NOT
> >> be used; such identities are to be encoded as rfc822Name.  Rules for
> >> encoding internationalized domain names are specified in Section
> 7.2.
> >
>
> The huge mess comes from the fact that this requirement of not
> using the underscore character (which is actually used in some
> RFC-specified DNS names labels, though for special purposes) was
> buried in a complicated reference to two old RFCs, each of which
> in turn describe that particular restriction in a complicated and
> indirect way.
>

I find your summary interesting. I presume, then, that you feel that the
need to use DNS is buried in complicated references to old RFCs, much as it
would be how HTTP works or, for that matter, how ASN.1 works. It's
certainly true that, as we build complex systems, we stand on the shoulder
of giants, and as we build code and systems, we layer them. I think it's
rather misguided and ignorant to suggest that, because a document is
referenced by another document, it somehow becomes complicated, or that the
age matters. Were that the case, we'd presume the Baseline Requirements
would include everything from the IP specification to the ASN.1
specification, and everything in between, and then lament at how anyone is
supposed to understand or maintain the salient bits of this 10,000 page
document.

Furthermore, Section 4.2.1.6 of RFC5280 applies only to
> SubjectAltNames, not to DNS names placed directly in the Subject
> Distinguished Name in the certificate.  Thus this particular
> restriction on DNS names to which certificates can be issued only
> became effective as a side effect of deprecating TLS certificates
> without SubjectAltNames.
>

If you're speaking to this side-effect being placed in 20 years ago, yes,
sure, then it's a side-effect, and the industry has had nearly twenty years
to contemplate the implications. The use of commonName within the context
of TLS was very much a 'hack', emerging both from the lack of X.509v3 (and
it's generic extension mechanism) and a repurposing of an existing OID in
the absence of the X.500 Global DIT (with would have otherwise set the
formatting restrictions). But it is inaccurate and revisionist to suggest
that this was a restriction on DNS names expressed through certificates -
as the underlying restriction itself comes from the host name form. That
is, 5280 is restating existing policy, not introducing new policy, in the
hope that people would understand, rather than entrench deeper into their
misunderstanding.

This made it completely unclear to most people that DNS labels
> with underscores were not 

Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

[Ryan Sleevi via dev-security-policy]

On Tue, Dec 18, 2018 at 7:41 AM Rob Stradling  wrote:

> On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:
> 
> > I think it;s worth calling out that Let's Encrypt has implemented what
> > appears to be a relatively simple mitigation:
> >
> https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945
>
> Sectigo implemented this same mitigation about a month ago.
>

Like Let's Encrypt, is there any data Sectigo can share regarding the
impact it has had on operations? Or has it been so negligible as to not
notice?

It's rather encouraging to hear another CA has deployed this, seemingly
successfully, and having data that shows the impact helps make informed
decisions about whether attempting to mandate through policy - whether
Mozilla or the CA/Browser Forum - would have any negative effects, given
the positive effects it seems to have.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Communication: Underscores in dNSNames

[Jakob Bohm via dev-security-policy]

On 10/12/2018 18:09, Ryan Sleevi wrote:
> On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> Hello!
>>
>> It would be helpful, if the CA/B or Mozilla could publish a document on
>> its web pages to which we can redirect our customers, if they have
>> technical questions about this underscore issue. Right now, I can only tell
>> them, that they are forbidden because the ballot to explicitly allow them
>> failed, but not really why. Especially since the first result in Google for
>> "underscore domain name" is a StackOverflow article (
>> https://stackoverflow.com/a/2183140/1426535) stating that it is
>> technically perfectly okay and also RFC 5280 says "These characters
>> [underscore and at-sign] often appear in Internet addresses.  Such
>> addresses  MUST be encoded using an ASN.1 type that supports them."
>>
> 
> There's definitely been a lot of back and forth on this topic. It's unclear
> if you're looking for a clearer statement about why they're forbidden or
> where they're forbidden.
> 

It is clear that Rufus is looking for a link to the deprecation ballot, 
rather than the old (failed) non-deprecation ballot.

> If the question is where they are forbidden,
> https://tools.ietf.org/html/rfc5280#section-4.2.1.6
> 
> When the subjectAltName extension contains a domain name system
>> label, the domain name MUST be stored in the dNSName (an IA5String).
>> The name MUST be in the "preferred name syntax", as specified by
>> Section 3.5 of [RFC1034] and as modified by Section 2.1 of
>> [RFC1123].  Note that while uppercase and lowercase letters are
>> allowed in domain names, no significance is attached to the case.  In
>> addition, while the string " " is a legal domain name, subjectAltName
>> extensions with a dNSName of " " MUST NOT be used.  Finally, the use
>> of the DNS representation for Internet mail addresses
>> (subscriber.example.com instead of subscri...@example.com) MUST NOT
>> be used; such identities are to be encoded as rfc822Name.  Rules for
>> encoding internationalized domain names are specified in Section 7.2.
> 

The huge mess comes from the fact that this requirement of not 
using the underscore character (which is actually used in some 
RFC-specified DNS names labels, though for special purposes) was 
buried in a complicated reference to two old RFCs, each of which 
in turn describe that particular restriction in a complicated and 
indirect way.

Furthermore, Section 4.2.1.6 of RFC5280 applies only to 
SubjectAltNames, not to DNS names placed directly in the Subject 
Distinguished Name in the certificate.  Thus this particular 
restriction on DNS names to which certificates can be issued only 
became effective as a side effect of deprecating TLS certificates 
without SubjectAltNames.

This made it completely unclear to most people that DNS labels 
with underscores were not permitted in certificates.  Thus the 
restriction was not widely known outside the CA/root program 
discussion groups until the rapid sunset was announced in November.

> 
> If the question is "why", then the answer is "Because the preferred name
> syntax forbids them"
> If the question is "Why does the preferred name syntax forbid them", that
> is answered in RFC 1035, Section 2.3.1
> 
> https://tools.ietf.org/html/rfc1035#section-2.3.1
> 
>> The DNS specifications attempt to be as general as possible in the rules
>> for constructing domain names.  The idea is that the name of any
>> existing object can be expressed as a domain name with minimal changes.
> 
> 
> 
> However, when assigning a domain name for an object, the prudent user
>> will select a name which satisfies both the rules of the domain system
>> and any existing rules for the object, whether these rules are published
>> or implied by existing programs.
> 
> 
> 
> For example, when naming a mail domain, the user should satisfy both the
>> rules of this memo and those in RFC-822.  When creating a new host name,
>> the old rules for HOSTS.TXT should be followed.  This avoids problems
>> when old software is converted to use domain names.
> 
> 
> 
> [ABNF omitted here]
> 
> 

Note that this ABNF is one of only two places expressing the 
restriction that is now being vigorously enforced 30 years later.

And that ABNF isn't even applicable due to RFC1123.

> 
> Note that while upper and lower case letters are allowed in domain
>> names, no significance is attached to the case.  That is, two names with
>> the same spelling but different case are to be treated as if identical.
> 
> 
> 
> The labels must follow the rules for ARPANET host names.  They must
>> start with a letter, end with a letter or digit, and have as interior
>> characters only letters, digits, and hyphen.  There are also some
>> restrictions on the length.  Labels must be 63 characters or less.
> 

And this paragraph is the second place, which is also not entirely 

Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

[Rob Stradling via dev-security-policy]

On 14/12/2018 21:06, Wayne Thayer via dev-security-policy wrote:

> I think it;s worth calling out that Let's Encrypt has implemented what
> appears to be a relatively simple mitigation:
> https://community.letsencrypt.org/t/edns-buffer-size-changing-to-512-bytes/77945

Sectigo implemented this same mitigation about a month ago.

> I am also interested to know if other CAs are considering this or other
> mitigations (e.g. multi-perspective validation) for this attack.

Multi-perspective validation is something we've started to think about too.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Online exposed keys database

[Matt Palmer via dev-security-policy]

Hi all,

I'd like to make everyone aware of a service I've just stood up, called
pwnedkeys.com.  It's intended to serve as a clearinghouse of known-exposed
private keys, so that services that accept public keys from external
entities (such as -- relevant to mdsp's interests -- CAs) can make one call
to get a fairly authoritative answer to the question "has the private key
I'm being asked to interact with in some way been exposed?".

It's currently loaded with great piles of Debian weak keys (from multiple
architectures, etc), as well as some keys I've picked up at various times. 
I'm also developing scrapers for various sites where keys routinely get
dropped.

The eventual intention is to be able to go from "private key is on The
Public Internet somewhere" to "shows up in pwnedkeys.com" automatically and
in double-quick time.

I know there are a number of very clever people on this list who have found
and extracted keys from more esoteric places than Google search, and I'd be
really interested in talking to you (privately, I'd imagine) about getting
specimens of those keys to add to the database.

I'd also welcome comments from anyone about the query API, the attestation
format, the documentation, or anything else vaguely relevant to the service. 
Probably best to take that off-list, though.

I do have plans to develop a PR against (the AWS Labs') certlint to cause it
to query the API, so there's no need for anyone to get deep into that unless
they're feeling especially frisky.  Other linting tools will *probably* have
to do their own development, as my Go skills are... rudimentary at best,
shall we say.  I'd be happy to give guidance or any other necessary help to
anyone looking at building those, though.

Finally, if any CAs are interested in integrating the pwnedkeys database
into their issuance pipelines, I'd love to discuss how we can work together.

Thanks,
- Matt

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