Re: Review of draft-saintandre-tls-server-id-check

Martin Rex <mrex@sap.com> Thu, 09 September 2010 21:11 UTC

Return-Path: <mrex@sap.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9FE33A6940 for <ietf@core3.amsl.com>; Thu, 9 Sep 2010 14:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.85
X-Spam-Level:
X-Spam-Status: No, score=-9.85 tagged_above=-999 required=5 tests=[AWL=0.399, 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 QdzdKl3-gY7b for <ietf@core3.amsl.com>; Thu, 9 Sep 2010 14:10:47 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id DCE7C3A68C7 for <ietf@ietf.org>; Thu, 9 Sep 2010 14:10:33 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o89LAa47016312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Sep 2010 23:10:36 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201009092110.o89LAZES029497@fs4113.wdf.sap.corp>
Subject: Re: Review of draft-saintandre-tls-server-id-check
To: shuque@isc.upenn.edu
Date: Thu, 09 Sep 2010 23:10:35 +0200
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
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: bernard_aboba@hotmail.com, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Sep 2010 21:11: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