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

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 18:16:32 +0200 (CEST)

Matt McCutchen wrote:
> 
> 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.

I actually believe that you're abusing TLSA with "dummy RRsets",
and if there was a desire to lock out public CAs from issuing certs
for a particular domain, a seperate TLSA usage type should be
defined specifically for that purpose.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 01 Jun 2012 10:12:12 -0700

> defined specifically for that purpose.

If a better solution becomes available
(https://trac.tools.ietf.org/wg/dane/trac/ticket/23), I will adopt it
promptly.  In the meantime, this approach should work according to the
semantics of TLSA.  I don't see why I should forego the concrete benefit
of locking out the public CAs.  If it makes you feel better, I could
generate an actual key pair and publish the certificate; it would make
no difference to DANE clients, but it would be less obvious to a human
looking at the record.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 01 Jun 2012 12:58:53 -0700

On Thu, 2012-05-31 at 15:46 +0100, Tony Finch wrote:
> 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.

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.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 01 Jun 2012 20:05:28 -0700

On Thu, 2012-05-31 at 08:05 -0700, Paul Hoffman wrote:
> On May 30, 2012, at 8:43 PM, Matt McCutchen wrote:
> > 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.)

I thought (and hoped) that TLSA was a generic protocol for
authenticating a TLS service at a given (DNS name, transport, port),
nothing more.  I didn't realize that subsequent documents would attach
other semantics to TLSA RRsets.  Nothing in the DANE doc anticipates
this.  (The clause, "Unless there is a protocol-specific specification
that is different than this one", appears to me to refer to putting TLSA
RRsets at a different owner name, not giving them different semantics.)
I would oppose doing this, but it looks like I'm outvoted.

> I think HASTLS might be a good idea, but the IETF still needs to have
> the discussion of layering of these types of announcements.

I think IETF should have that discussion before the WG commits to Tony's
proposal for SMTP.

> 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".

It's true that there was no strong support for ensuring that covering
every port works.  Though, if we intend to break it, section "A.2.1.3.
Provisioning TLSA Records with Wildcards" of the DANE doc should be
updated.

It's also true that I can't just expect the standard to support the
features I want without slogging through the process of building
consensus.  For now, I can have fun deploying records with the
private-use certificate usage and implementing them in my client.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 2 Jun 2012 08:10:17 -0700

> I would oppose doing this, but it looks like I'm outvoted.

It was discussed on the DANE mailing list off and on over time, particularly with respect to SRV-using protocols. You may disagree with it and hope for different, but it should not be a surprise to you. We all know that a TLS-on-defined-port protocol is not the same as a TLS-after-upgrade protocol when the TLS handshake fails, and DANE by design gives a different way for the TLS handshake to fail.

> I think IETF should have that discussion before the WG commits to Tony's

This draft is a great forcing function for the discussion. However, I will be shocked if the discussion comes to a fixed result any time soon.

> every port works.  

s/no strong support/no noticeable support/

> Though, if we intend to break it, section "A.2.1.3.

Disagree. The text in A.2.1.3 is still correct: it's only your interpretation of "if the port is covered, it must offer TLS" that is wrong.

> private-use certificate usage and implementing them in my client.

By all means let the mailing list know your experiences with that deployment. If DANE is anything like DNSSEC, we have muffed and understated many important features that will only be found by interesting deployment.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 02 Jun 2012 14:59:33 -0700

On Sat, 2012-06-02 at 08:10 -0700, Paul Hoffman wrote:
> It was discussed on the DANE mailing list off and on over time,
> particularly with respect to SRV-using protocols. You may disagree
> with it and hope for different, but it should not be a surprise to
> you.

Can you please provide the reference where the WG discussed using TLSA
to indicate "TLS is available"?  All I see is you promoting the opposite
position, at least for HTTP:

http://www.ietf.org/mail-archive/web/keyassure/current/msg01209.html

> We all know that a TLS-on-defined-port protocol is not the same as a
> TLS-after-upgrade protocol when the TLS handshake fails, and DANE by
> design gives a different way for the TLS handshake to fail.

Sorry, I don't follow.  Can you spell out the argument for protocols
with in-band TLS upgrade should be treated differently?

> Disagree. The text in A.2.1.3 is still correct: it's only your
> interpretation of "if the port is covered, it must offer TLS" that is
> wrong.

Can you explain?  The doc says, "This is possibly useful in some
scenarios where [...] the same certificate and/or key is used for all
services on a host."  I read this as "all TLS services".  So if the host
offers several TLS services with the same certificate, plus SMTP that
does not support TLS, then it would seem one could deploy a wildcard
RRset.  But then draft-fanf-dane-smtp would break the use of the SMTP
service.

-- 
Matt

---

From: Tony Finch <[email-masked]>
Date: Sun, 3 Jun 2012 18:08:03 +0100

>      existance of a TLSA record to signal to the client that the SMTP

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  <[email-masked]>  http://dotat.at/
Shannon: North 4 or 5, veering southeast 5 or 6. Moderate, occasionally rough
at first. Occasional rain. Good, occasionally poor.