Eran,
On Thu, Jan 8, 2015 at 7:49 PM, Stephen Kent <[email protected]
<mailto:[email protected]>> wrote:
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?
Yes. Do you find it necessary to explicitly state that?
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.
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?
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).
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.
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
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
that "stand-along auditing isn't likely to happen." Absent such an
explanation, and WG
concurrence, it seems that closing this ticket is premature.
Is "based on experience from deploying RFC6962" a valid explanation? :)
not for me ;-).
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.
Is a "participant" a client or is this a new, more generic term?
#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.
(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
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.
great.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
