Skip to main content

Telechat Review of draft-ietf-trans-rfc6962-bis-31
review-ietf-trans-rfc6962-bis-31-secdir-telechat-kaufman-2019-05-03-00

Request Review of draft-ietf-trans-rfc6962-bis
Requested revision No specific revision (document currently at 42)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2019-03-12
Requested 2019-03-01
Authors Ben Laurie , Adam Langley , Emilia Kasper , Eran Messeri , Rob Stradling
I-D last updated 2019-05-03
Completed reviews Genart Last Call review of -31 by Joel M. Halpern (diff)
Tsvart Last Call review of -31 by Jana Iyengar (diff)
Secdir Telechat review of -31 by Charlie Kaufman (diff)
Secdir Last Call review of -39 by Charlie Kaufman (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Request Telechat review on draft-ietf-trans-rfc6962-bis by Security Area Directorate Assigned
Reviewed revision 31 (document currently at 42)
Result Has nits
Completed 2019-05-03
review-ietf-trans-rfc6962-bis-31-secdir-telechat-kaufman-2019-05-03-00
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.

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 with those.
**PEOPLE INTERESTED IN TECHNICAL APPROACHES TO IMPROVING THE SECURITY OF THE
INTERNET PKI SHOULD TAKE A LOOK AT THIS APPROACH WHETHER OR NOT THIS PARTICULAR
PROPOSAL SUCCEEDS**

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.

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.

 --Charlie

Sent from Outlook<http://aka.ms/weboutlook>