Skip to content

Commit

Permalink
More minor grammar fixes.
Browse files Browse the repository at this point in the history
  • Loading branch information
davidv1992 committed Dec 21, 2023
1 parent 1e4e12c commit b15556f
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions draft-venhoek-nts-pool.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,13 +73,13 @@ In {{RFC8915}}, cookies are generated based on key material that is extracted fr

# Client facilities for pools

One challenge with getting multiple time sources from a single NTS Key Exchange server is that clients that allow for explicit pool configuration want to end up with multiple independent time sources. Without additional support, a user of a pool might receive a downstream time source it already has from an NTS Key Exchange session, resulting in that session being a waste of time. To avoid this, we also introduce a record that clients can use to indicate which downstream time servers they don't want, because they already have them.
One challenge with getting multiple time sources from a single NTS Key Exchange server is that clients that allow for explicit pool configuration want to end up with multiple independent time sources. Without additional support, a user of a pool might receive a downstream time source it already has from an NTS Key Exchange session, resulting in that session being a waste of time. To avoid unneccessary NTS Key Exchange sessions, we also introduce a record that clients can use to indicate which downstream time servers they don't want, because they already have them.

# Pool authentication

The extensions proposed below allow a client to establish an NTS association with a server with arbitrary keys, not just those extracted from the TLS session. To discourage misuse, it is not desirable to allow arbitrary clients to do this.

Therefore, a server supporting the Fixed Key Request record from {{fixedkey}} MUST implement authentication of clients using the Fixed Key Request record through TLS client certificates. Support MUST be disabled by default, and when enabled, MUST be limited to an explicitly configured list of clients.
Therefore, a server supporting the Fixed Key Request record from {{fixedkey}} MUST authenticate clients using the Fixed Key Request record using TLS client certificates. Support MUST be disabled by default, and when enabled, MUST be limited to an explicitly configured list of clients.

# New NTS record types

Expand Down Expand Up @@ -121,7 +121,7 @@ Server MUST ignore any client body sent and MUST send in response a Supported Al

When included, the server MUST NOT negotiate a next protocol, AEAD algorithm, or keys for this request.

We include algorithm key size in the response so that a pool does not itself need knowledge of which AEAD algorithm's exist, and what their key sizes are. Instead, it can use the provided key length when extracting keys from the TLS connection between end user and pool. This allows adoption of new AEAD algorithms without any software changes being needed in pool software.
We include the algorithm key size in the response so that a pool does not itself need knowledge of which AEAD algorithms exist, and what their key sizes are. Instead, it can use the provided key length when extracting keys from the TLS connection between end user and pool. This allows adoption of new AEAD algorithms without any changes being needed for the pool software.

## Fixed Key Request {#fixedkey}
Record Type Number: To be assigned by IANA (draft implementations: 0x4002)
Expand Down

0 comments on commit b15556f

Please sign in to comment.