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

[Danny Mayer <[e-mail]>]

On 10/7/21 8:56 AM, Salz, Rich wrote:
> 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?

I agree.

Danny

>
> 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
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp