"IETF Secretariat" | 24 Jun 18:00 2016

[Trans] trans - Requested session has been scheduled for IETF 96

Dear Melinda Shore,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

trans Session 1 (1:00:00)
    Wednesday, Morning Session I 1000-1230
    Room Name: Charlottenburg I size: 80

Special Note: 10:00-11:00

Request Information:

Working Group Name: Public Notary Transparency 
Area Name: Security Area
Session Requester: Melinda Shore

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: dane curdle dnsop tls
 Second Priority: ipsecme saag

Special Requests:

(Continue reading)

Steve | 21 Jun 18:26 2016

Re: [Trans] Suggesting an alternative mechanism for name redaction

So a real world situation has been brought forward that requires CT to care about visibility of subdomains when ownership of name property is granted from ICANN at the level of the visible content in a redacted name?

On Tue, Jun 21, 2016, 9:16 AM Eran Messeri <eranm <at> google.com> wrote:
FYI proposed text for this change (unreviewed) is in https://github.com/google/certificate-transparency-rfcs/pull/175

On Tue, Jun 21, 2016 at 4:56 PM, Steve <steve.medin <at> gmail.com> wrote:

If a client can un-redact, what's the point of redaction?

A  monitor of the log which observes a certificate with redacted dNSName fields and has a list of subdomains for that domain (for example, because it is operated by the legitimate domain owner who knows about all the subdomains registered under this domain) can distinguish between a redacted cert for one of the known subdomains and a redacted cert for an unknown subdomain.
TLS clients have to receive the un-redacted certificate, but having the redacted dNSNames alongside the unredacted ones allows clients to apply a policy for determining whether the redaction is acceptable or not.

Kind regards,

On Tue, Jun 21, 2016, 12:35 AM Andrew Ayer <agwa <at> andrewayer.name> wrote:
Hi Rob,

On Mon, 20 Jun 2016 14:39:00 +0100
Rob Stradling <rob.stradling <at> comodo.com> wrote:

> 1. When redacting a LABEL in the "redacted SAN" extension, the issuer
> replaces LABEL with "?"||HEX(HASH(SERIAL_NUMBER||LABEL)) instead of
> just "?".
> 2. If the client desires stronger SCT matching, it checks that each
> redacted label in the redacted SAN extension matches the
> corresponding label in the SAN extension, by computing HASH
> (SERIAL_NUMBER||LABEL), where SERIAL_NUMBER is the serial number of
> the certificate.

I'm a little uneasy about using the serial number, because of
the ways that serial numbers can be, and are, incorrectly encoded (e.g.
not minimally encoded, or a "positive" integer with the MSB set).  I
think it's simpler and more robust for the client to take the salt out
of an extension, so it can be treated as an opaque blob and therefore
be unaffected by the vagaries of parsers.
Per this feedback, the proposed text requires the use of all bytes used to encode the serial number, including the tag and length bytes.

> - Provides a (partial) technical solution to 'un'redaction (which is
> something that needs to be addressed before Chrome will ever support
> redaction [1]): If a domain owner's certificate team observes an
> unexpected precertificate, they can calculate HASH(SERIAL_NUMBER||
> LABEL) for all of the LABELs they manage.

Another way to support "un-redaction" is to just leave the salt
extension in the pre-certificate instead of removing it.  I'd prefer
that approach if this style of un-redaction is desired.
The reason I'm uneasy with the salt as a separate extension is it adds some complications (another extension to remove, another thing to get right when matching the redacted labels with unredacted ones). As far as I can tell, the serial number could serve the same purpose. 


Trans mailing list
Trans <at> ietf.org

Trans mailing list
Trans <at> ietf.org

Trans mailing list
Trans <at> ietf.org
Eran Messeri | 17 Jun 13:02 2016

[Trans] Suggesting an alternative mechanism for name redaction

This is a proposal for an alternative mechanism to redact domain names such that would shift most of the implementation complexity from the client to the issuer, while being functionally equivalent to the redaction mechanism in the current draft.

In short: Rather than describe how the client should modify the labels in SAN extension to get to the redacted form that was logged, the issuer will generate the redacted SAN extension and log it, as a part of the TBSCertificate submitted to the log.

- The issuer, when generating a TBSCertificate for submission to the log, will add a "redacted SAN" X.509v3 extension with what the current draft specifies should be in the SAN extension (i.e. dNSNames with redacted labels, ?.example.com).
- The TBSCertificate to be submitted will *not* have a SAN extension (thanks Rob for this suggestion).
- The log will issue an SCT that covers the submitted TBSCertificate (+ issuer key hash as currently described).
- The issuer then can issue the unredacted certificate by adding a SAN extension with the unredacted names (and potentially embedding the obtained SCTs).
- The client, when receiving the unredacted certificate, simply removes the SAN extension (and the embedded SCTs extension, if present), then validates the signature from the SCT over it.
- Then client can then extract the redacted domain names from the "redacted SAN" extension, compare them to the unredacted domain names from the SAN extension and apply a policy to determine if the redaction was appropriate. 

- The only manipulation clients have to do to validate an SCT is to remove another X.509 extension, which it already has to do for embedded SCTs (eliminating both the error-prone process of reconstructing the redacted labels and the need to re-assemble a TBSCertificate).
- Clients have both the redacted and unredacted domain names and can still choose to apply any desired policy.

- The commonName in the subject field cannot be redacted this way.
- monitors will have to go through another hoop to make sense of the logged entry (likely by assigning the value of the "redacted SAN" extension to the SAN extension before using a standard parser to parse the TBSCertificate).

Assuming this mechanism is technically sound, I would not object to keeping redaction in 6962-bis if implemented this way.

Trans mailing list
Trans <at> ietf.org
Andrew Ayer | 16 Jun 06:31 2016

[Trans] Redacted Labels extension with zero elements

There is an annoying edge case where a certificate with no DNS- or
CN-IDs can have a Redacted Labels extension with zero elements and not
be invalid according to 6962-bis.

This means you can't immediately reject a certificate if the Redacted
Labels extension has fewer than one element.  Combined with the
requirement that the last integer implicitly repeats, this made my
TBSCertificate reconstruction implementation more complicated than it
would be otherwise.  Considering that this code involves indexing an
array, which carries a risk of invalid memory access in memory unsafe
languages, I think it's important to make it possible to detect and
reject bad input as easily and as early as possible.

If redaction is not removed, could we specify that the Redacted
Labels extension MUST NOT be present if no labels are redacted?

Salz, Rich | 15 Jun 14:15 2016

Re: [Trans] Name redaction - stay or go?

> I think redaction should stay.

Same here.  Strongly in favor
Rob Stradling | 15 Jun 10:33 2016

Re: [Trans] Name redaction - stay or go?

On 15/06/16 06:53, Peter Bowen wrote:
> On Tue, Jun 14, 2016 at 9:03 PM, Melinda Shore <melinda.shore <at> gmail.com> wrote:
>> As we approach the end of working group last call on 6962-bis,
>> it looks like we have an unresolved question about whether
>> name redaction should stay or go.  I just went through the
>> mailing list archive and it looks like we have squishy
>> agreement that it should go (for example, Rob's comment:
>> "Regarding fixing it: I'd rather nuke the redaction
>> option than add further complexity.").  So, if anybody has
>> particularly strong feelings about this, or disagrees
>> about removing name redaction, please weigh in.
> I disagree with removing name redaction.  There is value in having
> redacted certificates and it isn't questionable that having some info
> is better than none.  For example, a CA could choose to log every
> certificate but redact some.  This would make it very clear if a
> "rogue" certificate should up that didn't match any certificate on
> record.
> Symantec has also shown there is customer demand for redacted
> certificates -- they swapped their default to "log full certificate" a
> couple of weeks ago and have had several hundred certificates
> explicitly opt for redaction.  From the domains, it seems that it is a
> number of different customers spanning multiple countries and types of
> organizations (commercial, government, non-profit, etc).
> I think redaction should stay.

Melinda, I think there are three potential ways forward...

1. (Stay) Keep the redaction mechanism in 6962-bis.

2. (Defer) Move the redaction mechanism into a separate I-D, so that 
TRANS can continue to work on defining redaction without holding up 
6962-bis from progressing to RFC.

3. (Go) Kill the redaction mechanism entirely.

Are you asking "Stay or Defer" or "Stay or Go" or "Stay or Defer or Go"?


Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Melinda Shore | 15 Jun 06:03 2016

[Trans] Name redaction - stay or go?

Hi, all:

As we approach the end of working group last call on 6962-bis,
it looks like we have an unresolved question about whether
name redaction should stay or go.  I just went through the
mailing list archive and it looks like we have squishy
agreement that it should go (for example, Rob's comment:
"Regarding fixing it: I'd rather nuke the redaction
option than add further complexity.").  So, if anybody has
particularly strong feelings about this, or disagrees
about removing name redaction, please weigh in.


Andrew Ayer | 15 Jun 05:31 2016

[Trans] Some comments on draft-ietf-trans-rfc6962-bis-16

Section 6.6 (get-all-by-hash): It's not clear whether the inclusion
proof is to the requested STH or to the returned STH.  I'm pretty sure
it's supposed to be the returned STH, but this wording suggests it's
the requested STH:

        tree_size:  The tree_size of the tree on which to base the
        proofs, in decimal

In this wording, it's unclear what "selected STH" refers to:

        inclusion:  A base64 encoded "TransItem" of type
        "inclusion_proof_v2" whose "inclusion_path" array of Merkle
        Tree nodes proves the inclusion of the chosen certificate in
        the selected STH.

Section 10.1 (metadata): Is the Final STH specified as a TransItem of
type signed_tree_head_v2 or as a tree_size integer?

Section 10.2.2 (Reconstructing the TBSCertificate): It's also necessary
to remove the Transparency Information extension, but this step is

Sections 10.2.5 - 10.2.7 (compliance): It's unclear what role the TLS
Feature extension plays.

10.2.5 says that compliance means "accompanied by at least one valid

10.2.6 says that if transparency_info is present in the TLS
Feature extension, then "CT compliance ... is required" and that "TLS
clients MUST treat certificates which fail this requirement as
non-compliant."  In other words, non-compliance must be treated as
non-compliant, which isn't saying anything.

10.2.7 says that if the certificate chain is non-compliant, the "TLS
client MUST refuse the connection," which renders the TLS feature
extension unnecessary.

I assume the intent is that if transparency_info is in the TLS Feature
extension, then TLS clients MUST refuse connections using non-compliant
chains.  Otherwise, they MAY refuse connections using non-compliant
chains, depending on the client's policy.
Daniel Kahn Gillmor | 10 Jun 20:13 2016

[Trans] threat analysis v06 review

Hi all--

This is a review of
https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-06, with a
specific focus on the colluding CAs section, which has been a subject of
some contention, and which i think was intended to capture the attack
which i described on-list a few months ago.

Many thanks to Steve for his work on this draft.

One brief comment on the Introduction:


In the Introduction:

>  Also note that one proposal for distributing Audit information (to
>  detect misbehaving logs) calls for a browser to send SCTs [...]

This should probably link directly to the gossip draft.


> 3.3. Malicious, Colluding CAs

The text in this section does not clearly describe the attack i had
outlined, although it comes close.  I think that some ascii-art diagrams
might be useful, and there is some terminology that can be cleaned up.
I'll try to intersperse some comments below for improved clarity.

One initial overall observation is that the "collusion" need not be

Consider CA A, whose intermediate CA with cert A_N (using key N) is
compromised and used to issue a bogus EE cert X:

  A → A_N → X

This compromise is identified, and X is revoked (by whatever means:
OCSP, CRLs, CRLsets, etc).  A considers the failure severe enough to
conclude that N was compromised, and revokes A_N.

However, the attacker has already used N to issue another bogus EE cert
Y, which is not yet deployed in any scenario, so it is unknown:

  A → A_N → Y

Some time later, the attacker gains control of CA B.

They use this control to issue intermediate CA cert B_N whose public key
is also N.  This means there are two possible chains for Y:

0) A + A_N → Y

1) B → B_N → Y

The attacker logs chain 0, and receives SCT SCT_Y.  The log operators
can't block this inclusion in their logs without themselves becoming
meta-CA.  If the log decides to try to do this, i believe that other
attacks on the ecosystem appear (based on non-synchronization between
the intermediate CAs blocked by the log and those blocked by the relying

Though it was logged with chain 0, the cert is deployed with chain 1,
and still shipped with SCT_Y.

Anyone just looking at chain 1 and SCT_Y can tell that it the cert chain
is correct, and that the EE cert has been logged.  However, none of the
certificates in its chain have been revoked, and so no alarm bells will
be raised.

Anyone monitoring the logs on behalf of the service identified in Y will
note that a cert was issued to it, but under a bogus, revoked,
known-compromised intermediate cert.  None of the existing revocation
mechanisms are likely to revoke Y, since the chain is already thoroughly

If the attacker is afraid of a risk of all their certs being revoked,
they can simply issue hundreds or thousands of certs while they have
access to A_N, which encourages narrow-bandwidth blocklisting mechanisms
like CRLsets to just revoke the intermediate CA, and not the EEs,
permitting the alternate chain to be used without detection.

Note that the attacker doesn't even need to maintain access to N if they
are thoughtful about their plans during the period in which N is

OK, on to specific comments:

>    Section 3.2 examined attacks in which a single CA might issue a
>    bogus certificate. There is also the potential that two or more CAs
>    might collude to issue a bogus certificate in a fashion designed to
>    foil the remediation (but not detection) safeguards envisioned by
>    CT. Their goal would be trick a CT-aware browser into accepting a
>    bogus certificate because it was accompanied by a valid SCT, while
>    evading certificate revocation status indications. This section
>    explores such scenarios.

Aside from the implication of contemporaneousness, i think this is a
fair characterisation.

>    In this attack two CAs that do not share a common path to a trust
>    anchor, 

I don't think that "do not share a common path to a trust anchor" is
relevant.  in a complex issuance hierarchy like this (where the "trust
anchor" is A, and all named nodes are intermediate CAs):

   / \
  B   C
 /|   |\
D E   F G

a compromise of any two nodes would suffice, despite the fact that they
all share a trust anchor.

>    collude to create a "doppelganger" (bogus) EE certificate.

I'm not sure that "doppelganger" is a useful turn of phrase here.  The
closest thing we have to a "doppelganger" in the particular attack i
described above is B_N, which technically *isn't* any more bogus than
A_N.  these intermediate CA certs are "doppelgangers" because they share
SPKI and Subject. But the EE cert in this attack scenario is singular,
not doubled.

>    The attack need not be initiated by trust anchors; any subordinate
>    pair of (not name-constrained) CAs can effect this attack without
>    the knowledge of superior CAs (which are presumed to be benign).

This isn't precisely true, because of path length (not name)
constraints. In the attack i've outlined, at least one of the
compromised CAs must either have pathLenConstraint absent, or greater
than zero.  If the public certs for all of the compromised CAs have
pathLenConstraint == 0, the attack is not possible.

>    (The following text refers to these as two CAs, because they might
>    be represented by entities that are organizationally distinct,
>    perhaps realized by different physical presences. However, because
>    they share the same name and key pair, one also might view them as
>    the same CA that appears in two cert paths terminating at different
>    TAs.) The two CAs must have the same Subject name and the same
>    public key for the attack. (RFC 5280 does not explicitly preclude
>    the creation of two CAs with the same name, so long as the parent
>    CAs are distinct. Requirements for Subject name uniqueness apply
>    individually to each CA but not across CA boundaries, as per Section
> However, the Security Considerations section of RFC 5280
>    warns that name collisions could cause security problems.)

This paragraph seems wrong to me.  The compromised CAs in question are
*not* the same CA, though they do need to create at least one "doubled"
intermediate CA that shares at least the same key (and likely, the same

Perhaps it would be better to think about "compromised CA keys" instead
of "compromised CAs", and leave the mechanism of compromise out of the
technical discussion?

>    Because the two CAs have the same name and make use of the same key,
>    each can issue the (bogus) doppelganger certificates.

This should say "either can issue the bogus end-entity certificate".
(s/each/either/ and dropping doppelganger)

>    Because the bogus certificate is logged, it is subject to detection
>    as such by a Monitor. Once the bogus certificate is detected it is
>    anticipated that action will be taken to render it invalid. The
>    bogus certificate itself might be revoked by the CA that issued and
>    logged it, an action that masks the malicious intent of that CA. A
>    browser vendor might add the bogus certificate to a blacklist
>    maintained by the vendor, e.g., because the CA failed to revoke the
>    bogus certificate.
> Kent                  Expires November 31, 2016               [Page 17]
> Internet-Draft  Attack Model for Certificate Mis-issuance      May 2016
>    If the CA that logged the bogus certificate is suspected of being
>    malicious, e.g., because it has a history of using bogus
>    certificates, the certificate of that CA might itself be revoked.
>    This revocation might be effected by the parent of that CA (which is
>    not complicit), or by a browser vendor using a blacklist. Whether
>    the proposed attack can achieve its goal depends on which revocation
>    mechanism is employed, and which certificate or certificates are
>    revoked.

It also depends on what bogus EE certificates are issued, and (arguably)
whether or not any of the logs reject certificate chains with
known-revoked CAs in them.  Of course, if the logs start doing that kind
of rejection, then log operators become required to act as meta-CAs,
which i believe is a rather radical departure from the story we've told
about logs in the past.

> 3.3.1. Revocation of the Bogus Certificate
>    If the bogus (EE) certificate is revoked by the CA that issued and
>    logged it, browsers should treat that certificate as invalid.
>    However, a browser checking a CRL or OCSP response might not match
>    this revocation status data against the doppelganger issued by the
>    second CA.

Again, the EE cert is actually the same cert; the "second CA" is the

>    This is because revocation status checking is performed
>    in the context of a certification path (during path validation). The
>    doppelgangers have different certification paths and thus the
>    revocation status data for each might be acquired and managed
>    independently. (RFC 5280 does not provide implementation guidance
>    for management of revocation data. It is known that some relying
>    party implementations maintain such information on a per-certificate
>    path basis, but others might not.)
>    Even if the bogus certificates contain an AIA extension pointing to
>    an OCSP server the attack might still succeed.

This would be better as:

    Even if the bogus EE certificate contains an AIA extension pointing to
    an OCSP server the attack might still succeed.

>    (As noted in the Section 1, RFC 5280 does not mandate inclusion
>    this extension, but its presence is required by CABF requirements.)

Does this mean that monitors should raise flags for EE certs missing AIA
extensions which identify an OCSP server?  If so, is anyone doing this
check?  What action should be taken if this is found missing?

>    As noted in Section, a malicious CA could send a "good"
>    OCSP response to a targeted browser instance, even if other parties
>    are provided with a "revoked" response. Also note that a TLS server
>    can supply an OCSP response to a browser as part of the TLS
>    handshake [RFC6961], if requested by the browser. A TLS server
>    posing as the entity named in the bogus certificate could acquire a
>    "good" OCSP response from the colluding CAs to effect the
>    attack. Only if the browser relies upon a trusted, third-party OCSP
>    responder, one not part of the collusion, would the attack fail.

This represents a separate and distinct CA key compromise from the
original described attack, since the OSCP responder is often a separate
key.  I think this muddies the waters when trying to describe the
"dual-CA compromise".

More broadly, this seems like a discussion about failings in the
revocation infrastructure, which might itself be out-of-scope for CT.  A
separate document that collates all the failings of revocation would be
interesting and useful, but shoehorning it into this section might be a

>    The analysis above also applies to the use of CRLs to disseminate
>    certificate revocation status data. The doppelganger certificate
>    could contain a CRL distribution point extension instead of an AIA
>    extension.

Again, i don't think "doppelganger" should be used here.  I think this
refers to the "bogus EE certificate", so please use that term.

>    In that case a site supplying CRLs for the colluding CAs could
>    supply different CRLs to different requestors, in an attempt to
>    hide the revocation status of the doppelganger from targeted
>    browsers instances. This is analogous to a split-view attack
>    effected by a CT log. However, as noted in Section and
>, no element of CT is responsible for detecting
>    inconsistent reporting of certificate revocation status data.

Again, this is a separate compromise, and i think it muddies the waters.

>    (Monitoring in the CT context tracks log entries made by CAs or
>    Subjects. Auditing is designed to detect misbehavior by logs, not by
>    CAs per se.)

I think this is correct, but i'm not sure it belongs in this section.

>    If the CA that logged the certificate does not revoke it, a browser
>    vendor might enter the bogus certificate into a "blacklist".
>    Unfortunately, there are no IETF standards for such blacklists. Thus
>    it is conceivable that the revocation status data also might be
>    managed in a path-specific fashion.

I think this is the most-relevant bit of this section.  Some revocation
mechanisms depend on the *path*, not just on the EE cert and signing

Perhaps it would make more sense to enumerate those revocation
mechanisms that are path-reliant (and therefore vulnerable to this
colluding-CA hiding attack):

 a) any blocklist mechanism (like CRLsets) that sometimes blocks
    intermediate CA certificates without also including a full explicit
    blocklist of all known child certs of the blocked intermediate CA.

 b) relying parties which depend on identifying OCSP or CRL or other
    revocation mechanisms in the issuing certificate, rather than in the
    end-entity certificate.

>    If that were true, then the attack could succeed. However, if a
>    vendor maintains revocation status data in a path-independent
>    fashion, then the attack will fail. For example, if revoked
>    certificates are identified by CA name and serial number, or a hash
>    of the certificate, this attack would fail.

The attack that fails for path-independent revocation mechanisms is use
the bogus, known-revoked EE certificates.

But the other attack (the hidden, secondary CA compromise) is still not
discovered by CT in this case.

> 3.3.2. Revocation of the Colluding CA Certificate
>    If the CA that logged the bogus certificate is viewed as acting
>    maliciously, its parent might revoke that CA's certificate. Even
>    though the two colluding CAs have the same name and use the same
>    public key, their certificates are distinct, e.g., they were issued
>    by different parents and almost certainly have different certificate
>    serial numbers. Thus revocation of the certificate of the CA that
>    logged the bogus certificate does not affect the certificate of its
>    colluding partner. In this case, the bogus EE certificate would be
>    treated as valid when it appears in a certification path involving
>    the second colluding CA. Thus revocation the certificate for the CA
>    that was detected as malicious does not prevent this attack from
>    succeeding.

This last sentence is missing an "of".

>    A vendor also might choose to add the certificate of the CA that
>    issued the bogus certificate to its blacklist, e.g., if that CA
>    refuses to revoke the bogus certificate. This also may not prevent
>    the bogus certificate from being accepted by a browser. For example,
>    if the CA certificate blacklist entry is analogous to a CRL entry
>    (Subject name of the parent of the malicious CA and the serial
>    number of the malicious CA's certificate), the colluding CA's
>    certificate would still be valid in this case.

Should we instead recommend "relying parties capable of blocking
known-malicious intermediate CAs should enumerate these entities by
public key" ?  This doesn't entirely solve the problem (two conspiring
CAs can create an unlimited number of doppelganger CA pairs), but it's
certainly better than blocking intermediate CAs by full certificate or
by issuer+serialnumber.

Sorry that describing this attack has proved so complex.  I think the
complexity is due to the complexity of the overall ecosystem (including
PKIX, X.509, CAs, logs, browsers, revocation mechanisms, etc).  the
simpler we can make things the better.


Trans mailing list
Trans <at> ietf.org
Melinda Shore | 9 Jun 22:19 2016

[Trans] IETF 96

Hi, all:

Because we're in a less-active period in the working group's
work cycle and because of problems with an overscheduled
agenda in Berlin, we've decided not to have a formal session
at IETF 96.  We will find some time for informal discussion,
for those who are interested.  Gossip would be the main
topic under discussion, and possibly DNSSEC logging.

Melinda Shore | 8 Jun 20:47 2016

[Trans] Threat document - status and question

Hi, all:

We'd like to restart working group last call on the threat
analysis draft 
but I wanted to make sure that any serious concerns have been
addressed.  In particular, it seems as if there may be some
unresolved questions about the conspiring CA attack identified
by DKG.

Do you all feel that the document is ready for working group
last call, and that any issues blocking it from being sent on
to the IESG have been resolved?