Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?

        You're correct that RFC 5280 section 6 doesn't consider 
extendedKeyUsage as an anchor parameter in the way that it considers 
policies, and that RFC 5914 section 2.5 doesn't either.  However, it's 
probably desirable for the client to specify the issuer level that must be 
within the proxy's chain separately from his primary set of anchors.  If 
my employer has a proxy certified by an intermediate under a large 
commercial CA, I'd rather require that my proxy be certified by my 
employer's intermediate rather than by "some descendant of TrustUS", even 
though my browser trusts any descendant of TrustUS as a server 
certificate.  Being a proxy or an MITM is more intrusive.

Tom Gindin

From:   Yoav Nir <ynir.ietf@gmail.com>
To:     noloader@gmail.com
Cc:     PKIX <pkix@ietf.org>
Date:   11/16/2015 12:25 AM
Subject:        Re: [pkix] How do we differentiate authentic servers from 
proxies performing TLS interception?
Sent by:        "pkix" <pkix-bounces@ietf.org>

> On 16 Nov 2015, at 5:54 AM, Jeffrey Walton <noloader@gmail.com> wrote:
> 
>> No certificate marking is needed, though.  Clients could invoke 
alternative certificate processing when a certificate name match fails but 
the certificate chains to a trust anchor marked as "trusted for proxy."
>> 
> You will have to forgive my ignorance... For user agents and other
> software that conforms to RFC 7469 and provides the overrides, how are
> they supposed to know when to break a known good pinset if its not
> signaled? That is, how do they differentiate between the "good" bad
> guys and the "bad" bad guys.
> 
> Examples:
> 
>  Corporate DLP - ACME, LLC sets Proxy key usage for subordinate
>      and server certificate. User agent allows an override to the Pinset
>      in accordance with RFC 7469 because they declared the intent and
>      confirmed with the user.
> 
>  Diginotar - Bad guy starts minting server certificates. Proxy is
>      not set in subordinate CA or server certificate. The user agent
>      refuses to break the known good pinset according to RFC 7469.
> 
> And RFC's 7469 {SHOULD NOT|MUST NOT} logging requirement can be lifted
> or refined so the failures can be reported instead of making user
> agents complicit in the cover-up.
> 
> RFC 7469's overrides opened a can of worms, but its probably best in
> the big picture. This stuff has always been going on and allowed to
> fester behind the scenes in a "don't ask don't tell" fashion. Now that
> its been brought to the fore-front, it can be dealt with accordingly.
> 

Before RFC 7469 (pins in HTTP) there were pre-loaded pins for a select 
group of servers. The policy of Chrome at the time was to allow ?wrong? 
keys whenever the root of trust was not part of the default set that comes 
with the operating system. This allowed for trust anchors installed 
specifically for proxy to sign certificates for mail.google.com. The 
unfortunate side-effect was that it allowed any corporate CA to also sign 
such certificates, which it shouldn?t. 

It would be nice if a trust anchor could be marked as ?for proxy? vs ?just 
another CA?, but no OS or browser provides that distinction.

Yoav

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix