Subject: [Ntp] Fwd: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-04.txt

From: James <[email-masked]>
Date: Sat, 13 Nov 2021 14:17:33 +0100

I have published a new version of the NTPv5 requirements draft, perhaps a little bit earlier than suggested at the working group session yesterday.

A summary of changes:
* A restructuring of the document to fit expected norms (i.e. not misappropriating IANA/security consideration sections)
* Rewording of the requirements to be specifically protocol requirements, rather than specification requirements. This isn't entirely complete, but further edits can finish it
* A "non-requirements" section included
* Bunch of other smaller changes throughout the document too numerous to mention

Feedback is always welcome, but I would now like to ask the chairs to start the call for adoption process if they're happy to do so.

- J

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-04.txt
> Date: 13 November 2021 at 13:58:07 CET
> To: "James Gruessing" <[email-masked]>
> 
> 
> A new version of I-D, draft-gruessing-ntp-ntpv5-requirements-04.txt
> has been successfully submitted by James Gruessing and posted to the
> IETF repository.
> 
> Name:		draft-gruessing-ntp-ntpv5-requirements
> Revision:	04
> Title:		NTPv5 use cases and requirements
> Document date:	2021-11-13
> Group:		Individual Submission
> Pages:		9
> URL:            https://www.ietf.org/archive/id/draft-gruessing-ntp-ntpv5-requirements-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-gruessing-ntp-ntpv5-requirements/
> Html:           https://www.ietf.org/archive/id/draft-gruessing-ntp-ntpv5-requirements-04.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-gruessing-ntp-ntpv5-requirements
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-gruessing-ntp-ntpv5-requirements-04
> 
> Abstract:
>   This document describes the use cases, requirements, and
>   considerations that should be factored in the design of a successor
>   protocol to supersede version 4 of the NTP protocol [RFC5905]
>   presently referred to as NTP version 5 ("NTPv5").  This document is
>   non-exhaustive and does not in its current version represent working
>   group consensus.
> 
> 
> 
> 
> The IETF Secretariat
> 
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 15 Nov 2021 17:17:05 +0100

> * Bunch of other smaller changes throughout the document too numerous to mention

Thanks for your work on this.

It's still not clear to me how a protocol design prevents downgrade
attacks. Maybe some examples would help me to understand.
In any case, I'm wondering if this doesn't conflict with the MUST for
extensions and SHOULD for hardware to be able to add information
without breaking authentication.

A major issue I have is with the "delay-based attacks" as a
non-requirements. There is a big difference in security of the NTP
client-server or symmetric mode vs the broadcast mode or other
protocols like PTP. I think we'll all agree that NTPv5 must not be
less secure than the NTPv4 client-server mode.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 15 Nov 2021 16:37:20 +0000

Do you mean the kind of thing like in https://www.rfc-editor.org/info/rfc7507 ?

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 16 Nov 2021 09:32:30 +0100

> Do you mean the kind of thing like in https://www.rfc-editor.org/info/rfc7507 ?

That's interesting, but if I read it correctly, it's a workaround for
some broken TLS implementations.

AFAIK NTP never had any security negotiation, so it's difficult for me
to imagine how would it work and how it could become vulnerable to a
downgrade attack. With symmetric keys, it is configured by the
user. With NTS, we rely on a separate protocol (NTS-KE using TLS).

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Tue, 16 Nov 2021 01:25:16 -0800

> That's interesting, but if I read it correctly, it's a workaround for some
> broken TLS implementations.

I wouldn't call it broken.  Maybe the defaults aren't what some users might 
want.

The contxt is making web connections more secure because somebody decides the 
current protocol is (or might be) not as secure as we would like.  So they 
issue an RFC with a new version.  During the upgrade transition some sites 
have upgraded to the new protocol and some are still using the old version.  
So browsers are setup to try for new and fall back to the previous version if 
the target site doesn't support the new version.

> AFAIK NTP never had any security negotiation, so it's difficult for me to
> imagine how would it work and how it could become vulnerable to a downgrade
> attack. With symmetric keys, it is configured by the user. With NTS, we rely
> on a separate protocol (NTS-KE using TLS). 

I can't think of any downgrade attacks on NTP using either shared keys or NTS.

There is a possibility of downgrading NTS-KE since it uses TLS which generally 
supports downgrading.  We took advantage of that during the early testing days 
since there were still distros that weren't shipping the new libraries yet.  
There was an explicit decision to require at least TLS 1.3 in the RFC since it 
was generally supported by then and that would avoid downgrading and there was 
no need to support downgrading since there weren't any installed old 
implementations that only supported older versions of TLS.

--------

I think non-downgrading would be a good item to consider for NTP v5.  It 
should be simple.

Note that software bugs could implement downgrading to no-security.  Suppose 
you send a packet with shared-key or NTS and get back a packet with no 
security.  It would be easy to write the test so that it asked 
does-this-packet-have-authentication rather than do-I-require-authentication.

-- 
These are my opinions.  I hate spam.