Re: [dane] draft-fanf-dane-smtp

Tony Finch <dot@dotat.at> Sun, 03 June 2012 17:08 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q53H889q097175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jun 2012 10:08:08 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.5/8.13.5/Submit) id q53H88ft097174; Sun, 3 Jun 2012 10:08:08 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q53H86wP097168 for <ietf-smtp@imc.org>; Sun, 3 Jun 2012 10:08:07 -0700 (MST) (envelope-from fanf2@hermes.cam.ac.uk)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:36978) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1SbEHb-0007ov-EZ (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Sun, 03 Jun 2012 18:08:03 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SbEHb-0007oF-Eu (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Sun, 03 Jun 2012 18:08:03 +0100
Date: Sun, 03 Jun 2012 18:08:03 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Matt McCutchen <matt@mattmccutchen.net>
cc: dane@ietf.org, ietf-smtp@imc.org
Subject: Re: [dane] draft-fanf-dane-smtp
In-Reply-To: <1338580733.1728.47.camel@localhost>
Message-ID: <alpine.LSU.2.00.1206031756170.20182@hermes-2.csi.cam.ac.uk>
References: <alpine.LSU.2.00.1205251812480.572@hermes-2.csi.cam.ac.uk> <1338435781.1728.29.camel@localhost> <alpine.LSU.2.00.1205311528510.10076@hermes-2.csi.cam.ac.uk> <1338580733.1728.47.camel@localhost>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>

Matt McCutchen <matt@mattmccutchen.net> wrote:

> >     As well as its normal function of providing an association
> >     between a domain name and a certificate, we are also using the
> >     existance of a TLSA record to signal to the client that it can
> >     expect a valid server certificate.
>
> TLSA always signals to the client that *if* it does TLS, it can expect a
> valid server certificate.  The issue is whether to do TLS.  I think you
> mean this:
>
>      As well as its normal function of providing an association
>      between a domain name and a certificate, we are also using the
>      existance of a TLSA record to signal to the client that the SMTP
>      server supports TLS.

There is a load of other text in the intro explaining that in the current
internet a lot of MXs support TLS but don't have valid certificates, and
even if they did the existing specs don't explain how to validate them. So
the point of that text is to explain that we are using TLSA to fix this.
You are right to point out that I had left server support for TLS
implicit; I already improved that between -01 and -02 so the paragraph now
reads:

   As well as its normal function of providing an association between a
   domain name and a certificate, we are also using the existance of a
   TLSA record to signal to the client that it can expect the server to
   offer TLS with a valid certificate.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Shannon: North 4 or 5, veering southeast 5 or 6. Moderate, occasionally rough
at first. Occasional rain. Good, occasionally poor.