Re: [secdir] Secdir review of draft-ietf-trans-rfc6962-bis-31

Eran Messeri <> Fri, 03 May 2019 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A4DE1200EF for <>; Fri, 3 May 2019 02:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ozSMziVCMZRX for <>; Fri, 3 May 2019 02:53:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57D9512006D for <>; Fri, 3 May 2019 02:53:38 -0700 (PDT)
Received: by with SMTP id n188so3856278ywe.2 for <>; Fri, 03 May 2019 02:53:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S2yhi0JX8am+SBQhbZsjZusDmN1PRN6+9QrlfL7y1ek=; b=vwvu2vdwwinKKXNXLV2XGcHmVilqDLNufpC45UQoDAd0dCr2SnpbJuWBriNZd3YrkE KLriTexPb1VGwjL4/RRO0FccMb8CfVjcdrML3JnfvFI/NL0Y+q/YEBs3IO9H/k/tP8MG /KeQ2doVbtpyNsSG4pmqUt9TXJchdXVSc9s7GAOpC94Y+33R7yE9hzItXAJDSnYNVSk3 iis9vaIYHwgFa7w9QkaVURCoOkinPLKMbho4lvLQ3Cg9oDOzwMOE+w9Gjr0pywZkd7dN sFNnCnIr5or/F22QkWFxxMDDZ06AH8vylaACJkLt7lJnW2J/83NfAN255m1D3YPctthT /CTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S2yhi0JX8am+SBQhbZsjZusDmN1PRN6+9QrlfL7y1ek=; b=hXlXfPwrUS7RgjVbWElOAsJi+eMRaCCo59zlZWVHX4SygJv0uEYEKgwMB3gW/tphC9 GyQT3AbOhmXs/+bHz66PSv/l2+jTLdFfMq0R9FMlQdJiY9oblmE4b//zX11BWvydWR3Q 6lCz+HymrgjniOLBTOwMF0ZL/l4Uw36FzSZ3UhmPV3pSwM9hzbiY3ltx0iLpaYVAAmqG ipkMHBgkq62/wPN2XdGBpLtn5CLLcHBM1zrEUm4F+0MqKWiFSzyMsEVkehfKtnW07mu0 hDvxcQpdQ28vILjcJsXw3NAPEXKD+IYTeAu3bkskw+NpxbQUBmEr3fM98Jl2wvp1NUUu Kl+A==
X-Gm-Message-State: APjAAAVwiHfxYkmyMqFm9FVAIYqx2ksnxJDmhU5/FYIEYkQthAYZ4aAQ pbpwMZ6Dy2bq+mMO2xVjiCQ97p+bjM6t5Hx2sRKiaA==
X-Google-Smtp-Source: APXvYqwelplV3RJ5xTspvXLnIK3KL4Xn9jRzTsPSDrJSwEo1g1cCh1SynEFNgmIfr4p4wWGn3gohl6B19hs33OOh6eQ=
X-Received: by 2002:a81:2556:: with SMTP id l83mr6875868ywl.300.1556877217056; Fri, 03 May 2019 02:53:37 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eran Messeri <>
Date: Fri, 3 May 2019 10:53:11 +0100
Message-ID: <>
To: Charlie Kaufman <>
Cc: "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000007beac90587f8b9b5"
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-trans-rfc6962-bis-31
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 May 2019 09:53:43 -0000

A few comments in-line.

On Fri, May 3, 2019 at 4:41 AM Charlie Kaufman <>

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> [**Note: This review is very late and likely moot. I was a few weeks late
> because I was travelling, then noticed I had missed the deadline and asked
> Tero whether there was any point in my reviewing this. He said "probably
> not" so I didn't, but it appears writing a review is the only way to get it
> off my secdir assignment list. So this will not be up to my usual
> standard**]
> I'm a little confused by a procedural issue. RFC6962 is experimental, and
> this revision is also proposed to be experimental. I didn't think that
> revisions to experimental protocols got the designation "bis", but perhaps
> I was misinformed.
6962-bis started its life as a standards-track document, but recently (a
year ago?) it was suggested we change it to an experimental-track document
due to the lack of existing implementations.

> This is an interesting proposal for testing the validity of certificates
> in the Internet PKI (in addition to CRLs, OCSP, some DNS extension, and
> perhaps some others I'm forgetting), and it has functionality that overlaps
FYI, Chrome has required that certificates issued by the public Certificate
Authorities be logged in Certificate Transparency logs based on RFC6962
since April 2018 and has been in place for much longer for Extended
Validation certificates.

> The idea may have been inspired by the success of block chain in other
> contexts, and proposes that all certificates that Internet users are
> expected to accept when they are presented should be published for all to
> see to give people the opportunity to watch for invalid certificates being
> issued for names they control so that they can complain about them.
While it was before my time on the project, to the best of my
understanding, the idea was inspired by multiple instances of public CA
compromise, resulting in attackers intercepting users' traffic for several
high-profile web services (circa 2011), not the recent blockchain

> The proposal specifies the actions of a partially trusted logging service
> that will take certificates as they are issued, sign an acknowledgement
> that can optionally be placed in the certificate itself or in the TLS
> headers during session initialization. The certificates are then placed in
> a Merkle hash tree and signed. This both reduces the signing work the log
> server has to do and allows it to prove that it has not removed any
> certificates from its database once they are posted there.
> An interesting question that I did not see addressed in the I-D concerns
> whether the list of all issued certificates is made world-readable. The
> system assumes that the owners of particular domain names can watch for the
> issuance of bogus certificates for names they own, but many issuers do not
> want to make public the complete list of certificates they have issued for
> the same reason they would not want to release a complete list of DNS names
> they are using below their arc. DNS allows verification of guessed names
> but not enumeration of all names (at least optionally). Doing the same with
> this system would lose some of its security benefits, but not doing it
> would make it unacceptable to some issuers.
Yes, all certificates in the log are world-readable. The topic of redaction
of certain components of the DNS names have been discussed and rejected by
the group as mostly too complex and having little benefit, given that there
are Enterprise controls for browsers supporting Certificate Transparency to
exempt certain domains from the CT enforcement requirement.

>  --Charlie
> Sent from Outlook <>