[Ntp] Re: [NTP] Roughtime: Inadequate Explanation of Protocol's Unique Feature? (Question to all WG members)

[Watson Ladd <[e-mail]>]

On Tue, Aug 13, 2024 at 11:23 AM <[e-mail]> wrote:
>
> Hey Watson, editors, WG members,
>
> To focus on one issue for now, here is a major one, that we wanted to take the opportunity to ask the WG's opinion on.
> Because we feel that this issue alone prevents last call readiness.
> The draft still states (Section 10 Security Considerations and Section 9 Roughtime Clients, respectively) that:
>
>         "Maintaining a list of trusted servers and adjudicating violations of the rules by servers is not discussed in this document and is essential for security."
>         "The venues for sharing [malfeasance] reports and what to do about them are outside the scope of this document."
>
> We feel that a specification of a security protocol cannot just omit discussion of its main security feature like this.
>
> @Watson/Marcus: do we understand correctly that you do intend to leave it like this?
> @WG members: what are your views on this?

You're correct we intend to leave it like this, but I'd like to
explain the reasons why. First note that the X509 related RFCs and ISO
standards do not cover the CAB Forum rules which govern the
operational requirements for CAs, which are again different from the
rules browsers put on CAs. The only standard a browser and site and CA
actually "have" to adhere to is the X509 RFCs, and then the matter of
trust can be entirely bypassed by using a private PKI. The IETF
doesn't determine what CAs should do, and doesn't enforce violations,
which happens on an outside the IETF channel with varying degrees of
complexity. I think this is fine.

When we initially brought roughtime we struggled significantly to find
people willing to put input on the ecosystem related parts. We need
operational experience before standardizing the mechanisms. In
currently envisioned deployments per-vendor solutions are acceptable
and roughtime fills a niche that others do not, even without a global
malfeasance reporting mechanism. If successful one will evolve and
could be standardized should it be useful, as happened with CT. I
think if we tried to address this more explicitly we'd run into the
issue of making plans for problems we've never encountered, for people
we don't know. I'm not saying it's out of scope forever, rather this
document isn't the right place.

Sincerely,
Watson Ladd

>
>
>
> Besten Gruß / Kind regards,
> Kristof Teichel
>
> __________________________________________
>
> Dr.-Ing. Kurt Kristof Teichel
> Physikalisch-Technische Bundesanstalt (PTB)
> Arbeitsgruppe 4.42 "Zeitübertragung"
> Bundesallee 100
> 38116 Braunschweig (Germany)
> Tel.:        [phone]
> E-Mail:   [e-mail]
> __________________________________________
>
>
>
> Von:        "Watson Ladd" <[e-mail]>
> An:        "NTP WG" <[e-mail]>
> Datum:        02.08.2024 21:02
> Betreff:        [Ntp] Latest Roughtime draft
> ________________________________
>
>
>
> We have fixed a typo in the representation of a tag thanks to Chris
> Patton's eagle eyes.
>
> As I mentioned at IETF 120 we'd like to get to last call ahead of next
> IETF. The repo is at https://github.com/wbl/roughtime-draft and I'll
> be trying to use issues to track work to do so we don't lose it.
>
> Please send in comments so we can get them dealt with and be ready for
> a last call soon. Pull requests, issues, or emails to the list all
> welcome: I'll take care of raising one in the other if necessary.
>
> Sincerely,
> Watson Ladd
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>


--
Astra mortemque praestare gradatim