NTP Working Group - IETF 125

Karen O'Donoghue: All right, it is 11:31 local time, so we will go ahead and get started. This is the NTP Working Group at IETF 125. As a reminder, this session will be recorded.

This is the IETF Note Well. You have agreed to this when you registered for this meeting or by joining any of our mailing lists. It's the rules and processes by which we operate. Please take time to read it. If you have any questions, feel free to reach out to the working group chairs or the area directors.

Speaking of area directors, this is the March meeting, so this is the point where we sometimes have a change in leadership. And we are going to say goodbye to Eric, our long-serving and hardworking AD. Eric, did you want to mention the incoming AD?

Eric Vyncke: Yeah, I don't know if this is going to work. There we go. Okay, you can sit here. That's all right, that's all right. I just wanted to say, thank you for bearing with me for six years. It's been very interesting to be your area director and to try to help get as much published as possible. Taking over from me tomorrow is Tommy Jensen, who will be the incoming NTP AD. So I'll let Tommy say hello, but let me also just say thank you to everybody for bearing with me. Thank you.

Tommy Jensen: I have big shoes to fill. Hello, everyone. I'm Tommy Jensen. I'm going to be taking over as your responsible Area Director starting tomorrow, fingers crossed, after you've successfully cleared all the discusses. I think there might be one left. I look forward to ensuring that you can keep your work unblocked and otherwise that I stay out of your way. Looking forward to working with you.

Karen O'Donoghue: All right, thank you. Again, thank you very much to Eric for all of his support over these years, and we look forward to working with Tommy going forward.

For this meeting, I am in Shenzhen and Dieter is at home. So with that, the next couple slides are the meeting tips and resources.

We have what looks like a long agenda, but it'll be pretty brief because a lot of this is going to be just quick updates on documents. We have the updates on the current working documents and then we also have some individual submissions and we have a quick IEEE 1588 update.

Two documents are beyond the working group. The PTP for NTP document is in the RFC Editor queue, and so we hope that it will be passed soon. I forgot my… I can't find my tab where I was cheating and had the list so I wouldn't misspeak. And then the second document is the one that Tommy just alluded to, which is the Rough Time document. That is proceeding… it has gone past IESG… it's gone past the IETF Last Call, it's gone through IESG balloting, and now they are in the process of clearing the discusses on that. There's been an enormous amount of work over the last few weeks. The authors, thank you, you've been very responsive and I think we are pretty close to being able to clear that before Eric leaves. I don't think there's anything more to add on that. Does anybody have any questions on either of those two documents?

Okay, we're down to one discuss. Look at that! Fantastic. So that moves us on to the next set—the actual working group documents that are still within our working group.

The first one of these is the draft-ietf-ntp-ntpv5 document. There has been a recent update published for that, and along with that there's a list of the four remaining issues that Miroslav has identified that have been sent to the mailing list. Miroslav will not be on this meeting, so I direct people to the mailing list and his email that has the four issues. We've also had a really nice review recently and so we really need to get some additional reviews on that document, but it is coming into shape. And if there are any additional comments on that, please feel free to join the queue, or… I don't think… I know Miroslav was not coming. I don't think Tal was coming either. Yeah, Tal’s not on the list. So that document's making good progress. We will schedule a virtual interim between now and Vienna, and then we hope to have a hackathon project in Vienna around that on that document.

The second document that is a working group document that we're working on is the draft-ietf-ntp-nts-for-ptp document. I know Martin is on the call. Martin, do you want to give a quick update on that?

Martin: Yes, of course. Hi. So, yeah, there has been a lot of progress since the last meeting. So the NTS for PTP draft is almost finished and essentially only sections like security considerations and IANA considerations are still missing, or at least not complete. A few small adjustments are still pending and that depends on the current developments in the IEEE security subcommittee. But I expect that Rainer and I will be able to finalize the NTS for PTP draft in the upcoming… in the coming months. I will also integrate and test the upcoming draft changes in the current NTS for PTP implementation and if everything works fine, then I guess the draft is final or should be final. So hopefully this year we can say this draft is final. So this is my hope. And thank you Eric for the last years. So yeah, this is the current state.

Karen O'Donoghue: I've mentioned this in previous NTP calls, but the corresponding document is making progress through the IEEE 1588 security subcommittee. If there's anybody who needs access to that document for the purposes of review, please reach out to me. And a lot of progress has been made. There was a face-to-face in December for that committee and there's been a lot of progress made since then, so hopefully that document is also getting pretty close.

The third working group document that we have is the NTS for NTP pools document. We have adopted that as a working group document. We still need to get a document submitted as a working group document, but it has been approved as soon as the next version is submitted with the name as a working group document. We have adopted this as an experimental RFC with the intent of primarily documenting the current experiment that's ongoing. Additional proposals for ways to do NTS pools are welcome in additional drafts, but that's not what the point of this one will be. And David, did you want to say anything about that document, schedule for that one?

David: No, I think you said it's fine.

Karen O'Donoghue: Said it all? Okay.

So that brings us to the end of the working group document segment. The individual submissions segment… the first document I wanted to discuss was the NTPv5 algorithms document. I have had a conversation with Sarah Grant offline about this document. The feedback from our last virtual interim is that it's too early for this document, and so her decision is to let this one expire and then we'll revisit it later when it's a little bit further along. Like people to continue thinking about, because in NTPv5 we've separated the protocol from the algorithms unlike NTPv4, what material do we need to have published around algorithms and what's the proper time frame for that material? Are there any questions about that? No.

The Timestamp Extension Field, we've had no further progress on. And the DNS record document, we also discussed at the virtual interim and there was a desire to continue the conversation on the mailing list.

So that brings us to the last individual submission, which is the Hardware-Rooted Attestation for PTP. Let me change my… stop sharing…

Okay. Diego.

Diego: So, I hope I will be brief as well, not to go against the spirit of the meeting. Basically, this is a result of some work that we have been making in using PTP for something that is not regarding time but space. It's about using PTP to assess the physical location of a server and it's very much connected with the geolocation attestation. And when doing this we have found that, well, it would be probably… it could be interesting to enhance PTP trustworthiness by providing mechanisms for attesting the messages and so be able to evaluate how the slave… it's not the slave anymore, I tend to have the slave because it's what the term that… how the time has been assigned from in a PTP network and having a mechanism that allow you to trace back how this happened and which has been the messages that have been received and to establish the authenticity of the process, but without impacting the protocol itself in its time sensitivity.

So the idea is to address this non-repudiation problem without impacting the throughput and trying to address as well the extension to use post-quantum cryptography. So basically it’s that, using this idea of using this physical location using the TPM.

So, roughly speaking, something is about assuming that we can… we have a hardware-based root of trust that can be used as the base for the whole trust fabric and applying the same mechanisms that have been already applied in groups like RATS using the SPIFFE as the… to issue verifiable IDs that can be used for the attestation. Let me say, this is about attesting the protocol. It's not about changing the protocol by any means. It's about making an additional mechanism so we can remain assured that the whole time processing has been done properly. And the third tier is about what is called as amortized execution is that instead of individually signing each one of the messages, the idea is to build batches of these messages and using a Merkle tree to ensure the integrity of these batches.

So, basically is that what we are proposing. The idea is that all the chain of time updates is built by providing these operational keys that are distributed from the hardware root of trust and guaranteeing that there is no impact with this signature and verification that the impact is minimized by the fact that we are dealing with batches of those messages. And this would allow as well for… since we are thinking about using mechanisms that are well-established in software and well-established in the hardware root to move towards PQC readiness as is required.

With this, the idea is that, as I said, this originates for an ongoing work in RATS about physical location attestation and how you can build proofs that a particular piece of hardware or a particular software is being executed in a particular geographical region. The idea is to properly align what is requested there with the attestation here so we can link the work and prepare some prototype validation. We have started with an implementation of this geofencing mechanism that is running right now in our labs in Madrid and the idea is to start working on this particular concrete idea and trying to bring it as a demonstration probably in the next hackathon.

Then the idea of which PQC algorithm to apply and how to apply it in the CBOR mechanisms for signing, etc. is something that will be afterwards. And when we have something that is minimum operative, the draft and the text of the draft is clearer because I acknowledge it's a little bit hard to follow right now. But the idea would be to adopt, to look for adoption with this idea. And let me say it's not a change to the protocol, it's not a change to the PTP protocol, it's changing… I mean, it's adding the value that you can attest the results of the use of PTP. And that's all.

Karen O'Donoghue: All right, are there any questions? You don't have any questions, right, Karen? Well, the one thing I… I mean, I happen to chair the 1588 security working group, so I'd like to get their feedback on this. If it's no changes to PTP…

Diego: No, it’s not change and it's trying to bring or somehow bridge between this and what RATS is doing in attestation. That's the idea basically.

Karen O'Donoghue: I think what I'd like to understand better is how this fits into other related work in the IETF because it is a little bit outside of what…

Diego: Yeah, no, we were discussing where to bring this because, you know, because for RATS, it's about, "No, no, we want to test PTP because it's the most critical in terms of… or demanding in terms of tight synchronization." And for RATS it's probably too much time-oriented. I know that for NTP it's probably too much attestation-oriented. We're trying to find the balance.

Karen O'Donoghue: Yeah, no, I definitely appreciate you bringing it here and I think we'll have to have a conversation about what to do with it and follow up from there. Oh, go ahead Eric.

Eric Vyncke: I was just going to offer that something the incoming AD can do is help you socialize the topic with security ADs and see what they say because it sounds like you might want to take a run through SAG or something else.

Tommy Jensen: Yeah, that makes perfect sense.

Karen O'Donoghue: You run it through SAG with the other related… I think we need to be sure that we have the connectivity to the other related activities like as a standalone document. It's like, "Wow, why is the NTP Working Group doing this?" But if there's two or three documents, I'd like to know what the connectivity is to other documents being progressed in other working groups.

Okay, so the next item… are there any other questions on this document? No.

The last item is a quick IEEE 1588 working group update. The work on CSPTP is continuing, so that's the client-server version of PTP. There is an architectural decision on one-step versus two-step clocks that is sort of blocking most of the work at the moment. As soon as that's resolved, then we expect the work that David has done to roll into… to be updated and then rolled into the core specification for that and that will be NTS for CSPTP. And then we've already discussed the NTS for PTP work progressing. Other than that, there's no real updates from 1588. They are hoping to have a face-to-face meeting in June that should be confirmed in the next week or two as to whether or not that will proceed as a face-to-face meeting.

The other items is we will plan for a virtual interim sometime between now and Vienna and we would like to have NTPv5 and the NTS for PTP or CSPTP types of hackathon projects in that time frame if at all possible. The next IETF meeting is Vienna and the one after that is San Francisco, and so the sweet spot for doing hackathon activities with the most participants for us, given our regular participant people, is in Vienna.

So with that, I said it would be a quick meeting. Is there any other comments or questions? No? All right, well, thank you and everybody have a lovely day.