Subject: [Trans] Addendum

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Jan 2015 09:00:37 -0900

To make it easier to review recent changes, you can see a
list of them here:
http://trac.tools.ietf.org/wg/trans/trac/query?changetime=2015-01-01..2015-01-07&col=id&col=summary&col=changetime&col=status&col=owner&col=type&col=priority&col=milestone&col=resolution&order=priority

Melinda

---

From: Stephen Kent <[email-masked]>
Date: Thu, 08 Jan 2015 14:49:24 -0500

I have a few questions/comments about the set of proposed ticket closures:

#37 - Are the gossiping clients discussed by this ticket just Auditors 
and Monitors, or
does it apply to TLS clients as well? Also, if gossiping is addressed in 
a separate set
of docs, does that mean that 6962-bis will make only minimal mention of 
it? That seems
appropriate since until those specs are completed and approved, on 
cannot attribute
any security features to gossiping, right?

#15 + #38 - For what range of clients is behavior not being specified? 
My recollection from
the IETF meeting was that the discussion focused on TLS clients, not 
Monitors or
Auditors, but the ticket closing comment is not clear on this point. 
Also, is it useful
(vs. confusing) to discuss possible client behaviors in this doc, yet 
mandate none? I don't
recall this issue (what to say about client behavior if we mandate none) 
being discussed
ion detail on the list.

#40 - I don't recall seeing an explanation by the editors about why they 
have decided
that "stand-along auditing isn't likely to happen." Absent such an 
explanation, and WG
concurrence, it seems that closing this ticket is premature.

#42 - Since this is a ticket I submitted, let me say that I don't think the
adverb "overly" is appropriate ;-). My concern is that the text didn't 
provide an
algorithmic way to determine when a submitted (pre-)cert with a redacted 
SAN was
"dangerous" and ought not be accepted. Also, the issue was not whether a 
single entity
controls the name space covered by the redacted name; it's whether the 
CA submitting the
pre-cert controls that space. Finally, if we are not specifying how any 
client (TLS or Monitor)
makes use of this feature, why is it part of the spec? Unless we have an 
agreed-upon set of
rules for how to use redacted certs, we are adding complexity to 
6962-bis without identifying
any benefits.

#43 - If key rollover is not supported, then the "freeze and begin a new 
one" process
needs to be documented in detail. This description must describe how 
clients of the old
log become aware of the transition to a new log (to avoid false positives).

Steve

---

From: Eran Messeri <[email-masked]>
Date: Tue, 13 Jan 2015 15:10:32 +0000

On Thu, Jan 8, 2015 at 7:49 PM, Stephen Kent <[email-masked]> wrote:

> #37 - Are the gossiping clients discussed by this ticket just Auditors and
> Monitors, or
> does it apply to TLS clients as well?

Yes. Do you find it necessary to explicitly state that?

> Also, if gossiping is addressed in a separate set
> appropriate since until those specs are completed and approved, on cannot
> attribute
 Correct - let's break this to two:
(1) How clients can compare instances of Signed Tree Heads.
(2) The security features that are achieved by comparing instances of STHs.
6962-bis makes only minimal mention of gossip in relation to (1).
Regarding (2), rfc6962-bis can only point out the overall benefit of
comparing STH instances (and it does), but the exact security benefits
depends on the mechanism used for (1).
FYI, the text diff is here:
https://github.com/google/certificate-transparency-rfcs/commit/52b15187c291a9a9e4aa2fa7146693d7487899f4

>
> #15 + #38 - For what range of clients is behavior not being specified? My
> recollection from
> Auditors, but the ticket closing comment is not clear on this point. Also,
> is it useful
(1) Client behaviour is mostly not specified for TLS clients, which, as you
correctly point out, was the topic discussed during the IETF meeting.
Regarding monitors, given that there's benefit to the community even from
partial monitors, I do not think it's reasonable to require a monitor to do
*all* the things described in 6962-bis to be compliant, but point out the
useful operations a monitor can perform and how it can do them.
(2) I think it's useful to point out the possible situations a TLS client
my find itself in, so we have common terminology when we discuss client
behaviour. It was not discussed on detail on the list but different aspects
have been brought up in the last IETF meeting and on several tickets.

> concurrence, it seems that closing this ticket is premature.
Is "based on experience from deploying RFC6962" a valid explanation? :)
In my opinion this section in RFC6962 was not clear and Ben added
(in-person) that his intent was never to have a stand-alone entity that
only does auditing, but that it is something that each participant in CT
could do. The original section in RFC6962 contained a bit of both, so we
cleared it up to indicate what are the auditing operations each participant
can do.

> controls the name space covered by the redacted name; it's whether the CA
> submitting the
> rules for how to use redacted certs, we are adding complexity to 6962-bis
> without identifying
> any benefits.
>
(1) to the best of my knowledge, detecting when a wildcard in a SAN is "too
wild" is not specified anywhere, other than the CA/Browser Forum BR, and
that is an equivalent problem. That's why I don't think it's appropriate to
try and specify it here.
(2) This falls into the TLS client behaviour specification - we'll point
out this situation but it's up to the client to decide what to do with such
a certificate.

> log become aware of the transition to a new log (to avoid false positives).
Acknowledged - this will be described in the metadata section I intend to
add.

>
> Steve
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 16 Jan 2015 13:30:02 -0500

Eran,

> On Thu, Jan 8, 2015 at 7:49 PM, Stephen Kent <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     #37 - Are the gossiping clients discussed by this ticket just
>     Auditors and Monitors, or
yes, I do. Gossiping among Monitors and Auditors seems more realistic 
than gossiping
among TLS clients. The former are (presumably) a much smaller set of 
entities
than the latter, and may be well known, making it credible that they may 
choose to communicate.
>     of docs, does that mean that 6962-bis will make only minimal
>     mention of it? That seems
My reason for posing this question is so that I can accurately update 
the attack analysis that
I posted previously, and that I hope will be part of 6962-bis. Since 
gossiping is not being
specified yet, this means that some attacks that would have been 
detected will now be described
as successful.
>     #15 + #38 - For what range of clients is behavior not being
>     specified? My recollection from
>     the IETF meeting was that the discussion focused on TLS clients,
>     not Monitors or
>     Auditors, but the ticket closing comment is not clear on this
>     point. Also, is it useful
>     (vs. confusing) to discuss possible client behaviors in this doc,
>     yet mandate none? I don't
>     recall this issue (what to say about client behavior if we mandate
>     none) being discussed
>     ion detail on the list.
>
> (1) Client behaviour is mostly not specified for TLS clients, which, 
> as you correctly point out, was the topic discussed during the IETF 
> meeting. Regarding monitors, given that there's benefit to the 
> community even from partial monitors, I do not think it's reasonable 
> to require a monitor to do *all* the things described in 6962-bis to 
> be compliant, but point out the useful operations a monitor can 
> perform and how it can do them.
Again, my reason for posing this question is to enable updating of the 
attack analysis. First, I'm
not sure what a "partial" Monitor is. In my description of the function, 
a Monitor looks for
certs in logs relative to a set of client-specified criteria. So, no 
Monitor is expected to
examine ALL certs being logged on behalf of everybody. Second, I think I 
suggested that each
Monitor advertise the set of logs that it examines, so there is also no 
expectation that every
Monitor examines every log. So, if one adopts these definitions of what 
a Monitor does, what is
a "partial" Monitor? If you think these definitions aren't appropriate, 
please offer concrete,
alternative text, so that we have a common basis for discussing Monitor 
behavior.

If we just describe "useful" operations for Monitors, then an attack 
analysis can't be accurate
in describing what benefits Monitors confer. I'd argue for being more 
precise in describing a minimal
set of Monitor functions that every Monitor MUST perform, and then note 
additional, optional
operations, if necessary. The two I-Ds that Rick and I authored, on 
checks to be performed
for DV and EV certs, follow this model. If 6962-bis adds text of the 
sort I proposed, calling
for a submitter of a (pre-)cert to state what sort of cert it is, then 
one can defer the
spec of Monitor (and optional log) checking to the ancillary docs for 
each cert type.

> (2) I think it's useful to point out the possible situations a TLS 
> client my find itself in, so we have common terminology when we 
> discuss client behaviour. It was not discussed on detail on the list 
> but different aspects have been brought up in the last IETF meeting 
> and on several tickets.
I'm not sure what "situations" means here; please elaborate.
>
>
>     #40 - I don't recall seeing an explanation by the editors about
>     why they have decided
not for me ;-).
> (in-person) that his intent was never to have a stand-alone entity 
> that only does auditing, but that it is something that each 
> participant in CT could do. The original section in RFC6962 contained 
> a bit of both, so we cleared it up to indicate what are the auditing 
> operations each participant can do.
Is a "participant" a client or is this a new, more generic term?
>     adverb "overly" is appropriate ;-). My concern is that the text
>     didn't provide an
>     algorithmic way to determine when a submitted (pre-)cert with a
>     redacted SAN was
>     "dangerous" and ought not be accepted. Also, the issue was not
>     whether a single entity
>     controls the name space covered by the redacted name; it's whether
>     the CA submitting the
>     pre-cert controls that space. Finally, if we are not specifying
>     how any client (TLS or Monitor)
>     makes use of this feature, why is it part of the spec? Unless we
>     have an agreed-upon set of
> (1) to the best of my knowledge, detecting when a wildcard in a SAN is 
> "too wild" is not specified anywhere, other than the CA/Browser Forum 
> BR, and that is an equivalent problem. That's why I don't think it's 
> appropriate to try and specify it here.
I see your point, but disagree. Yes, the use of wildcard DNS names in 
certs is analogous, to
the redacted cert issue for pre-certs.  But, as Rob noted in his 
message, the semantics are
not identical. This is new, a CT-created topic. The CABF defines (for DV 
certs) the
criteria to be used by a CA when a Subject requests a wildcard cert, and 
that spec is more
detailed than what the most recent version of 6962-bis says. You seem to 
be saying that
the IETF has no RFC for what constitutes appropriate checks for issuing 
a wildcard cert.
Yes, that's true, but since we have no standards for ANY Web PKI cert 
issuance, this seems
like an irrelevant observation ion this case. We're creating a new 
opportunity for bad things
to happen, so why do we get a pass on addressing the security issues 
that arise?  The CABF DV
cert BR describes (11.1.3) the checks that a CA is supposed to perform 
to ensure that the Subject
of such a cert controls the affected DNS subtree (and the EV spec 
prohibits wildcards). This
is an appropriate statement because it is describing a procedure to be 
followed by a CA.
But, in CT, CAs are not trusted, and the goal is to enable clients (of 
all sorts) to detect
mis-issued certs. I don't think we can rely on a procedural statement 
for a CA to use here.
6962-bis needs to be more specific about what clients (at least 
Monitors, if we punt on
requirements for TLS clients) are supposed to do to detect bad redacted 
certs. If we describe
Monitor behavior, then at least we can justify the text by saying what a 
Monitor does when
checking logs of redacted certs against cert info for its clients.

> (2) This falls into the TLS client behaviour specification - we'll 
> point out this situation but it's up to the client to decide what to 
> do with such a certificate.
Also Monitor behavior, as noted above.
>
>
>     #43 - If key rollover is not supported, then the "freeze and begin
>     a new one" process
>     needs to be documented in detail. This description must describe
>     how clients of the old
> Acknowledged - this will be described in the metadata section I intend 
> to add.
great.