Subject: Re: [Trans] Threat model outline, attack model

From: Stephen Kent <[email-masked]>
Date: Wed, 01 Oct 2014 10:32:03 -0400

Ben,

> ...
>> Again, I disagree. We should define what we can and make design decisions
>> based on that definition. Anything else that might be considered
>> mis-issuanve,
>> is out of scope for purposes of this work. This is the sort of delineation
>> that
>> we often impose on RFCs; we define a scope for a standard and declare that
>> other
>> stuff is out of scope, relative to the standard.
> Then perhaps we should have a broader scope. Focusing on mis-issuance
> seems to lead to all sorts of, IMO, unnecessary complications.
I'm may get in trouble for saying this, but it seems as though the 
"complications"
to which you allude are just the result of taking the terms that have 
been used
to motivate development of CT and making them concrete, rather than 
ambiguous.

If a "broader scope" means using more ambiguous terms, I can't see why that
would be an improvement.
> It might be simpler to define CT as a mechanism for allowing the
> public examination of the contents of all issued certificates, without
> getting into exactly what might be done as a result of that
> examination. Detecting mis-issuance is, of course, an obvious example.

I'm very bothered by your suggested change of focus. For me, this 
characterization of
CT is way too vague for an IETF security standard (vs. an experimental RFC).

It leads a reader to imagine that we don't have a simple, sound, 
defensible argument
for why we're pursuing this technology. It has the flavor of "CT is 
obviously good,
so let's just do it."  (pardon me for putting words into anyone's mouth.)

Steve

---

From: David Leon Gil <[email-masked]>
Date: Wed, 1 Oct 2014 10:54:09 -0400

On Wed, Oct 1, 2014 at 10:32 AM, Stephen Kent <[email-masked]> wrote:
> If a "broader scope" means using more ambiguous terms, I can't see why that would be an improvement.
> It has the flavor of "CT is obviously good, so let's just do it."

Okay. You've convinced me.

So: I've disabled syslog on all my servers. I can't define a-priori
what security issues logging might detect. Thus there's no point in
logging anything.

---

From: Tao Effect <[email-masked]>
Date: Wed, 1 Oct 2014 09:15:57 -0700

> what security issues logging might detect. Thus there's no point in

1. If CT were as useful and usable as syslog, I'd have fewer problems with it.

2. syslog does not claim to "make it impossible to [xyz hacker thing] without detection", whereas such claims have been made about CT [1].

3. Nor is syslog presenting it as an IETF security-related protocol.

4. syslog isn't "overtly forcing" [2] architectural changes upon anyone based on aforementioned false claims.

Kind regards,
Greg Slepak

[1] http://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/
[2] https://twitter.com/Cryptoki/status/514866111968706560

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Oct 2014 12:13:33 -0400

David,

> On Wed, Oct 1, 2014 at 10:32 AM, Stephen Kent<[email-masked]>  wrote:
This is a very poor analogy for many reasons, as Greg has already noted.

Steve