Re: Digicert issued certificate with let's encrypts public key

[Paul Wouters via dev-security-policy]

On May 18, 2020, at 23:58, Peter Gutmann via dev-security-policy 
 wrote:
> 
> 
> 
> This isn't snark, it's a genuine question: If the CA isn't checking that the
> entity they're certifying controls the key they're certifying, aren't they
> then not acting as CAs any more?

They are really only certifying that the requester can control the dns for the 
domain name mentioned in the certificate anyway. The same function DNSSEC 
provides without middle men :)

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

Re: Use of Certificate/Public Key Pinning

[Paul Wouters via dev-security-policy]

On Mon, 12 Aug 2019, Nuno Ponte via dev-security-policy wrote:


Recently, we (Multicert) had to rollout a general certificate replacement due 
to the serial number entropy issue. Some of the most troubled cases to replace 
the certificates were customers doing certificate pinning on mobile apps. 
Changing the certificate in these cases required configuration changes in the 
code base, rebuild app, QA testing, submission to App stores, call for 
expedited review of each App store, wait for review to be completed and only 
then the new app version is made available for installation by end users (which 
is turn are required to update the app the soonest).

Meeting the 5-days deadline with this sort of process is “challenging”, at best.


The OS and/or App should look at Certificate Transparency, instead of
hacks that hardcode the certificate serial number.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Paul Wouters via dev-security-policy]

> On Aug 12, 2019, at 14:30, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> Mozilla has announced that we plan to relocate the EV UI in Firefox 70,
> which is expected to be released on 22-October. Details below.

Relocate seems a wrong word here. You are basically removing it. A few geeks 
will be able to find it at the new location and I wonder why Firefox even 
bothered to leave it at the new location.

Paul

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

Re: DarkMatter Concerns

[Paul Wouters via dev-security-policy]

On Tue, 26 Feb 2019, Rob Stradling via dev-security-policy wrote:


Hi Scott.  It seems that the m.d.s.p list server stripped the
attachment, but (for the benefit of everyone reading this) I note that
you've also attached it to
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262.

Direct link:
https://bug1427262.bmoattachments.org/attachment.cgi?id=9046699


Thanks for sending the link. The letter is uhm interesting. It both
states they cannot say anything for national security reasons, say they
unconditionally comply with national security (implying even if that
violates any BRs) and claims transparency for using CT which is in fact
being forced by browser vendors on them.

"quests to protect their nations" definitely does not exclude "issuing
BR violating improper certificates to ensnare enemies of a particular
nation state".

Now of course, I don't think this is very different from US based
companies that are forced to do the same by their governments, which
is why DNSSEC TLSA can be trusted more (and monitored better) than a
collection of 500+ CAs from all main nation states that are known for
offense cyber capabilities. But you can ignore this as off-topic :)

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

Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec

[Paul Wouters via dev-security-policy]

On Thu, 6 Dec 2018, Peter Gutmann via dev-security-policy wrote:


Paul Wouters via dev-security-policy  
writes:


Usually X509 is validated using standard libraries that only think of the TLS
usage. So most certificates for VPN usage still add EKUs like serverAuth or
clientAuth, or there will be interop problems.


So just to make sure I've got this right, implementations are needing to add
dummy TLS EKUs to non-TLS certs in order for them to "work"?


You understanding is correct.


 In that case why
not add a signalling EKU or policy value, a bit like Microsoft's
systemHealthLoophole EKU (I don't know what its official name is, 1 3 6 1 4 1
311 47 1 3) where the normal systemHealth key usage is meant to indicate
compliance with a system or corporate security policy and the
systemHealthLoophole key usage is for systems that don't comply with the
policy but that need a systemHealth certificate anyway.


I'm not sure how that is helpful for those crypto libraries who
mistakenly believe a certificate is a TLS certificate and thus if the
EKU is not empty it should have serverAuth or clientAuth.


Better to define a new EKU, "tlsCompabitility", telling the relying party that
the TLS EKUs are present for compatibility purposes and can be ignored if it's
a non-TLS use.


As I stated earier, since often these certificates are re-used for the
VPN server's TLS (openvpn, openconnect, etc) protocols or for their
webgui's provisioning API, they will most likely want serverAuth anyway.

btw for nss this got fixed recently:

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

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

Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec

[Paul Wouters via dev-security-policy]

> On Dec 5, 2018, at 16:49, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> 
> 
> Another question of relevance:
> 
> Does the applicable VPN hardware and software (Cisco VPN servers and
> compatible VPN clients) work with certificates that omit all the TLS-
> related EKUs, thus allowing future VPN certificates to fall outside the
> BRs ?

Speaking as an IKE/IPsec implementer.

Usually X509 is validated using standard libraries that only think of the TLS 
usage. So most certificates for VPN usage still add EKUs like serverAuth or 
clientAuth, or there will be interop problems.
Our implementation uses NSS which only weeks ago implemented IPsec profiles 
that causes non-empty EKU’s that miss serverAuth and clientAuth to validate 
correctly for IPsec.

In other words, “no” is the answer to your question for the generic case. If 
Cisco VPN servers only need to talk to Cisco VPN clients, then maybe their 
implemention could do its

Another issue is that some provisions webgui’s for IPsec use the VPN gateway’s 
TLS server, usually using the same certificate. Especially if also supporting 
other VPN protocols such as openvpn or anyconnect/openconnect. So those would 
really need serverAuth.

Paul

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

Re: Mitigating DNS fragmentation attacks

[Paul Wouters via dev-security-policy]

On Oct 14, 2018, at 21:09, jsha--- via dev-security-policy 
 wrote:
> 
> There’s a paper from 2013 outlining a fragmentation attack on DNS that allows 
> an off-path attacker to poison certain DNS results using IP fragmentation[1]. 
> I’ve been thinking about mitigation techniques and I’m interested in hearing 
> what this group thinks.
> 

The mitigation is dnssec. Ensure your data is cryptographically protected.

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

Re: A vision of an entirely different WebPKI of the future...

[Paul Wouters via dev-security-policy]

On Thu, 16 Aug 2018, Matthew Hardeman via dev-security-policy wrote:


1.  Run one or more root CAs


Why would people not in the business of being a CA do a better job than
those currently in the CA business?


I recognize it's a radical departure from what is.  I'm interested in 
understanding if anything proposed here is impossible.  If what's proposed here 
CAN happen, AND IF we are confident that valid certificates for a domain label 
should unambiguously align to domain control, isn't this the ultimate solution?


If you want a radical change that makes it simpler, start doing TLSA in
DNSSEC and skip the middle man that issues certs based on DNS records.

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

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

[Paul Wouters via dev-security-policy]

On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote:


However, what does this buy us? Considering that the ZSKs are intentionally
designed to be frequently rotated (24 - 72 hours), thus permitting weaker
key sizes (RSA-512),


I don't know anyone who believes or uses these timings or key sizes. It
might be done as an _attack_ but it would be a very questionable
deployment.

I know of 12400 512 bit RSA ZSK's in a total of about 6.5 million. And I
consider those to be an operational mistake.


However, let us not pretend that recording the bytes-on-the-wire DNS
responses, including for DNSSEC, necessarily helps us achieve some goal
about repudiation. Rather, it helps us identify issues such as what LE
highlighted - a need for quick and efficient information scanning to
discover possible impact - which is hugely valuable in its own right, and
is an area where I am certain that a majority of CAs are woefully lagging
in. That LE recorded this at all, beyond simply "checked DNS", is more of a
credit than a disservice, and a mitigating factor more than malfeasance.


I see no reason why not to log the entire chain to the root. The only
exception being maliciously long chains, which you can easilly cap
and error out on after following about 50 DS records?

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

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Paul Wouters via dev-security-policy]

On Mon, 30 Apr 2018, Tim Hollebeek wrote:


What about the cases we discussed where there is DNSSEC, but only for a
subtree?


I don't know what that means? You mean a trust island not chained to the
root? If so, then yes, that is a zone without DNSSEC since it is missing
a DS in its parent (or grand parent, etc)

But again, using a proper validating DNS server will handle all that for
you.

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

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Paul Wouters via dev-security-policy]

On Mon, 30 Apr 2018, Tim Hollebeek via dev-security-policy wrote:


I don't think this opinion is in conflict with the suggestion that we
required
DNSSEC validation on CAA records when (however rarely) it is deployed. I
added this as https://github.com/mozilla/pkipolicy/issues/133


One of the things that could help quite a bit is to only require DNSSEC
validation
when DNSSEC is deployed CORRECTLY, as opposed to some partial or broken
deployment.  It's generally broken or incomplete DNSSEC deployments that
cause all the problems.

Getting the rules for this right might be complicated, though.


It's also wrong. You can't soft-fail on that and you don't want to be in
the business of trying to figure out what is a sysadmin failure and what
is an actual attack.

The only somehwat valid soft-fail could come from recently expired
RRSIGs, but validating DNS resolvers like unbound already build in a
margin of a few hours, and I think you should not to anything special
during CAA verification other then using a validating resolver.

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

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

[Paul Wouters via dev-security-policy]

On Wed, 25 Apr 2018, Ryan Hurst via dev-security-policy wrote:


Multiple perspectives is useful when relying on any insecure third-party 
resource; for example DNS or Whois.

This is different than requiring multiple validations of different types; an 
attacker that is able to manipulate the DNS validation at the IP layer is also 
likely going to be able to do the same for HTTP and Whois.


which is why in the near future we can hopefully use RDAP over TLS (RFC
7481) instead of WHOIS, and of course since the near past, DNSSEC :)

I'm not sure how useful it would be to have multiple network points for
ACME testing - it will just lead to the attackers doing more then one
BGP hijack at once. In the end, that's a numbers game with a bunch of
race conditions. But hey, it might lead to actual BGP security getting
deployed :)

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

Re: On the value of EV

[Paul Wouters via dev-security-policy]

On Mon, 11 Dec 2017, Ryan Hurst via dev-security-policy wrote:


The issues with EV are much larger than UI. It needs to be revisited and a 
honest and achievable set of goals need to be established and the processes and 
procedures used pre-issuance and post-issuance need to be defined in support 
those goals. Until thats been done I can not imagine any browser would invest 
in new UI and education of users for this capability.


While I agree that EV does not solve world peace, can you tell me what
is wrong with the firefox approach of showing EV? That is, browsers
hiding the real hostname with EV seems to behave wrong, and should be
fixed. This seems unrelated to other noble goals of giving users improved
security. It seems you are conflating many things, then say it is too
much work and lets just scrap it.

Thus, so far I see reason for some browsers to fix their UI. I can see
reasons for EV to improve. I see no reason to further confuse users
by removing EV without a successor.

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

Re: On the value of EV

[Paul Wouters via dev-security-policy]

On Mon, 11 Dec 2017, James Burton via dev-security-policy wrote:


EV is on borrowed time


You don't explain why?

I mean domain names can be confusing or malicious too. Are domain names
on borrowed time?

If you remove EV, how will the users react when paypal or their bank is
suddenly no longer "green" ? Are we going to teach them again that
padlocks and green security come and go and to ignore it?

Why is your cure (remove EV) better than fixing the UI parts of EV?

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

RE: Anomalous Certificate Issuances based on historic CAA records

[Paul Wouters via dev-security-policy]

On Thu, 30 Nov 2017, Tim Hollebeek via dev-security-policy wrote:

[somewhat off topic, you can safely hit delete now]


So it turns out DNSSEC solves CAA problems for almost nobody, because almost
nobody uses DNSSEC.


The only people who need to use CAA are the CA's. They can surely manage
to fire up a validating DNS resolver. I'm sure there are more BR's that
"almost nobody uses" because there is no need for everyone to use it but
CA's. If you talk about domain holders not being able to run DNSSEC,
that's a pretty lame excuse too, when we have many Registrars and
Hosters who run millions of DNSSEC secured zones. I feel this argument
is similar to "hosting your own email service is too hard". If it is,
there are excellent commercial alternatives available.


And given the serious flaws both in DNSSEC itself and exiting DNSSEC 
implementations


For one, I'm not aware of "serious flaws in DNSSEC". As for wanting
something to die because of bad implementations, can I suggest starting
with ASN.1 and X.509, then move to crypto primitives and TLS ? :)


The presence of DNSSEC in the BR policy
for handling DNS failures, in hindsight, was probably a mistake, and


Trusting unauthenticated data from the network should really be a no-op,
from a princple point of view. Making any security decisions based on
"some blob from the network that anyone could have modified without
detecting" is just madness.


Right now, the only thing it is really accomplishing is preventing certificate
issuance to customers whose DNS infrastructure is flaky, misconfigured, or
unreliable.


Seems like the kind of people who should be given a certificate award
for excellence :P


Longer term, DNS over HTTPS is probably a more useful path
forward than DNSSEC for CAA, but unfortunately that is still in it's
infancy.


Not really, because that only offers transport security and not data
integrity. A compromised nameserver should not be able to fake the lack
of CAA record for a domain that uses secure offline DNSSEC signing.


The problem DNSSEC checks for CAA was intended to solve was the fact that it
is certainly possible that a well-resourced attacker can manipulate the DNS
responses that the CA sees as part of its CAA checks.  A better mitigation,
perhaps, is for multiple parties to publicly attest in a verifiable way as
to what the state of DNS was at/near the time of issuance with respect to
the relevant CAA records.


Then why not simply cut out the DNS middle man, and give domains another
way to advertise this information. What about RDAP ? What about an EPP
"CA lock" similar to a "Registrar lock" ?


Of course, to avoid some of the extremely interesting experiences the
industry has had with CAA


Maybe people should use proper dns libraries and not invent their own
CNAME / DNAME handling :)

Paul

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

Re: Anomalous Certificate Issuances based on historic CAA records

[Paul Wouters via dev-security-policy]

On Thu, 30 Nov 2017, Wayne Thayer wrote:

[cut CC: list, assuming we're all on the list]


- Subscribers already (or soon will) have CT logs and monitors available to 
detect mis-issued certs. They don't need CAA Transparency.


It's not for subscribers, but for CA's.

Transparency is nice, but it does not _prevent_ misissue. The goal of
CAA is to prevent misissue.

We don't need a CAA Transparency log, because the only thing that needs
logging is the DNSSEC chain of the CAA record or lack thereof at the
time of issue. And only the issuing CA needs this information in case
they need to defend that there was no CAA record preventing them from
issuing at the time. Of course, you could still stuff it in some
transparency log if you want, but it is pretty useless for endusers.

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

Re: Anomalous Certificate Issuances based on historic CAA records

[Paul Wouters via dev-security-policy]

> On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy 
>  wrote:
> 
> This whole conversation makes me wonder if CAA Transparency should be a
> thing.

That is a very hard problem, especially for non-DNSSEC signed ones.

Paul

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