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.