Early Review of draft-halen-fed-tls-auth-14
review-halen-fed-tls-auth-14-secdir-early-perlman-2024-10-27-00

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.