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

From: Tony Finch <[email-masked]>
Date: Fri, 25 May 2012 18:15:36 +0100

I have just submitted an I-D describing how to use DANE with SMTP. All
comments welcome.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey: Northeasterly in Hebrides at first, otherwise southeasterly
4 or 5. Slight or moderate. Fog patches. Moderate, occasionally very poor.

---------- Forwarded message ----------
Date: Fri, 25 May 2012 10:10:23 -0700
From: [email-masked]
To: [email-masked]
Subject: New Version Notification for draft-fanf-dane-smtp-00.txt

A new version of I-D, draft-fanf-dane-smtp-00.txt has been successfully submitted by Tony Finch and posted to the IETF repository.

Filename:	 draft-fanf-dane-smtp
Revision:	 00
Title:		 Secure inter-domain SMTP with TLS, DNSSEC and TLSA records.
Creation date:	 2012-05-25
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   SMTP supports STARTTLS for inter-domain mail transfer, but it only
   provides very limited security because the server&#39;s certificate
   cannot be authenticated.  This memo specifies how TLSA records in the
   DNS can be used for proper MX target server authentication.

The IETF Secretariat

---

From: Ned Freed <[email-masked]>
Date: Fri, 25 May 2012 11:38:54 -0700 (PDT)

Just read through it. I think the approach is correct, in particular the
choice to put the TLSA at the server host name level rather than the mail
domain level is the correct one. As you explain in Appendix A, this is the
only way it can work given the use of cross-ADMD MXes for things like
secondary service.

You might want to put something in the security considerations section about
the trust involved when you have a signed MX pointing to a secondary outside 
your ADMD.

				Ned

---

From: Tony Finch <[email-masked]>
Date: Fri, 25 May 2012 19:45:57 +0100

Ned Freed <[email-masked]> wrote:

> Just read through it. I think the approach is correct

Thanks for the quick review :-)

> You might want to put something in the security considerations section
> about the trust involved when you have a signed MX pointing to a
> secondary outside your ADMD.

A good suggestion, thanks again.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet, Irish Sea, Shannon: Easterly or northeasterly 5 to 7,
occasionally gale 8. Moderate or rough. Thundery showers. Moderate or good,
occasionally poor.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 25 May 2012 16:51:27 -0400

On May 25, 2012, at 2:38 PM, Ned Freed wrote:

> Just read through it.

And I haven't read it yet (blush), other than the intro, but wanted to say thanks to Tony for submitting this -- we had discussed having the "How to do DANE with <foo>" series, but hadn't made much progress yet…

W

> I think the approach is correct, in particular the
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 25 May 2012 17:09:09 -0400

I don't really see the need to rule out the use of TLSA records under the MX name instead of the server name.  As long as they're signed, they don't create any additional vulnerability.  In fact, if you could provision signed TLSA, you don't really need signed MX.

--Richard

---

From: Tony Finch <[email-masked]>
Date: Fri, 25 May 2012 22:58:09 +0100

On 25 May 2012, at 22:09, "Richard L. Barnes" <[email-masked]> wrote:

> I don't really see the need to rule out the use of TLSA records under the MX name instead of the server name.

Please read the appendix.

Tony.

---

From: Ned Freed <[email-masked]>
Date: Fri, 25 May 2012 23:07:55 -0700 (PDT)

> Please read the appendix.

To be fair, the appendix is more about why host name TLSA records have to be
supported, not why you couldn't support domain TLSA records as well.

The main problem with having both is it complicates things considerably with no
real added benefit, and that's a really bad thing to do in a security protocol
like this.

And part of that added complexity is understanding that, as Appendix A
points out, there are real-world use cases where domain TLSA records cannot be
made to work. This creates complicated criteria for when they domain MX records
can be used and when they cannot.

Finally, one of the advantages of host name TLSA records is they require
no additional SMTP server functionality. In order to use domain TLSA records
Server Name Indication support is nearly essential, and in my experience at
least  support for this extension is currently uncommon. Requiring server
as well as client upgrades also seems like a bad idea.

				Ned

---

From: James Cloos <[email-masked]>
Date: Sat, 26 May 2012 20:13:45 -0400

I've read the draft now.  It looks good.

§3 specifies that the hostname MUST be in the cert as an DNS-ID and
also MAY be there as a CN-ID.

I suspect there are enough MXs in use still using certs generated (with
long validity periods) which were genreated back when only CN was used
for the dns names.

Should the draft allow either-or?  Or is there too much precedent in the
TLS specs to allow that in a new rfc?

Otherwise it looks spot on.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Scott Schmit <[email-masked]>
Date: Sat, 26 May 2012 22:52:53 -0400

> I've read the draft now.  It looks good.

I agree.

> TLS specs to allow that in a new rfc?

If there's no authentication today, then regenerating the cert shouldn't
be a big deal.

-- 
Scott Schmit

---

From: Hector Santos <[email-masked]>
Date: Sun, 27 May 2012 18:44:47 -0400

> I have just submitted an I-D describing how to use DANE with SMTP. All

Hi Tony,

I think an example should be added to make it clear what an possible 
implementator would be considering.  Showing maybe where similar 
idea(s) is applied now.

So if I read your document right, please correct, this would be akin 
to a BROWSER (interactive client) doing a "Common Name" check.

If so, I seem to recall some SMTP clients, interactive clients as with 
a MUA, also doing a popup for the user, but I may lumping that with 
our own wcSMTPJr client we provide as a command line tool for sending 
a message, usually for testing. which has an option to check the 
"common name" is the same as the host provide to connect.

Here an example run:

D:\local> wcsmtpuser /site:mail.winserver.com

wcSmtpUser 3.1 (c) 2004-2010 SSI (/? for help)
- ini file     : wcsmtpuser.ini
- ini section  : mail.winserver.com
- server name  : mail.winserver.com
- user name    : hector.santos
- use ssl      : YES
- auth method  : 1

* connecting to 208.247.131.9:25
S: 220-winserver.com Wildcat! ESMTP Server v6.4.454.1 ready
S: 220-************** WARNING:  FOR AUTHORIZED USE ONLY! 
**********************
S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY 
COMPUTERS    *
S: 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE 
UNSOLICITED *
S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT 
ACCESS *
S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. 
         *
S: 220 
************************************************************************
C: EHLO hdev20.santronics.com
S: 250-winserver.com, Pleased to meet you.
S: 250-SIZE 10240000
S: 250-8BITMIME
S: 250-SUBMITTER
S: 250-ETRN
S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
S: 250-AUTH=LOGIN
S: 250-HELP
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
** SSL Negotiated session
** Certicate Information File: secure.winserver.com.cert
** CERT Common Name : secure.winserver.com
** CERT Organization: secure.winserver.com
** CERT Valid Until : Dec 27 18:55:51 2012 GMT (Days Left: 214)
** CA Country       : US
** CA Organiziation : GoDaddy.com, Inc.
** CA Common Name   : Go Daddy Secure Certification Authority
!! connection domain : mail.winserver.com
!! common name       : secure.winserver.com
!! Certificate CONNECTION DOMAIN and COMMON NAME mismatch! Accept? Yes 
or No?

My MX is mail.winserver.com but I have been using our 
secure.winserver.com sub-domain for the SSL certificate.

wcSMTPjr has three options (per host section):

    Cert.Expired.Allow=0          # cert expiration check
    Cert.NoMatch.Server.Allow=0   # CN vs connecting host check
    Cert.NoMatch.Host.Allow=1     # CN vs PTR records of IP check

So if the above make sense, how does this DANE-SMTP proposal help me, 
as an example like including the TLSA record that needs to be created?

I guess, if anything else, there are two client suggestions to highlight:

   - Automated MTA (router)
   - Interactive MUA smtp client

Like RFC5321 provides insight here, only with an MUA-SMTP client can 
you do "human" confirmation checks or graceful aborts without losing 
the message.  The MUA-SMTP client may fail to send the message if any 
55x is issued, like with a RCPT TO command.  But with a MTA router, it 
continues.

Make sense?

Thanks

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sun, 27 May 2012 19:08:25 -0400

> long validity periods) which were genreated back when only CN was used

How this this apply to use usage of global wildcard certs? in 
additional, not a CA wildcard signed cert, but a unique domain?

For example, I use secure.winserver.com for our HTTPS (web site) SSL 
for eCommence mainly, but since the FTP, SMTP, POP, NNTP and TELNET 
servers is running on the same machine so I use the same cert for 
their TLS capabilities or specific implicit SSL ports, if any, as well.

If a TLSA record allows for an server authorized association of the 
CN=secure.winserver.com with the connecting host name, then I can see 
some worth in this dane-smtp proposal - from the client POV seeking a 
higher level of security.

-- 
HLS

---

From: Scott Schmit <[email-masked]>
Date: Mon, 28 May 2012 12:09:27 -0400

On Sun, May 27, 2012 at 06:44:47PM -0400, Hector Santos wrote:
> So if the above make sense, how does this DANE-SMTP proposal help
> me, as an example like including the TLSA record that needs to be
> created?

IMHO, you generate a self-signed certificate with a dnsname (and/or
CN) of mail.winserver.com and use TLSA certificate usage 3.

Based on your trace, your certificate isn't valid currently, so it
shouldn't break anything.

-- 
Scott Schmit

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 May 2012 12:54:48 +0100

> I've read the draft now.  It looks good.

Thanks.

> also MAY be there as a CN-ID.

That is basically adapting what RFC 6125 says to the specifics of SMTP,
i.e. subsetting the possible identities (omitting SRV etc.). Perhaps I
ought to make the DNS-ID a SHOULD rather than MUST to follow RFC 6125
more exactly.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover, Wight, Portland, Plymouth: Variable 3 or 4. Smooth or slight.
Fog patches. Moderate, occasionally very poor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 May 2012 12:59:25 +0100

>   - Interactive MUA smtp client

The draft is for inter-domain SMTP so message submission is out of scope.
I don't think I can make this clearer.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Cromarty, Forth, Tyne, Dogger: Variable 3 or 4. Slight or moderate. Occasional
rain. Moderate or good, occasionally poor later.

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 May 2012 13:04:09 +0100

Hector Santos <[email-masked]> wrote:
> CN=secure.winserver.com with the connecting host name, then I can see some
> worth in this dane-smtp proposal - from the client POV seeking a higher level
> of security.

Of course you can do that. You just have to ensure the names match, i.e.
the MX target and TLSA owner have to match the certificate.

The final version of this draft will probably have how-to appendix along
the lines of draft-ietf-dane-protocol appendix A.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
East Viking, North Utsire, South Utsire: Northerly or northwesterly 4 or 5,
increasing 6 for a time. Moderate, occasionally rough. Fair. Good.

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 May 2012 13:16:05 +0100

> supported, not why you couldn't support domain TLSA records as well.

Thanks for explaining this for me :-) I hope you don't mind if I add some
of your words to the draft.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties: Variable 3 or 4, becoming northwesterly 5 later in far northeast.
Moderate, occasionally slight in west. Occasional rain in southwest. Moderate
or good.

---

From: Ned Freed <[email-masked]>
Date: Tue, 29 May 2012 17:21:20 -0700 (PDT)

> of your words to the draft.

No problem! I'm glad you found them useful.

				Ned

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 May 2012 21:33:09 +0100

I have uploaded a revised version. I am rather unsure about
sections 4 and 5 so all cheers and jeers welcome, especially
if backed up with some kind of reasoning :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames: Variable 3 or 4. Smooth or slight. Fog patches developing,
occasional rain. Moderate or good, occasionally very poor.

---------- Forwarded message ----------
Date: Tue, 29 May 2012 13:22:40 -0700
From: [email-masked]
To: [email-masked]
Subject: New Version Notification for draft-fanf-dane-smtp-01.txt

A new version of I-D, draft-fanf-dane-smtp-01.txt has been successfully
submitted by Tony Finch and posted to the IETF repository.

Filename:        draft-fanf-dane-smtp
Revision:        01
Title:           Secure inter-domain SMTP with TLS, DNSSEC and TLSA records.
Creation date:   2012-05-29
WG ID:           Individual Submission
Number of pages: 11

Abstract:

The IETF Secretariat

---

From: Mark Andrews <[email-masked]>
Date: Wed, 30 May 2012 13:17:56 +1000

In message <[email-masked]>, Hector Santos writes:
> Oh, so that is what you meant by "inter-domain."   I am not use to 
> using that term within the confines of mail systems but it fits. 
> Other terms are "routers," "relays," etc or just MTA.  I prefer router.
> 
>    Inter-domain SMTP:  SMTP between different ADMDs across the public
>        Internet, where a client sends mail to a publicly-referenced SMTP
>        server.
> 
> I suggest to add an i.e.
> 
>     i.e. a router, relaying MTA, not an MUA with a possible interactive
>          CN vs Host domain checking method where the HUMAN is involved.
> 
> Anyway, ironically, we are having a related thread now in our support 
> forum regarding a sysop asking about self-signed vs CA signed certs.
> 
> My question is:
> 
> If the client has to be modified to do this extra TLSA check, then why 
> not just add login to do a CA 3rd party repository?   Or support OCSP 
> (Online Certificate Status Protocol) RFC2560?

OCSP is for when the CA knows the CERT is compromised.
TLSA, mode X, is to detect mis-issued CERT by some CA.

Different threat models.

OCSP are sometimes unreachable even when you have the address and CERT.
TLSA records will almost always be available if you can retrieve the address
as they live below the address in the DNS and are usually in the same zone.

Different failure models.

> When change is proposed, then it has to have a payoff.  A client 
> trusting a self-signed signature is going to be pre-defined or 
> pre-arranged or known upfront.

TLSA, mode Y, allows you to trust the self signed CERT by providing
a verifiable secure chain of trust back to a DNS trust anchor rather
than a CA trust anchor.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Hector Santos <[email-masked]>
Date: Tue, 29 May 2012 22:12:17 -0400

I suggest to add an i.e.

My question is:

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 May 2012 17:44:10 -0400

> Different failure models.

Yes, but its always been used for whatever the CA responds with and 
whatever the client decides to do as a negative response, but as the 
modus operandi has been, a positive response has "trust value."  I've 
seen it used in cases where a browser check provides a perfect SSL 
resolution, but with modern browsers having OCSP enabled now, it will 
provide a failure/security notification to the user.  In the case I 
recall, a big national chain store purchased a set of wildcard 
domains, then wanted to add more the same day, and there was a 
revocation issue that failure when OCSP was enabled.

So I guess that all falls under a "compromise" threat/failure window.

> a verifiable secure chain of trust back to a DNS trust anchor rather

Thanks for your comments.

At best, this proposal offers an easier protocol. But its not ready 
for prime time until the DNS servers better support unnamed types and 
across the OS platform board.

I think we would like a SMTP/TLS model where clients support/service 
the CA market, in the same way Browsers do for SSL/TLS certificates. 
  I can see an SMTP Server Extension that offers service keywords for 
the level of enforcement. This may answer one of the lingering 
questions the DANE-SMTP drafts states that the server has no way to 
know the client has looked up a TLSA record.

-- 
HLS

---

From: Mark Andrews <[email-masked]>
Date: Thu, 31 May 2012 10:18:13 +1000

> across the OS platform board.

Actually I believe it is ready for prime time.

If the DNS servers don't support DNSSEC then the MX, A and AAAA
will come back as insecure unless the administrators of the zones
are insane.

If the DNS servers do support DNSSEC and the MX, A and AAAA answers
come back as secure, then a TLSA lookup should succeed as the TLSA
lookups will be from the same zones as the MX, A and AAAA lookups
or will be in a secure zone beneath the zone that returned these
answers.  All DNSSEC aware servers are required to support unknown
types.  By checking the MX, A and AAAA results you elimitate the
possibility of NOTIMP on the TLSA lookup.

If DNSSEC is being broken then all bets are off.

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 30 May 2012 20:43:01 -0700

[This message, originally sent 2012-05-27, did not seem to reach the
archives.  Sending it again.]

> I have just submitted an I-D describing how to use DANE with SMTP. All

This approach is not going to work.  My understanding
(http://www.ietf.org/mail-archive/web/keyassure/current/msg01215.html)
is that a TLSA RRset at a given endpoint (DNS name + transport + port)
is not a guarantee that a TLS service is offered at that endpoint.  It
only indicates the server certificates to be considered authentic if a
client wants to attempt a connection to such a TLS service.  Indeed, an
organization with an existing private CA may publish may cover its
entire zone with TLSA RRsets of usage 2 referring to that CA.  And I
cover all the unused names in mattmccutchen.net with dummy TLSA RRsets
(SHA256 0000...0000) to ensure that TLS clients will never successfully
authenticate a TLS service that I do not offer if a MITM attacker tries
to spoof one into existence with a fraudulent certificate from a public
CA.

A mail client that is already configured to require authenticated TLS
could certainly use DANE.  But it would be incorrect for a client to
refuse to deliver insecurely because it found a secure TLSA RRset.  For
that kind of logic, we need something like HASTLS.

-- 
Matt

---

From: Tony Finch <[email-masked]>
Date: Thu, 31 May 2012 15:46:32 +0100

Matt McCutchen <[email-masked]> wrote:
>
> This approach is not going to work.

I think you mean that you want weaker semantics for SMTP+TLSA than I have
specified. I have deliberately stated that extra semantics apply - in the
intro I 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.

I agree that this might be a job for the HASTLS record - I wan't aware of
it. I can change the spec to require another DNS lookup for HASTLS if
others think this is worth doing.

The historical baggage for SMTP and HTTP are rather different so I am not
sure it makes sense to apply an HTTP fix to SMTP. It would add significant
programming and provisioning complexity, and I don't think your use cases
justify it. (For instance, your wildcard TLSA records are useless without
accompanying address or SRV records.) On the other hand perhaps it would
be nice to have better consistency across protocols.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Easterly or northeasterly 5 to 7, increasing gale 8, occasionally
severe gale 9 later in southeast, otherwise mainly northerly 4 or 5,
occasionally 6. Slight or moderate, occasionally rough in southeast. Thundery
showers later in east. Good, occasionally poor in east.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 31 May 2012 08:05:37 -0700

On May 30, 2012, at 8:43 PM, Matt McCutchen wrote:

> My understanding
> client wants to attempt a connection to such a TLS service.  

Correct.

> Indeed, an

It could do so if it wanted. That doesn't mean it is a good idea to do so.

> refuse to deliver insecurely because it found a secure TLSA RRset.  

That's incorrect. draft-fanf-dane-smtp is defining the specific use of TLSA for _25._tcp.hostname. (It would be good if it said so in the Introduction.)

> For

The second paragraph of the Security Considerations covers this. I think HASTLS might be a good idea, but the IETF still needs to have the discussion of layering of these types of announcements.

> This approach is not going to work.  

It will work fine for everyone who doesn't do the "cover every port and assume that no future protocol will ever define how specific applications will use TLSA".

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Thu, 31 May 2012 16:24:25 +0100

Paul Hoffman <[email-masked]> wrote:
>
> That's incorrect. draft-fanf-dane-smtp is defining the specific use of
> TLSA for _25._tcp.hostname. (It would be good if it said so in the
> Introduction.)

I've added that to my working copy. Thanks for the suggestion.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight, Portland, Plymouth: Southwest 4 or 5, occasionally 6 at first,
becoming variable 3 or 4 later. Slight or moderate. Occasional drizzle, fog
patches. Moderate or good, occasionally very poor.

---

From: Tony Finch <[email-masked]>
Date: Thu, 31 May 2012 18:39:38 +0100

Another version, with less added text this time - I've included a copy of
the change log below. Many thanks to everyone who has taken the time to
read the draft and comment.

     Clarify the wording that describes how a client determines that
     this protocol is in effect.

     Divide the security considerations into sub-sections, and add a
     subsection on denial of service.

     Clarify intro, mentioning TLSA owner name format.

     Extend the scope to cover MTA-to-MTA mail within an ADMD as
     well as between ADMDs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: North 4 or 5, backing northwest 5 or 6. Moderate, occasionally rough
later. Showers. Good.

---------- Forwarded message ----------
Date: Thu, 31 May 2012 10:33:51 -0700
From: [email-masked]
To: [email-masked]
Subject: New Version Notification for draft-fanf-dane-smtp-02.txt

A new version of I-D, draft-fanf-dane-smtp-02.txt has been successfully
submitted by Tony Finch and posted to the IETF repository.

Filename:        draft-fanf-dane-smtp
Revision:        02
Title:           Secure SMTP with TLS, DNSSEC and TLSA records.
Creation date:   2012-05-31
WG ID:           Individual Submission
Number of pages: 13

Abstract:
   SMTP has a STARTTLS extension, but (especially in the case of inter-
   domain mail transfer) it only provides very limited security because
   it does not specify how to authenticate the server&#39;s certificate.
   This memo specifies how TLSA records in the DNS can be used for proper
   SMTP server authentication.

The IETF Secretariat