Re: [dane] Review of DANE SMTP draft
Alexey Melnikov <alexey.melnikov@isode.com> Fri, 14 March 2014 17:14 UTC
Return-Path: <alexey.melnikov@isode.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 6A0521A018B for <dane@ietfa.amsl.com>; Fri, 14 Mar 2014 10:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.223
X-Spam-Level: **
X-Spam-Status: No, score=2.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 fCF_CTAYUp-8 for <dane@ietfa.amsl.com>; Fri, 14 Mar 2014 10:14:55 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id C57291A0170 for <dane@ietf.org>; Fri, 14 Mar 2014 10:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1394817286; d=isode.com; s=selector; i=@isode.com; bh=dq0EL4D3aKX+mpI8C05R6yOI3vDvJalTPwpyrVlJ/VE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=L6ElVdOqWUC8qozlXb4En7jqqKrZPTQv1gsZp7BamSr6qc461Gm/JE0NpS17XzGcQkp1vI TYhNgzBGKGtOIkH9iSqb04zJSJdusXaIACtT0uum2Iggm9MrHY+5zR0Hh7vaLDmuusHDOa MF7DRix/AWMAtx93pYPjDPSAbJikGEE=;
Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id <UyM5BgBvgTfJ@statler.isode.com>; Fri, 14 Mar 2014 17:14:46 +0000
Message-ID: <53233939.9020703@isode.com>
Date: Fri, 14 Mar 2014 17:15:37 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
To: dane@ietf.org
References: <C28AB0DE-0391-4EA3-8312-DC2D2F7FD167@isode.com> <20140314052342.GQ21390@mournblade.imrryr.org>
In-Reply-To: <20140314052342.GQ21390@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xOP-2HbRcZmPWSW6RzFRKXlI63Y
Subject: Re: [dane] Review of DANE SMTP draft
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 17:14:57 -0000
On 14/03/2014 05:23, Viktor Dukhovni wrote: > 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. Ok. >> 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. Ok. >> 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. No, it is not obvious, otherwise I wouldn't have asked. > 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. I am not sure I understand. If there are multiple subjectAltName values of the same type, any match works. Unless you mean something else. > 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, I think so, yes. > 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 general, I prefer when references are repeated. >> 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. I think your current text can be misinterpreted that such validation is allowed. Use of normative language didn't help. I think I interpreted some of the requirements as applying to SMTP clients, where they applied to ISPs. > 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. Thank you. >> 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). Ok. If you are departing from RFC 5280, they you should state all new requirements.
- 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