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
- Re: [dane] Review of DANE SMTP draft Viktor Dukhovni
- Re: [dane] Review of DANE SMTP draft Alexey Melnikov
- [dane] Review of DANE SMTP draft Alexey Melnikov
- Re: [dane] Review of DANE SMTP draft Viktor Dukhovni
- Re: [dane] Review of DANE SMTP draft Lawrence Conroy
- Re: [dane] Review of DANE SMTP draft Viktor Dukhovni
- Re: [dane] Review of DANE SMTP draft James Cloos
- Re: [dane] Review of DANE SMTP draft Viktor Dukhovni
- Re: [dane] Review of DANE SMTP draft James Cloos
- Re: [dane] Review of DANE SMTP draft Martin Rex
- Re: [dane] Review of DANE SMTP draft Viktor Dukhovni
- Re: [dane] Review of DANE SMTP draft Alexey Melnikov