Richard Barnes | 25 Jul 17:59 2014

DANE transparency

I didn't get my thoughts put together in time to get to the mic in the meeting today, but here's roughly what I was going to say:

tl;dr: Spam on CT logs is the only major problem to solve here, and protocol is probably not the way to solve it.

Doing transparency for the whole of DNSSEC is an unsolvable problem.  It's massive, like Wes pointed out, and littered with tautological pitfalls.  I could imagine some form of "DNSSEC pinning" allowing subordinates to impose hysteresis on frequently-accessed domains, but going further than that quickly approaches the madness that Stéphane noted.

Instead of focusing on the internals of DNSSEC, we should focus on the things that actually impact protocol, i.e., the TLSA records at the leaf.  Normal CT is totally sufficient for these -- certs/pubkeys asserted in TLSA are still certs/pubkeys.  If we need to change the syntax to capture things slightly differently, we should do that, but it seems straightforward.

The only reason that chains are needed in CT is to defend against spam.  With DANE, the potential spammer is the authority, so he can make as many spam domains as he wants.  So the "DNSSEC chain" is useless for spam mitigation.  It's all so possible that DANE-asserted certs will change more often, so again, we might want to tweak what's logged (e.g., to log the public key).  Fairly minor change.

We're left with the question of how to prevent spam.  I'm not sure there's a protocol mechanism here.  It seems like you could have a local policy at the log to, say, limit the rate of updates that are accepted.

So I think we should:
1. Forget about solving DNSSEC transparency generally
2. Focus on getting CT ready for DANE
3. Identify any tweaks that are necessary to support DANE-asserted certs
4. Maybe write some guidelines for anti-spam


Trans mailing list
Trans <at>
Eran Messeri | 23 Jul 22:30 2014

When are non-EE certificates expected to be logged?

Following a discussion about correlating SCTs to certificates (ticket 23):

My understanding is that any intermediate CA certificate may be logged (either as a Precertificate or after issuance) *in addition* to the end-entity certificate.

RFC6962 only requires TLS clients to validate SCTs for server certificates (presumably end-entity certificates), so SCTs for any intermediate is not very useful.

The only case I see where an intermediate CA certificate is logged *instead* of a CA certificate is when a Name-Constrained intermediate CA cert is logged.

In light of this, it seems that ticket 23 can be solved by specifying that TLS clients check all non-embedded SCTs against the end-entity certificate or the intermediate certificate with extension OID

Trans mailing list
Trans <at>
Melinda Shore | 23 Jul 15:19 2014

Contributing to the issue tracker

I've been reminded to remind everybody that the issue tracker
( is currently
open to additions from anybody who's got an IETF tools account.
Please review the open tickets, but also add tickets for issues
you've identified that need to be resolved before 6962-bis will
be ready for working group last call.  (It would be helpful
to start a discussion on the mailing list before opening a

In the event that the tracker is abused we'll restrict access,
but for the time being we're keeping it open.  Note that Eran
Messeri is the de facto issue tracker editor and can help
with issue tracker questions, etc.


Melinda Shore | 21 Jul 17:09 2014


If you're going to be showing slides during the trans
working group session on Friday, please send them to
Paul and me by noon Thursday, EDT.


Melinda Shore | 21 Jul 15:30 2014

Meetecho available during trans session

For those unable to be physically present during the
trans session on Friday, we've requested Meetecho
coverage.  The link will be:
once the session is underway.

Rick Andrews | 18 Jul 20:11 2014

List of Roots Accepted by Log Servers

I finally got around to reading the list of roots accepted by the pilot and aviator log servers (using the get-roots command). I see a number of our roots that seem inappropriate to me, meaning that we have never issued SSL certs (EV or non-EV) from those roots, and never intend to. It seems to me that Google cast a wide net to add all relevant roots to kickstart the log servers (perhaps bootstrapped from Mozilla’s root list?), but at some point (before CT is “live”) I would like to see the list trimmed.
My thinking is that if I somehow issue an SSL cert from a root that I did not intend to use for SSL, I would prefer to catch that as quickly as possible; ideally, when the log server refuses to give me an SCT. Is Google willing to remove roots from pilot and aviator?
I think we need a somewhat formal way for CAs to provide log server operators their list of roots, and update that over time. For example, we have a few new roots that we expect to be using in the next few months, and I need to make sure they’re added to log servers before I start using them. If log server operators provide an service level agreement (SLA) for such changes, that would be great.
Trans mailing list
Trans <at>
Internet-Drafts | 10 Jul 18:53 2014

I-D ACTION:draft-ietf-trans-rfc6962-bis-04.txt

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public Notary Transparency  Working Group of the IETF.

    Title         : Certificate Transparency
    Author(s)     : B. Laurie, et al
    Filename      : draft-ietf-trans-rfc6962-bis
    Pages         : 31 
    Date          : 2014-07-10 

   This document describes a protocol for publicly logging the existence
   of Transport Layer Security (TLS) certificates as they are issued or
   observed, in a manner that allows anyone to audit certificate
   authority (CA) activity and notice the issuance of suspect
   certificates as well as to audit the certificate logs themselves.
   The intent is that eventually clients would refuse to honor
   certificates that do not appear in a log, effectively forcing CAs to
   add all issued certificates to the logs.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.

A URL for this Internet-Draft is:

Internet-Drafts are also available by anonymous FTP at:

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Attachment (draft-ietf-trans-rfc6962-bis): message/external-body, 70 bytes
Trans mailing list
Trans <at>
Melinda Shore | 9 Jul 19:33 2014

Meeting agenda uploaded

I've uploaded a first cut at a meeting agenda for IETF 90.
Please let Paul and I know of any changes or additional requests.
Also, if you've got a slot on the agenda please get slides to
us by Wednesday before the session; it's a big help for remote
participants and non-native English speakers to have those
available reasonably well in advance.

Melinda Shore | 9 Jul 04:21 2014

Walking through the issue tracker: Ticket #10

I see that Rob's taken ownership of this one (on precertificate
SCTs and OCSP) - it looks like there was agreement about how
to handle it, but is there text?


Melinda Shore | 4 Jul 01:18 2014

Toronto planning

We've got a 2.5-hour slot on Friday, and based on discussions with Paul
and Ben, here's what we think is going to be on the agenda:

1) 6962bis status, updates, issues.  This will include discussion
   of issues raised on the mailing list, issue tracker tickets against
   the document, and so on

2) Gossip protocols, or rather a gossip protocol proposal.  I do not
   believe there is a write-up of this anywhere yet, so this should be
   seen as the start of that discussion

3) Other applications.  We've had some discussion both here and offline
   of dnssec logging, and there's been some interest in logging
   signatures of executables/binaries

4) any other work that needs to be done.  At the last meeting we had
   a brief discussion of whether or not a client behavior document
   should be separated out of the bis document; without a volunteer to
   do it the question is moot.

What are we omitting or have we forgotten?  We'll get a firmer agenda
out towards the end of next week, based on this list and any additional

Melinda Shore | 3 Jul 21:57 2014

Walking through the issue tracker: Ticket #8

This ticket asks about a mechanism for looking up Merkle proofs for a
batch of certificates around the SCT timestamp.

It looks as if there's an agreement to provide a DNS-based mechanism.
It may be worth pointing out that it's occasionally difficult to get
agreement to move data into the DNS and that we'll need to be prepared
to answer questions about that in order to get the document through the
process.  So, if you're not familiar with RFC 6950 ("Architectural
Considerations on Application Features in the DNS") it may be worth
giving it a read.

Should this ticket be closed?