Re: [certid] Review of draft-saintandre-tls-server-id-check
Martin Rex <mrex@sap.com> Mon, 13 September 2010 17:48 UTC
Return-Path: <mrex@sap.com>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id D9A533A69F9 for <certid@core3.amsl.com>;
Mon, 13 Sep 2010 10:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.857
X-Spam-Level:
X-Spam-Status: No, score=-9.857 tagged_above=-999 required=5 tests=[AWL=0.392,
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 8JwnRB7mc-G0 for
<certid@core3.amsl.com>; Mon, 13 Sep 2010 10:48:07 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by
core3.amsl.com (Postfix) with ESMTP id 5F0D43A6A1A for <certid@ietf.org>;
Mon, 13 Sep 2010 10:48:07 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id
o8DHmW9e018571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
verify=OK) for <certid@ietf.org>; Mon, 13 Sep 2010 19:48:32 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201009131748.o8DHmLmE021207@fs4113.wdf.sap.corp>
Orig-To: shuque@isc.upenn.edu (Shumon Huque)
To: certid@ietf.org
Date: Thu, 9 Sep 2010 23:10:35 +0200 (MEST)
In-Reply-To: <20100908195349.GA4292@isc.upenn.edu> from "Shumon Huque" at Sep
8, 10 03:53:49 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: mrex@sap.com
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: bernard_aboba@hotmail.com, certid@ietf.org, ietf@ietf.org
Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Representation and verification of identity in certificates
<certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2010 17:48:09 -0000
Shumon Huque wrote: > > On Wed, Sep 08, 2010 at 08:44:56AM -0700, Bernard Aboba wrote: > > > > If the "reference identifier" is _Service.Name then the match is being done > > on the *input* to the SRV lookup process, not the output, and prohibition on > > DNS lookups would not apply (or even make any sense). > > Yes. > > The output of the SRV record lookup contains a target hostname, > not a service name, so it's not applicable to the SRVName name > form. The target could be used in another name form (dNSName) > as the reference identifier, but then the client needs to convince > itself that the lookup was done securely (DNSSEC or some other > means) otherwise there's a security problem. I'm feeling very uneasy with the suggestion that a DNSSEC instead of the DNS lookup might make it less of a security problem. DNSSEC provides only data integrity protection and data origin authentication of the records, and NOTHING beyond that. In particular, it does _NOT_ provide any trust in the conveyed information. But in order to avoid the mentioned security problem, trust in the transformation is an absolute prerequisite for the name transformation in order to use the result in any kind of endpoint identity verification. Although I personally think the trustworthiness of the rootCA certs in web browsers is significantly overrated, there seems to be some understanding out there that there is a huge difference between cryptographic protection and trust, so there are browser vendors that require CAs to apply a certain amount of scrutiny before issuing certificates and subject themselves to an audit for a non-negligable amount of cost before the browser vendors are going to include the CAs self-signed rootCA cert as pre-trusted with their browser. Are DNS domain admins going to be required to apply as much scrutiny for each and every DNS record in their zone and have to succeed a comparable audit of their DNS record maintenance procedures before their parent domain will sign their zone signing keys? DNS is an important an vital part of the internet, and it needs to remain fast, efficient and free in order to remain useful. Besides, even if DNSSEC signed records are being made available in increasing numbers, that information is not visible to >90% of the end users of the internet (like DSL subscribers) and is going to remain invisible for most of them for many years to come. -Martin
- [certid] Fwd: Review of draft-saintandre-tls-serv… Paul Hoffman
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Bernard Aboba
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… James Schaad
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Paul Hoffman
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Richard L. Barnes
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Martin Rex
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] [TLS] Review of draft-saintandre-tls… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] [TLS] Review of draft-saintandre-tls… James Schaad
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- [certid] Why require EKU for certid? Paul Hoffman
- Re: [certid] Why require EKU for certid? Peter Saint-Andre
- Re: [certid] [TLS] Why require EKU for certid? Jim Schaad
- Re: [certid] Why require EKU for certid? Martin Rex
- Re: [certid] Why require EKU for certid? Henry B. Hotz
- [certid] CN-ID and name constraints Matt McCutchen
- Re: [certid] CN-ID and name constraints Martin Rex
- Re: [certid] CN-ID and name constraints Matt McCutchen
- Re: [certid] CN-ID and name constraints Martin Rex
- Re: [certid] CN-ID and name constraints Matt McCutchen
- Re: [certid] CN-ID and name constraints (oops) Matt McCutchen
- Re: [certid] CN-ID and name constraints Matt McCutchen
- Re: [certid] Why require EKU for certid? Peter Saint-Andre
- Re: [certid] CN-ID and name constraints Peter Saint-Andre
- Re: [certid] CN-ID and name constraints Jim Schaad
- Re: [certid] Why require EKU for certid? Peter Saint-Andre
- Re: [certid] Why require EKU for certid? Paul Hoffman
- Re: [certid] Why require EKU for certid? Stefan Santesson
- Re: [certid] Why require EKU for certid? Paul Hoffman
- Re: [certid] Why require EKU for certid? Martin Rex
- Re: [certid] Why require EKU for certid? Stefan Santesson
- Re: [certid] Why require EKU for certid? Peter Saint-Andre
- Re: [certid] Why require EKU for certid? Peter Saint-Andre
- Re: [certid] CN-ID and name constraints Peter Saint-Andre
- Re: [certid] CN-ID and name constraints Jim Schaad
- Re: [certid] CN-ID and name constraints Carl Wallace