Re: [pkix] RFC 6125, Server Identity Check and insecure DNS lookup

mrex@sap.com (Martin Rex) Mon, 02 February 2015 12:34 UTC

Return-Path: <mrex@sap.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4121A028A for <pkix@ietfa.amsl.com>; Mon, 2 Feb 2015 04:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level:
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rFVFkjsah95 for <pkix@ietfa.amsl.com>; Mon, 2 Feb 2015 04:34:57 -0800 (PST)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9141A0277 for <pkix@ietf.org>; Mon, 2 Feb 2015 04:34:56 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 5B1C3444EE; Mon, 2 Feb 2015 13:34:54 +0100 (CET)
X-purgate-ID: 152705::1422880494-00003099-9389FDD1/0/0
X-purgate-size: 1308
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 51F8C421C0; Mon, 2 Feb 2015 13:34:54 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 4BD661B14C; Mon, 2 Feb 2015 13:34:54 +0100 (CET)
In-Reply-To: <CAH8yC8k0mD4J9cSdryVytUCs=jvV4xAv0ogBO+42Y5SFkucegw@mail.gmail.com>
To: noloader@gmail.com
Date: Mon, 02 Feb 2015 13:34:54 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150202123454.4BD661B14C@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/8UCeo7KuhIPIxfwPZlE3LoRDlIM>
Cc: PKIX <pkix@ietf.org>
Subject: Re: [pkix] RFC 6125, Server Identity Check and insecure DNS lookup
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 12:34:59 -0000

Jeffrey Walton wrote:
> What does RFC 6125 mean when they say the following:
> 
>    2.4.  Server Identity Check
> 
>    o  The client MUST use the server hostname it used to open the
>       connection as the value to compare against the server name as
>       expressed in the server certificate.  The client MUST NOT use any
>       form of the server hostname derived from an insecure remote source
>       (e.g., insecure DNS lookup).  CNAME canonicalization is not done.
> 
> Is this saying that all DNS is considered insecure, and only the
> original hostname used by the client should be used for validation?
> 
> Or is it saying its OK to follow the CNAME aliases when using a
> "secure" DNS, like DNSSEC?


The difference here is "lack of trust" in the data contained in DNS.

The two characteristics that DNSSEC provides (according to its own
specification) is data origin authentication and data integrity protection.
But using DNSSEC does not increase the trustworthyness of the data
conveyed through DNS.

Similarily using HTTPS rather than HTTP for searching Google will provide 
only data origin authentication and data integrity protection for the
search results, but will not increase the trustworthyness of the
search results (there is no trust).


-Martin