Re: [certid] Fwd: secdir review of

Martin Rex <mrex@sap.com> Thu, 16 September 2010 05:27 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 9D3A13A6879 for <certid@core3.amsl.com>; Wed, 15 Sep 2010 22:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.535
X-Spam-Level:
X-Spam-Status: No, score=-9.535 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, 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 2hgTJeulCQdE for <certid@core3.amsl.com>; Wed, 15 Sep 2010 22:27:30 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C8A103A67E1 for <certid@ietf.org>; Wed, 15 Sep 2010 22:27:29 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o8G5RrWH011417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Sep 2010 07:27:53 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201009160527.o8G5RoxM013370@fs4113.wdf.sap.corp>
To: stpeter@stpeter.im (Peter Saint-Andre)
Date: Thu, 16 Sep 2010 07:27:50 +0200 (MEST)
In-Reply-To: <4C912A86.3040402@stpeter.im> from "Peter Saint-Andre" at Sep 15, 10 02:20:22 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
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 05:27:31 -0000

Peter Saint-Andre wrote:
> 
> -- Page 22, sec 5.1:
>    When the connecting application is an interactive client, the source
>    domain name and service type MUST be provided by a human user (e.g.
>    when specifying the server portion of the user's account name on the
>    server or when explicitly configuring the client to connect to a
>    particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
>    the user inputs in an automated fashion (e.g., a host name or domain
>    name discovered through DNS resolution of the source domain).  This
>    rule is important because only a match between the user inputs (in
>    the form of a reference identifier) and a presented identifier
>    enables the client to be sure that the certificate can legitimately
>    be used to secure the connection.
> 
> Does this mean that a client specifically designed for the "gumbo"
> service can't automatically use the service type "gumbo", without the
> user's involvement?

The current wording does not seem to adequately illustrate the
characteristics that are important here.

"MUST NOT be derived from the user inputs in an automated fashion"
could be very misleading.  The real problem is with using using
information from untrusted sources or performing transformations
of (originally user-supplied or user-confirmed) untrusted information
prior to matching the server endpoint.

There are situations where the implicit assertion of the
protocol "gumbo" is fully aligned with the intention of the user
and is safe to use for matching SRV-IDs. s/gumbo/xmpp/g  wash,rinse,repeat.

Clearly unsafe operations:

  - building a reference identifier from the result of a
    DNS CNAME lookup (the use of DNSSEC does not make this safe)

  - retrieving the URL to a HTTPS resource from a HTML page
    that was loaded through HTTP based on information provided by the user.



>
>                      Or that a client put out by example.net can't
> assume a host name of services.example.net in the absence of user
> input that says otherwise?

It depends.
It is OK when it is sufficiently aligned with the users intention
(although some users may not be fully aware of all technical details).


> 
> Further, it's entirely reasonable for a program to have a user enter
> something like "gmail", and have the client turn that into something
> like "mail.google.com", deriving it from the user's input in an
> automated fashion.  Do we really want to forbid that sort of thing?

That should be fine as long at it is sufficiently aligned with the
users intention and this translation is based purely on trusted sources
of information and protected access to these information sources.

This precludes both, DNS and DNSSEC lookups.

Sufficiently protected local configuration options or protected local
mappings should be fine. (meaning protected from changes without
explicit consent and awareness of the user).



-Martin