with #1449 the OHTTP configuration will have a clear TTL. this introduces some privacy downsides, but arguably not very severe (see #445 (comment))
however, with clear TTLs we do have the possiblity of improving privacy as well, specifically bolstering key consistency using the shared cache approach
currently clients use the HTTP CONNECT or websockets to bootstrap. this requires using TLS, once to connect securely to a relay, and then again to authenticate that the relay isn't a MITM, i.e. the directory's OHTTP keys are authenticated based on the CA trust model
because of the cache control headers, the mailroom service could now add a mechanism for asking about the OHTTP config of a different mailroom.
used on top of the existing bootstrap mechanism, this can provide some evidence that the directory is not equivocating, assuming all relays present a consistent view, then each relay's matching view of the config is an attestation that the bootstrap was correct.
used instead of the existing bootstrap mechanism, this can allow a client with no (direct) TLS support but with Tor to use a number of relays with hidden service addresses to bootstrap the config of a clearnet directory (see also #766)
although a much bigger undertaking, this can be further bolstered by the relays checking on each other, similarly to certificate transparency (i.e. every mailroom checks that every other mailroom it knows about is accurately reporting the OHTTP config of every other mailroom it knows about)
with #1449 the OHTTP configuration will have a clear TTL. this introduces some privacy downsides, but arguably not very severe (see #445 (comment))
however, with clear TTLs we do have the possiblity of improving privacy as well, specifically bolstering key consistency using the shared cache approach
currently clients use the HTTP CONNECT or websockets to bootstrap. this requires using TLS, once to connect securely to a relay, and then again to authenticate that the relay isn't a MITM, i.e. the directory's OHTTP keys are authenticated based on the CA trust model
because of the cache control headers, the mailroom service could now add a mechanism for asking about the OHTTP config of a different mailroom.
used on top of the existing bootstrap mechanism, this can provide some evidence that the directory is not equivocating, assuming all relays present a consistent view, then each relay's matching view of the config is an attestation that the bootstrap was correct.
used instead of the existing bootstrap mechanism, this can allow a client with no (direct) TLS support but with Tor to use a number of relays with hidden service addresses to bootstrap the config of a clearnet directory (see also #766)
although a much bigger undertaking, this can be further bolstered by the relays checking on each other, similarly to certificate transparency (i.e. every mailroom checks that every other mailroom it knows about is accurately reporting the OHTTP config of every other mailroom it knows about)