Reviewer: Radia Perlman Review result: Has nits, but well written and interesting design 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. This document describes FedTLS, a deployed system implementing supplemental security controls on the PKI supporting a group of federated systems. This document aspires to be an Informational RFC, and as such what is important is that it accurately describes when is deployed. As such, I only found a few nits (though I can't speak to its accuracy). The document is well written and very comprehensible. This system addresses a number of weaknesses in the current Internet PKI and has general utility such that it could be considered for standardization. In that context, it raises a number of issues where the design could be better. The following thoughts might be passed on to any future standardization efforts, or to the maintainers of the FedTLS system for their consideration. The system was designed to support servers that make connections to one another using MTLS, though it has broader applicability. The basic idea is that a federation leader create a configuration file (in the form of a JWS signed JSON file) containing web site key pinning information that is periodically downloaded by federation members in order to protect those sites from security problems with CAs. It also supports secure operations where there are no CAs and all the servers use self-signed certificates. Issues in the context of standardization: Expiration dates and caching times should be carefully considered. Page 14 under cache_ttl says "Once the metadata expires, it MUST no longer be trusted to maintain the security and integrity of the federation." It is somewhat ambiguous as to whether this means that when the metadata expires the federation must effectively shut down until the components are manually restarted with a new trust root or whether it means the federation will continue to operate without the protections provided by FedTLS and hence be insecure. Both possibilities seem bad; which is worse depends on the scenario. In most cases, it would probably be better to continue to operate with expired data than either of the alternatives. Page 16: Requiring that issuers be explicitly listed seems redundant with the listing of the pinned public keys, and in particular seems wasteful when self-signed certificates are in use. It greatly increases the size of the metadata file and the effort required to maintain it. This may be required because of the APIs provided by existing TLS implementations, but if so that should be called out. It seems likely that there will be cases where software is opening a connection that might be to a service within the federation (and want to use FedTLS) and might be to a service outside the federation (and want to use the Internet PKI). Federation metadata should somehow specify templates for resource names to easily distinguish those two cases when connecting to a service not listed in the Federation metadata but which might be missing because it is newly created. Page 23 Federation Metadata Updates. In addition to having a periodic timer as to when new federation metadata will be retrieved, any time a failure occurs that may have been caused by obsolete metadata, a new download should be triggered with a retry if the metadata has changed. Page 24: Time synchronization can cause problems with recursion since it may need to be secured using mechanisms in FedTLS while FedTLS depends on time synchronization for proper functioning. In this case, it appears that time synchronization only needs to be very rough (i.e., within days) for FedTLS to operate, and this can usually be accomplished manually. Any requirements requiring tighter time synchronization should be carefully considered and spelled out. Nits: page 8: Section 4: refers to the "stringent security measures to safeguard the integrity and confidentiality of the stored information". In general, there is only a strong requirement to safeguard the integrity of the data. There may be a requirement of safeguard the confidentiality, but since this metadata includes only public keys and names of participating entities, the need here is not likely to be stringent and there may be no need to protect it at all. page 9: Unique Public Key Pins. This document seems to ambiguously use the term pin sometimes referring to the pinning of site public keys and sometimes to the thumbprints of public keys. This paragraph seems to say that thumbprints are used to look up entities in the metadata database and that different entities are therefore required to have different public keys. That should not be necessary... the entity should always be known first and its name used to look up the public key thumbprint in the metadata database. If that's not true, further explanation would be helpful. Page 17: Tags are issued to both clients and servers, and it appears server tags are used by clients and client tags are used by servers. The description here seems to obscure that relationship.