Re: [dane] #13: Server name check for certificate type 1

Martin Rex <mrex@sap.com> Wed, 09 November 2011 23:19 UTC

From: Martin Rex <mrex@sap.com>
Message-Id: <201111092319.pA9NJQwA007005@fs4113.wdf.sap.corp>
To: rbarnes@bbn.com
Date: Thu, 10 Nov 2011 00:19:26 +0100
In-Reply-To: <91EDC182-2CC8-4B57-B451-8354B973956D@bbn.com> from "Richard Barnes" at Nov 9, 11 05:52:39 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: paul.hoffman@vpnc.org, dane@ietf.org
Subject: Re: [dane] #13: Server name check for certificate type 1
Precedence: list
Reply-To: mrex@sap.com

Richard Barnes wrote:
> 
> >> I still disagree with this.  Names are not considered at the
> >> DANE/PKIX/TLS layer -- only the application considers the name.
> >> This document should not place any constraints on what names should
> >> or should not be in certificates.  
> > 
> > I strongly disagree.
> > 
> > Matching of DNS names is an integral part of the security architecture
> > of DANE, because the name is necessary in order to obtain the relevant
> > DANE records.
> 
> I certainly agree.  The choice of domain name is critical.
> Hence the suggestion at the bottom of my previous message,
> pasted here for your convenience:
>
>  [...]
> 
> That's the level at which we need to address domain names, not the
> content of the certificate.

Thinking about it, I might need to clarify and adjust my position about
"PKIX validation" being unrelated to "server endpoint identification".

While technically independent, there are certainly assumptions made
on the part of the issuing CA and on the part of PKIX (at least those
who still believe that Name Constraints are not a complete failure).

If we allow skipping of the traditional server endpoint identification
for type 1 certificates, then we would be actively creating new
security problems and nullify the security value of commercial
SSL certificates and the RA process behind it for TLS clients that
implement DANE.

Picture this:
  - a TLS client with the intention to connect to
    https://www.higlytrustedbank.x-z-z
  - being MiTMed by an attacker, who is in posession of
    a real server cert for https://www.realbadguy.x-y-y
    from a commercial CA.

If we specify that traditional server endpoint matching is to
be skipped when a DANE TLSA record for a type 1 certificate
with a completely different server name exists, then we're
completely subverting the original TLS X.509 PKI trust model
for TLS clients that implement DANE.

Personally, I really do _not_ like that idea.  DANE adds value
when both checks are performed.  Doing the orginial (PKIX-based)
server endpoint identification only half-assed IMHO renders
the type 1 certificates useless.

-Martin

Re: [dane] #13: Server name check for certificate… dane issue tracker
Re: [dane] #13: Server name check for certificate… Zack Weinberg
Re: [dane] #13: Server name check for certificate… Paul Hoffman
Re: [dane] #13: Server name check for certificate… Richard Barnes
Re: [dane] #13: Server name check for certificate… Paul Wouters
Re: [dane] #13: Server name check for certificate… Zack Weinberg
Re: [dane] #13: Server name check for certificate… Paul Hoffman
Re: [dane] #13: Server name check for certificate… Paul Hoffman
Re: [dane] #13: Server name check for certificate… Zack Weinberg
Re: [dane] #13: Server name check for certificate… Martin Rex
Re: [dane] #13: Hostnames in Certificates (was: S… dane issue tracker
Re: [dane] #13: Server name check for certificate… Richard Barnes
Re: [dane] #13: Server name check for certificate… Martin Rex
Re: [dane] #13: Server name check for certificate… Richard Barnes
Re: [dane] #13: Server name check for certificate… Martin Rex
Re: [dane] #13: Server name check for certificate… Richard Barnes
Re: [dane] #13: Server name check for certificate… Warren Kumari
Re: [dane] #13: Hostnames in Certificates dane issue tracker