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

Jeffrey Walton <noloader@gmail.com> Sat, 21 February 2015 22:18 UTC

Return-Path: <noloader@gmail.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 009A41A00F4 for <pkix@ietfa.amsl.com>; Sat, 21 Feb 2015 14:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 IGKgUJWAPRaX for <pkix@ietfa.amsl.com>; Sat, 21 Feb 2015 14:17:58 -0800 (PST)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9801A00F3 for <pkix@ietf.org>; Sat, 21 Feb 2015 14:17:58 -0800 (PST)
Received: by mail-ig0-f171.google.com with SMTP id h15so10677189igd.4 for <pkix@ietf.org>; Sat, 21 Feb 2015 14:17:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kzezk9fMJt/2J2Qnkdys3C0dbj1uRGCHbk4wVIiHDe0=; b=CwtrnQfCeXZIXWvKEhhqRUMmu66Ly9TJo8kgEzgmD85Cp6amSGK0V63Isw1R1qTrpm 2UHOLF2+CBbLw5f5FIK8fuZAFziMwU9EAFfOf4I+KWrPrL/VdeZ2MOv2Y/t00pcl+Nlv K+cWcYNxp9VUQeGMn6qxepJFqYCRnfwZxho5hnBXlwGX1rc+Z56q9owRAolzm7Nydh9P AS2q2unhWWxA1GnxakU9peKxKXbOyrXgRJonQI2CfUuCc0ss3QndtklCd8T5v3ZdID0K euBAL79IOvjNpL7Jz8HH6ihdH1j4apxz4OQlhixmoRoDlTf3jtbnz2K2eY3Md7NkZKoW kyyA==
MIME-Version: 1.0
X-Received: by 10.107.35.140 with SMTP id j134mr5514791ioj.11.1424557077623; Sat, 21 Feb 2015 14:17:57 -0800 (PST)
Received: by 10.36.81.15 with HTTP; Sat, 21 Feb 2015 14:17:57 -0800 (PST)
In-Reply-To: <20150202123454.4BD661B14C@ld9781.wdf.sap.corp>
References: <CAH8yC8k0mD4J9cSdryVytUCs=jvV4xAv0ogBO+42Y5SFkucegw@mail.gmail.com> <20150202123454.4BD661B14C@ld9781.wdf.sap.corp>
Date: Sat, 21 Feb 2015 17:17:57 -0500
Message-ID: <CAH8yC8mUX8LUc9M=NenJgD4VmY3HAbGxAcpyVJRztwxZ0PXDKw@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/mdrnkq4xaX-lR5r9APOMM_jC3OA>
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: noloader@gmail.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: Sat, 21 Feb 2015 22:18:00 -0000

Thanks Martin.

> 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.

Isn't this the equivalent problem issuing certificates via domain
validation from the WHOIS database? That is, the data can be sent
securely (for some definition of secure), but we're not sure the data
itself is accurate?

If they are equivalent, then why do we accept certificates based on
domain validation from the WHOIS database?

It seems to me both should be accepted, or both should be rejected.

Jeff

On Mon, Feb 2, 2015 at 7:34 AM, Martin Rex <mrex@sap.com> wrote:
> 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).