Re: Update to phasing out SHA-1 Certs

[Eric Mill]

On Tue, Jan 19, 2016 at 9:38 PM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:

> On Tue, January 19, 2016 5:38 pm, Eric Mill wrote:
> >  If your experience with MD5 supports the notion that removing support
> for
> >  it in the enterprise hurt user security in some other way, such as
> causing
> >  enterprises to lock their users to older versions of Chrome for a long
> >  period of time, please give more qualitative or quantitative detail to
> >  support that. Otherwise, I have to assume a more traditional and typical
> >  competitive dynamic that doesn't generally work in the public's
> interest.
>
> While I sent a more comprehensive reply off-list explaining why I have
> trouble with your arguments, I don't believe I can in good-faith continue
> this conversation with you, Eric.
>
> I appreciate your curiosity and enthusiasm, but I don't believe your
> questions are at all relevant to this discussion, nor do I appreciate the
> implication that my participation is an attempt to gain competitive
> advantage - simply because I don't want to see users switch to Firefox or
> another browser.
>

That was a wholly unintentional implication -- I did not mean to say that
you personally were arguing in bad faith, or were seeking competitive
advantage. In fact, you're one of the last people I would ever accuse of
bad faith, since your level of personal and direct honesty is maybe the
highest in the entire community.

However, I can see how my comments would be taken that way, which is my
fault, and I apologize to you for that, and for potentially lowering the
level of discourse on the thread.

Avoiding losing users is a legitimate product interest, not intrinsically
bad, and I didn't think the idea that browsers considered this interest
would be a controversial one. Again, my fault for addressing that poorly.


I've suggested several paths that Richard and the Firefox team may
> consider, as compromises that allow Firefox to ensure secure
> communications for users, while allowing enterprises the necessary relief
> valves for their (longer) timelines and unique challenges. I can
> appreciate that you don't see the utility in the relief valve, but there's
> ample evidence (and your own experience should tell you) that such things
> would and are necessary. They are paths being pursued by the Chrome team,
> and, based on the evidence and historical precedence, believed to be the
> Microsoft strategy as well.
>

I believe in the utility of that relief valve -- my only disagreement has
been whether it was early enough to know whether that relief valve was
needed in this particular case. Your position is clear, and even though I
don't think it's futile to consider making choices other than Chrome's or
Microsoft's on this issue, I appreciate the details and rationale you've
provided, and hope others continue discussing it.

-- Eric


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

Re: Update to phasing out SHA-1 Certs

[Ryan Sleevi]

On Tue, January 19, 2016 5:38 pm, Eric Mill wrote:
>  If your experience with MD5 supports the notion that removing support for
>  it in the enterprise hurt user security in some other way, such as causing
>  enterprises to lock their users to older versions of Chrome for a long
>  period of time, please give more qualitative or quantitative detail to
>  support that. Otherwise, I have to assume a more traditional and typical
>  competitive dynamic that doesn't generally work in the public's interest.

While I sent a more comprehensive reply off-list explaining why I have
trouble with your arguments, I don't believe I can in good-faith continue
this conversation with you, Eric.

I appreciate your curiosity and enthusiasm, but I don't believe your
questions are at all relevant to this discussion, nor do I appreciate the
implication that my participation is an attempt to gain competitive
advantage - simply because I don't want to see users switch to Firefox or
another browser.

I don't believe it's necessary to satiate your curiosity, nor is it a
reasonable request, especially when ample information about the impact
that the MD5 deprecation had (as shown on the bug you previously linked),
ample academic literature exists to warning fatigue, and by your own
admission, you're familiar with the purchasing, upgrade, and deployment
cycles of enterprises and the challenges therein.

I've suggested several paths that Richard and the Firefox team may
consider, as compromises that allow Firefox to ensure secure
communications for users, while allowing enterprises the necessary relief
valves for their (longer) timelines and unique challenges. I can
appreciate that you don't see the utility in the relief valve, but there's
ample evidence (and your own experience should tell you) that such things
would and are necessary. They are paths being pursued by the Chrome team,
and, based on the evidence and historical precedence, believed to be the
Microsoft strategy as well.

In any event, I don't believe either of us are contributing positively to
the conversation at this point, so I'll bow out, and would encourage
considering the same.

Best,

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

Re: Update to phasing out SHA-1 Certs

[Eric Mill]

On Tue, Jan 19, 2016 at 4:15 AM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:

> On Mon, January 18, 2016 9:05 pm, Eric Mill wrote:
> >  Really? Given your last few years of experience, if you could time
> travel
> >  back to 2012, you would tell Past Ryan Sleevi to make a different
> decision
> >  at that time about adding a flag for MD5 support in the enterprise?
>
> Yes.
>
> > Was there significant observed negative fallout of that decision?
>
> Yes.
>

What was the nature of that fallout? I don't know how to incorporate that
into my worldview without details.


>  That's a great point, but Peter's data was from website logs, and
> >  detecting
> >  middleboxes in that data is about comparing TLS "fingerprints" to sent
> >  user
> >  agents. That's not something enterprises have to opt-in to. So, large
> >  website operators could be providing valuable (appropriately aggregated,
> >  etc.) data in this regard.
>
> Only to an extent. You're again presuming the enterprise MITM box, which
> may show for sites like Amazon (of course, it would not show at all for
> enterprise MITM boxes that blocked it). This would not, however, show up
> at all for the case of using UAs to access internal enterprise resources,
> which is a far greater (by volume of users, though necessarily not volume
> of certificates) use case.
>

That is a great point. But do we throw up our hands and say we can just
never know how enterprises use browsers? It doesn't seem practical from a
product management standpoint either -- it'd be foolhardy to have no data
that tells you how it's being used.

The general public uses browsers which also serve the enterprise without
substantial modification, so data on how enterprises use browsers is
relevant to decisions that affect the general public. I encourage your team
to find a way to publicly contribute some version of the data you're using
to drive your decisions.


But I certainly am more aware of the impact these decisions
> have, and of the real tradeoffs involved for these users, and thus the
> need for a softer touch.
>
> Arguing that enterprise users should be thrown under the bus is not a new
> argument, nor is it one without grounding. We've certainly seen the
> energetically emotional appeals in cases like HPKP, where some corners
> have argued for making it harder and harder for enterprises to accomplish
> their goals because they're seen as disagreeable. And while I certainly
> don't agree with many of the reasons why such organizations see the need
> to MITM, I'm quite aware of the lengths that MITM vendors will go to, and
> of the lengths businesses will go to to support their needs. The same can
> be said for SHA-1 here.
>
> To me, the root of the issue here is education - how do we educate
> enterprises that SHA-1 issuance is risky (to their organization, not to
> the Internet at large), such that they lean on their vendors, such that
> they have the economic incentives to switch vendors or, in many cases, pay
> the exorbitant fees the vendors demand in order to support better
> security. It's certainly one strategy to "hold users hostage" (via
> interstitials), but that's one that doesn't seem to pay off well. Even
> holding users hostage via lock icons is one that, as it played out, was
> significantly less effective than desired. Nor is it a good game - for
> users or for browser vendors - to get in the habit of hostage taking "for
> the greater good".


I didn't think Chrome regretted using the lock icon to raise awareness
among site owners about SHA-1. It may not have been as effective as you
were hoping it would be, but I think plenty of people, myself included,
observed that it generated real action by site owners across the public and
enterprise spheres.

We don't have the alternate universe where Chrome didn't do that to compare
it to, but if it felt like less than desired, there's another conclusion
you could draw: that if Firefox and IE and Safari were in the habit of
trying the same thing, the effect it did have would been amplified.

Another strategy is "pure outreach", although that's
> unlikely to have the economies of scale necessary to get the industry to
> move, and is the one previously attempted with MD5. So there's likely
> somewhere in the middle ground - and that's something I hope Mozilla will
> consider, in taking the necessary steps to secure PTCs, and working to
> employ all appropriate means for ETCs.
>

I can understand and agree with your larger point, and the idea that
browser influence is much more limited and specific than it may seem to the
outside community.

I just don't like the feeling of making decisions without any data, and I
don't like the idea that browsers should default to using kid gloves with
enterprises.

We're willing to break connections to significant fractions of the world's
general population over the next few years as the SHA-1 issuance deadline
has its intended effect -- but we're not willing to even show warnings

Re: SHA-1 with 'notAfter >= 2017-1-1'

[Richard Barnes]

On Tue, Jan 19, 2016 at 6:30 PM, Ryan Sleevi <
ryan-mozdevsecpol...@sleevi.com> wrote:

> On Tue, January 19, 2016 2:56 pm, s...@gmx.ch wrote:
> >  Hi
> >
> >  We're already having some discussions about SHA-1, but I'll split this
> >  up into a new thread.
> >
> >  The initial goal of bug 942515 was to mark certs as insecure, that are
> >  valid 'notBefore >= 2016-01-01' (means issued to use in 2016+) AND also
> >  for certs that are valid 'notAfter >= 2017-1-1' (means still valid in
> >  2017+).
> >
> >  The first condition has been implemented, but there are some
> >  'compatibility' issues with MITM software. [1]
> >  The second condition has not been implemented, but it was already
> >  announced [2] and also considered to set the cut-off a half year earlier
> >  to the  July 1, 2016. If this should really happen, we need to hurry up
> >  on this discussion. Of course the problem mentioned in [1] should be
> >  solved first.
> >
> >  Regards,
> >  Jonas
>
> Moving dev-tech-crypto to BCC
>
> You've misread [2]. It is *not* about the notAfter but the notBefore. I
> can assure you, based on our telemetry, there will still be some nasty
> breakages with measuring on the notAfter. The goal of the announcement
> (and as agreed by Mozilla, Microsoft, Google, and, of course, the
> CA/Browser Forum) is that effective 2017-1-1, it's reasonable to turn off
> support for SHA-1.
>

In particular, there's no action to take with regard to Firefox until we
start to get close to the end of 2016.  And given the experience this past
Jan 1, I'm not really inclined to make changes that take effect on that day
:)



> The only use of the notAfter, in the context of [2], was using that as a
> signal to show some form of prominent warning in the developer console.
> And that's been implemented for some time, AFAIK.
>

There have been SHA-1 cert warnings there for ages.  I suppose we could
make them shoutier.

--Richard


> So the implementation of [2] is still something that, based on Firefox's
> release calendar, puts it around Firefox 52 [3], thus needing to be
> implemented sometime around late October / early November, 2016.
>
>
> [2]
>
> https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
> [3] https://wiki.mozilla.org/RapidRelease/Calendar
>
>
> ___
> 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: SHA-1 with 'notAfter >= 2017-1-1'

[Ryan Sleevi]

On Tue, January 19, 2016 2:56 pm, s...@gmx.ch wrote:
>  Hi
>
>  We're already having some discussions about SHA-1, but I'll split this
>  up into a new thread.
>
>  The initial goal of bug 942515 was to mark certs as insecure, that are
>  valid 'notBefore >= 2016-01-01' (means issued to use in 2016+) AND also
>  for certs that are valid 'notAfter >= 2017-1-1' (means still valid in
>  2017+).
>
>  The first condition has been implemented, but there are some
>  'compatibility' issues with MITM software. [1]
>  The second condition has not been implemented, but it was already
>  announced [2] and also considered to set the cut-off a half year earlier
>  to the  July 1, 2016. If this should really happen, we need to hurry up
>  on this discussion. Of course the problem mentioned in [1] should be
>  solved first.
>
>  Regards,
>  Jonas

Moving dev-tech-crypto to BCC

You've misread [2]. It is *not* about the notAfter but the notBefore. I
can assure you, based on our telemetry, there will still be some nasty
breakages with measuring on the notAfter. The goal of the announcement
(and as agreed by Mozilla, Microsoft, Google, and, of course, the
CA/Browser Forum) is that effective 2017-1-1, it's reasonable to turn off
support for SHA-1.

The only use of the notAfter, in the context of [2], was using that as a
signal to show some form of prominent warning in the developer console.
And that's been implemented for some time, AFAIK.

So the implementation of [2] is still something that, based on Firefox's
release calendar, puts it around Firefox 52 [3], thus needing to be
implemented sometime around late October / early November, 2016.


[2]
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
[3] https://wiki.mozilla.org/RapidRelease/Calendar


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

SHA-1 with 'notAfter >= 2017-1-1'

[sjw]

Hi

We're already having some discussions about SHA-1, but I'll split this
up into a new thread.

The initial goal of bug 942515 was to mark certs as insecure, that are
valid 'notBefore >= 2016-01-01' (means issued to use in 2016+) AND also
for certs that are valid 'notAfter >= 2017-1-1' (means still valid in
2017+).

The first condition has been implemented, but there are some
'compatibility' issues with MITM software. [1]
The second condition has not been implemented, but it was already
announced [2] and also considered to set the cut-off a half year earlier
to the  July 1, 2016. If this should really happen, we need to hurry up
on this discussion. Of course the problem mentioned in [1] should be
solved first.

Regards,
Jonas


[1]
https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/
[2]
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
[3]
https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA1 certs issued this year chaining to included roots

[Charles Reiss]

On 01/19/16 11:49, Jakob Bohm wrote:
> On 19/01/2016 02:49, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this 
>> year
>> which chain to root CAs in Mozilla's program:
>>
>> - https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root 
>> [DigiCert]
>> via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"
>>
>> Also, the OCSP responder for this certificate appears to not include a
>> nextUpdate field.
>>
> 
> Does the OCSP spec say what "no nextUpdate" should default to?  Like maybe
> "dontcache, expires instantly".
> 
>>
>> - https://crt.sh/?id=12090324 -- chains to Security Communication RootCA1
>> [SECOM] via subCA "YourNet SSL for business"
>> 
>> Also, this certificate is also missing OCSP information and appears to be 
>> being
>> served without OCSP stapling support.
>>
> 
> If there is no OCSP, it obviously cannot be stapled.

The CA/Browser forum BRs contemplate OCSP stapling without an OCSP responder
being listed in the certificate in section 7.1.2.2.c ("The HTTP URL of  the
Issuing CA’s OCSP responder MAY be omitted, provided that the Subscriber
“staples” the OCSP response for the Certificate in its TLS handshakes
[RFC4366].") I assume the idea is that the OCSP responder URL would be manually
configured in the server and that this would make the certificate slightly 
smaller.

> In addition to the above, note that *code signing* and *document
> signing* certificates may be issued after the deadline for SSL SHA-1
> certificates, because some important relying party software cannot be
> upgraded to support modern signature hash algorithms (most notably
> Microsoft platforms released before 2009).
> 
> Such compatibility SHA-1 certificates typically have to chain to
> existing roots too (again because of relying party software
> limitations).

I would hope such issuance is occurring under technically constrained subCAs so
that a Flame-style chosen-prefix collision attack cannot result in a rogue
certificate that Mozilla would trust for TLS servers so long as Mozilla does not
disable SHA-1 certificates entirely.

> 
> 
> Enjoy
> 
> Jakob

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

Re: FNMT Root Inclusion Request

[Kathleen Wilson]

On 1/15/16 4:42 AM, rafa...@gmail.com wrote:

Hi all.

We have developed a solution plan for this issues.


I believe that some of the concerns that were raised have been resolved,
and that the remaining open concerns are as follows. Please reply if I
missed any other items that still need to be resolved.

1) This root certificate has subordinate certificates that are not
technically constrained and not audited/disclosed according to sections
8-10 of Mozilla's CA Certificate Policy. The noted subCAs are "AC FNMT
Usuarios" (doesn't issue server certificates) and "ISA CA" (server
certificates are issued exclusively to a very restricted (almost
private) environment). Unless there are technical constraints on the
intermediate CA certificates representing those subCAs which make it
impossible for them to issue TLS or S/MIME certificates, they are
in-scope for this inclusion request, because they are a potential source
of mis-issuance which puts users of the Mozilla trust store at risk.


We are going to audit in-scope CAs. Finally our FNMT-RCM CAs hierarchy audit 
scheme will be as follows:

+ AC RAIZ FNMT-RCM
+ AC Administración Pública
  - Issues: SSL certs, QCP certs
  - Audits: WebTrust for CAs, WebTrust SSL BRs, ETSI 101 456
+ AC Componentes Informáticos
  - Issues: SSL certs
  - Audits: WebTrust for CAs, WebTrust SSL BRs
+ AC FNMT Usuarios
  - Issues: issues QCP certs, not restricted by EKU extension
  - Audits: (ETSI 101 456 or WebTrust for CAS) and audit of non-existence 
of SSL certs
+ ISA CA Will be revoked in early 2016
+ AC APE No longer used. Will be revoked in early 2016

As you can see, the two subCAs in-scope will be audited ("AC Usuarios) and revoked ("ISA 
CA"). Also, "AC APE" which is no longer used will be revoked


2) The allowed methods of verifying domain name ownership/control must
be in compliance with section 3.2.2.4 of version 1.3 (or later) of the
Baseline Requirements.


ISA CA is going to be revoked.

With this audit scheme, the remaining open issues would be solved.




I think this approach is reasonable, because I think the additional 
annual audit check to ensure the AC FNMT Usuarios intermediate has not 
issued SSL certs meets the intention of Mozilla's Policy and the BRs.


Does anyone see any problems with this approach?

Thanks,
Kathleen

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

Re: Second Discussion of ANF Root Inclusion Request

[Kathleen Wilson]

On 1/12/16 4:16 PM, Kathleen Wilson wrote:

On 12/9/15 1:35 PM, Kathleen Wilson wrote:

The first discussion of the ANF root inclusion request was here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/cNgy1_rkv6A/h8YOlR3AFMIJ


ANF has responded to the concerns that were raised, so I am now opening
the second discussion about their inclusion request.

ANF has applied to include the “ANF Global Root CA” root certificate,
enable the Websites trust bit, and enable EV treatment.

ANF Autoridad de Certificación (ANF AC) is a private Certification
Authority, recognized and accredited by the Spanish Government as a
Certificate Services Provider (CSP). ANF AC has accredited more than
1000 Registry Authorities throughout Spain to issue qualified user
identity certificates. ANF CA also issues certificates for SSL with and
without Extended Validation.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=555156

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8644470

Noteworthy points:

* The primary documents are the CPS and SSL CP, which are provided in
Spanish and English.

Document repository (Spanish):
http://www.anf.es/es/politicas/psc-acreditado/documentos-publicados
Document Repository (English): http://www.anf.es/en/

CP: https://www.anf.es/es/pdf/PC_SSL_Sede_EV_EN.pdf
CPS: https://www.anf.es/es/pdf/DPC_ANF_AC_EN.pdf

* CA Hierarchy: This root has eight internally-operated subordinate CAs
which sign end-entity certificates for individuals and organizations.
- ANF High Assurance EV CA1 (SHA1 and SHA256): Issues technical
certificates for authentication services SSL, SSL EV, Encryption and
Code Signing.
- ANF High Assurance AP CA1 (SHA1 and SHA256): Issues end-entity
certificates for Public Administrations.
- ANF Global CA1 (SHA1 and SHA256): Issues certificates for the
management and administration of the PKI of ANF AC.
- ANF Assured ID CA1 (SHA1 and SHA256): Issues end-entity in accordance
with the provisions of Electronic Signature Law 59/2003.

* This request is to enable the websites trust bit and enable EV
treatment.



Does anyone need more time to review this request?

If not, and no one has any questions/concerns about this request, then I
will close this discussion and recommend approval in the bug.

Thanks,
Kathleen




ANF responded to all of the questions and concerns that were raised in 
the first discussion, and no one has raised further questions or 
concerns in this second discussion.


Therefore, I am closing this discussion and will recommend approval in 
the bug.


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

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen




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

RE: SHA1 certs issued this year chaining to included roots

[Jeremy Rowley]

Thanks we are investigating. This was a SubCA that existed well before our 
acquisition of the Baltimore roots.  We are contracting the customer and are 
requesting a full report.

Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jakob Bohm
Sent: Tuesday, January 19, 2016 4:49 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: SHA1 certs issued this year chaining to included roots

On 19/01/2016 02:49, Charles Reiss wrote:
> Via censys.io, I found a couple SHA-1 certs with notBefore dates from 
> this year which chain to root CAs in Mozilla's program:
>
> - https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root 
> [DigiCert] via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"
>
> Also, the OCSP responder for this certificate appears to not include a 
> nextUpdate field.
>

Does the OCSP spec say what "no nextUpdate" should default to?  Like maybe 
"dontcache, expires instantly".

>
> - https://crt.sh/?id=12090324 -- chains to Security Communication 
> RootCA1 [SECOM] via subCA "YourNet SSL for business"
>   
> Also, this certificate is also missing OCSP information and appears to 
> be being served without OCSP stapling support.
>

If there is no OCSP, it obviously cannot be stapled.

In addition to the above, note that *code signing* and *document
signing* certificates may be issued after the deadline for SSL SHA-1 
certificates, because some important relying party software cannot be upgraded 
to support modern signature hash algorithms (most notably Microsoft platforms 
released before 2009).

Such compatibility SHA-1 certificates typically have to chain to existing roots 
too (again because of relying party software limitations).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com Transformervej 
29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10 This public discussion 
message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
___
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: Update to phasing out SHA-1 Certs

[Jakob Bohm]

On 19/01/2016 10:15, Ryan Sleevi wrote:

On Mon, January 18, 2016 9:05 pm, Eric Mill wrote:

  Really? Given your last few years of experience, if you could time travel
  back to 2012, you would tell Past Ryan Sleevi to make a different decision
  at that time about adding a flag for MD5 support in the enterprise?


Yes.


Was there significant observed negative fallout of that decision?


Yes.

...


Only to an extent. You're again presuming the enterprise MITM box, which
may show for sites like Amazon (of course, it would not show at all for
enterprise MITM boxes that blocked it). This would not, however, show up
at all for the case of using UAs to access internal enterprise resources,
which is a far greater (by volume of users, though necessarily not volume
of certificates) use case.


Indeed.  In our small enterprise, I have observed the following sources
of non-public weaker certificates:

1. Embedded https administration interface servers in difficult to
  upgrade hardware (such as otherwise functional HP printers long past
  warranty, with the added sting that downgrading to even older
  firmware was the only solution for a major vulnerability).

2. An internal CA, which has been almost completely supplanted by a new
  one now.  It used SHA-1 solely for compatibility with older clients
  and may survive in that role as long as such clients are needed for
  special tasks.

3. MITM-box like behavior in endpoint antivirus programs (these default
  to intercepting SSL/TLS traffic to scan it for viruses.  I have not
  checked the algorithm used to signing the pseudo-certificates used
  for traffic that never leaves the computer on which the signature is
  checked, and this is going to be brand-specific anyway.

4. E-mail certificates compatible with Outlook 2007.  That one is a
  real bummer because of the upgrade costs.  And the lack of
  confidentially when using "cloud-focuses" programs that do too much
  telemetry.




My point is that the over-reliance on metrics underestimates (on orders of
magnitude) the impact to enterprises, which is why IF a user agent wishes
to support enterprises (and it's a complex question of business and
product direction), more nuance is needed.


Indeed.  In any security conscious environment, telemetry is an alias
for industrial espionage and can easily get a product thrown out if
blocking the telemetry isn't trivially easy and reliable.



...




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA1 certs issued this year chaining to included roots

[Jakob Bohm]

On 19/01/2016 02:49, Charles Reiss wrote:

Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
which chain to root CAs in Mozilla's program:

- https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root [DigiCert]
via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"

Also, the OCSP responder for this certificate appears to not include a
nextUpdate field.



Does the OCSP spec say what "no nextUpdate" should default to?  Like 
maybe "dontcache, expires instantly".




- https://crt.sh/?id=12090324 -- chains to Security Communication RootCA1
[SECOM] via subCA "YourNet SSL for business"

Also, this certificate is also missing OCSP information and appears to be being
served without OCSP stapling support.



If there is no OCSP, it obviously cannot be stapled.

In addition to the above, note that *code signing* and *document
signing* certificates may be issued after the deadline for SSL SHA-1
certificates, because some important relying party software cannot be
upgraded to support modern signature hash algorithms (most notably
Microsoft platforms released before 2009).

Such compatibility SHA-1 certificates typically have to chain to
existing roots too (again because of relying party software
limitations).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA1 certs issued this year chaining to included roots

[Kurt Roeckx]

On Mon, Jan 18, 2016 at 10:45:17PM -0500, Reed Loden wrote:
> https://cabforum.org/pipermail/public/2016-January/006519.html has
> more information on these certs.

Thanks, that seems to list the same 5 I already had.

I'm currently also seeing:
https://crt.sh/?id=12090324


Kurt

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

Re: Update to phasing out SHA-1 Certs

[Ryan Sleevi]

On Mon, January 18, 2016 9:05 pm, Eric Mill wrote:
>  Really? Given your last few years of experience, if you could time travel
>  back to 2012, you would tell Past Ryan Sleevi to make a different decision
>  at that time about adding a flag for MD5 support in the enterprise?

Yes.

> Was there significant observed negative fallout of that decision?

Yes.

>  Sure, but part of the benefit of shutting off SHA-1 issuance is to remove
>  SHA-1 code from the overall software pipeline altogether, and to remove
>  the
>  opportunity for bugs and mistakes from having outsized impacts on critical
>  infrastructure.

This argument doesn't really hold any water for the case of enterprise
CAs, nor does it (in a practical sense) hold water for SHA-1. For that
matter, even MD5 as an implementation isn't removed from most
cryptographic libraries - including OpenSSL, BoringSSL, and CryptoAPI -
because of its use in other constructs (e.g. HMAC-MD5 or the MD5+SHA1
concatenation in TLS < 1.2)

>From an issuance standpoint, it really doesn't reduce code, and from the
validation standpoint, the need for SHA-1 in the PKI products will remain
for some time (e.g. AKI/SKI synthetic construction, or the use in OCSP)

>  I would put browser certificate validation code in a similar category of
>  critical software infrastructure as CA issuance code. Removing SHA-1
>  validation code from browsers altogether is a much stronger guarantee than
>  depending on logic which distinguishes between publicly trusted and
>  locally
>  trusted roots, which, as discussed on this thread already, is quite
>  tricky.

Again, not really.

>  That's a great point, but Peter's data was from website logs, and
>  detecting
>  middleboxes in that data is about comparing TLS "fingerprints" to sent
>  user
>  agents. That's not something enterprises have to opt-in to. So, large
>  website operators could be providing valuable (appropriately aggregated,
>  etc.) data in this regard.

Only to an extent. You're again presuming the enterprise MITM box, which
may show for sites like Amazon (of course, it would not show at all for
enterprise MITM boxes that blocked it). This would not, however, show up
at all for the case of using UAs to access internal enterprise resources,
which is a far greater (by volume of users, though necessarily not volume
of certificates) use case.

My point is that the over-reliance on metrics underestimates (on orders of
magnitude) the impact to enterprises, which is why IF a user agent wishes
to support enterprises (and it's a complex question of business and
product direction), more nuance is needed.

I think the benefits to restricting SHA-1 in PTCs is both obvious and
uncontroversial, and offers positive security steps - more than doing
nothing. I can understand the desire of those *not* impacted by such
changes to wish to push the industry towards changes - I know, I've been
there myself. But I certainly am more aware of the impact these decisions
have, and of the real tradeoffs involved for these users, and thus the
need for a softer touch.

Arguing that enterprise users should be thrown under the bus is not a new
argument, nor is it one without grounding. We've certainly seen the
energetically emotional appeals in cases like HPKP, where some corners
have argued for making it harder and harder for enterprises to accomplish
their goals because they're seen as disagreeable. And while I certainly
don't agree with many of the reasons why such organizations see the need
to MITM, I'm quite aware of the lengths that MITM vendors will go to, and
of the lengths businesses will go to to support their needs. The same can
be said for SHA-1 here.

To me, the root of the issue here is education - how do we educate
enterprises that SHA-1 issuance is risky (to their organization, not to
the Internet at large), such that they lean on their vendors, such that
they have the economic incentives to switch vendors or, in many cases, pay
the exorbitant fees the vendors demand in order to support better
security. It's certainly one strategy to "hold users hostage" (via
interstitials), but that's one that doesn't seem to pay off well. Even
holding users hostage via lock icons is one that, as it played out, was
significantly less effective than desired. Nor is it a good game - for
users or for browser vendors - to get in the habit of hostage taking "for
the greater good". Another strategy is "pure outreach", although that's
unlikely to have the economies of scale necessary to get the industry to
move, and is the one previously attempted with MD5. So there's likely
somewhere in the middle ground - and that's something I hope Mozilla will
consider, in taking the necessary steps to secure PTCs, and working to
employ all appropriate means for ETCs.

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