search

csosto-pk / tls-suppress-intermediates

Suppress intermediate certificates in TLS
Other
0 stars 0 forks source link

Crisper text on what the client capabilities are #11

Open csosto-pk opened 2 years ago

csosto-pk commented 2 years ago

From Ryan S.

Basically, it needs to be a little crisper what the client capabilities are. Presently, it handwaves them as out-of-scope, but as a consequence, makes it difficult to justify the assumptions/complexity that they hide. Does the client have durable storage (e.g. does the IoT device need rewritable media and not just ROM)? Does the client have a reliable (within TBD3) out-of-band update mechanism for metadata such as intermediates? Is the TLS implementation expected to be able to re-establish a connection (which many TLS APIs are not themselves responsible for, or at least, abstract that away)? These all affect the shape of the present design, but also any simplifications.

We ought to crisp up the text more.

csosto-pk commented 2 years ago

Addressed in commit https://github.com/csosto-pk/tls-suppress-intermediates/commit/dd597815ba5b1c3b09680aed565ffedf9e7d04cd

This draft assumes that the endpoint can keep as set of ICAs in memory to use them while building certificate chains to authenticate a peer. Most usually the set will be stored locally in non-volatile memory. In constrained devices the intermediates could be cached, kept and updated only in volatile memory especially when the communicating peers' PKI domains are limited.

How CA certificates are identified and stored is dependent on the use case. In some use cases (e.g. WebPKI [ICA-PRELOAD]) the peer may assume that all intermediates are assembled, distributed and updated regularly using an out-of-band mechanism. In other use cases when the communicating peers' PKI domains are limited and not all CA certificates can be stored (i.e., constrained devices), or distributed, intermediates could be cached and updated dynamically using a caching mechanism. Such mechanisms are discussed in [TLS-SUPPRESS].

Although this document uses mechanisms to minimize TLS authentication failures due to stale or incomplete ICA lists, an endpoint is expected to re-attempt a TLS connection if it failed to authenticate a peer certificate after requesting ICA suppression. [EDNOTE: draft- ietf-tls-esni already requires the client to retry a connection when ECH is "securely replaced by the server" or "securely disabled by the server". ]

Will close when we think the text works.