Re: [dane] Review of DANE SMTP draft

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 18 March 2014 21:09 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 EAFF81A0417 for <dane@ietfa.amsl.com>; Tue, 18 Mar 2014 14:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 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] 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 Ln8FhQ64TR_v for <dane@ietfa.amsl.com>; Tue, 18 Mar 2014 14:09:25 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B4A971A0421 for <dane@ietf.org>; Tue, 18 Mar 2014 14:09:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1395176956; d=isode.com; s=selector; i=@isode.com; bh=xPfVzLJbenTJxT0Ih65AuiFkYJ4RLQ4yn8/fJaZSc7k=; 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=Kz0HzWM8jV0AYSYHV5df6etxMLpaZZPP9o4iceUgX6sRFaJp6vz9yoUjr91e29IwgLJ/L+ 7Zq2RNeI+LMFAjtD6YAXFCL7oT4spqrJFPrwqmohM+0fqYAisNgUUoyFgizBPgqmH+vp5l 7+ycFYKp0vIXc61R1RZfjASzA1WJS2Q=;
Received: from [192.168.0.12] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <Uyi1=ABIqT8W@statler.isode.com>; Tue, 18 Mar 2014 21:09:16 +0000
X-SMTP-Protocol-Errors: PIPELINING
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: iPad Mail (11B651)
In-Reply-To: <20140314174101.GU21390@mournblade.imrryr.org>
Date: Tue, 18 Mar 2014 21:13:59 +0000
Cc: "dane@ietf.org" <dane@ietf.org>
Message-Id: <AA4EBC07-2215-4539-A60F-2D62CCFEF2F4@isode.com>
References: <C28AB0DE-0391-4EA3-8312-DC2D2F7FD167@isode.com> <20140314052342.GQ21390@mournblade.imrryr.org> <53233939.9020703@isode.com> <20140314174101.GU21390@mournblade.imrryr.org>
To: "dane@ietf.org" <dane@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qNrBEyVmNXIPog_fCYUFOKHCpeU
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: Tue, 18 Mar 2014 21:09:32 -0000

Hi Victor,

> On 14 Mar 2014, at 17:41, Viktor Dukhovni <viktor1dane@dukhovni.org>; wrote:
> 
> On Fri, Mar 14, 2014 at 05:15:37PM +0000, Alexey Melnikov wrote:
> 
>>> [ 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.
> 
> The original sentence reads:
> 
>    Similarly, when an MX RRset incorrectly lists a network address in
>    lieu of an MX hostname, if the MTA chooses to connect to the network
>    address, DANE TLSA does not apply for such a connection.
> 
> Anyone else feel this deserves an example?  There are some poor
> sods who attempt to stuff IPv4 addresses into MX hostname RRDATA,
> and some MTAs may do them a favour and handle this broken syntax.
> In that case DANE is clearly out of scope.

Ok, after thinking more about this, your current text looks Ok as is.
> 
>>> 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.
> 
> No, the SMTP and SRV drafts specify that the client has multiple
> names it is willing to accept, any one of which may match one of
> the many SAN names in the peer certificate.  There can be up to
> three names.  The original name before redirection by MX or SRV,
> the securely CNAME expanded version of that if different, and
> finally the TLSA base domain of the server.

RFC 6125 allows for that, so I see no conflict.
> 
>>> 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.
> 
> That is Postini fix their mess?

Yes.

> Or SMTP support multi-label wildcards?

I suppose this might be another reasonable outcome, if we can get IETF consensus on this.