Re: [certid] Fwd: secdir review of

Martin Rex <mrex@sap.com> Thu, 16 September 2010 15:33 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 CADD73A6B64 for <certid@core3.amsl.com>; Thu, 16 Sep 2010 08:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.836
X-Spam-Level:
X-Spam-Status: No, score=-9.836 tagged_above=-999 required=5 tests=[AWL=0.413, 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 BEK0CSGAYnqn for <certid@core3.amsl.com>; Thu, 16 Sep 2010 08:33:37 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 8F72E3A6B83 for <certid@ietf.org>; Thu, 16 Sep 2010 08:33:25 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8GFXmPg027004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Sep 2010 17:33:48 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201009161533.o8GFXlAG016810@fs4113.wdf.sap.corp>
To: matt@mattmccutchen.net (Matt McCutchen)
Date: Thu, 16 Sep 2010 17:33:47 +0200 (MEST)
In-Reply-To: <1284615555.5722.92.camel@mattlaptop2.local> from "Matt McCutchen" at Sep 16, 10 01:39:15 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: certid@ietf.org
Subject: Re: [certid] Fwd: secdir review of
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: Thu, 16 Sep 2010 15:33:42 -0000

Matt McCutchen wrote:
> 
> On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote:
> > Clearly unsafe operations:
> > 
> >   - building a reference identifier from the result of a
> >     DNS CNAME lookup
> > 
> > (the use of DNSSEC does not make this safe)
> 
> Why not?  I'm not saying it's good practice, but I don't see an actual
> vulnerability.

You need two characteristics:

  (1) trustworty information source for a name transformation
  (2) protected access to this trustworthy source

DNSSEC meets (2) but not (1)

DNSSEC provides only data integrity protection and data origin
authentication for the distribution of the informtion, it has
zero impact on the quality, accuracy and trustworthyness of
the underlying information source.

If Wikipedia enables TLS on their web-servers tomorrow so
that you can access it through https://www.wikipedia.org/
what impact will this have on the trustworthyness of the
information in Wikipedia articles?

When there is not change to how others can can access wikipedia
and edit the information there, the impact of you using
TLS to access wikipedia will have exactly zero _impact_ on
the trustworthyness of the information in wikipedia.


-Martin