Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview)

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Aug 2020 02:16:53 -0400

{trying to catch up on this thread}

Stephen Farrell <[email-masked]> wrote:
    > On 28/07/2020 20:42, Benjamin Kaduk wrote:
    >> Sorry for the clumsy description.  Basically, if you squint hard, you could
    >> claim that at least some types of pinning are actually a PKI, just a
    >> degenerate PKI.

    > Ah gotcha.

    > ISTM more useful to treat pinning as an adjunct to whatever
    > PKI is used by the application that can be MITM'd and not
    > bother with pinning as a potential replacement for that
    > PKI. There's nothing wrong with an application being based
    > on it's very-own PKI of course, but seems less useful for
    > the IETF to try describe pinning for custom protocols where
    > we don't know the details.

Why would the protocol detail matter?
It some protocol (could be well known), that has a custom, non-CABForum
mediate, trust relationship.
So, basically, ALL of IoT: whether Web Connected devices that only ever call
home, or Information Centric Network IoT based systems of the future.
All of the remote attestation systems are based upon various amounts of
private-PKI pinning as well.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Aug 2020 02:24:08 -0400

Eric Rescorla <[email-masked]> wrote:
    > Pinning on the Web [RFC 7469] is now more than five years old and in
    > the intervening period, opinion has shifted, with people increasingly
    > believing that pinning was too brittle a feature to deploy safely.

    > For this reason, Firefox and Chrome have both deprecated pinning (I
    > believe that Safari and IE never had it). So, to the extent to which
    > there is a consensus, its that pinning is not a best practice.

Are there some reports, threads, or port-mortems that would allow people to
understand the nature of the brittle-ness?   Without attempting to disagree,
I can see all sorts of things that could go wrong, but I'd like to understand
what did go wrong.

(If this conversation happened in an IETF list, then which one would probably
be enough for me to track it down)

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 17 Aug 2020 16:46:52 +1000

> I can see all sorts of things that could go wrong, but I'd like to understand

https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eNMwKPmUBAAJ contains a pretty good summary.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 17 Aug 2020 00:01:57 -0700

> https://groups.google.com/a/chromium.org/g/blink-dev/c/he9tr7p3rZ8/m/eNMwKPmUBAAJ contains a pretty good summary.

The web server prompts for a login. Is there a publicly available
version of that document?

-- Christian Huitema

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 17 Aug 2020 14:30:37 +0300

RFC 8672 ("identity pinning") eliminates the first problem listed, because certificates are not involved.

The two other problems are mitigated, because pinning is time limited, and should be capped at 31 days. If the operator follows the recommended procedures [1], the server is not disabled at all even when recovering from an attack, but pinning - as a second factor security control - is disabled for a while.

Thanks,
	Yaron

[1] https://www.rfc-editor.org/rfc/rfc8672.html#name-server-compromise

On 8/17/20, 09:47, "saag on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    _______________________________________________
    saag mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/saag

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Aug 2020 15:57:00 -0400

Hi Ben,
A long consolidate email.

I missed SAAG because of conflicts with gendispatch.
I watched the youtube yesterday, and read the thread last week, and I read
the NFSv4 thread just now.

First, I think that to first order, this is a quality of implementation issue.

Having said that, implementations are going to lack quality, and being able
to (in a NAFTA/CETA/TPP/etc. compliant government RFP) reference something
has great value.  The alternative is that someone with minimal clue procures
some things and they don't work well together, and the IETF NFSv4 spec gets
blamed.  NFSv4 is the converged storage system spec.  While many of us know
it is successful (and helped find the Higgs boson), many do not.

I think that the use case scenarios for NFSv4 are largely intra-entraprise
rather than inter-enterprise.   Scaling *down* to two systems is pretty
important. Being able to do it without external systems matters here.
And for this being able to pin things matters.
That is WHY SSH was so well received.
At that scale, you don't need to care what you pin, as if it changes, it is
because you did something.

At the >10 desktop scale where some technology like Kerberos is hard to
justify in terms of human learning resources, the use of either a private CA,
or a single public anchor for the server makes sense, and the pinning modes
that are described in the thread make sense to me.
It's not really bits on the wire, but:

  a) it may require new error codes to clearly articulate when the pinning is
     broken. This goes to comments during SAAG as to the need for well
     articulated APIs.

  b) while it is sometimes true that:
     "Modern TLS stacks allow for indicating that a non-root CA and
      even an end-entity (non-CA) certificate are considered to be trusted as
     trust anchors, and thus the pinning you desire can be implemented within
     generic PKI trust frameworks as choice of a single specific trust
     anchor"

     the way in which this done even in the so-called "modern" OpenSSL is
     pretty much a black art.
     While some applications like curl (and fetchmail) have figured it out,
     and mostly present this well, it's not universally done well.

The blob that I move (with human supervised integrity) from machine A to
machine B for the four pin cases described is not standardized.
This matters once an administrative interface is placed on top of it.
Whether that's a web UI, or a netconf YANG model.

I use NFSv4 within my LAN, where I authenticate with IP addresses, and the thing
that keeps me from using it from my laptop (vs SSHFS) is that I don't know
how to trivially do the right certificate exchange.
I'm sure I could figure out, but I'm not sure write a UI for it.

As you write:

> feel quite confident that putting the entire Mozilla root set in my trust
> store is the wrong thing to do for this purpose; the question I'm
> interested in asking relates to "what is the right thing for this purpose?".

so it seems that we ought to have some nomenclature that describes the
recovery cases that are important.

Yaron writes:
> Exactly! Daniel Migault and I published an RFC [1] on "identity pinning" in
> TLS 1.3. This is TOFU pinning seen as a second factor, where the first
> factor is PKI. It also happens to be very low maintenance and independent
> of certificate (EE and CA certificate) changes. This solution is especially
> useful for enterprise use cases, where certificate transparency doesn't do
> the job.

I think that there are two divergent types of pin, and there were allusions
which I missed in the saag meeting as to who is using the term in a different
way.   Yaron describes pinning as second factor, which assumes that the PKI
is minimally valid.  It guards, I think, against a different CA issuing a
name.   The pin is more of a configured name-constraint, I think, but I only
browsed that RFC very quickly.
The other kind of pinning assumes that the PKI does not reach known root,
or rather it configures a new trust anchor for the use of this API.
I gave a talk at INTC today about Enterprises and trust anchors, and I think
that this is very relevant.  Enterprises are mostly lost here.

In summary:
  I think that many non-HTTPS users of TLS would benefit from a common
  understanding of pinning.
  The HTTPS uses of the term are different, and are tied up in the
  WebPKI,CT,etc. uses.
  We probably need a few new terms.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 21 Aug 2020 11:57:05 +0300

On 8/20/20, 22:57, "saag on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

To further clarify: I used the word PKI loosely, and should have said "a preconfigured trust store". The first factor in RFC 8672 is normal TLS cert validation, where the trust store can be the Mozilla set of trust anchors, or that set plus the enterprise CA, or just the enterprise CA. Yes, the main goal is to protect from a different CA mis-issuing a certificate for the same name, but surprisingly, even the same CA is prevented from issuing a stealth cert with the same name for a different TLS server. The pin is an additional constraint but not a configured one. Because of the TOFU behavior, no configuration is required.

Thanks,
	Yaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Aug 2020 21:43:28 -0400

On Tue, Jul 28, 2020 at 12:13:31PM -0700, Benjamin Kaduk wrote:

> Is there benefit in arranging for a description of the system where
> the ability to pin is just a degenerate case of a PKI, with a single
> trust anchor and no real hierarchy?

FWIW, I should mention that the DANE support in OpenSSL (since 1.1.0) is
really just support for verifying a certificate chain against a list of
EE and/or TA pins.  The pins need not come from DNS, and DNSSEC is not
required to use the "DANE" in OpenSSL.  How the application obtains the
pin values is not OpenSSL's concern.

The PKIX-TA and PKIX-EE pins are second factors, while the DANE-TA
and DANE-EE pins are bypass verification via the usual root CA
store, and use only the pins to validate the chain.

Thus, for example, in Postfix the following all use the same underlying
"DANE" (really general-purpose pinning) API.

    - The "fingerprint" security level that verifies the peer
      against a static locally configured list of acceptable
      certificate or public key fingerprints.

    - The "secure" level with a local per-destination "tafile",
      which pins acceptable (possibly intermediate) issuer
      certificates or public keys.  The chain must be signed
      by an issuer that matches one of the pins.

    - The "dane" level, where the "pins" take the form of
      dynamically obtained DNSSEC-validated TLSA records,
      which can be a mixture of EE and TA pins.

So if an OpenSSL application wants to implement pinning that
either replaces or augments WebPKI validation, the code is
already there in OpenSSL, in the form of support for "DANE",
but perhaps it is not correctly "marketed".  It is a really
a fairly general framework for validating certificate chains
against a list of "pins" ("OR" rather than "AND" semantics,
success when any *one* of the pins works out).

-- 
    Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Aug 2020 23:51:51 -0500

On Fri, Aug 21, 2020 at 09:43:28PM -0400, Viktor Dukhovni wrote:
> [...]

Shorter Viktor: TLSA RDATA is a generic data format for specifying pins,
and if you have an API that accepts trust-me-they-are-validated TLSA
RRsets, then you've got an API that does pinning.  That's what OpenSSL
has -- its DANE API does no DNSSEC lookups, so it's not _DANE_ as such.

I.e., one could use TLSA RDATA as a pin configuration and exchange format!

Nico

PS: So OpenSSL's DANE API is a no-batteries-included thing.  I don't why
    Viktor is so 'stingy' about it :) putting his DNSSEC code only in
    Postfix and not in OpenSSL.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Aug 2020 16:38:27 -0400

> store, and use only the pins to validate the chain.

There are some terms here that I want to lift up:

1) PKIX-TA
2) PKIX-EE
3) DANE-TA
4) DANE-EE

I think that the "DANE" in (3) and (4) are not, (as is pointed out in by Viktor),
specifically DNS/DNSEC, but rather the point is that they aren't descending
from a *PKIX* trust anchor.

That there are four ways to pin seems consistent with other comments on this
thread.  It seems to me that having a short document that explains the
four methods would be a useful thing to do.  Are there more than four? Maybe.

    > which can be a mixture of EE and TA pins.

These have different security properties, and maybe represent two additional
forms of pin.

    > success when any *one* of the pins works out).

Stephen Farrel mentioned the banking app that comes with a pin.
I think that such a an app would like to know that it is not getting through
due to Enterprise audit-based MITM, or National-Firewall MITM.
Of course, it could also be another attacker, and RFC7258 in many ways labels
the above as attacks.

Someone using that app might want to ask their bank about what kind of
pin they are using, and they might like to get back a clear answer.

---

From: Nico Williams <[email-masked]>
Date: Sun, 23 Aug 2020 21:16:02 -0500

> from a *PKIX* trust anchor.

In the first two cases you write the pins down in local storage, and
this has significant operational considerations in both, the TA and EE
cases, but more so in the EE case.  In the other two cases you write the
pin down in a distributed storage system called DNS(SEC).  The main
semantic difference security-wise has to do with trusting all the zones
in the chain.  (You want QName minimization in order to make it much
harder for intermediate zone admins zone to mount an MITM attack.)

But "local storage" isn't really, not in most cases.  Those local pins
come with apps, and the app distribution mechanisms have their own
chains of trust.

Is there any difference, then, between (1)&(2) and (3)&(4)?  In both
cases you'll end up with security considerations of both, PKIX and the
pin distribution mechanism.

The only thing DNSSEC adds to any other existing pin distribution
mechanism is authenticated denial of existence, which allows one to have
a fairly fast way to switch between DNSSEC and alternative pin
distribution mechanisms.  See below.

> four methods would be a useful thing to do.  Are there more than four? Maybe.

There's one more.  draft-dukhovni-tls-dnssec-chain allows one to have a
pin of just support for a TLS extension as opposed to a pin of some
credential verifier.  Support for the extension means commitment _only_
to providing DNSSEC chains, either authenticating TLS RRset non-
existence, or else providing the desired authenticated TLSA RRset.

I.e., draft-dukhovni-tls-dnssec-chain is a mechanism for negotiating how
you select a trust anchor / pin: DANE or not-DANE.  Switching between
the two can be done very quickly.

The operational semantics of this quite good because DNS has better
operational semantics for distributing this sort of metadata than code
distribution, and because authenticated denial of existence makes it
alternate pin distribution methods quickly.  Its security semantics are
essentially those of DNSSEC if you're pinning EE certs, or those DNSSEC
as a sort of bridge PKI if you're pinning TAs.

> Stephen Farrel mentioned the banking app that comes with a pin.  I
> think that such a an app would like to know that it is not getting
> through due to Enterprise audit-based MITM, or National-Firewall MITM.

Pinning lets apps detect MITM attacks, but not whether they are
tolerable attacks (enterprise proxies).

In enterprise environments it's common to allow connection to banking
sites through proxies w/o MITMing them.  Typically the banking sites
allowed are either on some generic list (e.g., supplied by the
enterprise proxy vendor), or those that the proxy's operator has
reporting agreements with.

Financial entities might do the latter, say, because they don't need to
know what you're doing in real-time in order to enforce strict
compliance with rules about insider trading.  (If an employee is using
another financial entity with whom the employer has a reporting
agreement, then the employer will find out in due time and will be able
to discipline you for any violations.)

There are strong privacy reasons to exempt certain sites from
otherwise-required MITM proxying.  Employees know they have no real
privacy at work when using their employer's network no matter how
convenient that network.  But employers don't want to have in their
possession any information that only increases their liability, such as
employees' banking credentials.  The biggest reason to MITM is data loss
protection (DLP), but there's no risk of DL when employees engage in
online banking, and again, compliance in the case of banking can be
enforced asynchronously.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 24 Aug 2020 01:25:37 -0400

> > from a *PKIX* trust anchor.

Indeed (3) and (4) pin an EE (leaf) or TA (issuer) certificate or public
key respectively, where there is no expectation of validation via the
the default PKI(X) trust anchors.  In the case of DANE-TA, one then
still implements essentially PKIX validation, but the trust anchor
is the target-specific pin, rather than a trusted-by-default issuer.

> cases, but more so in the EE case. 

This description of (1) and (2) is at least misleading.  These pins
constrain, but do not replace, PKIX validation.  Thus the chain must
validate under PKIX *and* satisfy the pins.  The pins may be from local
storage (as could (3) and (4)), or they may be in the form of DANE TLSA
records with "certificate usage" PKIX-TA(0) or PKIX-EE(1).

All this is defined in RFC6698, but what's interesting is that the basic
chain validation algorithm, is independent of and separabel from the DNS
aspects of DANE TLSA.

Thus OpenSSL implements just the chain validation logic, which one the
one hand means "no batteries included", ..., users roll their own DNS
glue if they want DNSSEC-validated TLSA records to be the source of the
pins.  But, on the other hand, it also means that the implementation is
more flexible, it can verify semantically compatible pins from any other
source (e.g. some day the ISE track dnssec-chain extension).

A batteries-included library for doing the DNS lookups and then DANE TLS
is not difficult to write, but because MTAs are so specialised in their
needs, I've not had cause to write a general-purpose one for the simpler
client to server (with no MX indirection, ...) use-case.  Perhaps some
day.

> pin distribution mechanism.

Yes, (1) and (2) augment (constrain) PKI(X), while (3) and (4)
replace it.

Anyone, I hope this digression might be of some use to someone, if
some sort of pinning makes sense in their applications and maps
reasonably well onto one of the RFC6698 "usages", whether the
pin is from DNS(SEC) or not.

-- 
    Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Aug 2020 23:14:24 -0400

On 2020-07-28 3:42 p.m., Benjamin Kaduk wrote:
> degenerate PKI.  E.g., in a PKI I have to pin at least one trust anchor as
> the root of the PKI, and if that pinned trust anchor just happens to also
> be the certificate directly used in the protocol, it's still a PKI, just a
> tree of height one.

I had suggested that a PKI that consisted of ROOT, Intermediate, and EE
had a height of "three".
Some disagreed, and said that the EE didn't count, and it was a height 
of "two"
Others disagreed: the EE counts, but the root doesn't count, so it's a 
height of "two"

So is your case above a height of "one", or a height of "zero"

If there is a definitive answer, I haven't found it yet.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Aug 2020 00:35:30 -0400

> If there is a definitive answer, I haven't found it yet.

What's "definitive"?  And which certificate is at depth 0, the root or
the leaf?  These questions have no answer (different X.509 libraries
answer them differently), just be clear about your notation in context.

You could of course go with RFC5280, but its numbering is by no means
universally used.

-- 
    Viktor.

---

From: Russ Housley <[email-masked]>
Date: Wed, 26 Aug 2020 10:43:57 -0400

> On Aug 25, 2020, at 11:14 PM, Michael Richardson <[email-masked]> wrote:
> 
> Some disagreed, and said that the EE didn't count, and it was a height of "two"
> Others disagreed: the EE counts, but the root doesn't count, so it's a height of "two"
> 

You may find the description of pathLenConstraint in Section 4.2.1.9 of RFC 5280 helpful.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Aug 2020 17:52:31 -0400

Viktor Dukhovni <[email-masked]> wrote:
    >> On 2020-07-28 3:42 p.m., Benjamin Kaduk wrote: > Sorry for the clumsy
    >> description.  Basically, if you squint hard, you could > claim that at
    >> least some types of pinning are actually a PKI, just a > degenerate
    >> PKI.  E.g., in a PKI I have to pin at least one trust anchor as > the
    >> root of the PKI, and if that pinned trust anchor just happens to also
    >> > be the certificate directly used in the protocol, it's still a PKI,
    >> just a > tree of height one.
    >>
    >> I had suggested that a PKI that consisted of ROOT, Intermediate, and
    >> EE had a height of "three".  Some disagreed, and said that the EE
    >> didn't count, and it was a height of "two" Others disagreed: the EE
    >> counts, but the root doesn't count, so it's a height of "two"
    >>

    > answer them differently), just be clear about your notation in context.

I would be interested in which libraries do what.

    > You could of course go with RFC5280, but its numbering is by no means

Alright.  Let me look again there.

}6.1.  Basic Path Validation
}...
}   To meet this goal, the path validation process verifies, among other
}   things, that a prospective certification path (a sequence of n
}   certificates) satisfies the following conditions:
}
}      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
}           the issuer of certificate x+1;
}
}      (b)  certificate 1 is issued by the trust anchor;
}
}      (c)  certificate n is the certificate to be validated (i.e., the
}           target certificate); and
}
}      (d)  for all x in {1, ..., n}, the certificate was valid at the
}           time in question.

So this means that the trust anchor is at height one.
The End-Entity Certificate is to be counted, and it's a height n.

So, in my example of root, intermediate-CA and EE, the height is three.
Which is what I originally thought.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Aug 2020 17:54:58 -0400

Russ Housley <[email-masked]> wrote:
    >>> Sorry for the clumsy description.  Basically, if you squint hard, you
    >>> could claim that at least some types of pinning are actually a PKI,
    >>> just a degenerate PKI.  E.g., in a PKI I have to pin at least one
    >>> trust anchor as the root of the PKI, and if that pinned trust anchor
    >>> just happens to also be the certificate directly used in the
    >>> protocol, it's still a PKI, just a tree of height one.
    >>

    > You may find the description of pathLenConstraint in Section 4.2.1.9 of

That's interesting, but in of itself, it does not establish a zero-indexed or
one-index absolute count, as it describes an interval.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Aug 2020 15:49:58 -0400

> harder for intermediate zone admins zone to mount an MITM attack.)

I agree with your analysis.
Do you think we need to capture it into a document?

I was picking apart the fact that Viktor had identied two cases where the
PKIX part/trust anchor didn't matter.  His point was that (3) and (4) just
happened to match the DANE use case, and thus provided that name, but it
doesn't matter exactly where the storage is.

If I were to write a document explaining this, I would use DANE an example,
but I wouldn't name it that.

    > existence, or else providing the desired authenticated TLSA RRset.

I didn't know that this document exists.  To save others the step of learning
about it:
  Abstract
   This draft describes a new TLS extension for in-band transport of the
   complete set of DNSSEC validated records needed to perform DANE
   authentication of a TLS server without the need to perform separate
   out-of-band DNS lookups.  When the requisite DNS records do not
   exist, the extension conveys a validated denial of existence proof.

So, I wanted to do EXACTLY this for IPsec OE (RFC4322).
I imagined two entities (Opus and Bill the Cat) sitting in a meadow, doing
security of IPv6-LL addresses without any outside connectivity.
[You can't expect a dead cat to fetch CRLs..]

I guess this is intended for the TLS WG?

    > tolerable attacks (enterprise proxies).

Agreed.
That would have to come by some attestation statement in the decline.
draft-ietf-capport-api-08 is one place I would like to that.

    > reporting agreements with.

Yes.  But, generating exceptions to the site administrator to approve/deny
might also be a good way to this.  MUD/RFC8520 statements from the app would
also be interesting as supporting evidence.

    > online banking, and again, compliance in the case of banking can be

+1

---

From: Nico Williams <[email-masked]>
Date: Fri, 28 Aug 2020 15:19:44 -0500

On Fri, Aug 28, 2020 at 03:49:58PM -0400, Michael Richardson wrote:
>     > In the first two cases ...
> 

I hadn't understood that those were specifically TLSA RR usage values.
So I was a bit confused, but still, I think the analysis was right.

> Do you think we need to capture it into a document?

It might be nice.  The realization that DANE is akin to a pin dist.
mechanism, that app stores and such are comparable in that sense, seems
like something that should be written down somewhere.

>     > There's one more.  draft-dukhovni-tls-dnssec-chain allows ...
> 
>    ...

Yeah!

> [You can't expect a dead cat to fetch CRLs..]

You'd need an IKEv2 extension like Viktor's TLS extension, but which
also includes A/AAAA RRsets.

> I guess this is intended for the TLS WG?

Funny story about that.  There had been a TLS WG work item for it that
didn't support either the extension pin or the denial of existence
chain, and when we pushed for that to be added WG consensus fell apart
and the WG dropped the I-D with the agreement that all parties would get
to publish their own versions of it on the ISE.

> draft-ietf-capport-api-08 is one place I would like to that.

Tolerable attacks are essentially site-local pins that the app needs to
decide are OK or not OK, probably by hardcoding an OK/not-OK policy.

> also be interesting as supporting evidence.

Yes.

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Aug 2020 17:32:00 -0400

> also includes A/AAAA RRsets.

Yes, exactly.  RFC4322 was also going to have a standards track version that
depended upon IKEv2, and RFC4025...but.

    > to publish their own versions of it on the ISE.

Oh. I feel many beers may be required to understand.
Or perhaps to achieve consensus :-)

    > decide are OK or not OK, probably by hardcoding an OK/not-OK policy.

Enough that your banking app can say, "Example.COM says you can not connect
securely, please try a different network",  .. and the user can realize that
they are on the example.com guest network.  So, okay.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2020 14:39:33 -0700

> they are on the example.com guest network.  So, okay.

Note that this is not how browser clients behave. Rather, they do not
enforce pin checks when the certificate chains to a locally installed root.
I do not know how apps behave. Does someone have an example of one that
enforces pin checks against locally installed roots?

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Aug 2020 22:56:56 +0100

> enforces pin checks against locally installed roots?

I'm not quite sure what you're asking but a number of
the GAEN covid-tracking apps enforce pins [1], for
example the Irish app ships with 5 root CA pins, 4 of
which are for the CA service in use today with one from
a different CA service that is presumably for insurance.
There seem to be two or three libraries that are used
by such apps for this kind of pinning.

Cheers,
S.

[1] https://www.scss.tcd.ie/Doug.Leith/pubs/contact_tracing_app_traffic.pdf

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Aug 2020 19:02:53 -0400

> by such apps for this kind of pinning.

What happens if there is an official MITM installed on the phone,
and the phone is in that "Enterprise"?
I assume it doesn't work, but what does the app *do*?

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 29 Aug 2020 00:27:57 +0100

> I assume it doesn't work, but what does the app *do*?

I believe the intent is that an enterprise MITM ought
not see that a person has tried to upload keys as a
result of a positive COVID test (that being sensitive
medical information) and so the app would fail to connect
to the public health authority services whilst being
MITM'd. I don't know what the UI would display in that
case as we didn't do any tests of the upload features,
as that could in theory interfere with a live service.

For the regular download (every ~2 hours), I'd have to
re-do the test to be sure, but IIRC, the app didn't
display anything to the user, just the same as if the
n/w weren't up at that time. (Pinning for the download
isn't as big a deal though as the data retrieved is
signed at the application layer so it could be ok
if some of the apps don't enforce pins for downloads.)
Most of these apps are open-source though so you
could figure it out if it mattered.

Cheers,
S.

PS: I know what you meant but "official MITM" is a bit
of a yukkie term;-)