Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Martin Rex <mrex@sap.com> Mon, 04 October 2010 16:18 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40DCA3A6FED; Mon, 4 Oct 2010 09:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.841
X-Spam-Level:
X-Spam-Status: No, score=-9.841 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F8kVK7DF86O; Mon, 4 Oct 2010 09:18:25 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E85E83A6CAB; Mon, 4 Oct 2010 09:18:24 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o94GJHi1008108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2010 18:19:17 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201010041619.o94GJFXF006308@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Mon, 4 Oct 2010 18:19:15 +0200 (MEST)
In-Reply-To: <4CA9EED5.5050006@extendedsubset.com> from "Marsh Ray" at Oct 4, 10 10:12:21 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: dnsop@ietf.org, saag@ietf.org, pkix@ietf.org, tls@ietf.org
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2010 16:18:26 -0000

Marsh Ray wrote:
> 
> On 10/04/2010 09:37 AM, Martin Rex wrote:
> >
> > It seems that you do not realize that the entire TLS PKI security model,
> > as far as the automatic / no-prompt "server endpoint identification" is
> > concerned, has always been relying completely on that DNS data being
> > accurate.
> 
> How do you figure that?
> 
> I can put an entry in /etc/hosts (do this all the time for testing) and 
> DNS isn't even queried. Yet the server certificate is validated as usual.

In order to get a TLS server cert issued for a particular DNS f.q.d.n
under most of the existing pre-configured trust anchors, you only need
to provide some vague proof that you leased that DNS domain.

The no-prompt server endpoint identification will ignore any information
in the cert besides the DNS f.q.d.n, no matter how carefully that other
part of information may be validated.


> 
> > But keep in mind that few TLS clients (such as browsers), currently
> > support "pinning" of PKIX-authenticated server certs, so that on future
> > connects only the very same server cert (with user-authenticated
> > attributes other than DNS f.q.d.n) will be accepted from that server.
> > In is very common misbehaviour in TLS clients to accept arbitrary other
> > server certs on future connects, as long as the DNS f.q.d.n matches.
> 
> Is there a spec saying this is invalid behavior?

No.  For the existing specs, this issue fell into the huge
"out-of-scope" gaps between rfc-2818, PKIX and TLS.

I know there is a school of thought popular in the US that is build
around "but it didn't come with a warning label that I must not shoot
in my foot, so it isn't my fault".  

I assume that _very_ few of those TLS-enabled servers that offer
TLS client cert authentication, base their authorization decision
on only one particular certificate attribute and ignore all the
rest of the certificate and allow it to chain to arbitrary CAs
operated under any one of >100 pre-configured trust anchors.

But for the server side, no-prompting usability has always been deemed
MUCH more important than security.


> 
> > One thing that needs to be addressed/solved is the key/cert rollover
> > for any TLS-Server, so that it is possible to list more than one
> > server cert as "valid" for a Server through DNS, at least for the
> > time of the transition/rollover.
> 
> If you're going to trust certs you get out of DNS, you might as well 
> just put a self-signed organizational CA cert in there. Maybe that's 
> what's being proposed.

That only affects the frequency of the key/cert rollover, not the fact
that key/cert rollover needs to be addressed.

Distributing an organizations CA cert through DNS instead of the
server certs is somewhat incompatible with how a lot of traditional
PKI software works (like Microsoft's CryptoAPI on XP/2003).

PKIX specs define certificate path validation only when you have
a certificate chain to one of your trust anchors.  You probably
will _NOT_ want most of these CAs a trust anchor, even when you might
allow the use of such organizational CA certs for verification of
specific server certificates.

I once received an S/Mime signed Email in Outlook 2003, and the signature
included an end-entity and an intermediateCA cert.  I found myself
unable to make Outlook verify the digital signature of that Email,
because of a lack of the (non-public, organizational) RootCA cert
for that chain.


> 
> Say, what's the link to the Internet Draft proposal we're discussing anyway?

To me it sounded like it is a post-prototype implementation,
pre-draft discussion about the charter of the "keyassurance" WG.

-Martin