Subject: [Ntp] Antw: [EXT] Re: draft‑ietf‑ntp‑roughtime‑05: tag change makes implementation more complex

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Oct 2021 09:19:08 +0200

>>> Danny Mayer <[email-masked]> schrieb am 26.09.2021 um 18:24 in
Nachricht <[email-masked]>:

...
> According to the diagram in Section 6, you do specify the length of the 
> message. I'm not clear why you are wasting 8 bits at the beginning to 

you mean "8 bytes"?

> say 'ROUGHTIM', what else would it be? You are better off using that 
> space to specify roughtime versioning information.
> 
> Danny

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Oct 2021 09:28:15 +0200

>>> Watson Ladd <[email-masked]> schrieb am 28.09.2021 um 03:48 in
Nachricht
<CACsn0cmks2fdwem1rS+QNzCL1WhNR4890Fi1zpjQrL=E3Y=[email-masked]>:
...
>> 9. Hashing algorithm in Section 6.3
>>
>> It's not clear why the algorithm can only be SHA‑512. This really should
>> be separately referenced so that if SHA‑512 is considered too week in
>> can be replaced by a different hashing algorithm like say HMAC‑SHA‑512,
>> without having to update the proposed RFC.
> 
> Part of what is required for roughtime is interoperability between all
> servers, auditors, and clients. Using only a single hash function and
> signature, and then migrating entire versions, is a better approach
> than permitting everything.

Why not specify that the only supported hash algorithm for this protocol
version is SHA-512, while later protocol version might require or support
different algorithms?
For completeness the used/expected hash algorithm could indicated by a tag
even in this version, maybe providing a mechanism how to allow/require
different algorithms in a later version.
That design would avoid some bad compatibility designs in a later version
(like NTP's "famous" extension fields).

...

Regards,
Ulrich Windl

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Oct 2021 09:33:14 +0200

>>> "Salz, Rich" <rsalz=[email-masked]> schrieb am 29.09.2021 um
17:30
in Nachricht <[email-masked]>:
> *   Can you point to an existing RFC where the protocol name is in the 
> header? Is there something useful about it that the security folks think it

> would be a good addition? Any other references to make sense of this?
> 
> Does ALPN count?  It’s a protocol identifier in the TLS clientHello message.

>  There’s lots of ALPN identifiers picked, 
>
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-v

> alues.xhtml#alpn-protocol-ids
> 
> For HTTP, the h2 identifier when connecting over TCP.

Would SMTP count also?

> 
> Any ASN1-based protocol (SNMP, PKIX, etc) has an identifier.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 4 Oct 2021 10:53:04 -0400

>> For HTTP, the h2 identifier when connecting over TCP.
I don't think that the string "SMTP" appears anywhere in the exchange. 
"MAIL" does but that's not what we are talking about.

Danny

---

From: Watson Ladd <[email-masked]>
Date: Mon, 4 Oct 2021 19:16:38 -0700

> version is SHA-512, while later protocol version might require or support

I'm happy to add that sentence: it means nothing. Future protocols can
change a lot of things.

> (like NTP's "famous" extension fields).

I'm not sure why the hash function is so worthy of singling out here,
perhaps you can explain more. The intention is every version has its
own single signature algorithm.
Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 05 Oct 2021 10:25:07 +0200

>>> Danny Mayer <[email-masked]> schrieb am 04.10.2021 um 16:53 in

> "MAIL" does but that's not what we are talking about.

Well, I thought differently, so I looked it up:

RFC 2821 (Simple Mail Transfer Protocol), page 53:
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol

Despite of that SMTP servers include the token "SMTP" in their greeting,evn
not demanded:

# telnet localhost smtp
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 mail.blabla.de ESMTP
quit
221 2.0.0 Bye

Or very traditional:
# telnet mail-1 smtp
Trying 172.20.2.18...
Connected to mail-1.
Escape character is '^]'.
220 mail-1...de ESMTP Sendmail 8.14.9/8.14.9/20191212TS-1; Tue, 5 Oct 2021
10:23:32 +0200
quit
221 2.0.0 mail-1...de closing connection
Connection closed by foreign host.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 05 Oct 2021 10:29:22 +0200

>>> Watson Ladd <[email-masked]> schrieb am 05.10.2021 um 04:16 in
Nachricht
> own single signature algorithm.

If that is part of the design, say so. However having to start a new
incompatible protocol version just to replace a hash algorithm is bad design
IMHO.
Imagine SSL/TLS had a new or different version for every hash algorithm that
is supported.

Regards,
Ulrich

---

From: Danny Mayer <[email-masked]>
Date: Tue, 5 Oct 2021 11:52:21 -0400

> Imagine SSL/TLS had a new or different version for every hash algorithm that
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.

Danny

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Oct 2021 16:10:12 +0000

I think you're agreeing with each other.  TLS defines codepoints as places for extension. You can see a list of such points at https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml  The "TLS Cipher Suites" table for example is directly on-point.  Note that every protocol has its own tables.

Historically NTP didn't really have extension points (probably because the concept, and IANA as currently used, didn't really exist back then).  The WG has adopted a draft, https://datatracker.ietf.org/doc/draft-ietf-ntp-update-registries/ that updates and creates the historical extension points.

As for the question of whether SHA-512 should be part of the Roughtime spec, or use a registry and a digest identifier...  The only other Merkle tree document, Certificate Transparency (CT), uses a registry.  (See https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/, Section 10.2.1) and notably it uses SHA-256 as the default.  We could add SHA-512 to the CT registry and then roughtime could just refer to that. It would mean adding a byte to the protocol messages.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 6 Oct 2021 19:43:21 -0700

>     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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Oct 2021 12:56:25 +0000

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" <[email-masked]> wrote:

    Sincerely,
    Watson Ladd

---

From: Danny Mayer <[email-masked]>
Date: Thu, 7 Oct 2021 10:34:21 -0400

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

I agree.

Danny

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp