[Git][NTPsec/ntpsec][master] Add Martin Langer's notes, reorganize.

[Eric S. Raymond]

Eric S. Raymond pushed to branch master at NTPsec / ntpsec


Commits:
52536ed6 by Eric S. Raymond at 2019-02-05T14:39:31Z
Add Martin Langer's notes, reorganize.

- - - - -


1 changed file:

- devel/nts.adoc


Changes:

=====================================
devel/nts.adoc
=====================================
@@ -431,6 +431,18 @@ The binary KE request-response format is unfortunate for all the usual
 reasons (endianness issues etc). At the expected transaction volume,
 the encode/decode overhead shouldn't be an issue.
 
+link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.3[4.1.3], link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.4[4.1.4]
+
+Is the response in case of abuse 'continue the abuse, just wait a minute'?
+
+link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.7[5.7]
+
+Does the unique identifier extension need to be omniversally unique?
+
+Why are the timestamps, unique identifier extension etc. seemingly not tamper resisted?
+
+Can NTSN and other KODs get signed?
+
 == NTS/mode 7 next
 
 === NTS and mode 6 and 7
@@ -439,12 +451,13 @@ Network Time Security explicitly only supports modes 3 and 4 at this time.
 I see no reason why NTS could not be expanded to cover modes 1, 2, 6, and 7.
 Expansion to cover modes 6&7 should require an authentication token extension.
 
-
 === mode 6 -> mode 7 next
 
-I feel that in keeping with comments. It should be possible to shift a copy of mode 6 to UTF-8 JSON-RPC and rebadge it as a new mode 7.
-The following is an overly verbose partial mockup of a transaction chain querying peer-stats.
-All the numbers should be in _decimal_ without the hexadecimal timestamps and such.
+I feel that in keeping with comments. It should be possible to shift a
+copy of mode 6 to UTF-8 JSON-RPC and rebadge it as a new mode 7.  The
+following is an overly verbose partial mockup of a transaction chain
+querying peer-stats.  All the numbers should be in _decimal_ without
+the hexadecimal timestamps and such.
 
 [source, json]
 ----
@@ -556,14 +569,20 @@ All the numbers should be in _decimal_ without the hexadecimal timestamps and su
 ...
 ----
 
+== Martin Langer's notes == 
 
-=== link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.3[4.1.3], link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-4.1.4[4.1.4]
+um... maybe the first hint... The current OpenSSL version doesn't
+work with NTS and TLS1.3. The TLS key exporter function fails
+because the exporter label is too long. It's an OpenSSL bug which is
+already committed and fixed. The next OpenSSL version 1.1.1b should
+work again.
 
-Is the response in case of abuse 'continue the abuse, just wait a minute'?
+This is my current workaround:
 
-=== link:https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp#section-5.7[5.7]
-Does the unique identifier extension need to be omniversally unique?
-
-Why are The timestamps, unique identifier extension etc. seemingly not tamper resisted?
+--
+// TODO: bug in OpenSSL 1.1.1a --> "EXPORTER-network-time-security/1"
+// doesn't work.
+#define *TLS_Exporter_Labe**l* **"EXPORTER-nts/1"
+--
 
-Can NTSN and other KODs get signed?
+// end



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/52536ed60e319a5c3918b4cf1eef3df21788ec86

-- 
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/52536ed60e319a5c3918b4cf1eef3df21788ec86
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20190205/e16ff7c9/attachment-0001.html>