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

"Tom Gindin" <tgindin@us.ibm.com> Tue, 17 November 2015 02:29 UTC

Return-Path: <tgindin@us.ibm.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E011A00EF for <pkix@ietfa.amsl.com>; Mon, 16 Nov 2015 18:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.284
X-Spam-Level:
X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_71=0.6, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_MCwL1fRwkL for <pkix@ietfa.amsl.com>; Mon, 16 Nov 2015 18:29:11 -0800 (PST)
Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520E11A0155 for <pkix@ietf.org>; Mon, 16 Nov 2015 18:29:11 -0800 (PST)
Received: from localhost by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <pkix@ietf.org> from <tgindin@us.ibm.com>; Mon, 16 Nov 2015 19:29:09 -0700
Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 16 Nov 2015 19:29:07 -0700
X-IBM-Helo: d03dlp03.boulder.ibm.com
X-IBM-MailFrom: tgindin@us.ibm.com
X-IBM-RcptTo: pkix@ietf.org
Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id B8CA319D803F for <pkix@ietf.org>; Mon, 16 Nov 2015 19:17:14 -0700 (MST)
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tAH2T796721334 for <pkix@ietf.org>; Mon, 16 Nov 2015 19:29:07 -0700
Received: from d03av01.boulder.ibm.com (localhost [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tAH2T7Vm002246 for <pkix@ietf.org>; Mon, 16 Nov 2015 19:29:07 -0700
Received: from d50lp02.ny.us.ibm.com (d50lp02.pok.ibm.com [146.89.104.208]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id tAH2T6Sm002235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <pkix@ietf.org>; Mon, 16 Nov 2015 19:29:06 -0700
Message-Id: <201511170229.tAH2T6Sm002235@d03av01.boulder.ibm.com>
Received: from /spool/local by d50lp02.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <pkix@ietf.org> from <tgindin@us.ibm.com>; Mon, 16 Nov 2015 21:29:06 -0500
Received: from smtp.notes.na.collabserv.com (192.155.248.74) by d50lp02.ny.us.ibm.com (158.87.18.21) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256/256) Mon, 16 Nov 2015 21:29:03 -0500
Received: from /spool/local by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for <pkix@ietf.org> from <tgindin@us.ibm.com>; Tue, 17 Nov 2015 02:29:01 -0000
Received: from us1a3-smtp01.a3.dal06.isc4sb.com (10.106.154.100) by smtp.notes.na.collabserv.com (10.106.227.92) with smtp.notes.na.collabserv.com ESMTP; Tue, 17 Nov 2015 02:28:59 -0000
Received: from us1a3-mail59.a3.dal09.isc4sb.com ([10.142.3.90]) by us1a3-smtp01.a3.dal06.isc4sb.com with ESMTP id 2015111702294512-532370 ; Tue, 17 Nov 2015 02:29:45 +0000
In-Reply-To: <C4D1A2CB-4CF1-4E4F-A0BC-6417634F100F@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
From: "Tom Gindin" <tgindin@us.ibm.com>
Date: Mon, 16 Nov 2015 21:28:58 -0500
References: <BY2PR09MB1094EA71ADDC83440AE82F2AE120@BY2PR09MB109.namprd09.prod.outlook.com> <20151112163810.E8F351A368@ld9781.wdf.sap.corp> <BY2PR09MB109B9B70BC1746B516CB335AE120@BY2PR09MB109.namprd09.prod.outlook.com> <CAH8yC8n41uA-Aj3pLKRHgjGu1P6smwG-r-dA595rXHMjhAZC_A@mail.gmail.com> <BY2PR09MB10945A7D32E11E8C5E74750AE120@BY2PR09MB109.namprd09.prod.outlook.com> <201511152227.tAFMRTjH000463@d01av04.pok.ibm.com> <6ADE63A8-8B81-48F5-BF37-F91B734935C3@mitre.org> <CAH8yC8=XK12R=ox=Uw2jYyk_z0ukB4nbpeVbiyb-ZGOKMSskFQ@mail.gmail.com> <C4D1A2CB-4CF1-4E4F-A0BC-6417634F100F@gmail.com>
MIME-Version: 1.0
X-KeepSent: 30AA25A5:E8ACC06B-85257F00:000C3301; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP4 Octobe4, 2013
X-LLNOutbound: False
X-Disclaimed: 61347
X-TNEFEvaluated: 1
Content-Type: multipart/alternative; boundary="=_alternative 000DA2FF85257F00_="
x-cbid: 15111702-0025-0000-0000-00001ED37972
X-IBM-ISS-SpamDetectors: Score=0.4332; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.4332; ST=0; TS=0; UL=0; ISC=
X-IBM-ISS-DetailInfo: BY=3.00004590; HX=3.00000236; KW=3.00000007; PH=3.00000004; SC=3.00000121; SDB=6.00618487; UDB=6.00274346; UTC=2015-11-17 02:29:01
x-cbparentid: 15111702-5920-0000-0000-000004F0E7AE
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/KUgv7fZ-uCxDtrsr-jT2-LtTOqY>
Cc: PKIX <pkix@ietf.org>
Subject: Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2015 02:29:14 -0000

        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