Re: [dane] Review of DANE SMTP draft
Lawrence Conroy <lconroy@insensate.co.uk> Fri, 14 March 2014 19:34 UTC
Return-Path: <lconroy@insensate.co.uk>
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 B2A4C1A00A9 for <dane@ietfa.amsl.com>; Fri, 14 Mar 2014 12:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, 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 kM7s4D5_hai5 for <dane@ietfa.amsl.com>; Fri, 14 Mar 2014 12:34:52 -0700 (PDT)
Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id CFAB21A0092 for <dane@ietf.org>; Fri, 14 Mar 2014 12:34:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 12D3A143C8B9 for <dane@ietf.org>; Fri, 14 Mar 2014 19:34:44 +0000 (GMT)
Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rys0LQC-3mrC for <dane@ietf.org>; Fri, 14 Mar 2014 19:34:43 +0000 (GMT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id 16DE6143C8AE for <dane@ietf.org>; Fri, 14 Mar 2014 19:34:43 +0000 (GMT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1085)
From: Lawrence Conroy <lconroy@insensate.co.uk>
In-Reply-To: <20140314174101.GU21390@mournblade.imrryr.org>
Date: Fri, 14 Mar 2014 19:34:42 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <FD33C78A-D442-4654-86AE-863675262A83@insensate.co.uk>
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
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AA67TVZmrGwX5JuKdodEQnLrLDs
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 19:34:54 -0000
Hi Viktor, Alexey, folks, Please, please, please do NOT give invalid/incorrect examples (even as examples of what NOT to do). Viktor: The text you have seems pretty obvious to me on reading. To nail it in with a hammer, maybe c/when an MX RRset incorrectly lists a network address in lieu of an MX hostname, if the MTA chooses/Even though this form is invalid, some MX RRsets may be encountered that list a network address in lieu of an MX hostname. If the MTA nevertheless chooses/ (but that really is smashing the point home). Now back to lurking. all the best, Lawrence On 14 Mar 2014, at 17:41, Viktor Dukhovni 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. > >>> 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. > >>> 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? Or SMTP support multi-label > wildcards? > >>> 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. > > We can do that. There is clearly sufficient distance between page > 6, and page 22, for the reference not to appear repetitive. > >>>> 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. > > What do you mean by "such validation is allowed"? Would you mind > starting a new thread with questions specifically about the digest > agility part of the SMTP draft? This mechanism is not intended to > be SMTP-specific, and should some day make it into DANEbis via the > SRV draft as a first hop perhaps (unless it should be its own > stand-alone draft on just digest agility for DANE). > >>>> 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. > > Yes. > > -- > Viktor. > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane
- 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