Re: [dane] Review of DANE SMTP draft

mrex@sap.com (Martin Rex) Mon, 17 March 2014 22:34 UTC

Return-Path: <mrex@sap.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027F11A032C for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 15:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.781
X-Spam-Level:
X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SPOOF_COM2COM=2.048, SPOOF_COM2OTH=2.723] 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 O4RZ2d5AswbQ for <dane@ietfa.amsl.com>; Mon, 17 Mar 2014 15:34:16 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F2C461A0322 for <dane@ietf.org>; Mon, 17 Mar 2014 15:34:15 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s2HMY7iu020059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dane@ietf.org>; Mon, 17 Mar 2014 23:34:07 +0100 (MET)
In-Reply-To: <20140315024203.GW21390@mournblade.imrryr.org>
To: dane@ietf.org
Date: Mon, 17 Mar 2014 23:34:07 +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: <20140317223407.679571AC59@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/QX-ZVojLlVQz4q6fBpP4nTo_uj0
Subject: Re: [dane] Review of DANE SMTP draft
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Mar 2014 22:34:18 -0000

Viktor Dukhovni wrote:
> On Fri, Mar 14, 2014 at 09:01:48PM -0400, James Cloos wrote:
> 
>>> The folks at Postini have a wildcard cert for "*.psmtp.com" and
>>> clients publish MX records of the form:
>>>
>>>   verisign.com.           IN      MX      100 verisign.com.s6a1.psmtp.com.
>>>   verisign.com.           IN      MX      200 verisign.com.s6a2.psmtp.com.
>>>   verisign.com.           IN      MX      300 verisign.com.s6b1.psmtp.com.
>>>   verisign.com.           IN      MX      400 verisign.com.s6b2.psmtp.com.
>> 
>> For some historical context, mozilla's original wildcarded ssl implement-
>> ation also allowed an *. to match any number of labels.
>> 
>> Several sites were broken by the change to limit a wildcard to a single label.
> 
> I take it you're suggesting to not perpetuate Postini's abuse of
> wildcard certs?  Implementations might choose to be more liberal,
> but servers can't expect multi-label wildcard support.  Right?

See:

 http://tools.ietf.org/html/rfc6125#section-6.4.3

   6.4.3.  Checking of Wildcard Certificates

   A client employing this specification's rules MAY match the reference
   identifier against a presented identifier whose DNS domain name
   portion contains the wildcard character '*' as part or all of a label
   (following the description of labels and domain names in
   [DNS-CONCEPTS]).

   For information regarding the security characteristics of wildcard
   certificates, see Section 7.2.

   If a client matches the reference identifier against a presented
   identifier whose DNS domain name portion contains the wildcard
   character '*', the following rules apply:

   1.  The client SHOULD NOT attempt to match a presented identifier in
       which the wildcard character comprises a label other than the
       left-most label (e.g., do not match bar.*.example.net).

   2.  If the wildcard character is the only character of the left-most
       label in the presented identifier, the client SHOULD NOT compare
       against anything but the left-most label of the reference
       identifier (e.g., *.example.com would match foo.example.com but
       not bar.foo.example.com or example.com).

   3.  The client MAY match a presented identifier in which the wildcard
       character is not the only character of the label (e.g.,
       baz*.example.net and *baz.example.net and b*z.example.net would
       be taken to match baz1.example.net and foobaz.example.net and
       buzz.example.net, respectively).  However, the client SHOULD NOT
       attempt to match a presented identifier where the wildcard
       character is embedded within an A-label or U-label [IDNA-DEFS] of
       an internationalized domain name [IDNA-PROTO].


-Martin