Re: [certid] Fwd: secdir review of

Martin Rex <mrex@sap.com> Thu, 16 September 2010 22:34 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 B1B323A6A0C for <certid@core3.amsl.com>; Thu, 16 Sep 2010 15:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.849
X-Spam-Level:
X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.400, 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 Zdi+8NQEtVv8 for <certid@core3.amsl.com>; Thu, 16 Sep 2010 15:34:01 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 5CCE83A69F3 for <certid@ietf.org>; Thu, 16 Sep 2010 15:34:01 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8GMYPNv017695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Sep 2010 00:34:25 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201009162234.o8GMYJZg010452@fs4113.wdf.sap.corp>
To: mrex@sap.com
Date: Fri, 17 Sep 2010 00:34:19 +0200 (MEST)
In-Reply-To: <201009161533.o8GFXlAG016810@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 16, 10 05:33:47 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: 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 22:34:02 -0000

Cleanup of my prior message:

 
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 the information source

DNSSEC meets (2) but not (1)

DNSSEC provides only data integrity protection and data origin
authentication for the distribution of the informtion.  The
use of DNSSEC for distribution of DNS data has zero impact on
the quality, accuracy and trustworthyness of the underlying
DNS 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 no change to how others can access wikipedia
and edit the content, your selection of accessing Wikipedia
through HTTPS instead of HTTP will have exactly _zero_ impact
on the trustworthyness of the information in wikipedia articles.

-Martin