NTS support

[jpds]

Wishlist issue, but it would be neat if Graphene could use NTS to do time synchronization:

• https://datatracker.ietf.org/doc/html/rfc8915
• https://www.netnod.se/time-and-frequency/new-proposed-standard-to-ensure-secure-time-on-the-internet
• https://blog.cloudflare.com/nts-is-now-rfc/
• https://fedoramagazine.org/secure-ntp-with-nts/
• https://blog.meinbergglobal.com/2021/07/14/network-time-security-nts-updated-security-for-ntp/

[ghost]

GrapheneOS already has a secure implementation of time keeping using HTTPS.

The OS makes a HTTPS request to a server that generates a 204 blank response. The OS gets the Date header and uses that for the time and date. It's far better than NTS and has all the security benefits of HTTPS such as TLS 1.3, secure ciphers, etc.

https://grapheneos.org/faq#default-connections

An HTTPS connection is made to https://time.grapheneos.org/ to update the time from the date header field. This is a full replacement of Android's standard network time update implementation, which uses the cellular network when available with a fallback to SNTP when it's not available. Network time updates are security sensitive since certificate validation depends on having an accurate time, but the standard NTP / SNTP protocols used across most OSes have no authentication.

[jpds]

GrapheneOS already has a secure implementation of time keeping using HTTPS.

This isn't an Internet standard, and by extension makes one easy to identify as a GrapheneOS user (which wouldn't be an issue using standard NTS network servers - which would also remove a single point of failure on time.g.o).

It's far better than NTS and has all the security benefits of HTTPS such as TLS 1.3, secure ciphers, etc.

NTS has TLS1.3, secure ciphers and also additional privacy characteristics.

[thestinger]

This is far too complex to implement ourselves and the only advantage over HTTPS is that it would provide more precise network time.

This isn't an Internet standard, and by extension makes one easy to identify as a GrapheneOS user (which wouldn't be an issue using standard NTS network servers - which would also remove a single point of failure on time.g.o).

It is an internet standard. TLS and HTTPS each include the time with second precision (which isn't great) which is all we're currently using. We were going to improve the precision with more accurate latency compensation and a more precise time field but we haven't done that yet. It's literally just using standard TLS / HTTP with no special stuff.

[thestinger]

Android doesn't use NTS and hardly anything else does either so using NTS doesn't blend in any more.

[ypid]

First of all, I was about to open the same issue because I recently looked into NTS and was happy to see a standard that covers basic requirements.

We were going to improve the precision with more accurate latency compensation and a more precise time field but we haven't done that yet.

This sounds like redundant work to me. I hope AOSP would support NTS eventually. I don’t think sub-second accuracy is so important on a phone. Am I missing something? Why not leave the current HTTPS implementation as simple as it is right now?

[jpds]

It is an internet standard. TLS and HTTPS each include the time with second precision

Synchronizing clocks from arbitrary HTTPS endpoints is not an Internet standard:

• https://datatracker.ietf.org/doc/html/rfc8446 states that this is from...
• https://datatracker.ietf.org/doc/html/rfc6962 which is for certificate transparency logs

And whilst this is talking about logs, there is this bit in 5.2:

TLS clients MUST reject SCTs whose timestamp is in the future.

NTS doesn't blend in any more.

To be clear: NTS-KE is only used for establishing crypto parameters and the initial cookie - after that, the clients fallback to NTP traffic (albeit with NTS extension fields).

But yes, this will likely need to be imported from AOSP.

[thestinger]

We're not planning to implement this downstream.

[thestinger]

If AOSP supported NTS, we'd happily be hosting a server and using it. There's no way we're implementing this and we're more than happy with the HTTPS-based checks. The checks go over the VPN and they aren't a privacy issue. NTS would be useless if it was just used with an untrusted pool with open membership.