Subject: [ietf-smtp] certificate pinning

From: Brandon Long <[email-masked]>
Date: Fri, 6 Jun 2014 16:12:02 -0700

Now that more servers are offering STARTTLS, it would seem beneficial to
move forward towards certificate validation.

How do people feel about bringing the concept of certificate pinning from
HTTP (http://tools.ietf.org/html/draft-ietf-websec-key-pinning-13) to SMTP?

I realize there's also DANE TLSA (RFC 6698), but that has a requirement on
DNSSEC that may limit its deployment for some time to come.

translating the syntax in the http draft to smtp ehlo, I would imagine
something like (on a second EHLO after the TLS session is started):

C: EHLO foo
S: 250-SIZE 35882577
S: 250-8BITMIME
S: 250-PKP PIN-SHA256=d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=
S: 250-PKP PIN-SHA256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=
S: 250-PKP MAX-AGE=259200
S: 250-ENHANCEDSTATUSCODES
S: 250 CHUNKING

alternative syntaxes:
S: 250-PKPPIN SHA256 d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=
S: 250-PKPEXPIRES 259200

Or one line:
S: 250-PKP MAX-AGE=259200
PIN-SHA256=d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=

Brandon

---

From: "John Levine" <[email-masked]>
Date: 7 Jun 2014 03:54:06 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-

Interesting idea.  I'd be willing to work up a draft with you.

R's,
John

---

From: Evert Mouw <[email-masked]>
Date: Sat, 07 Jun 2014 07:47:45 +0000

On 06/06/2014 11:12 PM, Brandon Long wrote:
> Now that more servers are offering STARTTLS, it would seem beneficial 
> to move forward towards certificate validation.
>
> How do people feel about bringing the concept of certificate pinning 
> from HTTP 
> (http://tools.ietf.org/html/draft-ietf-websec-key-pinning-13) to SMTP?
>
> I realize there's also DANE TLSA (RFC 6698), but that has a 
> requirement on DNSSEC that may limit its deployment for some time to come.
>
DNSSEC would be great. Now there's either self-signed certificates 
(which would cause problems with certificate validation) or paid 
services that cannot always be trusted (in my country: Diginotar) or 
hinder deployment for administrative reasons (needs management approval 
in some organizations). For deploying new features, it would not hurt to 
use the currently best option. Maybe it would even accelerate DNSSEC 
with DANE, improving security for everyone. Just my 2c.

Evert

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 7 Jun 2014 01:24:00 -0700

> Interesting idea.  I'd be willing to work up a draft with you.

Ditto.

-MSK

---

From: Peter Bowen <[email-masked]>
Date: Sat, 7 Jun 2014 22:35:15 -0700

> S: 250-ENHANCEDSTATUSCODES

What about bringing HSTS to SMTP as well?

S: 250-STSEC MAX-AGE=31536000

This would indicate that connections must use STARTTLS for future
connections.  Ideally, this would allow a client to directly issue
STARTTLS on connect, rather than EHLO (a protocol violation today),
reducing the amount of unencrypted data on the connection and speeding
up the connection sequence.

Thanks,
Peter

---

From: Evert Mouw <[email-masked]>
Date: Sun, 08 Jun 2014 08:34:37 +0000

> up the connection sequence.
Would be nice to have. However, I could repeat my doubts about breaking 
connectivity with all those mailservers out there that use self-signed 
certificates (wat HSTS does). I advocate the use of DANE. If support for 
DANE would be mandatory for a "HSTS for SMTP", then it would be a great 
solution.

Evert

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 8 Jun 2014 13:09:53 +0100

> On 7 Jun 2014, at 09:24, "Murray S. Kucherawy" <[email-masked]> wrote:
> 

+1

---

From: Gilles Chehade <[email-masked]>
Date: Sun, 8 Jun 2014 14:23:24 +0200

+1

-- 
Gilles Chehade

https://www.poolp.org                                          @poolpOrg

---

From: Peter Bowen <[email-masked]>
Date: Sun, 8 Jun 2014 09:10:33 -0700

> DANE would be mandatory for a "HSTS for SMTP", then it would be a great

TLSA records make sense in many contexts.  Unfortunately the current
spec for using them with SMTP (draft-ietf-dane-smtp-01 and
draft-ietf-dane-srv-05) make them unusable unless both the source and
target domains use DNSSEC.  For example, if I have

    example.com. IN MX 5 spmx.example.net.

Then both example.com and example.net have to be using DNSSEC.

Without DNSSEC: "If the SRV response was insecure, the client MUST NOT
perform any TLSA queries" and "SRV is insecure: The reference
identifiers SHALL include the service domain and MUST NOT include the
SRV target host name."

This means that the certificate on spmx.example.net must have
example.com in the subject alternative name, most likely as a SRVName.
I am not area of any public CAs that issue certificates with SRVName
in the SAN.

I'm also not sure if any current SMTP clients follow RFC 6125 and RFC
4985 and would check SRVnames in the certificate if it was present.

Thanks,
Peter

---

From: Jim Fenton <[email-masked]>
Date: Sun, 08 Jun 2014 22:22:28 -0700

> to move forward towards certificate validation.

Before we get too far down the road with how to accomplish this, I'd
like to ask about the "beneficial" part: What behavior we would like to
occur with respect to certificate validation?

Currently, if certificates don't validate correctly for SMTP, most
clients just let the TLS connection complete anyway. This has the
obvious problem with man-in-the-middle attacks, but is effective against
passive attacks.

If this changes, we'd presumably be bouncing messages when the cert
doesn't validate. That might be the right thing to do for some very
sensitive messages, but the vast majority aren't. Email is biased to
favor delivery over security, and our usage assumes that in various ways.

If these messages do bounce, what happens if it isn't possible to
establish a TLS path with validated certificates on the return path?

It's the receiving SMTP server that sets the level of security (pins the
certificate) here, while it's only the SMTP client that could possibly
know what the sensitivity of the message is and therefore how important
that might be -- and we don't have mechanisms to convey that to the SMTP
client either.

I'd like to improve the resistance to MITM attacks, sure -- but I
wouldn't want collateral damage to the bulk of traffic, which doesn't care.

-Jim

---

From: Brandon Long <[email-masked]>
Date: Fri, 13 Jun 2014 16:08:15 -0700

> occur with respect to certificate validation?

Preventing MITM attacks.  Really, that's more certificate-pining than
validation itself.

> favor delivery over security, and our usage assumes that in various ways.

Yes, we would bounce messages, or at least temp fail them for re-try later.

With pining, a domain is choosing that having messages bounce/delayed is
preferably to the MITM hole.
The sender can still choose to ignore that and send anyways.

To me, there are a couple reasons why a cert-pin would fail:
1) Domain switched certs suddenly
2) Traffic is being intercepted

I agree that delaying/bouncing mail for #1 is not what one would want.  The
http pining spec allows for you to pin intermediate certs, which means you
can switch the leaf cert with no issues to reduce the chance of this
problem.  That said, there are plenty of other ways in which email can be
disrupted in a similar fashion (domain expires, DNS misconfigurations,
DNSBL and reputation)

As for #2, most people would say they don't want their email watched there.
 Now, its possible that there are countries, government agencies,
companies, schools that would insist on being able to intercept, and their
citizens, employees, students are subject to their rules and willing to
allow it.  I think in most of those cases (well, besides countries), its
easy enough for the admins to block outbound port 25 and install their own
relay server for sending mail, and in many cases this is already done.  If
people allow access to external web mail or allow outbound MSA, they've
already lost the ability to guarantee interception at some point anyways.

I should point out that many MTA's (including Google Apps for your Domain),
allow the admin to require TLS or require a valid certificate or matching
certificate for talking with specific hosts.  This would be a way of
expanding that at the will of the sender/receiver.

> establish a TLS path with validated certificates on the return path?

Obviously we've moved to a world where such bounces are less likely, but
they still occur.  We're not talking about a "require encryption" statement
for the message like was proposed by my colleagues in the "Manadatary
Secure Mail Delivery" proposal (
http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg07557.html).

Example wise, we're talking about A -> B -> C where B -> C fails a pin, so
the message is bounced either to A or to some other D.  Either all paths
from B are compromised, in which case, yes, the bounce will expose, or its
C which is compromised, so the bounce to A|D isn't any more likely to be
compromised.

> that might be -- and we don't have mechanisms to convey that to the SMTP

Well, in reality its both.  The receiver says it wants you to pin its
certs, but there's nothing preventing the sender from ignoring the pin.

> wouldn't want collateral damage to the bulk of traffic, which doesn't care.

Presumably the traffic that doesn't care isn't encrypting today.  Our
transparency report shows that many senders of promotional mail don't care,
for example, and why should they if they're sending the same thing to
millions of users.

I also think that certificate pining like this helps to prevent bad
behavior by removing the holes.

I think without something like this, you're likely to see people doing
manual federation instead, where Gmail talks to Facebook and agrees on a
cert pin to ensure our traffic is encrypted.

And, there is already DANE TLSA, the concept of doing this is not new.  I
don't know where that was discussed in order to read the discussion and
understand what was already learned.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Fri, 13 Jun 2014 16:12:53 -0700

> up the connection sequence.

I don't have a strong opinion either way on that.  My original take was
that HSTS was important to HTTP since the whole request is sent unencrypted
immediately (including cookies, potentially), where-as with SMTP, their is
a negotiation prior to anything but the ehlo itself.

This is also why Gmail only offers imap/pop over ssl-wrapped connections,
less chance of clients mistakenly sending passwords in the clear (even if
the server ignores them since they haven't invoked STARTTLS).
 Unfortunately, we didn't have a choice with smtp-msa as some clients
didn't support ssl-wrapped connections.

If there is sufficient interest in removing the extra round-trip or hiding
the original ehlo, I'm certainly not opposed to it, though.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Fri, 13 Jun 2014 16:15:52 -0700

> DANE would be mandatory for a "HSTS for SMTP", then it would be a great

I don't want to prevent self-signed certificates.  Presumably, at the
least, they would still work without pining, they would just be open to
MITM (ie, no better than now).

Depending on the spec, there's nothing preventing us from allowing a pin
without root validation, but I'm not a security expert enough to know if
that leaves other holes.

Brandon

---

From: Brandon Long <[email-masked]>
Date: Fri, 13 Jun 2014 16:18:38 -0700

One interesting question, is what is pinned?

Do you pin just the host?  Do you pin every host in the same MX preference?
Do you pin the MX domain?  Does the pin apply to all MX hosts?

My original thought was the pin would apply to all MX hosts, but I realize
that some folks use off-site and third party relays as fallbacks, so I'm
curious what people think about that.

Brandon

On Fri, Jun 6, 2014 at 8:54 PM, John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >

---

From: "John R Levine" <[email-masked]>
Date: 13 Jun 2014 20:05:49 -0400

> curious what people think about that.

Interesting question.  My not particularly well informed opinion is that 
you pin the host, i.e., every host with the same host name.  I don't think 
you can assume that different hosts are under the same management, even if 
they are someone's MX at the same preference.

There's a fair amount of wiggle room in 5321 about how a sender chooses 
the recipient hosts to use, so I think it's entirely legitimate to ignore 
unpinned hosts if you have pinned ones.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John R Levine" <[email-masked]>
Date: 13 Jun 2014 20:07:58 -0400

>>> something like (on a second EHLO after the TLS session is started):

Oh, another questions: why would you need more than

TLSPIN 12345

where 12345 is the number of seconds to pin the certificate you just saw?

Regards,

---

From: Claus Assmann <[email-masked]>
Date: Fri, 13 Jun 2014 17:18:31 -0700

> where 12345 is the number of seconds to pin the certificate you just saw?

Because people use different certificates for the same "host" (not
just same hostname, but even same IP address). MeTA1 has an experimental
cert-pinning feature and it very often logs that the presented cert
doesn't match the previous cert -- it currently only stores one per
IP address (that's why the feature is experimental...)

Hence you need to be able to offer a multiple valid cert fingerprints
(probably with individual TTLs), e.g.,

250-PKP SHA256=d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM= TTL=200000
250-PKP SHA256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= TTL=100000

---

From: Claus Assmann <[email-masked]>
Date: Fri, 13 Jun 2014 17:24:45 -0700

> occur with respect to certificate validation?

That's local policy. For example, in sendmail (and most likely
other MTAs) you can require certain restrictions on connections,
this would be just another one, e.g.,

TLS_Clt:example.com      PERM+VERIFY:112

requires successful cert verification from hosts within the
example.com domain.

---

From: Brandon Long <[email-masked]>
Date: Fri, 13 Jun 2014 17:26:14 -0700

> 250-PKP SHA256=LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ= TTL=100000

Also, for replacement.  You can advertise before you issue the new cert, at
least for planned replacements, if you aren't pinning to something up the
chain.

For us, we roll out certs with new releases and canary them to ensure we
don't break clients (and we have broken clients in the past with new
certs), so its possibly for new connections to go to either prod or
canary.  Ditto for when we upgraded from 1024 to 2048 bit certs.

Brandon

>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: Evert Mouw <[email-masked]>
Date: Sun, 15 Jun 2014 13:44:58 +0200

> MITM (ie, no better than now).

Thanks. I agree that self-signed certificates are a risk, although
better then no encryption at all -- waiting for DANE ;-)  Maybe we
should recommend DANE / DNSSEC based certs in the RFC as the way forward
in the future? And also recommend best practices to prevent mail being
dropped? (Jim Fenton, "delivery over security")

I've no experience writing RFCs and have less expertise than many others
on this list, but if I can help / proofread, let me know.

Evert

---

From: Evert Mouw <[email-masked]>
Date: Sun, 15 Jun 2014 13:49:42 +0200

Peter Bowen schreef op 8-6-2014 18:10:
> target domains use DNSSEC.

Any chance to have influence on the authors of the draft? I will forward
your mail to Tony Finch, the first author of both drafts.

Evert

---

From: Tony Finch <[email-masked]>
Date: Mon, 16 Jun 2014 18:02:51 +0100

> curious what people think about that.

The DANE SMTP logic is that you are only secure with DNSSEC everywhere and
if all your MX targets have the necessary TLSA records. Anything less than
that gives you less security but it still works, so you can do a partial
or incremental deployment without breaking anything.

For pinning I think you need two levels: a per-mx-target pin, and a
per-mail-domain pin. The latter is triggered when all of a domain's MX
targets are pinned.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
West Forties, Cromarty: Northerly backing northwesterly, 4 or 5, occasionally
6 later. Slight or moderate. Occasional rain. Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Mon, 16 Jun 2014 18:04:46 +0100

> your mail to Tony Finch, the first author of both drafts.

Can't do DANE without DNSSEC. Yes there's a chicken-and-egg problem, so
everyone should get laying.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet: Northeast 3 or 4, increasing 5 at times. Slight or
moderate. Fair. Moderate or good.

---

From: Claus Assmann <[email-masked]>
Date: Mon, 16 Jun 2014 10:30:36 -0700

> Can't do DANE without DNSSEC. Yes there's a chicken-and-egg problem, so

Well, not according to the RFC.
However, it seems it should be possible to use the DNS records
(without DNSSEC) as additional check if so desired. Whether that
offers any value is of course a different question.

---

From: Brandon Long <[email-masked]>
Date: Mon, 16 Jun 2014 10:48:37 -0700

Right, I wasn't sure exactly why DANE requires DNSSEC.

DNSSEC provides assurance that the record isn't compromised.

But, SMTP works today without that assurance.  If you can compromise DNS
for a host today, you can already send the mail to a compromised relay, or
one that doesn't have STARTTLS at all.

Maybe a poison DNS would allow you to not require TLS... but if it is
offered, you'd take it anyways.  So, you'd have to poison DNS to remove the
DANE record and MITM the connection to remove the STARTTLS offer from the
EHLO response.... I guess this leaves "fewer" fingerprints than just
re-directing traffic?  Anyone who care can log the TLS usage as easily as
the IP address, though maybe its less obvious.

Otherwise, you can provide a false DANE record which will cause a DoS
because the certs or status don't match, so the sender refuses to deliver
the message.  Again, DNS compromise today can already do that by directing
the MX somewhere else or returning lookup failures.

DANE requiring DNSSEC seems to be the perfect being the enemy of the good.

The next problem with DANE is that it requires users to have an updated
enough DNS server/client that provides tools for the new RR-Type, as
opposed to the "overload the TXT record" mechanism that has been popular in
the email world recently.  I know our code hasn't added support yet, though
it looks like its in recent BIND implementations.  Of course, we're happy
to add support if we need it, I'm more concerned about the added
requirement for all hosts to update that... though, obviously folks would
have to update their MTA either way... well, it may be that some servers
have the ability via config to advertise things in EHLO response, but
clearly senders would need updating.

Brandon

---

From: "John Levine" <[email-masked]>
Date: 16 Jun 2014 19:01:52 -0000

>Right, I wasn't sure exactly why DANE requires DNSSEC.

It was essentially a political decision, but one that is now cast in
concrete.  The rationale. as I understand it, is that to be a
reasonable replacement for CAs it needs a comparably strong chain of
authority.  DANE without DNSSEC would be a particularly egregious
example of the Internet's traditional security model of putting a ten
ton steel lock on a screen door.

>DANE requiring DNSSEC seems to be the perfect being the enemy of the good.

That, too.  Technically, there's nothing keeping you from publishing DANE
records in unsigned zones, although I don't know what libraries are likely
to do with them.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 16 Jun 2014 19:07:18 -0000

PS:

>it looks like its in recent BIND implementations. ...

BIND and NSD have supported TLSA since 2012, and any reasonably recent DNS
cache should handle TLSA since it doesn't have any special semantics.  The
problem is more likely to be the web crudware that people use to provision
their DNS zones.

R's,
John

---

From: Brandon Long <[email-masked]>
Date: Mon, 16 Jun 2014 12:26:42 -0700

> problem is more likely to be the web crudware that people use to provision

Right, and my desktop at work as well as most of my personal servers are
running the last Ubuntu LTS release (precise) from Spring 2012 and don't
have it.  Some things upgrade slowly.  I don't have any knowledge one way
or the other on how much of a burden it would be for the open source MTAs
and their admins, etc.

Probably less work than getting DNSSEC up, I guess.

Brandon

---

From: "John Levine" <[email-masked]>
Date: 16 Jun 2014 19:35:50 -0000

>or the other on how much of a burden it would be for the open source MTAs

DNS client software is largely indifferent to rrtypes.  You ask for
type N, it sends off the request hands you back the type N records.
It's the application's job to parse it up.

>Probably less work than getting DNSSEC up, I guess.

Way less, since DNSSEC requires significant client library upgrades.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Jun 2014 07:58:22 +1000

In message <[email-masked]>, Brandon Long writes:
> --===============2997689142148642025==
> Content-Type: multipart/alternative; boundary=089e013a1d86cfb6ee04fbf901a6
> 
> --089e013a1d86cfb6ee04fbf901a6
> Content-Type: text/plain; charset=UTF-8
> 

But they do support unknown record format.  You can publish TLSA
records with those servers.  It is trivial to turn a TLS record
into a unknown record.

Below is the same record in both forms.  Just turn the first 3
fields into hex octets and add a octet count.

TLSA 3 0 1 88B54DA87A0E5D1E4EB4CD9B87D24E79A57EAD51C34E350FD071582070BEA3B3
TYPE52	\# 35 03000188b54da87a0e5d1e4eb4cd9b87d24e79a57ead51c34e350fd071582070bea3b3

Or you get and compile BIND 9.10.x and use "named-rrchecker -u"
from it to print the record out in unknown format.  You don't even
need to install it to do this.

% named-rrchecker -u
IN TLSA 3 0 1 88B54DA87A0E5D1E4EB4CD9B87D24E79A57EAD51C34E350FD0715820 70BEA3B3
CLASS1	TYPE52	\# 35 03000188b54da87a0e5d1e4eb4cd9b87d24e79a57ead51c34e350fd071582070bea3b3
% 

Or you upgrade the nameserver component.  It's not like Ubuntu LTS
isn't made up of packages which you can upgrade individually.

If you have outsourced your DNS and they do not support TLSA or
unknown format, go somewhere else or bring it back in house.

Mark

> --089e013a1d86cfb6ee04fbf901a6
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
> _quote">On Mon, Jun 16, 2014 at 12:07 PM, John Levine <span dir=3D"ltr">&lt=
> ;<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&g=
> t;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">PS:<br>
> <div class=3D""><br>
> &gt;The next problem with DANE is that it requires users to have an updated=
> <br>
> &gt;enough DNS server/client that provides tools for the new RR-Type, as<br=
> >
> &gt;opposed to the &quot;overload the TXT record&quot; mechanism that has b=
> een popular in<br>
> &gt;the email world recently. =C2=A0I know our code hasn&#39;t added suppor=
> t yet, though<br>
> </div>&gt;it looks like its in recent BIND implementations. ...<br>
> <br>
> BIND and NSD have supported TLSA since 2012, and any reasonably recent DNS<=
> br>
> cache should handle TLSA since it doesn&#39;t have any special semantics. =
> =C2=A0The<br>
> problem is more likely to be the web crudware that people use to provision<=
> br>
> their DNS zones.<br></blockquote><div><br></div><div>Right, and my desktop =
> at work as well as most of my personal servers are running the last Ubuntu =
> LTS release (precise) from Spring 2012 and don&#39;t have it. =C2=A0Some th=
> ings upgrade slowly. =C2=A0I don&#39;t have any knowledge one way or the ot=
> her on how much of a burden it would be for the open source MTAs and their =
> admins, etc.</div>
> <div><br></div><div>Probably less work than getting DNSSEC up, I guess.</di=
> v><div><br></div><div>Brandon</div></div><br></div></div>
> 
> --089e013a1d86cfb6ee04fbf901a6--
> 
> 
> --===============2997689142148642025==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============2997689142148642025==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 17 Jun 2014 00:48:19 -0000

>unknown format, go somewhere else or bring it back in house.

Um, Mark, you might want to review your mail and note where Brandon
works.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Jun 2014 12:56:07 +1000

> Um, Mark, you might want to review your mail and note where Brandon

Yes, and he also mentioned personal servers.  Additionally this
conversation is being archived and read by others.

His tools will support tlsa lookups

e.g.
	dig _443._tcp.isc.org type52

or with really old versions

	dig -t 52 _443._tcp.isc.org

Just because the nmemonic tlsa is unknown doesn't mean that the
record cannot be looked up or be published.

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Jun 2014 12:05:23 +0100

> Right, I wasn't sure exactly why DANE requires DNSSEC.

The aim is to improve security. There's no point adding complexity if it
doesn't achieve anything.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Northeast 5 or 6. Slight or moderate. Fair. Good.

---

From: Brandon Long <[email-masked]>
Date: Tue, 17 Jun 2014 08:39:02 -0700

Of course, my point is that clearly DANE is better than nothing and DNSSEC
makes it better.  I don't see what leaving out DNSSEC adds holes that don't
already exist worse without DANE.

I was hoping there was something I was missing in my analysis that
explained it.

Brandon

---

From: "John Levine" <[email-masked]>
Date: 17 Jun 2014 18:16:05 -0000

>already exist worse without DANE.

The baseline for comparison is certs signed by an authority, not the
DNS.

R's,
John

---

From: Peter Bowen <[email-masked]>
Date: Tue, 17 Jun 2014 11:26:16 -0700

On Tue, Jun 17, 2014 at 8:39 AM, Brandon Long <[email-masked]> wrote:
> I was hoping there was something I was missing in my analysis that explained
> it.

DANE is better than nothing in some cases but also can be worse than
nothing in other cases.  It all comes down to whether the DANE record
has a certificate usage that specifies to skip checking the trust
store.   Without DNSSEC, this leaves no functional trust chain.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jun 2014 08:17:21 +1000

In message <[email-masked]>
> store.   Without DNSSEC, this leaves no functional trust chain.

DANE is impossible to exist without DNSSEC.  The D in DANE is DNSSEC.

TLSA without DNSSEC can exist but TLSA is only part of DANE.
 
Mark

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Jun 2014 16:47:57 -0700

> DANE is impossible to exist without DNSSEC.  The D in DANE is DNSSEC.

The charter says it's "DNS-Based".

-MSK