Re: [Ntp] Antw: Re: [EXT] Danny's Review (was Re: draft‑ietf‑ntp‑roughtime‑05: tag change makes implementation more complex)

["Salz, Rich" <[e-mail]>]

I think that if you are going to make that argument, you need to make it very clearly and explain why "algorithm agility" does not apply.

At a minimum, why not include the digest identifier in the messages?


On 10/6/21, 10:43 PM, "Watson Ladd" <[e-mail]> wrote:

    On Tue, Oct 5, 2021 at 9:10 AM Salz, Rich <[e-mail]> wrote:
    >
    > >    That was my point. You can put an ID into the protocol to reference the
    >     hashing algorithm used which references an ID maintained by IANA. That
    >     way the protocol doesn't change if you need to replace the protocol.
    >     It's okay to reference a minimum required protocol in the document
    >     provided that can be updated if the algorithm becomes compromised. I'm
    >     sure you can find a list of supported hashing algorithms on IANA.

    I think it's important to understand the reality of negotiation. We
    have to have roughtime 1 and roughtime 2: Clients that support both
    can discover what a server supports and use the highest supported
    version.

    Now if we say that we must have Hash X and Hash Y we must then have
    another negotiation mechanism. But why? If hash X is broken, define
    roughtime 2, exactly the same as roughtime 1 but with X replaced by Y.
    In TLS we've found that it is very difficult to make negotiation work,
    and that using a single well-trod mechanism is better than a wide
    variety. Why do we need both Hash X and Hash Y? We don't. If a signer
    is signing data hashed with hash X and hash Y is that secure? It's not
    usually considered! Now, if there is a good reason SHA-256 would be
    preferable we can use it.

    While TLS supports a lot of junk, in practice people would like to
    support very few ciphersuites, and only 3 signature algorithms are
    permitted for the Web PKI. For Roughtime it's essential to maximize
    compatibility between servers, clients, and auditors and having
    versioning is necessary. Additional extension points for the core of
    signing and verifying time correctness run the risk of fragmentaton.
    Furthermore what we've seen with TLS is that configurable, pickable
    suites lead to persistence of bad choices, and aren't understood.

    Sincerely,
    Watson Ladd

    --
    Astra mortemque praestare gradatim