Subject: [dane] [[email-masked]] New Version Notification for draft-dukhovni-dane-ops-01.txt

From: Wes Hardaker <[email-masked]>
Date: Mon, 15 Jul 2013 16:58:15 -0700

FYI:

Subject: New Version Notification for draft-dukhovni-dane-ops-01.txt
From: [email-masked]
To: Viktor Dukhovni <[email-masked]>, Wes Hardaker <[email-masked]>, Wesley Hardaker <[email-masked]>
Date: Mon, 15 Jul 2013 16:45:48 -0700

A new version of I-D, draft-dukhovni-dane-ops-01.txt
has been successfully submitted by Viktor Dukhovni and posted to the
IETF repository.

Filename:	 draft-dukhovni-dane-ops
Revision:	 01
Title:		 DANE TLSA implementation and operational guidance
Creation date:	 2013-07-15
Group:		 Individual Submission
Number of pages: 18
URL:             http://www.ietf.org/internet-drafts/draft-dukhovni-dane-ops-01.txt
Status:          http://datatracker.ietf.org/doc/draft-dukhovni-dane-ops
Htmlized:        http://tools.ietf.org/html/draft-dukhovni-dane-ops-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-dukhovni-dane-ops-01

Abstract:
   This memo provides operational guidance to server operators to help
   ensure that clients will be able to authenticate a server's
   certificate chain via published TLSA records.  Guidance is also
   provided to clients for selecting reliable TLSA record parameters to
   use for server authentication.  Finally, guidance is given to
   protocol designers who wish to make use of TLSA records to secure
   protocols using a TLS and TLSA combination.

The IETF Secretariat

-- 
Wes Hardaker
Parsons

---

From: Ben Laurie <[email-masked]>
Date: Tue, 16 Jul 2013 15:48:05 +0100

I have to push back on the text in 3.7. Interaction with Certificate
Transparency:

"If ... DANE TLSA RRs constrain the end-entity certificate to a fixed
   public key, there is no role for CT, and clients SHOULD NOT apply CT
   checks."

This assumes that DNSSEC is impossible to subvert. If you
realistically assume that DNSSEC may suffer from the same kinds of
issues that CAs do, then CT has a role: the detection of incorrect
issuance of certs in conjunction with incorrect DANE records.

On 16 July 2013 00:58, Wes Hardaker <[email-masked]> wrote:
>
> FYI:
>
>
>
> ---------- Forwarded message ----------
> Cc:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Seth David Schoen <[email-masked]>
Date: Tue, 16 Jul 2013 08:09:39 -0700

> issuance of certs in conjunction with incorrect DANE records.

I'd suggest that when there are multiple mechanisms available to
constrain the end-entity certificate, clients SHOULD be able to
protect themselves by taking advantage of more than one of them.
We might say that this is a matter of allowing the end-entity to
use both belt and suspenders.

-- 
Seth Schoen  <[email-masked]>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Jul 2013 15:11:32 +0000

> issuance of certs in conjunction with incorrect DANE records.

In effect you're saying you don't trust DANE (period), because
DNSSEC security is not absolute.

An attacker who can modify the server's DNS RRs can make them all
3 1 1 certificate associations, with self-signed certificates of
his choice that are not anchored at any known CA (I've posted
examples of certificates with no names in them at all, no issuer,
no subject no altnames, just the public key ma'am).  How would CT
help?

An attacker who can't modify the server's TLSA RR's cannot MITM
the connection between a client and the legitimate server since
he lacks the server's private key.

Other attacks that also compromise CT include root-kits on the
client and compromise of the of the server's private key or break-in
into the server.   I am not suggesting any problems with CT just
because it does not prevent these.

With usage 3, there are no trusted CAs, so it would be inappropriate
to attempt to impute any meaning to the validity of the certificate's
issuance.  The server operator has indicated which public key (3
1 1) provides the service, the certificate can be:

	- expired

	- name a completely unrelated entity

	- have a key usage that indicates something other than TLS server

	- ...

The attacker could also publish "2 1 1" with some synthetic CA and
a child server certificate issued by it.  Similarly CT can't help
here.

If we take DANE types 2/3 seriously, then an EE certificate match
means we're at the right place.  If we don't take types 2/3 seriously,
we're done with DANE, there's not much of anything useful left.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Jul 2013 15:16:35 +0000

> use both belt and suspenders.

Except that the suspenders aren't attached to the trousers.  The
hypothetical DNSSEC attack subverts both DANE and CT.

The CT suspenders for DANE just add weight, we're leaving CT in
place for usage 0, because once you're doing PKIX checks you may
as well do CT.

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 16 Jul 2013 16:46:09 +0100

> DNSSEC security is not absolute.

I am saying I trust CT more.

> no subject no altnames, just the public key ma'am).  How would CT

It would help because if I don't follow your SHOULD NOT, then I would
decline that certificate. As we have said before, we cannot allow DANE
to do an end-run around CT. There is no point in finding a way to fix
the problem with one set of trusted third parties only to reintroduce
it via another set of trusted third parties.

Also, as I have said before, we could mitigate this problem in DNSSEC
by also applying transparency to it.

> we're done with DANE, there's not much of anything useful left.

See above. I am happy to help with applying transparency to DNSSEC.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Jul 2013 16:01:13 +0000

> I am saying I trust CT more.

This is not surprising. :-)  And TLS clients don't need to implement
DANE.  DANE enables server operators to bind trust to self-signed
certificates (essentially bare public keys) via DNSSEC.  If the
client and server agree on this security mechanism, CT is out of
scope at the level of the server certificate, because it is self-signed
and not issued by an CA to which one can apply CT.

We're merely restating the obvious.

> it via another set of trusted third parties.

You would decline all DANE self-signed 3 1 1 certificates.  None
of them can be verified via CT.  This removes one of the primary
use cases for DANE.  So I stand by the observation that you basically
don't trust DANE (at least in its present form) regardless of CT.

> by also applying transparency to it.

The place to apply transparency here is not to the certificate in
the TLSA RR published by the domain owner, but to the chain DNSSEC
of key and signature records that lead to the TLSA RRset.  Right?

If so, this would be a new DNSSEC CT mechanism, not an X.509 PKI
CT.  It would prevent parent zones from lying about DS key signatures,
and support for this would be in the DNSSEC libraries, not in the
application TLS libraries.

With CT for DNSSEC I'd have more confidence that the TLSA RRset is
not fraudulent, and *then* still not apply CT at the TLS layer,
because the X.509 certificate is basically vestigial with DANE,
despite the 24 different flavours it is just a public key bound to
the service.

> See above. I am happy to help with applying transparency to DNSSEC.

I think that's a fine idea, but it is orthogonal to the interaction
of DANE with CT for X.509 certificates.  DANE is a parallel PKI,
so transparency for the world of PKIX CAs plays no useful role here.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Jul 2013 12:05:41 -0400

Ben,

...

> I am saying I trust CT more.
not surprising, given the source of the CT idea :-).

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 16 Jul 2013 17:25:38 +0100

> not surprising, given the source of the CT idea :-).

I was also one of the early supporters of DANE, so you can't read all
that much into that :-)

I don't care where the ideas came from, I just care about making the
'net more secure.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 16 Jul 2013 18:18:34 +0100

> application TLS libraries.

Correct.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Jul 2013 19:26:54 +0000

> > application TLS libraries.

I have nothing against this, sounds cool, if it can scale and has
a chance to get adopted by the various registries.

Should we amend the draft to change "CT interaction" to "X.509 hierarchy
CT interaction"?  To me these were synonymous.  We wanted to make sure
that it is understood that X.509 CT does not apply to DANE.

If there is someday a separate CT mechanism for DNSSEC, it is a
mechanism for determining whether DNSSEC responses are trustworthy,
and so may well be transparent to the DNSSEC consumer, or in any
case lives below the layer where the TLS client is processing
already validated TLSA RRs and trying to decide whether they
patch peer certificates.

So I think we're in violent agreement then.  What if anything needs
to be changed in the dane-ops draft?

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 23 Jul 2013 12:19:24 +0100

> don't trust DANE (at least in its present form) regardless of CT.

This seems to me to miss the point. The problem is that if we allow DANE to
verify self-signed certs, what stops an attacker from taking over DNS and
using it to certify a self-signed cert for google.com?

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 23 Jul 2013 09:44:21 -0300

> using it to certify a self-signed cert for google.com?

How is this different from taking over the CT "information publisher"
point/process?

---

From: Ben Laurie <[email-masked]>
Date: Tue, 23 Jul 2013 13:46:46 +0100

> How is this different from taking over the CT "information publisher"

CT is an untrusted, verifiable service.

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 23 Jul 2013 07:55:30 -0600

Right - It doesn't matter who takes over the log.  Either the certificate is
present in the log or it isn't. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben
Laurie
Sent: Tuesday, July 23, 2013 6:47 AM
To: Frederico A C Neves
Cc: IETF DANE WG list
Subject: Re: [dane] [[email-masked]] New Version Notification for
draft-dukhovni-dane-ops-01.txt

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 Jul 2013 14:54:32 +0000

> using it to certify a self-signed cert for google.com?

    - If you don't trust "IN TLSA 3 1 1", you don't trust DANE,
      but there is no DANE without "3 1 1", the majority of published
      TLSA RRsets will be "3 1 1". 

      It sure looks like the major browsers are not in a hurry to implement
      DANE, which is ironic, since RFC 6698 is mostly focused on browser-like
      applications, and needs adjustments for protocols like SMTP, where
      DANE will be actively implemented first.

      We're in violent agreement, you don't trust DNSSEC/DANE.
      You don't have to implement DANE.

    - With "3 1 1" the attacker would in no sense certify a
      self-signed cert for "google.com", they would temporarily
      bind a set public keys to a specific set of TLS service
      endpoints (e.g.  _25._tcp.smtp.gmail.com), this binding trusted
      by applications that (are configured to) trust DNSSEC.

    - "Taking over DNS" (really DNSSEC) is not that simple, why do you
      believe that "taking over DNS" is easier than compromising the
      user's desktop or the target server or bribe an employee with
      access to the server keys, or infect the employee's desktop.

    - You're proposing DNSSEC transparency, which would be similar
      in spirit to the recently published spec for X.509 CT.  That's
      cool.  The substance of the draft language Wes and I propose is
      to explain that X.509 CT is fundamentally at odds with DANE.

      There will in the majority of cases be no issuing CA for the
      certificates of DANE validated servers.  And if there is one,
      it will typically not be a public CA.

      The real chain of trust with DANE is the sequence of DS,
      DNSKEY and RRSIG records from the root down to the domain,
      not any chain of X.509 certificate signatures.  So if you
      want accountability for DANE along the lines of CT, I would
      support your future work on transparency for DNSSEC.  I don't
      know whether this is likely to lead to a usable, politically
      acceptable standard and ultimately deployed standard, but you
      may as well try.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 Jul 2013 15:26:02 +0000

> present in the log or it isn't. 

Not that simple, since there is a window during which the data is not
yet in the log.   If the attacker only needs to convice a victim that
a fraudulent site is legimate for a brief time, the log is not a major
deterrent.

Compromise a weak CA, and don't publish the promised chain to the
log.  Serve the chain to a victim (compromise that victim and erase
its memory of ever seeing the evil cert chain).  Various other
difficult, but not impossible attacks.  No security system is
perfect.

Audit trails are very useful, but there is no perfect audit trail
either.  One can attack the audit trail.  I have nothing against
CT, all I am saying is that X.509 CT is not for DANE (TLSA).

Clients that trust DANE dont't benefit from X.509 CT.  They could
benefit from a hypothetical implementation of DNSSEC transparency,
but that would happen at the DNSSEC lookup layer, and would not
involve the vestigial X.509 certificates.

By all means harden DNSSEC with any reasonably appropriate mechanisms.

-- 
	Viktor.

---

From: Jack Bates <[email-masked]>
Date: Tue, 23 Jul 2013 08:46:59 -0700

On 23/07/13 04:19 AM, Ben Laurie wrote:
>
> On 16 July 2013 17:01, Viktor Dukhovni <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> This seems to me to miss the point. The problem is that if we allow DANE
> to verify self-signed certs, what stops an attacker from taking over DNS
> and using it to certify a self-signed cert for google.com
> <http://google.com>?

Could I upload a self-signed certificate to CT, and have CT add it to 
the log if it matched a DANE DNS record? Would that add any protection?

CT normally checks that the certificate is rooted in a known CA 
certificate, to avoid logs being spammed into uselessness. Could it also 
accept self-signed certificates that match a DANE DNS record?

If you take over DNS, you can probably get a certificate issued by some 
known CA? CT adds protection by requiring that certificate to be 
published, where it can be audited.

If in addition to publishing a self-signed certificate with DANE, you 
also publish it with CT, does that similarly add any protection? Or is 
auditing CT just the same as auditing DNS? (Auditing that the DNS for 
google.com isn't compromised)

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 Jul 2013 16:10:37 +0000

On Tue, Jul 23, 2013 at 08:46:59AM -0700, Jack Bates wrote:

> Could I upload a self-signed certificate to CT, and have CT add it
> to the log if it matched a DANE DNS record? Would that add any
> protection?

To be useful, it would have to be submitted along with the chain
of DNSKEY and RRSIG records that validated it.  Otherwise one learns
nothing (anyone can submit bogus certificates claiming they were 
matched by DANE and make the system useless).

Note that there would also be little point in submitting the actual
certificate, it is uniquely fingerprinted by the TLSA RRset and
the domain owner could check that any log contains no unauthorized
public key digests, ... more efficiently than looking for a
certificate.

Furthermore, there is not even much point in submitting the TLSA
RRset, since if all the keys in the chain are legitimate, the actual
record is sound and not needed in the log, provided the leaf key
is not leaked to the attacker.  The only thing that submitting the
TLSA RRset audits is attacks that steal the leaf key of the domain
owner.

So we're back to DNSSEC transparency, with a question as to which
records DNSSEC transparency would cover, just the chains of DS,
DNSKEY and RRSIGs, or also security-related leaf records (TLSA,
SMIMEA, SSHFP, ...).   I don't known that covering all the leaf
records would scale well.  Note that attacks that compromise the
domain owner's keys can equally compromise other elements of their
infrastructure, CT is primarily about keeping 3rd parties honest.

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Jul 2013 09:38:25 -0700

Ben Laurie <[email-masked]> writes:

> This seems to me to miss the point. The problem is that if we allow
> DANE to verify self-signed certs, what stops an attacker from taking
> over DNS and using it to certify a self-signed cert for google.com?

I think the wording in the current draft doesn't explain the context
very well, just like you agreed a while back that the wording in the CT
document doesn't explain things well either in terms of when CT does
apply.  What I would like for the -ops draft to state clearly where dane
applies and how it may or may not interact with CT.  The reality is that
CT and DANE are two very different models, and they interact heavily in
odd ways and I think the end result is that we need a document that
simply says "it probably won't help you to do both at once".  Each has
negative impacts on the other.

The reality is that there are two different models.  And *each* use case
needs to pick one:

  CT:
    - Places trust in CAs, and their assurance statements
    - Trust in the audit records provided to logs by the CAs
    - Zones can check that no one else has issued certs they don't know
      about by checking the log (but requires everyone who cares to
      check the log)
    - Eventually does away self-signed certificates entirely in the long
      term future and requires registration with a CA when an
      application refuses anything not in a log
    - most vulnerable points: CAs and the audit logging systems

  DANE:
    - Places trust in DNSSEC
    - Requires DNSSEC to be deployed, but it's not deployed heavily yet
    - Allows for CA signed and self-signed infrastructures
    - Vulnerable point: the dns (insert a fake TLSA record and the game
      is won).

Each protocol, or an implementation of a protocol must chose which model
they trust.  Simply put, if you trust the CT system then you don't do
DANE.  If you trust the DANE system, then it's pointless to trust CT (as
you spelled out above).  Each system must pick one.

For the web with browsers, it's clear that browser and CA vendors want
the CA/CT path.  Great!  Then DANE is not of consequence, because it
won't be implemented.  Thus the part in the DANE ops draft that talks
about interaction with CT clearly does not apply, because the
implementations won't be doing DANE in the first place.

For the web with scripts (curl, etc), I could see command line options
to select between them (--ct or --dane) so that the criteria can be
picked at run-time.  I'd love to see that preference radio dialog in a
web browser too, but I'm not holding my breath.

For SMTP, clearly DANE is the choice going forward both because the
dominate implementations are selecting it and because the CA model
can't work in a STARTTLS environment.  Clearly, they shouldn't do CT
at all.

The draft, however, tries to discuss the oddball cases where people
actually do attempt to use both.  The security considerations section
really needs a strong note that says if you trust in both, you end up in
a situation that is broken.  So don't do that.  Pick one.  Because
you're right: turning on DANE support when CT is in play breaks CT.  And
clearly, CT breaks DANE because it rules out discoverable self-signed
certs.

Ideally, there should be a document that compares and contrasts and
points all of this out.  The problem, however, is that it shouldn't be
in either a dane specific draft (like the dane-ops draft), nor should it
be in a CT specific draft (not that there are any more coming).  There
is no "current" place to document the important elements of the choice
that must be made for protocol designs and/or implementers.

-- 
Wes Hardaker
Parsons

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Jul 2013 10:41:35 +0100

On 23 July 2013 15:54, Viktor Dukhovni <[email-masked]> wrote:

> to

SMTP starts from a position of no assurance at all, so even DANE improves
it.

>       access to the server keys, or infect the employee's desktop.

Two points:

1. I believe it because I see DNS getting taken over on a regular basis -
perhaps not as often as user's desktops are taken over, but then, targeted
attacks are not the only attacks. And not all desktops are equally
vulnerable.

2. Just because an attack is not the easiest attack, that does not mean we
should not defend against it.

>       to explain that X.509 CT is fundamentally at odds with DANE.

What it says, though, is that DANE trumps CT, which is not really the
position.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Jul 2013 10:47:30 +0100

>     - Places trust in CAs, and their assurance statements

The whole point of CT is avoiding placing trust in anyone.

>     - Trust in the audit records provided to logs by the CAs

Again, no trust.

>       about by checking the log (but requires everyone who cares to

A quibble, really, but: people who care can hire others to check for them -
and I imagine this will be what happens for the most part.

>       application refuses anything not in a log

One reason I would like to make DNSSEC/DANE an acceptable alternative is
because it would be unfortunate to do away with self-signed certs.

>     - most vulnerable points: CAs and the audit logging systems

It depends what you mean by vulnerable - CAs vulnerability is mostly
unchanged by CT, and logs are untrusted...

> DANE.

Once more: the point of CT is you don't have to trust it.

>  If you trust the DANE system, then it's pointless to trust CT (as

Why is that clear? CT is perfectly applicable to SMTP - also, I don't
understand why CAs can't work with STARTTLS?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Jul 2013 10:57:53 +0100

> because it would be unfortunate to do away with self-signed certs.

I think that's an excellent reason fwiw. There are I guess
a large number of web sites with self-signed certs that work
just fine now, and making that work better somehow, rather
than making 'em worse seems like a good goal. Even if
making that situation better via DNSSEC might not be the
easiest path one could imagine, its still well worth having
the option worked out.

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Jul 2013 14:10:12 +0000

> because it would be unfortunate to do away with self-signed certs.

I generate a self-signed certificate and publish:

    _25._tcp.mx.example.com. IN TLSA 3 1 1 <public key SHA-256 digest>

how is a TLS-enabled SMTP client to apply CT in this situation?  My
reading of 6962 (particularly the text I took the liberty to shout out
in upper case):

   Each log consists of certificate chains, which can be submitted by
   anyone.  It is expected that public CAs will contribute all their
   newly issued certificates to one or more logs; it is also expected
   that certificate holders will contribute their own certificate
   chains.  In order to avoid logs being spammed into uselessness, IT IS
   REQUIRED THAT EACH CHAIN IS ROOTED IN A KNOWN CA CERTIFICATE.  When a
   chain is submitted to a log, a signed timestamp is returned, which
   can later be used to provide evidence to clients that the chain has
   been submitted.  TLS clients can thus require that all certificates
   they see have been logged.

is that it it impossible to apply X.509 certificate chain transparency
here.  What am I missing?  If there were a DNSSEC transparency
standard, it could well be applicable and would help with keeping
the 1LDs, 2LDs, ... honest if there is a concern about unauthorized
DS RRs being signed by parent zones.

> understand why CAs can't work with STARTTLS?

In the tiny fraction of cases where SMTP is compatible with PKIX,
CT is then indeed compatible with SMTP.  See:

https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01#section-1.2

   The Simple Mail Transport Protocol (SMTP) ([RFC5321]) is multi-hop
   store & forward, while TLS security is hop-by-hop.  The number of
   hops from the sender's Mail User Agent to the recipient mailbox is
   rarely less than 2 and is often higher.  Some hops may be TLS
   protected, some may not.  The same SMTP TCP endpoint can serve both
   TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS
   command ([RFC3207]).  MX RRs abstract hop destinations via DNS.  SMTP
   addresses are not transport addresses and are security agnostic.
   Unlike HTTP, there is no URI scheme for email addresses to designate
   whether the SMTP server should be contacted with or without security.

   A Mail Transport Agent (MTA) may need to forward a message to a
   particular email recipient <[email-masked]>.  To deliver the
   message, the MTA needs to retrieve the MX hosts of example.com from
   DNS, and then deliver the message to one of them.  Absent DNSSEC, the
   MX lookup is vulnerable to man-in-the-middle and cache poisoning
   attacks.  As a result, verifying MX host certificates without using
   DNSSEC is futile as the attacker can simply forge DNS replies and
   issue bogus MX records, directing traffic to a server of his choice.

	[ Given DNSSEC nomenclature, "bogus" is unfortunate above,
          we should say "fake", fixed in Git. ]

   One might try to harden STARTTLS with SMTP against DNS attacks by
   requiring each MX host to posess an X.509 certificate for the
   recipient domain that is obtained from the message envelope and is
   not subject to DNS reply forgery.  Unfortunately, this is
   impractical, as email for many domains is handled by third parties,
   which are not in a position to obtain certificates for all the
   domains they serve.  Deployment of SNI (see [RFC6066] Section 3.1) is
   no panacea, since the key management is operationally challenging at
   large scale unless the email service provider is also the domain's
   registrar and its certificate issuer; this is rarely the case for
   email.

   A man-in-the-middle can also suppress the MX host's STARTTLS EHLO
   response.  Unless the sending MTA is statically configured to use TLS
   for mail sent to example.com, the message will be sent
   unauthenticated and in the clear.  Sender-side configuration of peer-
   domains for which TLS must be used can protect an organization and a
   few of its business partners, but is not a viable approach to
   securing the Internet email backbone.  Internet email requires
   contacting many new domains for which security configurations can not
   be established in advance.

> Once more: the point of CT is you don't have to trust it.

CT is part of the broader story of PKIX CAs, with CT to keep them
honest.  So a more clear statement could be that if one is doing
PKIX with CT one is not doing DANE.  Thus the dichotomy is between
trusting DNSSEC + DANE vs. trusting a set of public CAs plus CT as
an audit trail.

So more to the point conversely, if one is doing DANE (which necessarily
includes support for "IN TLSA 3 1 1" EE public keys) if this case is not
protected by X.509 CT (please explain how it could be, perhaps we've
missed some import detail of CT) then since attackers who compromise
DNSSEC are free to choose "3 1 1", there is no defence against DNSSEC
compromising attacks via CT.

> unchanged by CT, and logs are untrusted...

My incomplete reading of 6692 suggests that logs are "trusted" to
not disclose their signing keys and to actually publish the data
they've committed to publish.  This is not the same as trusted to
authenticate the peer, but it seems they are trusted to securely
play their role in the protocol.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Jul 2013 14:23:33 +0000

> SMTP starts from a position of no assurance at all, so even DANE improves

Yes, but the key observation is that PKIX cannot improve it absent
DNSSEC (which must therefor be trusted, Wes will explain this in
Berlin).  So the *only* path to securing SMTP on Internet scale is
with DANE.

> attacks are not the only attacks. And not all desktops are equally

Do you mean attacks on the client<->registrar authentication weak
link?  Hijacking of domains that are not registrar locked?  Or DNS
reply forgery?

With DANE, as you know, we are assuming DNSSEC, so presumably the
reply forgery attack is out of the picture.

> What it says, though, is that DANE trumps CT, which is not really the

We are trying to say that clients that choose to trust DANE, can't
benefit from CT, given the required support for DANE's primary use
case: 3 1 1.  Perhaps we failed to understand how to apply CT to
this case.

My reading of the CT RFC could well have glossed over some critical
ingredient.  How does CT work with EE self-signed certificates? Perhaps
there is more to it than the text below indicates:

   https://tools.ietf.org/html/rfc6962#section-1

   chains.  In order to avoid logs being spammed into uselessness, it is
   required that each chain is rooted in a known CA certificate.  When a

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 25 Jul 2013 10:14:39 +0100

> play their role in the protocol.

This is incorrect - if logs fail to publish (or otherwise fail to follow
the protocol), this can be detected - no trust involved.

Disclosing a log's signing keys would be unwise, because whoever has them
might decide not to follow the protocol (indeed, it would be hard to
correctly follow it without all key holders collaborating closely), in
which case the log will no longer be usable. But one does not have to trust
the log to not do this, again, abuse of the key can be detected.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 25 Jul 2013 10:21:22 +0100

> Berlin).  So the *only* path to securing SMTP on Internet scale is

That is a strong claim which I find a little hard to swallow, certainly
without some supporting evidence.

> link?  Hijacking of domains that are not registrar locked?

I mean attacks on registrars and registries. Registrar lock is not a magic
spell that suddenly makes the DNS invulnerable.

>  Or DNS

Forgery attacks are available even in DNSSEC to the parent.

> case: 3 1 1.  Perhaps we failed to understand how to apply CT to

No, I think you understand it correctly - and I think Wes has summed it up
best: what we really need is a document that discusses tradeoffs between
the two protocols.

Or, really, what we need is a way to make DNSSEC stronger than PKIX (+ CT),
not weaker, then this discussion would be moot.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Jul 2013 17:26:25 +0000

> without some supporting evidence.

The supporting evidence is in the draft.  SMTP security is inextricably
bound to the security of DNS, if DNS is insecure, SMTP is compromised,
thus DANE is the only reasonable security architecture for SMTP (for
the Internet at large).

    - SMTP addresses are transport security agnostic, and STARTTLS
      discovery is subject to obvious MITM downgrade attacks.

    - SMTP addresses are end-to-end, TLS security is hop by hop,
      the security for a given hop must is necessarily out of band
      (not implied by the address).

    - MX records indirect from the recipient domain to the target server.
      Absent DNSSEC and barring a miraculously scalable implementation
      of SNI with every MX host holding certificates for the hosted
      domain (which may also let it impersonate web servers for
      the domain, ...) the SMTP client has no secure mechanism to
      perform certificate name checks.

In short without DNSSEC the SMTP client does not have a secure copy of
the server's name, and does not know whether the server supports TLS.

DANE addresses both downgrade-resistant TLS *discovery* (does the
peer support TLS), clarifies which name to expect in the peer's
certificate (the TLSA base domain) and provides relevant key material
to support authentication (MTAs often have empty or incomplete lists
of root CAs, with DANE usage 2/3 an empty CA list works fine).

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Jul 2013 08:18:32 +1000

> without some supporting evidence.

You need to secure the MX lookup.  This is 100% dependent on DNSSEC working.
After that DANE/PKIX can be used with STARTTLS.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Jul 2013 22:36:46 +0000

> After that DANE/PKIX can be used with STARTTLS.

One also needs a downgrade-immune indication of STARTTLS support.
And without DANE one has no idea what to expect to find in the
server certificate, it may be and often is self-signed, ...

Since trust in DNS is unavoidable, securing SMTP via DNSSEC is the
only sensible thing to do.  Throwing PKIX into the mix adds no
value, if DNSSEC is compromised, game over.  Thus the new SMTP
draft you (those attending) will be discussing in Berlin.

-- 
	Viktor.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 26 Jul 2013 09:33:38 +0100

> After that DANE/PKIX can be used with STARTTLS.

Ah! Fair point.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 26 Jul 2013 10:28:52 -0400 (EDT)

> One also needs a downgrade-immune indication of STARTTLS support.

Note that (contrary to my opinion at the time) people decided that the
precense of a TLSA record would not indicate "TLS only". A draft was
written for the HASTLS record to specify that, which seems to have
been pretty much ignored. So now people really have no choice but to
take the presence of a TLSA record as the only indication not to
downgrade to no TLS.

I guess an ERRATA is not the proper way for clarifying this - perhaps a
small RFC should be written to formalize this behaviour? [*]

> value, if DNSSEC is compromised, game over.

That's not entirely true. If you get the TLS certificate via other
means, eg PKIX or certificate pinning (or TACK) or via another
reputation system, you could in fact decide that _despite_ DNSSEC
saying otherwise, you will not connect to a different TLS certificate
as it seems DNS was compromised.

Paul
[*] chairs can add this to "other business" in Berlin :)

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Jul 2013 15:02:53 +0000

> small RFC should be written to formalize this behaviour? [*]

Perhaps the lack of general (application protocol independent)
guidance on this topic is due in part to the fact that with some
application layers TLS is required by the destination address syntax
(e.g. HTTPS URL).   Tony's SRV and SMTP drafts, as well as SMTP draft,
therefore specify that for DANE with SMTP "TLSA" presence implies a
TLS requirement (subsumes HASTLS).

So I am not too worried about lack of precision on this point in 6698.

> as it seems DNS was compromised.

DNSSEC secures the MX record, and TLSA RRs provide a mandatory TLS
indication, plus base domain for TA usages plus authenticated key
material.  Client maintained out-of-band TLS information does not
scale.  MTAs are non-interactive, when a site updates MX records,
the MTA must send to the MX records it finds, it can't pop a dialogue
to ask the user.

Pinning the MX hosts and or certificates for a set of domains is
not an architecture for securing SMTP on an Internet scale.  It
can certainly be done (and is done at some sites) for a handful of
"high value" (to the sender) domains, but this ad-hoc approach does
not scale.

Until recently I was the postmaster of a site with O(100) such
manual TLS policies,  each one was a pain to setup (30minutes of
conf call with the peer site's email admins) and the resulting
static configurations were fragile.

FWIW, when I say that SMTP with PKIX does not scale, I mean it,
and have the scars to prove it.  I chose to implement DANE in
Postfix because it addresses a real problem which has resisted
solution for over a decade.

    http://www.postfix.org/TLS_README.html#client_tls_limits

-- 
	Viktor.

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 26 Jul 2013 14:19:26 -0700

Hi Victor, all,

Don't mean to derail discussion but I heard the word pinning... :-)

> static configurations were fragile.

That's pretty interesting, I didn't know there was SMTP manual pinning
on that scale.  If you don't mind sharing, I'm curious:
 - Can you configure TLS pins on common mail servers?
 - Is this a common practice?
 - Are there any efforts at aggregating and sharing pin lists, so they
don't need pairwise phone calls?

FWIW, the way we saw cross-domain SMTP working for TACK was:  If the
sending MTA indicates TACK support in its TLS ClientHello, the
receiving MTA could return a "tack", and the sender could activate a
pin between the TACK Signing Key and the email recipient's domain
name.  (NOT the mailserver's name - this would be special cross-domain
SMTP semantics).

This assumes the sending MTA would send the MX hostname in TLS SNI,
and the receiving MTA would use this to determine which certs / tacks
to return.  (Not sure this is workable, but I think DANE SRV [1]
expects to use SNI in a similar way?)

Anyways, aside from this, the MX hostname wouldn't matter for the pin
validation.

Trevor

[1] http://tools.ietf.org/html/draft-ietf-dane-srv-02

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Jul 2013 21:36:40 +0000

>  - Can you configure TLS pins on common mail servers?

Postfix supports a "fingerprint" security level, but in most cases, the
manual security arrangements used PKIX with hand-crafted name checks.
So we did not often "pin" certificates with outside parties, such pins
were only used from time to time on SMTP links where we controlled the
certificates on both ends.

>  - Are there any efforts at aggregating and sharing pin lists,
> so they don't need pairwise phone calls?

Yes, there was an industry effort to aggregate TLS configuration
data, but it never went very far.  I am hoping DANE will obviate
the need for this, provided we can get people to adopt DNSSEC.

> name.  (NOT the mailserver's name - this would be special cross-domain

I don't think this is practical for SMTP.  My focus is on DANE.

-- 
	Viktor.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 30 Jul 2013 13:22:43 +0200

Hi,

I am (re-)reading the drafts before the meeting and I have few comments:

1. the high/low bit part in "2.  DANE TLSA record overview".

Please drop/rewrite the bit part since it will become confusing when we adopt draft-ietf-tls-oob-pubkey for DANE.

2. Section 3.5 on CNAMES

The recommendation to follow the CNAME chain and do hop-by-hop checks won't work with most used protocol - HTTPS.  Generally you expect an TLS certificate for "www.iamconnecting.to" and not for "server.provider.srv" as suggested by the draft.

Also checking for CNAME means that the DANE PKI client would have to (re-)implement whole follow-the-CNAME login instead of using simple getaddrinfo().

So I am not sure if this is a sensible default.

O.

On 16. 7. 2013, at 1:58, Wes Hardaker <[email-masked]> wrote:

> Date: 16. července 2013 1:45:48 GMT+2

--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 30 Jul 2013 15:23:32 +0000

On Tue, Jul 30, 2013 at 01:22:43PM +0200, Ond?ej Sur? wrote:

> Please drop/rewrite the bit part since it will become confusing when we
> adopt draft-ietf-tls-oob-pubkey for DANE.

Since we only discuss usages 0-3, perhaps the "bit part" can be restricted
to cover just those 4 usages.  Clearly usages 4 and up are likely to break
the pattern.  Or we can change the wording.  It really is not important
that the feature matrix for 0-3 is bit-aligned.

By the way, is there any reason to adopt a new usage for bare public
keys?  What's wrong with "3 1 1"?  Existing TLSA associations that
match public keys inside an EE certificate can equally match public
keys that are not inside a certificate.

> 2. Section 3.5 on CNAMES
> 
> The recommendation to follow the CNAME chain and do hop-by-hop
> checks won't work with most used protocol - HTTPS.  Generally you
> expect an TLS certificate for "www.iamconnecting.to" and not for
> "server.provider.srv" as suggested by the draft.

What may be missing from the draft, but was intended to be there,
is a fallback to the initial name when no TLSA RRs are found at
the CNAME expanded target.  Certainly, for example, when the final
target is in an insecure zone (prime example from Wes: www.paypal.com).

If however, there is a TLSA RRset on the right side of a secure
alias, it makes sense to use that in preference to the initial
name. As explained loudly in the POSH BOF on Monday, key sharing
with SNI is not for everyone, and finding a way to use the provider's
keys securely is far better.

In effect all that POSH is trying to do is a secure redirect, but
in a complicated ad-hoc manner via PKIX HTTPS servers.  That's a
bit lame IMHO.  But they are identifying a real need to get past
SNI.  If we model the old world of HTTPS too closely, we capture
its unintended faults (no CNAME chasing and hence SNI, because
without DNSSEC CNAMEs are MITM vulnerable) as well as its useful
features.

There is no axiom that HTTPS secure names must be what the user
typed.  It is  just that's all that was possible previously.  With
DNSSEC+DANE we *can* do better (obviate SNI and solve the issue
that motivates POSH).

Also keep in mind that the browsers seem to be the least likely to
implement DANE any time soon.  Basing DANE on the application least
likely to adopt it seems a bit perverse.

Anyway, I'll be in the chat room on Thursday, I am hoping Wes will
cover this issue in detail.

> Also checking for CNAME means that the DANE PKI client would have
> to (re-)implement whole follow-the-CNAME login instead of using
> simple getaddrinfo().

They already need a DNS API.  This is not a big deal.

> So I am not sure if this is a sensible default.

It is certainly worthy of discussion!  But I would point out the
POSH BOF as a strong signal that dealing with hosting is a very
important issue.  For protocols with SRV (and SRV-like MX, â¦)
records indirection is already largely dealt with.  I wanted to
make CNAMEs behave like poor-man's SRV records and deliver the same
benefit.  That's is allow the client to discover the hosting
provider's name!  Thereby avoiding the pain and suffering of SNI.

-- 
	Viktor.