Subject: [Trans] TRANS Draft minutes for IETF-93

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Jul 2015 19:58:30 +0000

Please send/post corrections.

Paul, WG Status update
Charger unchanged; need to reset milestone.

Eran RFC6962-bis status+
Still needs some tweaks. Suggests waiting for Google to finish their implementation to clean out all nits before WGLC
A log cannot do a single v1/v2 log, must run both in parallel.
Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90, 82, 83,  84, 92, 89, 58; 63, 74, 76, 77, 70; See tracker for details
Open tickets 78 (alg agility needs more description) 83 (should require deterministic ECESA) 96 (dynamic metadata; does only CA root list really change?) 95 (include get-entries response size in the log metadata, for cursoring through a log)
Steve raised issue of exposing what certs a client is interested in if size of get-entries can shrink to one, for example.
More on open: 87 (ref to attack model doc) 64 (remove spec of sig and hash lags) 93 (monitor description inconsistencies) 94 (when/why clients should fetch inclusion proofs)
Stephen raised issue fhat if threat analysis is normative, schedule gets pushed out further. Should be informative.

Steve Kent, attack model
Name changed on doc, even if filename can't easily be changed. Not a threat model, we don't know what the attackers are thinking, but we do know possible actions so it's an attack model.
Includes an intro to CT, he prefers it move into an arch document but if not it will stay.
"CT is a set of mechanisms, designed to detect, deter, and facilitate remediation of certificate mis-issuance"
Semantic mis-issuance: name in the cert refers to an entity incorrectly.
Syntactic mis-issuance: violation of certificate profile(s) that apply.
Reviewed a taxonomy of attacks.  Read the doc.  Discussion of additions and bigger picture needs.
Incorporated all (but one) comments.
Wants WG agreement via list on goals, definitions, attacks.
We have a half-dozen people commit to read and review the document.
Ben agrees about having an arch doc; Steve and Ben will collaborate on an arch doc

Dkg, Gossip
Gossip important to keep logs accountable by making sure everyone sees the same append-only data and keep their MMD/SCT promises.
Works by browser's sharing and comparing SCT and STH
Three channels:
	SCTFeedback;  browser sends cert/sct to website, website sends to auditing function/third-party auditor
	STH Pollination: auditor/website send STH to each other.  STH are not privacy-sensitive
	Optional Trusted Auditor: browser passes sct/cert to auditor (e.g., the DNS resolver since it already knows what you might be looking at)
Call for adoption is on the mailing list.

Dkg, CT for binary 
Goal is to know that you are running the same software as "everyone else," not guaranteeing that the software isn't compromised.
Add a binary lLogEntryType; add binary and binary_digest to Signed_Type
Many details of what and how is signed are still open; need feedback from s/w distributors.
PHB suggest to not use ASN.1
Discussion and agreement that changing the s/w distribution format is a non-starter.

Rich Salz, selective logs
Some logs will not log every single cert from the CA's in their root list.
What do we do?
Discussion, no conclusion.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz
-

---

From: Melinda Shore <[email-masked]>
Date: Thu, 23 Jul 2015 22:18:00 -0800

Thanks, Rich!

Melinda

On 7/23/15 11:58 AM, Salz, Rich wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Ben Laurie <[email-masked]>
Date: Fri, 24 Jul 2015 11:28:53 +0000

On Thu, 23 Jul 2015 at 20:59 Salz, Rich <[email-masked]> wrote:

> Still needs some tweaks. Suggests waiting for Google to finish their
> implementation to clean out all nits before WGLC
> Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90, 82,
> 83,  84, 92, 89, 58; 63, 74, 76, 77, 70; See tracker for details
> Open tickets 78 (alg agility needs more description) 83 (should require
> deterministic ECESA) 96 (dynamic metadata; does only CA root list really
> change?) 95 (include get-entries response size in the log metadata, for
> cursoring through a log)
> Steve raised issue of exposing what certs a client is interested in if
> size of get-entries can shrink to one, for example.
>

My response was omitted: this doesn't matter so long as the client
continues to request entries until it has all the ones it originally
decided to fetch.

> More on open: 87 (ref to attack model doc) 64 (remove spec of sig and hash
> lags) 93 (monitor description inconsistencies) 94 (when/why clients should
> fetch inclusion proofs)
> Stephen raised issue fhat if threat analysis is normative, schedule gets
> pushed out further. Should be informative.
>
> Steve Kent, attack model
> Name changed on doc, even if filename can't easily be changed. Not a
> threat model, we don't know what the attackers are thinking, but we do know
> possible actions so it's an attack model.

I thought I heard other volunteers. :-)

>
> Dkg, Gossip
> Gossip important to keep logs accountable by making sure everyone sees the
> same append-only data and keep their MMD/SCT promises.
>         Optional Trusted Auditor: browser passes sct/cert to auditor
> (e.g., the DNS resolver since it already knows what you might be looking at)
> Goal is to know that you are running the same software as "everyone else,"
> not guaranteeing that the software isn't compromised.

dkg also noted that some distros (at least Debian and FreeBSD) have been
discussing the question of what exactly should go in the logs. We'd like to
hear from anyone interested in joining those discussions.

---

From: Eran Messeri <[email-masked]>
Date: Mon, 27 Jul 2015 17:36:51 +0100

On Fri, Jul 24, 2015 at 12:28 PM, Ben Laurie <[email-masked]> wrote:

>> Recently closed tickets 4, 64, 68, 69, 72, 81, 73, 65, 91, 80, 86, 90,
>> 82, 83,  84, 92, 89, 58; 63, 74, 76, 77, 70; See tracker for details
>> More on open: 87 (ref to attack model doc) 64 (remove spec of sig and
>> hash lags) 93 (monitor description inconsistencies) 94 (when/why clients
>> should fetch inclusion proofs)
I'm happy to help with the architecture document .

>
>
>>
>> Dkg, Gossip
>> Gossip important to keep logs accountable by making sure everyone sees
>> the same append-only data and keep their MMD/SCT promises.
>> Goal is to know that you are running the same software as "everyone
>> else," not guaranteeing that the software isn't compromised.