Re: [dane] Review of DANE SMTP draft
Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 14 March 2014 05:23 UTC
Return-Path: <viktor1dane@dukhovni.org>
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 E7CE51A0035 for <dane@ietfa.amsl.com>; Thu, 13 Mar 2014 22:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.871
X-Spam-Level: **
X-Spam-Status: No, score=2.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPOOF_COM2COM=2.048, SPOOF_COM2OTH=2.723] autolearn=no
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 Bn9J88Tvnl_Q for <dane@ietfa.amsl.com>; Thu, 13 Mar 2014 22:23:50 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 90F0C1A002F for <dane@ietf.org>; Thu, 13 Mar 2014 22:23:50 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3EB072AADF5; Fri, 14 Mar 2014 05:23:42 +0000 (UTC)
Date: Fri, 14 Mar 2014 05:23:42 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140314052342.GQ21390@mournblade.imrryr.org>
References: <C28AB0DE-0391-4EA3-8312-DC2D2F7FD167@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C28AB0DE-0391-4EA3-8312-DC2D2F7FD167@isode.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/B20JRnO1KaEGMvxAt3KxH7Bud9M
Subject: Re: [dane] Review of DANE SMTP draft
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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: Fri, 14 Mar 2014 05:23:53 -0000
On Thu, Mar 06, 2014 at 01:44:17PM +0000, Alexey Melnikov wrote: > In the terminology section: what about no MX record case (A or AAAA only)? Thanks. This was a global replace error. The term used to define "MX Host". All of its occurrences got replaced with "SMTP server", no longer specific to MX hosts of domains, but the terminology is now wrong. I am going to just delete this dangling definition. > In 1.3.1: why mention SMTP URIs? How would introduction of such > URIs help with securing SMTP? I suggest you just mention that there > is no signalling of "secure" SMTP. There are no URIs and none are desired. This is an attempt at a contrast with HTTP, and yes the point is that there is no signalling of HOP by hop security policy in the envelope address (which is more of a feature than a bug). I'm tweaking the text to talk about signalling more explicitly, rather than a hypothetical URI scheme. > In 2.2: Network address instead of MX hostname - I think this > deserves an example. [ Second-last paragraph of 2.2 ] Is it not obvious that this means the misguided: example.com. IN MX 0 192.0.2.1. I am not adding this yet, do others feel this really warrants more text? > In 2.2.3 (page 17, 3rd from the last para): and possibly other places: > TLS server certificate matching rules should be fully specified. Use RFC > 6125 (for example look at draft-melnikov-email-tls-certs-01) or specify > the rules directly. In 6125 (where the exceptions dominate the rules) there are no provisions for matching one of a set of candidate names. So, I guess, we should be more explicit about the wildcard matching (perhaps generically in the SRV draft) and otherwise defer to 6125 for international domain names, Subject commonName vs. subjectAltName:DNS, etc. FWIW Postfix by default (Postini work-around) supports wildcard certificates that match multiple DNS labels: http://www.postfix.org/postconf.5.html#tls_wildcard_matches_multiple_labels 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. I have not given much thought to writing DANE-specific rules for SMTP TLS with respect to the mechanics of matching of any particular candidate name against the certificate. (To be honest, I did not need to write any new code for this, since name matching is handled in Postfix TLS policy generically for DANE and PKIX. The existing PKIX code was already flexible enough to do all the work, so this did not cross my radar). In https://tools.ietf.org/html/rfc6125#appendix-B.4 we have matching with just "*" as a wildcard (no "foo*.example.com" or "*foo.example.com") and only for a single label. While SMTP-AUTH forbids chasing CNAMEs insecurely, it only works well for MSA hosts, not MX hosts which already lose after insecure MX delegation. With DANE we have a secure TLSA base domain, so this does not apply. I don't know whether the Postfix (on by default) Postini work-around deserves IETF blessing. Perhaps it would be better for Postini to fix their certificates, or if they ever deploy DANE to publish only DANE-EE(3) certs, which make the question moot. I don't know whether any other sites are attempting to use SMTP with wildcard certs for multi-label sub-domains. There is not enough authenticated TLS happening for SMTP today to know what's out there in the wild. > Page 22, 3rd para: please add reference for the SNI TLS extension (a > Normative reference, because you use normative language when referencing > the extension) and various versions of TLS. RFC 6066 is referenced on page 6 (second last paragraph) and appears in the References section. Should the reference be repeated on page 22? > In 2.3.3: it is not clear whether the client needs to check that for every > record covered by the WORSE hash there is a corresponding record covered > by the BETTER hash. This is not possible. The records don't carry separate "instance" identifiers that allow one to identify all the TLSA records of a single certificate or public key. The various digest algorithms are not invertible! All that the client can check is that the number of records for the best algorithm is the same as that for all other algorithms within each combination of usage and selector. We may need a separate thread on pinning down algorithm agility (unless it is good enough as-is, perhaps with clarifications if the intent is not completely clear). > In Section 3, last para: add "or bounced", as this can be more serious > than just being delayed. Fine. > In 4.2, last para: did you mean "SHOULD"? Perhaps so, though this may hold up publication of the SMTP draft until the "ops" draft is also done. We could cut/paste the relevant text, or move it to the more generic SRV draft. Ultimately, there is a real need for DANEbis, but it looks like it won't move forward until there are more published and deployed protocols, so we'll all be parroting the "missing" text in multiple drafts, or perhaps the normative text from "ops" can be published as a standards track "clarifications" to 6698? Any suggestions from the chairs? > I've heard Not checking expiration dates in certificate - I don't think > this was mentioned in the document. This is in the "ops" draft, but I'll add it to the description in the SMTP draft, after we figure out exactly what should be ignored in DANE-EE(3) certs (and possibly DANE-TA(2) SPKI(1) trust anchor certs). (Separate thread on this soon). -- Viktor.
- 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