Subject: [ntpwg] NTS Synthesis

From: Daniel Franke <[email-masked]>
Date: Thu, 13 Oct 2016 19:41:55 -0400

I've been asked to provide some notes in advance of Friday's interim
regarding interaction between the two NTS drafts and prospects for
merging them. Here I'll refer to my protocol as "Franke NTS" and the
Sibold-Roettger-Teichel protocol as "SRT-NTS".

It is possible and theoretically sound for both protocols to
independently co-exist provided that clients are always explicitly
configured to speak only one protocol or the other with a given
server, and that if whichever protocol they are configured to speak
cannot run to completion, they will fail to communicate with that
server altogether. It is unsound for clients ever to fall back to
attempting the other protocol if the first one fails, because this
would allow a MitM adversary to induce such a failure by dropping
relevant packets, therefore freeing the adversary to attack the weaker
of the two protocols. It is, of course, always unsound for a client
ever to fall back to unauthenticated communication if authenticated
communication fails, regardless of whether the client is capable of
one authenticated protocol or both.

With that said, it is my opinion that we should not be advancing both
protocols as Proposed Standards. One or the other, or a synthesis of
the two, should win out on technical merit and that alone should
advance.

Any synthesis should preserve most or all of the following benefits of
Franke NTS:

1. It should provide a mechanism suitable for protecting control mode:
encrypted, mutually authenticated, and mutually protected from replay.

2. It should provide an application-level fragmentation mechanism so
that certificate chains or other large messages can be sent without
relying on IP fragmentation.

3. It should be capable of preserving the privacy of mobile clients
without expecting NATed clients to be able to reliably detect that
their public IP has changed.

4. It should support elliptic-curve-based asymmetric primitives in the
handshake. The current X.509 ecosystem makes it difficult to fill
SRT-NTS's asymmetric encryption primitive with anything besides RSA,
though in principle it could take something like elliptic curve
ElGamal if the relevant standards existed. Ability to use elliptic curve
cryptography results in smaller messages, better CPU efficiency, and
prevents the system from being tied to any one hardness assumption.

5. Where necessary functionality can be provided by an existing IETF
standard (such as (D)TLS, RFC 5705, or RFC 5116), any decision not to
adopt that standard should be technically justified.

I think SRT-NTS can be straightforwardly adapted to address #2, and #3
shouldn't be all that difficult either, but it cannot provide #1 or
#4, or justify itself with respect to #5, without radical alteration.
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: [email-masked]
Date: Fri, 14 Oct 2016 04:41:15 +0200

Thanks for your notes.

Kristof worked the last week on the merging of the two documents. I'm 
going to present the current status of this merge at the tomorrow's 
interim meeting. 

Dieter

PS - We currently have a student who realized #4 by using ECC ed25519. 
That allows the KE to work without fragmentation. But of course, this was 
a rather academic study.

"ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]> schrieb am 
14.10.2016 01:41:55:

> Von: Daniel Franke <[email-masked]>
> An: [email-masked]
> Datum: 14.10.2016 01:43
> Betreff: [ntpwg] NTS Synthesis
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=[email-masked]>
>

---

From: [email-masked]
Date: Fri, 14 Oct 2016 10:44:36 +0200

Thank you for the analysis, Daniel.

One thing that I personally would like to conserve is the structure of two documents, one describing general recommendations for securing time synchronization protocols, and another describing a concrete protocol for crypto-secured NTP.

Right now, my impression is that for the second mentioned document (the NTS-specific one), we are looking for a merge of the documents that on the technical side consists largely of input from Franke-NTS and expands it on the design side with elements of SRT-NTS. That is to say that things like statement of objectives, design decisions, security consideration discussions and general approach could be taken from SRT-NTS, but the KE protocol from it would be dropped.

For the first mentioned document, I currently imagine an adapted form of SRT-NTS (the generic doc), with the current concrete KE protocol deleted (potentially recommending DTLS-related techniques for consistency). This document should also describe secured broadcast/one-way the synchronization (with TESLA, if no other proposals come in) without specifying the technical details. This document can also contain much of the general discussion requested (chicken-and-egg problem, delay attack problematique, respective advantages of different approaches,...)

The document that Dieter is going to present represents a first draft of the NTS-specific part of the merge.

Best regards,
 Kristof

(I'm on mobile, if a something really doesn't make any sense, it might be due to some autocorrect issue)

 [email-masked] schrieb: -----

 =======================
 An: Daniel Franke <[email-masked]>
 Von: [email-masked]
 Datum: 14.10.2016 04:42 
 Kopie: [email-masked]
 Betreff: [ntpwg] Antwort:  NTS Synthesis
 =======================
   Thanks for your notes.

Dieter

---

From: [email-masked]
Date: Fri, 14 Oct 2016 10:58:26 +0200

One follow-up: in the merge, I did not yet include the technical details on the actual time sync messages in client-server mode from Daniel's proposal. Instead, there is some abstract description in a separate section. This is not an oversight. It represents my perceived need for discussion about the privacy goal as started by Sharon:
- what is the concrete privacy objective?
- is the privacy goal important enough to justify use of AEAD over simply MACs?
- what is the cost of AEAD compared to MAC?
- does AEAD as currently used completely fulfill the privacy objective? (If no, how can this be redeemed)

>From my point of view, this is the top priority issue on the technical side of things.

Best regards,
Kristof

 [email-masked] schrieb: -----

 =======================
 An: [email-masked]
 Von: [email-masked]
 Datum: 14.10.2016 10:45 
 Kopie: [email-masked]
 Betreff: [ntpwg] Antwort:  Antwort:  NTS Synthesis
 =======================
   Thank you for the analysis, Daniel.

Best regards,
 Kristof

 [email-masked] schrieb: -----

 =======================

Dieter