Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Dear Steven,
CA certificates can have a validity longer than 398 days. The policy
applies to the validity period of TLS server certificates. At the CA level,
it will be enforced as a compliance issue in the root store when we accept
or remove a root CA in the "publicly trusted" root store. It will also be
enforced at the server-certificate level, through the incident-reporting
process and treated as a mis-issuance. See
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#24-incidents.
However, if a user installs its own CA certificate, then that CA can issue
server certificates with validity longer than 398 days. The code will check
the TLS server certificate to see if it chains to a publicly trusted root
and whether it was issued on or after 1-Sept-2020. If so, then if it does
not have a lifetime of less than 398 days, the TLS connection will be
blocked and there will be a warning message. See
https://bugzilla.mozilla.org/show_bug.cgi?id=908125
Does that answer your question?
Thanks,
Ben

On Tue, Aug 25, 2020 at 10:42 AM None Of via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tuesday, July 14, 2020 at 2:13:30 PM UTC-4, Ben Wilson wrote:
> > Hi Christian,
> > I think your concern is about how our code will enforce this. Because
> our
> > policy only applies to roots that are built in, our intent is to have
> our
> > code apply this restriction only to certificates that chain up to
> built-in
> > roots.
> > Thanks,
> > Ben
> > On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via
> dev-security-policy <
> > dev-secur...@lists.mozilla.org> wrote:
> >
> > > Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
> > > >
> > >
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
> > >
> > > Hi,
> > >
> > > blog post should clarify if this is valid for certificates issued by
> > > preinstalled root CAs only or also for CAs installed by user.
> > >
> > >
> > > regards
> > > Christian
> > > ___
> > > dev-security-policy mailing list
> > > dev-secur...@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> > >
> Hello Ben,
>
> I also would like clarification as to whether this change is an
> "administrative change" for Mozilla accepting CAs in the included root
> store, or whether it will be a technical change in how Firefox validates CA
> certificate validity.
>
> If users install a CA cert that has a validity longer than 398 days after
> 1 Sept 2020, will this cause warning messages to appear?
> ___
> 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: New Blog Post on 398-Day Certificate Lifetimes

[None Of via dev-security-policy]

On Tuesday, July 14, 2020 at 2:13:30 PM UTC-4, Ben Wilson wrote:
> Hi Christian, 
> I think your concern is about how our code will enforce this. Because our 
> policy only applies to roots that are built in, our intent is to have our 
> code apply this restriction only to certificates that chain up to built-in 
> roots. 
> Thanks, 
> Ben
> On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via dev-security-policy < 
> dev-secur...@lists.mozilla.org> wrote: 
> 
> > Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy: 
> > > 
> > https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
> >  
> > 
> > Hi, 
> > 
> > blog post should clarify if this is valid for certificates issued by 
> > preinstalled root CAs only or also for CAs installed by user. 
> > 
> > 
> > regards 
> > Christian
> > ___ 
> > dev-security-policy mailing list 
> > dev-secur...@lists.mozilla.org 
> > https://lists.mozilla.org/listinfo/dev-security-policy 
> >
Hello Ben,

I also would like clarification as to whether this change is an "administrative 
change" for Mozilla accepting CAs in the included root store, or whether it 
will be a technical change in how Firefox validates CA certificate validity.  

If users install a CA cert that has a validity longer than 398 days after 1 
Sept 2020, will this cause warning messages to appear?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Hi Christian,
I think your concern is about how our code will enforce this. Because our
policy only applies to roots that are built in, our intent is to have our
code apply this restriction only to certificates that chain up to built-in
roots.
Thanks,
Ben

On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:
> >
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
>
> Hi,
>
> blog post should clarify if this is valid for certificates issued by
> preinstalled root CAs only or also for CAs installed by user.
>
>
> regards
> Christian
> ___
> 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: New Blog Post on 398-Day Certificate Lifetimes

[Christian Felsing via dev-security-policy]

Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy:

https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/


Hi,

blog post should clarify if this is valid for certificates issued by 
preinstalled root CAs only or also for CAs installed by user.



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

Re: New Blog Post on 398-Day Certificate Lifetimes

[Nick Lamb via dev-security-policy]

On Sat, 11 Jul 2020 11:06:56 +1000
Matt Palmer via dev-security-policy
 wrote:
> A histogram of the number of certificates grouped by their notBefore
> date is going to show a heck of a bump on August 31, I'll wager.
> Will be interesting to correlate notBefore with SCTs.

I expect there will be a modest number of entities which are all three
of:

1. Aware this is happening in time to obtain certificates on or before
  August 31

2. Sufficiently unprepared for shorter certificate lifetimes still
  that they desire a longer lived certificate rather than just using new
  one year certificates (or automation).

3. And also organised enough to execute on a plan which obtains
  certificates in a timely fashion.

But, there's no particular attraction to August 31 itself for these
subscribers, once they meet these criteria why shouldn't they take
action sooner? So I'd expect this bump to be quite small and also
spread over days and weeks.

For the subscribers who are too late, too bad. I'm sure from September
for the next year or two commercial CAs will see some level of whining
from disgruntled customers whose cheese has been moved and aren't happy
about it. Some of it might leak here too.

I don't anticipate a WoSign-style back-dating epidemic. The benefits to
the subscriber are relatively small and the risk to a CA that gets
caught is more obvious than ever.


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

Re: New Blog Post on 398-Day Certificate Lifetimes

[Matt Palmer via dev-security-policy]

On Fri, Jul 10, 2020 at 10:48:39AM -0600, Ben Wilson via dev-security-policy 
wrote:
> Some people have asked whether two-year certificates existing on August 31
> would remain valid.  The answer is yes. Those certificates will remain
> valid until they expire. The change only applies to certificates issued on
> or after Sept. 1, 2020.

A histogram of the number of certificates grouped by their notBefore date is
going to show a heck of a bump on August 31, I'll wager.  Will be
interesting to correlate notBefore with SCTs.

- Matt

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

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Yes, that's right.

On Fri, Jul 10, 2020 at 12:11 PM Doug Beattie 
wrote:

> Ben,
>
> For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC.
>
>
> -Original Message-
> From: dev-security-policy 
> On
> Behalf Of Ben Wilson via dev-security-policy
> Sent: Friday, July 10, 2020 12:49 PM
> To: mozilla-dev-security-policy
> 
> Subject: Re: New Blog Post on 398-Day Certificate Lifetimes
>
> Some people have asked whether two-year certificates existing on August 31
> would remain valid.  The answer is yes. Those certificates will remain
> valid
> until they expire. The change only applies to certificates issued on or
> after Sept. 1, 2020.
> ___
> 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: New Blog Post on 398-Day Certificate Lifetimes

[Doug Beattie via dev-security-policy]

Ben,

For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC.


-Original Message-
From: dev-security-policy  On
Behalf Of Ben Wilson via dev-security-policy
Sent: Friday, July 10, 2020 12:49 PM
To: mozilla-dev-security-policy

Subject: Re: New Blog Post on 398-Day Certificate Lifetimes

Some people have asked whether two-year certificates existing on August 31
would remain valid.  The answer is yes. Those certificates will remain valid
until they expire. The change only applies to certificates issued on or
after Sept. 1, 2020.
___
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: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Some people have asked whether two-year certificates existing on August 31
would remain valid.  The answer is yes. Those certificates will remain
valid until they expire. The change only applies to certificates issued on
or after Sept. 1, 2020.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Eric Mill via dev-security-policy]

Just to depersonalize it a bit so it's not only Ryan responding - what Ryan
is saying is correct. Mozilla's blog post uses the phrase "impersonating a
website" to describe non-phishing attacks, such as performing active MITM
attacks that modify or replace (or surveil) data in flight, or relying on
cached DNS data from a domain which recently changed hands to otherwise get
"in front" of the connection to the authorized website. This is
impersonation in the more narrow, technical sense of having subverted
technical assurance guarantees that cause a user's client software to be
unable to realize they're not talking to the intended destination -- not in
the sense of impersonating a hostname or organization to deceive humans.

In other words, neither of those are phishing attacks. Phishing isn't
really relevant to this discussion at all, so it would be better to focus
the discussion on the security improvements that Mozilla cites in their
post, which relate to mitigating damage from key compromise, improving the
web's agility in replacing old or compromised ciphers/protocols/techniques,
and giving domain owners stronger assurance over the security of
connections to the domains they acquire.

On Thu, Jul 9, 2020 at 7:17 PM Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> >
> > Now that I have proven beyond a shadow of a doubt that we are talking
> > about phishing, feel free to debate the merits of my points raised in my
> > original email.
> >
>
> Thanks Paul. I think you're the only person I've encountered who refers to
> key compromise as phishing, but I don't think we'll make much progress when
> words have no meaning and phishing is used to describe everything from
> "monster in the middle" to "cache poisoning".
>
> Since, to use the same analogy, everything from speed limits and signs to
> red light cameras to speed traps to roundabouts is being called "speed
> bumps", it's not worth engaging further.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


-- 
Eric Mill
617-314-0966 | konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ryan Sleevi via dev-security-policy]

>
> Now that I have proven beyond a shadow of a doubt that we are talking
> about phishing, feel free to debate the merits of my points raised in my
> original email.
>

Thanks Paul. I think you're the only person I've encountered who refers to
key compromise as phishing, but I don't think we'll make much progress when
words have no meaning and phishing is used to describe everything from
"monster in the middle" to "cache poisoning".

Since, to use the same analogy, everything from speed limits and signs to
red light cameras to speed traps to roundabouts is being called "speed
bumps", it's not worth engaging further.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Paul Walsh via dev-security-policy]

Ryan,

If you said “Mozilla is making this change and there’s nothing you can say or 
do to change that” I would accept those words, as I did with Ben’s response. 
But you engaged after Ben’s response, so I’d like to respond to your comments.

Here’s some common ground… we both believe that there are security implications 
that are NOT related to phishing. BOOM! We agree on something. 

Dear Mozilla, and this wonderful community, I’m not debating this change. I 
accept it is happening irrespective of what other stakeholders might think. I 
am simply responding to Ryan’s comments :-))

Back to Ryan… 

Mozilla provides 3 reasons for its decision. 

"1. Agility”

No comment. I will defer to the people who know way more than me.

There are lots of people who know more than me on the subject of 
phishing-related security risks too and I learn from them. But it’s an area in 
which I have an extremely deep understanding and appreciation for so it might 
be a good idea to try to understand where I’m coming from. It’s pretty much all 
I work on every day. 

Phishing  is all about how humans interact with URIs and web documents based on 
whatever UI they use. If there’s dedicated UI that provides additional context 
for URIs and web documents, that too will impact their actions. 

My research into UI and metadata for providing additional context for URIs 
started before I co-founded the first ever W3C Incubator Activity (with Phil 
Archer from) - to create a new method of URL Classification and Content 
Labeling, which later replaced PICS as a Full Recomendation in 2009. The W3C 
Mobile Web Initiative was going to mandate compliance with best practices using 
the outcome of this initiative (a trustmark in the form of metadata) - 
coincidentally, I was one of the original seven founders of the W3C MWI and was 
on the Steering Council for the first year. I digress with a humblebrag because 
I don’t have the Google or Mozilla brand behind me to automatically assert 
credibility. 

Here’s one of the first browser extensions that provided additional UI for 
URIs, to help make the web easier to navigate for people with accessibility 
considerations as well as security and privacy related information:   
https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ 
 I was the founder and 
CEO of Segala.

(For anyone who’s moderately interested in phishing, please look up 
“reverse-proxy phishing” as it will scare the pants off you.)

So… 

"2. Limit exposure to compromise"

Keys valid for longer than one year have greater exposure to compromise, and a 
compromised key could enable an attacker to intercept secure communications 
and/or ***impersonate a website*** until the TLS certificate expires.”

“Impersonate a website” = phishing. This is a security risk. “Security risk” 
and “phishing” are not interchangeable and I never said they were. It’s 
preferable that you don’t quote me with words that I didn’t use. 

"3. TLS Certificates Outliving Domain Ownership"

TLS certificates provide authentication, meaning that you can be sure that you 
are sending information to the correct server and ***not to an imposter trying 
to steal your information***."

“Imposter” on the Internet = phishing.

"If the owner of the domain changes or the cloud service provider changes, the 
holder of the TLS certificate’s private key (e.g. the previous owner of the 
domain or the previous cloud service provider) ***can impersonate the 
website*** until that TLS certificate expires."

“can impersonate the website” = you guessed what I’m about to say… “PHISHING”. 

It doesn’t matter if you don’t call this phishing, in the same way that it 
doesn’t matter if you don’t call the things that are used to reduce the risk of 
pedestrians being hit by speeding traffic, “speed bumps”. You could argue that 
they’re not called “speed bumps” but are in fact, called “speed breakers” - but 
they all refer to the same thing. So, even if you personally don’t call this 
phishing, it is phishing in the eyes of the security world and every single 
phishing expert in the universe.

I had to encourage the MWI team not to redefine the meaning of “webpage” 
because everyone just knew what it was. There’s no point in taking about 
documents and URIs to consumers. So rather than teach them the real words, we 
should talk to them in the language they understand. 

Separately...

I previously ignored the fact that the post says “you can be sure that you are 
sending information to the correct server and not to an imposter trying to 
steal your information”, because I didn’t want an EV conversation to take away 
from the above. I’ll bring it up now for the sake of the record though.

If “you can be sure" refers to ‘consumers', this statement is fundamentally 
wrong because it does not reference EV. If it’s not referring to consumers, who 
is it referring to and in what context? It’s a very strange sentence that could 
have 

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ryan Sleevi via dev-security-policy]

I’m not sure how that answered my question? Nothing about the post seems to
be about phishing, which is not surprising, since certificates have nothing
to do with phishing, but your response just talks more about phishing.

It seems you may be misinterpreting “security risks” as “phishing“, since
you state they’re interchangeable. Just like Firefox’s sandbox isn’t about
phishing, nor is the same-origin policy about phishing, nor is Rust’s
memory safety about phishing, it seems like certificate security is also
completely unrelated to phishing, and the “security risks” unrelated to
phishing.

On Thu, Jul 9, 2020 at 2:48 PM Paul Walsh  wrote:

> Good question. And I can see why you might ask that question.
>

> The community lead of PhishTank mistakenly said that submissions should
> only be made for URLs that are used to steal' credentials. This helps to
> demonstrate a misconception. While this might have been ok in the past,
> it’s not today.
>
> Phishing is a social engineering technique, used to trick consumers into
> trusting URLs / websites so they can do bad things - including but not
> limited to, man-in-the-middle attacks. Mozilla references this attack
> vector as one of the main reasons for wanting to reduce the life of a cert.
> They didn’t call it “phishing” but that’s precisely what it is.
>
> We can remove all of my references to “phishing” and replace it with
> “security risks” or “social engineering” if it makes this conversation a
> little easier.
>
> And, according to every single security company in the world that focuses
> on this problem, certificates are absolutely used by bad actors - if only
> to make sure they don’t see a “Not Secure” warning.
>
> I’m not talking about EV or identity related info here as it’s not
> related. I’m talking about the risk of a bad actor caring to use a cert
> that was issued to someone else when all they have to do is get a new one
> for free.
>
> I don’t see the risk that some people see. Hoping to be corrected because
> the alternative is that browsers are about to make life harder and more
> expensive for website owners with little to no upside - outside that of a
> researchers lab.
>
> Warmest regards,
> Paul
>
>
> On Jul 9, 2020, at 11:26 AM, Ryan Sleevi  wrote:
>
>
>
> On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> According to Google, spear phishing
>
>
> I didn't see phishing mentioned in Mozilla's post, which is unsurprising,
> since certificates have nothing to do with phishing. Did I overlook
> something saying it was about phishing?
>
> It seems reasonable to read it as it was written, which doesn't mention
> phishing, which isn't surprising, because certificates have never been able
> to address phishing.
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ben Wilson via dev-security-policy]

Thanks, Paul, for your comments and concerns regarding our reasons 2 and 3,
and the costs vs. benefits of going to a 398-day certificate lifetime.
We'll keep those in mind as we move forward. In response, the security of
our users is the primary concern for Mozilla. So while we recognize there
might be added costs and burdens, we still believe that they do not
outweigh the user security benefits of moving to a 398-day certificate
lifetime.
Thanks again,
Ben

On Thu, Jul 9, 2020 at 12:48 PM Paul Walsh  wrote:

> Good question. And I can see why you might ask that question.
>
> The community lead of PhishTank mistakenly said that submissions should
> only be made for URLs that are used to steal' credentials. This helps to
> demonstrate a misconception. While this might have been ok in the past,
> it’s not today.
>
> Phishing is a social engineering technique, used to trick consumers into
> trusting URLs / websites so they can do bad things - including but not
> limited to, man-in-the-middle attacks. Mozilla references this attack
> vector as one of the main reasons for wanting to reduce the life of a cert.
> They didn’t call it “phishing” but that’s precisely what it is.
>
> We can remove all of my references to “phishing” and replace it with
> “security risks” or “social engineering” if it makes this conversation a
> little easier.
>
> And, according to every single security company in the world that focuses
> on this problem, certificates are absolutely used by bad actors - if only
> to make sure they don’t see a “Not Secure” warning.
>
> I’m not talking about EV or identity related info here as it’s not
> related. I’m talking about the risk of a bad actor caring to use a cert
> that was issued to someone else when all they have to do is get a new one
> for free.
>
> I don’t see the risk that some people see. Hoping to be corrected because
> the alternative is that browsers are about to make life harder and more
> expensive for website owners with little to no upside - outside that of a
> researchers lab.
>
> Warmest regards,
> Paul
>
>
> On Jul 9, 2020, at 11:26 AM, Ryan Sleevi  wrote:
>
>
>
> On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>>
>> According to Google, spear phishing
>
>
> I didn't see phishing mentioned in Mozilla's post, which is unsurprising,
> since certificates have nothing to do with phishing. Did I overlook
> something saying it was about phishing?
>
> It seems reasonable to read it as it was written, which doesn't mention
> phishing, which isn't surprising, because certificates have never been able
> to address phishing.
>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Paul Walsh via dev-security-policy]

Good question. And I can see why you might ask that question.

The community lead of PhishTank mistakenly said that submissions should only be 
made for URLs that are used to steal' credentials. This helps to demonstrate a 
misconception. While this might have been ok in the past, it’s not today.

Phishing is a social engineering technique, used to trick consumers into 
trusting URLs / websites so they can do bad things - including but not limited 
to, man-in-the-middle attacks. Mozilla references this attack vector as one of 
the main reasons for wanting to reduce the life of a cert. They didn’t call it 
“phishing” but that’s precisely what it is.

We can remove all of my references to “phishing” and replace it with “security 
risks” or “social engineering” if it makes this conversation a little easier.

And, according to every single security company in the world that focuses on 
this problem, certificates are absolutely used by bad actors - if only to make 
sure they don’t see a “Not Secure” warning. 

I’m not talking about EV or identity related info here as it’s not related. I’m 
talking about the risk of a bad actor caring to use a cert that was issued to 
someone else when all they have to do is get a new one for free. 

I don’t see the risk that some people see. Hoping to be corrected because the 
alternative is that browsers are about to make life harder and more expensive 
for website owners with little to no upside - outside that of a researchers 
lab. 

Warmest regards,
Paul


> On Jul 9, 2020, at 11:26 AM, Ryan Sleevi  wrote:
> 
> 
> 
> On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy 
>  > wrote:
> 
> According to Google, spear phishing
> 
> I didn't see phishing mentioned in Mozilla's post, which is unsurprising, 
> since certificates have nothing to do with phishing. Did I overlook something 
> saying it was about phishing?
> 
> It seems reasonable to read it as it was written, which doesn't mention 
> phishing, which isn't surprising, because certificates have never been able 
> to address phishing.

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

Re: New Blog Post on 398-Day Certificate Lifetimes

[Ryan Sleevi via dev-security-policy]

On Thu, Jul 9, 2020 at 1:04 PM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> According to Google, spear phishing


I didn't see phishing mentioned in Mozilla's post, which is unsurprising,
since certificates have nothing to do with phishing. Did I overlook
something saying it was about phishing?

It seems reasonable to read it as it was written, which doesn't mention
phishing, which isn't surprising, because certificates have never been able
to address phishing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: New Blog Post on 398-Day Certificate Lifetimes

[Paul Walsh via dev-security-policy]

Ugh, some poor language/typos but I”m sure people can navigate them. Sorry 
about that. 



> On Jul 9, 2020, at 10:04 AM, Paul Walsh  wrote:
> 
> Thanks Ben, 
> 
> I’ve only had half a cup of coffee this am, so it’s possible I’m not yet 
> awake :)
> 
> I have a question about reasons 2 and 3 as they’re closely related to the 
> attack vector.
> 
> According to Google, spear phishing attacks have a shelf life of 7 minutes 
> while bulk campaigns have a shelf life of 13 hours. Even if we disbelieve 
> this data and multiple the numbers by 10, we end up with the majority of the 
> harm being done within a week. 
> 
> Also, if bad actors can automatically acquire a DV cert for any available 
> domain they please, is there actual risk of bad actors waiting for a domain 
> to expire so they can have a valid cert? And they can easily execute a 
> man-in-the-middle attack using a new cert that has a shelf life of 3 months.
> 
> All I’ve been working on for years is anti-phishing techniques, so I’m not 
> seeing all of the benefits as some others see them, but perhaps I’m missing 
> something.
> 
> I’m talking about the human element of bad actors here, because at the end of 
> the day, it’s all about them and what they will do with expired certs. 
> 
> If we were talking about EV I’d see every single benefit as described, but 
> not for DV. When I look at our phishing data, the reasons provided for 
> reducing the shelf life of DV outweighs the cost. 
> 
> There is a cost to website owners. I’d argue it’s an expensive exercise. CAs 
> stand to generate more revenue by shortening the life of a cert, so I don’t 
> know what their motivates could be to fight against this change - aside from 
> wanting to support their customers (website owners). There was no consensus 
> in the CA/Browser Forum - CAs voted against this change.
> 
> For those who think I love CAs, my company displaces the need for EV, so I’m 
> certainly not fighting on their behalf. I just don’t see the benefits as 
> browser vendors see them, and there is still no data that I can find, to help 
> me better understand the fine details of points 2 and 3.
> 
> I believe browser vendors have the right to enforce what they deem 
> appropriate. I’m simply asking for more details given that you’re engaging 
> with the community.
> 
> Thanks,
> Paul
> 
> 
> 
> 
>> On Jul 9, 2020, at 8:46 AM, Ben Wilson via dev-security-policy 
>> > > wrote:
>> 
>> All,
>> This is just to let everyone know that I posted a new Mozilla Security blog
>> post this morning. Here is the link>
>> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
>>  
>> 
>> As I note at the end of the blog post, we continue to seek safeguarding
>> secure browsing by working with CAs as partners, to foster open and frank
>> communication, and to be diligent in looking for ways to keep our users
>> safe.
>> Thanks,
>> Ben
>> ___
>> 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: New Blog Post on 398-Day Certificate Lifetimes

[Paul Walsh via dev-security-policy]

Thanks Ben, 

I’ve only had half a cup of coffee this am, so it’s possible I’m not yet awake 
:)

I have a question about reasons 2 and 3 as they’re closely related to the 
attack vector.

According to Google, spear phishing attacks have a shelf life of 7 minutes 
while bulk campaigns have a shelf life of 13 hours. Even if we disbelieve this 
data and multiple the numbers by 10, we end up with the majority of the harm 
being done within a week. 

Also, if bad actors can automatically acquire a DV cert for any available 
domain they please, is there actual risk of bad actors waiting for a domain to 
expire so they can have a valid cert? And they can easily execute a 
man-in-the-middle attack using a new cert that has a shelf life of 3 months.

All I’ve been working on for years is anti-phishing techniques, so I’m not 
seeing all of the benefits as some others see them, but perhaps I’m missing 
something.

I’m talking about the human element of bad actors here, because at the end of 
the day, it’s all about them and what they will do with expired certs. 

If we were talking about EV I’d see every single benefit as described, but not 
for DV. When I look at our phishing data, the reasons provided for reducing the 
shelf life of DV outweighs the cost. 

There is a cost to website owners. I’d argue it’s an expensive exercise. CAs 
stand to generate more revenue by shortening the life of a cert, so I don’t 
know what their motivates could be to fight against this change - aside from 
wanting to support their customers (website owners). There was no consensus in 
the CA/Browser Forum - CAs voted against this change.

For those who think I love CAs, my company displaces the need for EV, so I’m 
certainly not fighting on their behalf. I just don’t see the benefits as 
browser vendors see them, and there is still no data that I can find, to help 
me better understand the fine details of points 2 and 3.

I believe browser vendors have the right to enforce what they deem appropriate. 
I’m simply asking for more details given that you’re engaging with the 
community.

Thanks,
Paul




> On Jul 9, 2020, at 8:46 AM, Ben Wilson via dev-security-policy 
>  wrote:
> 
> All,
> This is just to let everyone know that I posted a new Mozilla Security blog
> post this morning. Here is the link>
> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/
> As I note at the end of the blog post, we continue to seek safeguarding
> secure browsing by working with CAs as partners, to foster open and frank
> communication, and to be diligent in looking for ways to keep our users
> safe.
> Thanks,
> Ben
> ___
> 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