Subject: [Trans] IETF 94 TRANS minutes Draft

From: "Salz, Rich" <[email-masked]>
Date: Mon, 2 Nov 2015 05:38:16 +0000

Certificate Transparency (trans)
IETF 94; 13:00-15:00 Monday 2 November 2015
Chairs: Melinda Shore, Paul Wouters
Minutes by Rich Salz

STATUS UPDATE
--------------------
* milestone review and reset; not great. Initial WGLC date 12/2014, proposed now 12/2015.  Gossip 10/2016; threat 7/2016

* open trac issues run-down (Eran) ; 59 comments and 12 tickets closed since IETF-93 (mainly via Rob Stradling). Details: 75 wording; 5 and 70 adding extensions to STH's; 77 remove client behavior; 96 log metadata not dynamic and distribution is out-of-scope; 106 add LogID to STH; 107, make TLS-encodable; 110 reorganize requirements into separate sections; 105, shrink logid via OID's not a hash value (reduces SCT size by nearly a 3rd).
Open tickets divide into three areas: missing functionality (104, 10, 109), "better wording required" where there is consensus, but editorial work needs to be done (64,76,78,93,94,95,99), technicalities/small issues (81,83,87,102,108,53,97).  Feedback, particularly on domain redaction, is wanted.  Bryan brought up STH extensions issue: all extensions being signed is problematic if, e.g., the thing being added is an "alternate signature"  To followup offline.

* implementation news?  OpenSSL is implementing it. Other working on Google ref code, want to add STH extensions.

THREAT ANALYSIS
---------------------
 (Steve Kent; not present)  No comments, so ready for WGLC?  Melinda: no, we need reviewers. Volunteers include: Eran, Bryan, Rich, Karen.  See Steve's slides (in proceedings) for questions about the doc. Will there be an architecture document?  Eran volunteered to edit, dkg volunteered to contribute.

GOSSIPING IN CT (Linus Nordberg)
-----------------------------------------
At IETF 93, WG adopted, no major changes to previous mechanisms; better wording including rationale.
Policy recommendations.
Issues: STH freshness. Protection of locally-trusted roots? Log misbehavior that is privacy sensitive? What is "same domain" for SCT feed back? Define data format for trusted auditors?  Various TBD and TODO in the text.
Discussion about what inclusion proof is/contains. Dkg and bryan agree embedding them in cert is probably bad idea.

LOG SERVER OPERATIONS
--------------------------------
Karen O'Donahue is interested in operational issues of public log servers. Governance model. What do we need to get this deployed more? If you're interested, contact her. There was post-meeting discussion about risks, e.g. 

POTENTIAL NEW WORK
-----------------------------
* Architecture draft -- see above.

* Logging binary (executable) signatures (Daniel Kahn-Gillmor/Dacheng Zhang) -- update from dkg:  various participants including debian, freebsd, python pip, node.js; if you if distribute "binary artifacts" contact [email-masked]  Right now working on identifying common attributes. Early stages. Bryan: what if attacker turns off CT for future updates? Dkg: yes, that's an issue, but main goal is to detect unlogged/malicious software. Linus: are you protecting mis-use of existing signing keys? Dkg: yes. Paul: Fedora is interested. Are other implementations being done to allow this (generalization)? Linus, Eran: yes. dkg: No timetable yet for WG ID; if we can come to agreement, we'll come to the WG.

* DNSSEC logging (Paul Wouters): Some agreement on what to log, e.g. not A or AAAA records, but rather the path. Wes: concern about parent/child relationship this doesn't protect that. Paul: not sure, but mostly concerned about domains moving across registrars and such. Have to keep every DS record ever seen? Poul: share Wes's concerns, there are operational issues similar to key rollover.  Wes: useful if married to public suffix list. PHB: I'm interested in protecting against attacks from my registrar or registree.  Dkg: Suggest get experience by logging the root zone. Stefan: DNS lookup doesn't imply actually visiting the site; Paul agrees. There will be a BarBof this week (per Melinda), watch mailing list. Paul: draft concentrates on data formats and we now see that there important issues to resolve first.

* CT over DNS (Eran): Seeking feedback. Motivation is to preserve privacy for inclusion proofs, by not having them go to logs and disclose. New query is TXT lookup for base32-leafhash.hash.domain (slide moved too fast). Various TXT retrievals walk through the Merkle proof. Server returns as many nodes as it can (probably around seven). Also defined TXT query for sth.certid.domain  Similarly TXT consistency proof query/steps.  Doc in Github repo, to be updated shortly. Linus: Will it explode with 100M certs? Eran: no. Wes: how many new DNS servers? Eran: we're doing custom server, it's dynamic. Wes: is this DNSSEC signed? Eran: probably not needed since the data is signed.

STH COLLECTIVE SIGNING  (Bryan Ford)
-----------------------------------------------
Split multiple authority functions across multiple parties so that single compromise doesn't break. This is complementary to gossip. Motivation is clients in tyrannical environment where "ruler" has stolen private keys.  Raise the number of keys that need to be stolen to a very large number.
CoSi: scalable collective signing. Authority generates statements; witnesses countersign in an efficient way. Uses Merkle trees, Schnorr signatures and multisignatures. Allows for server failures (assumed rare but not negligible). Implementation https://github.com/DeDiS/cothority includes integration into Google CT log server (demo shown). Interested in getting more participation. Eran: do users need all the witness keys?  Bryan: no, only STH.
Want feedback, too early to have a WG adopted document.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 2 Nov 2015 15:17:55 +0900

Thanks, Rich.  Participants: please send comments/corrections/etc.
to the mailing list.

On 11/2/15 2:38 PM, Salz, Rich wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Karen Seo <[email-masked]>
Date: Mon, 2 Nov 2015 07:25:20 -0500

Could not attend IETF 94. So reading the minutes ...

 >>Will there be an architecture document?

Not sure of the context of the above question but an architecture draft 
was published on October 2.  See announcement below..

-------- Forwarded Message --------
Subject: 	I-D Action: draft-kent-trans-architecture-00.txt
Date: 	Fri, 02 Oct 2015 14:20:39 -0700
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : Certificate Transparency (CT) System Architecture
         Authors         : Stephen Kent
                           David Mandelberg
                           Karen Seo
	Filename        : draft-kent-trans-architecture-00.txt
	Pages           : 27
	Date            : 2015-10-02

Abstract:
    This document describes the architecture for Certificate Transparency
    (CT) focusing on the Web PKI context. It defines the goals of CT and
    the elements that comprise CT. It also describes the critical
    features of these elements. Other documents describe in detail the
    operation of these elements.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kent-trans-architecture/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-kent-trans-architecture-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ben Laurie <[email-masked]>
Date: Mon, 16 Nov 2015 18:08:48 +0000

On Mon, 2 Nov 2015 at 05:38 Salz, Rich <[email-masked]> wrote:

> Issues: STH freshness. Protection of locally-trusted roots? Log
> misbehavior that is privacy sensitive? What is "same domain" for SCT feed
> back? Define data format for trusted auditors?  Various TBD and TODO in the
> text.
> Discussion about what inclusion proof is/contains. Dkg and bryan agree
> embedding them in cert is probably bad idea.
>

This is not helpful: I think it is probably a good idea. Why is it a bad
idea?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 16 Nov 2015 13:22:30 -0500

>From a privacy-perspective: with relatively long-lived certs, embedded
inclusion proofs are going to contain "stale" STHs.  As a result, it
makes the verification of these STHs (via consistency proofs)
potentially privacy-sensitive, since they could be tied to a specific
origin.

in the current Gossip approach, we manage to make STHs
non-privacy-sensitive specifically because clients keep them "fresh" and
are therefore all gossiping about the same current set of STHs.

Does this make sense?  I'd love to hear a counterargument, as i'm
generally more in favor of inclusion proofs than of SCTs.  Including an
up-to-date inclusion-proof *alongside* a cert seems fine to me, as would
including a "fresh" inclusion proof in a short-lived cert.

But my understanding of the lifetime of certs and the narrow window of
freshness we'd like to keep for STH gossip don't line up.

If a cert includes an older inclusion proof to STH k, and that's always
bundled with a consistency proof from k to the current "fresh" STH n, i
don't think that'd be a bad thing.

    --dkg

---

From: Ben Laurie <[email-masked]>
Date: Tue, 17 Nov 2015 16:49:24 +0000

> don't think that'd be a bad thing.

Hmm. I see your point. Obviously if you're capable of bundling an STH
proof, you're also capable of bundling an inclusion proof...