Subject: [Ntp] WG Call for Adoption: draft-stenn-ntp-extension-fields

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 25 Jul 2018 02:16:37 +0000

Folks,

As per the discussion at IETF 101 in Montreal, this email starts a WG Call for Adoption for: 
https://datatracker.ietf.org/doc/draft-stenn-ntp-extension-fields/

This document has been around since Nov 2016. The intent of this document is to make changes to the extension field mechanism specified in RFC 5905 and 5906 and clarified in RFC 7822. 

Anyone opposed to its adoption as a working group draft please speak up by Friday 22 June. 

Thanks!
Karen

---

From: Karen O'Donoghue <[email-masked]>
Date: Wed, 25 Jul 2018 02:59:21 +0000

Quick correction folks… the deadline for speaking up is 7 August. (That is what I get for copying from a previous email… )

Karen

> On Jul 24, 2018, at 10:16 PM, Karen O'Donoghue <[email-masked]> wrote:
> 
> Folks,
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Martin Langer <[email-masked]>
Date: Wed, 25 Jul 2018 12:44:29 +0200

Hello together,

I have read the document and would like to briefly describe how I see 
the whole thing.
As I see various changes are present and RFC7822 is actually not 
perfect. I'm bothered
by the minimum sizes of extension fields too. However, I think that the 
changes do not
bring any real advantages and are more of a problem at the moment.

Concrete points that bother me:

1. The draft looks like it is designed for Autokey only:

     The draft contains many references to Autokey. I guess Autokey is 
an insecure and
     deprecated security mechanism. I do not see why it should be 
supported further.
     Is it really useful?

2. Restructuring of the Field Type:

     Well, I guess subtypes are not bad as they allow grouping. However, 
I do not see
     any benefit of the flags on that position. I mean, not every 
extension field uses
     these and therefore they should be outsourced to the payload (Value 
field).

Other documents (e.g. RFC 7821, NTS draft) also refer to the normative 
RFC7822.
I am not sure if such changes will guarantee compatibility.

This is only my opinion.

best regards,
Martin

-- 
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel. : +49 5331 939 43370
Web  : https://www2.ostfalia.de/cms/de/pws/bermbach/start/kontakt_langer.html

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 25 Jul 2018 03:50:09 -0700

On 7/25/18 3:44 AM, Martin Langer wrote:
>     The draft contains many references to Autokey. I guess Autokey is an
> insecure and

Would you please say where?  It mentions autokey because the original
significant information about Extension Fields was in RFC5906, the
Autokey document.

The proposal moves this from 5906 into the general document.

As far as autokey is concerned, even though its no longer recommended,
it *is* a Standard, and needs to be documented.

There are a bunch of other EF proposals out there that rely on the EF
header description.

>     these and therefore they should be outsourced to the payload (Value

They are part of the extension field format that was specified in 5906,
and that *should* have been a general spec.

Not all EFs use the flag bits, but some do.  There is benefit to keeping
this information consistent across all the EF types that need them.

> I am not sure if such changes will guarantee compatibility.

I haven't reviewed 7821 specifically, but I'm not aware of any problem.

7821 uses a 28-octet length that is no longer *required* with this
update, but there's no problem if it remains at its current length.

H
--
>> This document has been around since Nov 2016. The intent of this
>> document is to make changes to the extension field mechanism specified
>> in RFC 5905 and 5906 and clarified in RFC 7822.
>>

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 25 Jul 2018 13:58:52 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 25.07.2018 um 12:50 in Nachricht

> this information consistent across all the EF types that need them.

I think the current implementation of NTP does NOT really implement the format as described: How does this macro
#define CRYPTO_CMD(x)   (((CRYPTO_VN << 8) | (x)) << 16)

#define CRYPTO_ASSOC    CRYPTO_CMD(1) /* association */

match the (16-bit-field type, 16-bit length) definition (Figure 14 of rfc5905)?
And the field type (command) is specified like this (rfc 5906, chap. 13):
      |   0x0002   | No-Operation Request                     |
      |   0x8002   | No-Operation Response                    |
      |   0xC002   | No-Operation Error Response              |

(BTW: Where are the (now obsolete) codes of previous autokey protocol defined?)
Unfortunately this reserves several block of non-contiguous values (three numbers per operation).

Also RFC 5906 states: "In Autokey the 8-bit Field Type field is interpreted as the version    number, currently 2." The field type is 16-bit as of rfc5905, however!

I think this is all bad design (and specification)! Adding response and error flags to the type code is just stupid. OK, it was done like that, but don't continue that practice in the future.

On page 25 of rfc 5906 (and rfc 7822) there should be a picture of the bit assignments (R, E, Version, and code).

Regards,
Ulrich

---

From: Daniel Franke <[email-masked]>
Date: Wed, 25 Jul 2018 15:37:25 -0400

I oppose adoption of this draft or any variant thereof; RFC 7822 should stand.

The parsing changes it proposes will make a sufficient mess of the
extension mechanism as to render it essentially unusable, and the
damage will be irreparable short of starting fresh with NTPv5 and
possibly also abandoning port 123. Creating syntactic ambiguity that
it is left to the implementation how to resolve is simply
unacceptable. It is essential to any protocol that correctly-formed
packets have exactly one possible meaning, and that incorrectly-formed
packets can be reliably rejected as such.

The added of the flag bits, in addition to obviously being
backward-incompatible (insert "flag day" pun here), make no sense
outside the context of Autokey. Other extensions have no use for them.
To the extent that Autokey relies on these flag bits for its
semantics, it can simply allocate all combinations thereof as
Autokey-related extension codes, and apply interpretation of the flags
only once the extension field has already been identified by its code
as an Autokey extension.

RFC 5906 is Informational, and Autokey is not a standard in any sense
of the word. Only the NTF implementation supports it and only the NTF
implementation ever will. Furthermore, as soon as NTS goes to the
IESG, I'm going to be submitting a
"draft-franke-ntp-autokey-diediedie" draft for WG adoption. The intent
of this draft will be to reclassify RFC 5906 as Historical, discuss
the problems with the protocol, and address the discrepancy between
the IANA EF codes and the ones used by NTF by leaving the current
registrations in place but flagging the squatted codes as Reserved so
that they will not be accidentally allocated to anything else.

So far I have not seen a call for adoption for
draft-stenn-ntp-mac-last-ef-02, but since the two drafts are
inextricably dependent on each other I will remark here that I oppose
adoption of that one as well, because the new extensions it proposes
serve no purpose when RFC 7822 is correctly followed. On the other
hand, at such time we decide to take up NTPv5 (which doesn't have to
be syntactically backward-compatible with v4 in anything after the
version field), I agree that it will then make sense to abandon the
legacy MAC field and replace it with an EF.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 26 Jul 2018 09:46:03 -0400

I'll keep this short and sweet... I agree with Daniel's assessment that
we would be creating a mess within the protocol by adopting this document.

Let's get NTS out the door and then we can worry about designing NTPv5,
if there is interest.

Brian

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 26 Jul 2018 17:08:02 +0200

> I oppose adoption of this draft or any variant thereof; RFC 7822 should stand.

I agree with all Daniel's points.

If there is a need for shorter extension fields, I think we can
still support them in NTPv4 using the packing/padding extension
fields I proposed in one of the earlier threads we had about this
draft. I can help with the specification if there is interest.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 26 Jul 2018 15:28:04 +0000

I am also opposed, because adding per-implementation ambiguity is not something we want to do more of these days.

---

From: Daniel Franke <[email-masked]>
Date: Thu, 26 Jul 2018 12:59:57 -0400

If for whatever reason we really, really have to support shorter
extension fields and can't wait for NTPv5 to do it, then I agree with
Miroslav that his sub-extensions proposal is the sanest way to go
about it. But I don't want to adopt that proposal either until I've
seen a use case for it that's compelling enough to justify the extra
complexity, and so far I haven't seen one.

NTPv5 can simply abolish the legacy MAC field, in which case all the
complexity goes away because then it's no longer necessary to enforce
a minimum EF length in order to unambiguously parse v5 packets. All
MACs go in an EF, and no need for a last-EF extension. But this is
only possible in conjunction with a version bump.

---

From: Hal Murray <[email-masked]>
Date: Thu, 26 Jul 2018 12:05:02 -0700

[email-masked] said:
> complexity goes away because then it's no longer necessary to enforce a
> minimum EF length in order to unambiguously parse v5 packets. All MACs go in
> an EF, and no need for a last-EF extension. But this is only possible in
> conjunction with a version bump. 

Is it worth doing a quick bump to V5 just to clean up this mess?

The idea behind the "quick" is that we would only remove legacy MAC fields and 
not get involved with extensive discussions about all the other changes 
somebody would like to make.

-- 
These are my opinions.  I hate spam.

---

From: Philip Prindeville <[email-masked]>
Date: Thu, 26 Jul 2018 13:25:30 -0600

> On Jul 26, 2018, at 1:05 PM, Hal Murray <[email-masked]> wrote:
> 
> 

It’s worth doing, but not “quickly”.  If we’re going to “big bang” things, let’s make sure that all current issues are adequately addressed and all new issues are properly reviewed.

“Too quickly” has gotten us into trouble before.

Or perhaps “too hastily” is more accurate.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 26 Jul 2018 12:45:03 -0700

Tell me again how getting even a simple NTPv5 that deprecates the legacy
MAC will happen "quickly".  I would be stunned if we could get a good
quality spec done in less than 3 years' time.  I

Implementations will have to support v4 clients for DECADES.

I don't think this idea has been carefully examined.

I will add that it would be trivial to add "Legacy MAC support" to the
I-DO EF, and that would be an easy way to also avoid this problem.

But it's clear to me that some people either don't understand or don't
care to understand the proposal, as the issues being complained about
are simply not "real".  I've been running this code for about a year and
a half now, and there have been *no* problems.  But I've said this
before, too.

H

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 26 Jul 2018 13:08:59 -0700

On 7/26/2018 1:03 PM, Philip Prindeville wrote:
> I think I see the source of confusion here: you’re assuming your experiences are typical.  They’re not.

I agree with you completely, and I also believe that my experience leads
me to a different conclusion than what others, with their experience,
leads them.

> Most people take the feedback they’re getting, consider it, integrate it, and come back with something new that they believe addresses all (or the most important ones, anyway) of the concerns raised.

I'm pretty comfortable that I've done this.

> This is how their experience differs from yours.

I look forward to real examples from others that support their position
and conclusion.

> Um… no.  HTTP/1.0 was found to be woefully inadequate (the single transaction per connection limitation alone meant latency on a multiple fetch page like an Amazon shopping page was orders of magnitude higher than it needed to be).  HTTP/1.1 came out, and all the major servers and browsers were supporting it in less than a year (indeed, high penetration in less than 6 months).
> 
> Perhaps we should have gone with subversions of the protocol, like NTP v4.1 (a la HTTP).

You are making my point.

Please show us how, in the existing NTPv4 header packet, we'd designate
"NTP v4.1".

H
--
> 
>> On Jul 26, 2018, at 1:45 PM, Harlan Stenn <[email-masked]> wrote:
>>

---

From: Daniel Franke <[email-masked]>
Date: Thu, 26 Jul 2018 16:38:15 -0400

> a half now, and there have been *no* problems.  But I've said this

The most recent commit to your ntp-dev is 26 months old, but I'm
willing to believe that you have code somewhere that happens to
correctly handle whatever combinations of EFs that it also happens to
emit. This in no way rebuts or addresses any of the criticisms raised
on this thread.

---

From: Philip Prindeville <[email-masked]>
Date: Thu, 26 Jul 2018 16:50:23 -0600

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 26 Jul 2018 16:18:32 -0700

> emit. This in no way rebuts or addresses any of the criticisms raised

This has NOTHING to do with ntp-dev.

Likewise, nobody has presented any support for the alleged claims that
the proposal has the cited problems.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 26 Jul 2018 17:19:12 -0700

> I am also opposed, because adding per-implementation ambiguity is not something we want to do more of these days.

What is this "per-implementation ambiguity" of which you speak?

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 26 Jul 2018 17:23:10 -0700

> we would be creating a mess within the protocol by adopting this document.

I'm genuinely curious.  In what way do you think the proposal "would be
creating a mess within the protocol"?

> Let's get NTS out the door and then we can worry about designing NTPv5,

Let's keep NTS separate from this.

There's a lot to be done with EFs in general, as evidenced by the number
of proposals from Tal, Danny, Miroslav, Sharon, me, ...

H
--

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 27 Jul 2018 10:19:18 +0200

> complexity, and so far I haven't seen one.

Some of the EFs that were proposed are shorter than 28 octets, e.g.
I-Do or Suggested-REFID. Also, I'm considering to split some of the
fields from the correction EF into a separate EF. I think it would be
nice to allow short EFs to limit the waste of bandwidth.

If we limited the use of the packing EF to one, not allowed MACs after
it, and required it to contain all EFs in the packet, it would
basically provide what we want from NTPv5. We could call it NTPv4.1 if
you like. The extra complexity would be a new check and flag in the
parser.

An NTPv4.1 packet would have the following format:
- 48-octet NTPv4 header
- 2-octet magic number (the packing EF type)
- 2-octet length of all data following the NTP header (the packing EF
  length)
- >24 octets of one or more EFs with no restrictions on minimal length

A parser that supports the NTPv4.1 format would check that:
- the length of the packet is at least 76 octets
- the 49th and 50th octets contain the magic number
- the 51th and 52th octets contain a value that is equal to the
  length of the packet - 48

If the above is true, the parser knows there is no legacy MAC, i.e. 
the remaining data should be parsed as extension fields. There is no
ambiguity in parsing.

An older parser following RFC7822 would see a valid NTPv4 packet with
a single >28-octet EF of an unknown type.

When compared to the "quick" NTPv5 approach, NTPv4.1 packets would be
longer by 4-24 octets. The 24-octet waste would be with a single
4-octet extension field (if one is ever specified). With
longer/multiple EFs it would decrease down to 4 octets.

Does that make sense?

-- 
Miroslav Lichvar

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 27 Jul 2018 12:09:51 +0200

> This is how their experience differs from yours.

Hm, but in the past this has also been true the other way round, i.e.
when Harlan made a suggestion it wasn't accepted, either.

It's really a pity how the discussion goes here, and that no party tries
to make a step towards the other one, to agree to a good solution which
meets all requirements.

> Um… no.  HTTP/1.0 was found to be woefully inadequate (the single transaction per connection limitation alone meant latency on a multiple fetch page like an Amazon shopping page was orders of magni…

Yes, I think what Harlan wrote is true.

You know we at Meinberg are manufacturing NTP server appliances, and I
know from quite a number of customers that they had machines or Unix
operating systems that were shipped with NTPv3, even when NTPv4 had
already been out for years.

The same will happen when NTPv5 is released: we *will* have to support
NTPv4 for a long time. I think this is pretty much different than the
http example.

In my opinion it would be the best to merge the 2 proposals and
implement the new extension fields in a way they can as good as possible
be distinguished.

What we *don't* need, IMO, is the possibility to have a *mixture* of old
and new extension fields in the same NTP packet. If we say that we only
allow new EFs, *or* old EFs, this would be *much* easier:

- Old/ existing clients could send packets with old EFs to the server
(they are not aware of the new EFs anyway).

- New implementations could use the new EFs explicitly. They wouldn't
even have to know about the old EFs at all, and there's no need to
support them.

- NTP servers could optionally support for both types, first try to
decode the new EFs, and if this fails try to decode the legacy ones.
This would make sure the server can be used in a mixed environment with
old and new clients.

If I remember correctly (haven't looked at the docs right now) parts of
Harlan's proposal could help to avoid the requirement for a minimum
extension field length, and if we remove the requirement for mixed
extension fields from it the 2 proposals could be merged and would
resuld in a very nice solution for all.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy

---

From: Hal Murray <[email-masked]>
Date: Fri, 27 Jul 2018 04:12:57 -0700

[email-masked] said:
> The same will happen when NTPv5 is released: we *will* have to support NTPv4
> for a long time. I think this is pretty much different than the http example.

"Support NTPv4" isn't well defined.  Support for everything but EFs seems 
pretty straightforward.  I agree that we will have to support that much for a 
long time.

It's not obvious to me what we have to support in the way of EFs.

What EFs are currently in use?  Who is using them?  Which packages currently 
support them?  ...

---

From: Brian Haberman <[email-masked]>
Date: Fri, 27 Jul 2018 08:32:16 -0400

> creating a mess within the protocol"?

This WG is effectively making it impossible for anyone (an implementer,
an operator, or a user) to understand what is/isn't a part of NTPv4.

> Let's keep NTS separate from this.

I made my comment as way to express a priority. I see it as far more
important to publish NTS than anything else being discussed on the list.

Regards,
Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 27 Jul 2018 13:37:38 +0000

>    What is this "per-implementation ambiguity" of which you speak?
  
you said that you have code that works.

Others have said that this change brings ambiguity.

Therefore, the ambiguity is apparently per implementation.

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 27 Jul 2018 19:52:58 -0700

I'll let somebody else point out your logic flaws.

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 27 Jul 2018 19:55:25 -0700

A functional replacement for RFC5806 (Autokey V2) is very important.

NTS is in no way that replacement.

H

---

From: "Majdi S. Abbas" <[email-masked]>
Date: Sat, 28 Jul 2018 12:31:58 -0400

On Thu, Jul 26, 2018 at 04:50:23PM -0600, Philip Prindeville wrote:
> Um… no.  HTTP/1.0 was found to be woefully inadequate (the single 
> transaction per connection limitation alone meant latency on a multiple 
> fetch page like an Amazon shopping page was orders of magnitude higher 
> than it needed to be).  HTTP/1.1 came out, and all the major servers 
> and browsers were supporting it in less than a year (indeed, high 
> penetration in less than 6 months).

	A live data point, from a server in the NTP pool on the US East
Coast:

$ ntpq -c sysstats | grep version
current version:        9330731771
older version:          2136010783

	20 years after ntp-4.0 was released, a full 18% of the client
requests that arrive at this pool server are NTPv3.  I have another
one in Europe that is running around 45% NTPv3 requests.  I fully expect
a similar long tail of NTPv4 requests.

	HTTP is a terrible example.  In 2018, HTTP's major use case is 
interactive browser software and mobile applications that run on general
purpose computers and receive regular updates.  Despite this, it took
nearly 20 years to get from HTTP 1.1 to HTTP 2.0, which is still not
deployed on the majority of websites:
	
	"HTTP/2 is now used by 25% of all websites, up from 12.9% one 
year ago." https://w3techs.com/technologies/details/ce-http2/all/all

	There are many, many older NTP implementations out there 
embedded in things that just don't receive updates.  Even my home PDU
and UPS have embedded SNTP clients that speak v3.

	So, fine...evolve the protocol, but do it as correctly and
completely as we can.  Rushing it is a bad idea, and breaking backwards
compatibility is not a practical answer.  NTPv4 is going to be with
us for quite a while.  I suspect NTPv3 may be with us even longer.

	--msa

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 28 Jul 2018 18:38:02 -0700

Ulrich,

On 7/25/2018 4:58 AM, Ulrich Windl wrote:
>>> ...

I disagree with you, and besides, that ship sailed long ago.

...

> Unfortunately this reserves several block of non-contiguous values (three numbers per operation).

The reference implementation has been shipping the V1 EF header format
that was first released in March of2000.  Please note that RFC5906 came
out *10 years later*.  RFC5906 documents the V2 EF format.

That's why you're seeing a difference between the CRYPTO_CMD macro and
the spec.

I've never heard of anybody else implementing Autokey, and ntp-4.4.0
will have a configuration knob to dictate "autokey with V1 EF format
(legacy)" or the 'current' EF layout.

People will be able to choose what they want to support, legacy Autokey
EFs, or "current" EF format (which will support Autokey-V2 (RFC5906) and
new EFs, but there should be no good reason for anybody to want to use
Autokey-V2.

> Also RFC 5906 states: "In Autokey the 8-bit Field Type field is interpreted as the version    number, currently 2." The field type is 16-bit as of rfc5905, however!

The language of RFC 5906 was not of my choosing.  That sentence is using
"field type" to mean the octet that includes only the 8-bit EF Type,
whereas the 16 bit field is talking about the overall Field Type, which
is comprised of high-end flag bits, low-end subcommand/subtype, and the
8 bit "base" EF Type.

> I think this is all bad design (and specification)! Adding response and error flags to the type code is just stupid. OK, it was done like that, but don't continue that practice in the future.

I strongly disagree, and I'll re-read my proposal to see it can be
better justified.

Did you complain about this before RFC 5906 was passed in 2010?

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 30 Jul 2018 08:09:50 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 26.07.2018 um 21:45 in
Nachricht
<[email-masked]>:
> I‑DO EF, and that would be an easy way to also avoid this problem.
> 

Hi Harlan,

honestly: Running some code without a problem, and making some reasonable
specification are two very different things: You can code a bad specification
that works without a problem, but still the specification will be bad.

Regards,
Ulrich

>>> an EF, and no need for a last‑EF extension. But this is only possible in
>> The idea behind the "quick" is that we would only remove legacy MAC fields

> and 
> ‑‑ 
> http://nwtime.org ‑ be a Member!
>

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 29 Jul 2018 23:14:26 -0700

> that works without a problem, but still the specification will be bad.

Please support your POV that the specification is "bad".

By what criteria are you asserting that POV?

H
--

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 30 Jul 2018 08:15:03 +0200

>>> Philip Prindeville <[email-masked]> schrieb am
27.07.2018
um 00:50 in Nachricht
<[email-masked]>:
> I think I see the source of confusion here: you’re assuming your experiences

> are typical.  They’re not.
> 
> Most people take the feedback they’re getting, consider it, integrate it, 
> and come back with something new that they believe addresses all (or the
most 
> important ones, anyway) of the concerns raised.
> 
fetch 
> page like an Amazon shopping page was orders of magnitude higher than it 
> needed to be).  HTTP/1.1 came out, and all the major servers and browsers 
> were supporting it in less than a year (indeed, high penetration in less
than 
> 6 months).

You are missing that a lot of (embedded) software that uses some libraries
still does work with HTTP 1.0, and even the newer Servers still support HTTP
1.0 (AFAIK). And there a still a few servers around that are unable to continue
an aborted download (that any HTTP 1.1 server should support).

> 
> Perhaps we should have gone with subversions of the protocol, like NTP v4.1

> (a la HTTP).

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 30 Jul 2018 08:48:43 +0200

>>> Hal Murray <[email-masked]> schrieb am 27.07.2018 um 13:12 in

> What EFs are currently in use?  Who is using them?  Which packages currently 

Yes, especially there's no document on autokey v1. Actually we still run an old server with old NTP software (SLES 10 SP4) that speaks autokey v1 successfully (while being unable to communicate to a server speaking autokey v2). Maybe it's because some experimental protocol was released as official version...

It would have been better to discuss before implementing, I guess...

Regards,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 29 Jul 2018 23:58:27 -0700

> It would have been better to discuss before implementing, I guess...

Huh?

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 30 Jul 2018 10:16:20 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 29.07.2018 um 03:38 in Nachricht
<[email-masked]>:

[...]
> Did you complain about this before RFC 5906 was passed in 2010?

No, because I did not feel like having a strong vote. Also the main problem is the implementation, specification following it. But it's too late to complain about the past now...

Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Jul 2018 01:28:14 -0700

> No, because I did not feel like having a strong vote. Also the main problem is the implementation, specification following it. But it's too late to complain about the past now...

Sorry, Ulrich, but I'm not buying it.

The code first saw "light of day" in March of 2000.

Draft-00 of 5606 came out in September of 2007.

Draft-08 came out in March of 2010.

RFC-5906 came out in June.

So you believe that the specification should be made before it can be
shown to work?
-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 30 Jul 2018 10:33:13 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 30.07.2018 um 08:58 in
Nachricht
<[email-masked]>:

>> Nachricht <20180727111257.B233940605C@ip‑64‑139‑1‑69.sjc.megapath.net>:
>> 
NTPv4

>>> pretty straightforward.  I agree that we will have to support that much
for 
>>> a 
>> Yes, especially there's no document on autokey v1. Actually we still run an

> old server with old NTP software (SLES 10 SP4) that speaks autokey v1 
> successfully (while being unable to communicate to a server speaking autokey

> v2). Maybe it's because some experimental protocol was released as official

> version...

What I meant to say is: If the autokey format had been better designed
(probably discussing the protocol before implementing and distributing it), the
corresponding document (taht was written years later) would be much easier to
read and understand. Before the official document the implementation was
considered to be "in flux" and thus no valid subject for discussion. Once the
document came out it was much to late to discuss the details. IMHO some details
are "very strange". Of course nobody likes if others talk bad about his/her own
pets...

> http://networktimefoundation.org ‑ be a member!
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 30 Jul 2018 10:47:19 +0200

> out *10 years later*.  RFC5906 documents the V2 EF format.

Is the EF format version something different from the Autokey version?

According to the log of the NTF's ntp_crypto.h file, ntpd started
encoding "2" as the Autokey version in the EF type in 2001.

> new EFs, but there should be no good reason for anybody to want to use

So there are two different Autokey V2 protocols using an incompatible
EF type? What's the point of this?

If nobody else has implemented Autokey, why not just make an errata
for RFC5906 to describe what the only implementation is using?

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Jul 2018 01:52:11 -0700

> are "very strange". Of course nobody likes if others talk bad about his/her own

I disagree completely, as you might expect, for reasons I've recently
written.

The entire point of making sure the implementation works as expected is
to make sure the specification describes something that we know will work.

There was *tons* of time to bring up discussion and make fixes.

Your point about "pets" is disturbing, and I believe incorrect.  It does
a disservice to Dave and others who have put HUGE amounts of work in to
this project.  The entire goal here has always been and continues to be
an excellent protocol description, with well-behaved algorithms, and a
corresponding reference implementation.

I also find it quite troubling that so many people here think we should
specify levels of behavior that clearly cross over into "implementor's
choice".  It's an overreach that I think creates more problems than it
solves.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Jul 2018 01:55:53 -0700

> Is the EF format version something different from the Autokey version?

The EF layout in my proposal matches the layout in RFC5906, which is
what we want to be using.

> EF type? What's the point of this?

Not to my knowledge.

> for RFC5906 to describe what the only implementation is using?

Why bother?  We want EFs to work as well as we can moving forward, and
we want to deprecate the usage of Autokey V2.

Everything will still work moving forward.

---

From: [email-masked]
Date: Mon, 30 Jul 2018 11:46:31 +0200

> There was *tons* of time to bring up discussion and make fixes.

Procedure-wise, I agree with Ulrich: coding first and then writing down 
what the code does has lots of problems (I honestly would hardly even call 
it design).
Most of all, yes, it does obscure when the right time for inspection and 
criticism is.

Having an implementation of a specification running for a certain time 
without detectable runtime errors is nice.
But it is not (strictly) necessary for judging the quality of the 
specification.
And most importantly, it is also not sufficient for that goal. It proves 
that the specification is implementatble, but not that it is sound. A 
specification can absolutely have gaping holes that just never come up at 
runtime under normal circumstances. They will still be gaping holes.

> corresponding reference implementation.

And criticism should neither be intended nor taken as diminishing the 
amounts of work, the dedication, or the intent of anyone involved.
But neither of those points should prohibit criticism of the result, 
either.

> choice".  It's an overreach that I think creates more problems than it

The point here is that it is not objectively "clear" what crosses that 
line.
>From my point of view, for example, any choice sould really only be 
"implementor's choice" if two implementations with wildly different 
choices made can still interact and if the degree to which the 
specification's goals are reached is genuinely independent of that choice 
- and those conditions can be hard to fulfill.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Jul 2018 03:05:44 -0700

On 7/30/2018 2:46 AM, [email-masked] wrote:
> what the code does has lots of problems (I honestly would hardly even
> call it design).

As opposed to write a standard that has not been thru any rigorous
engineering testing, and then decide that in theory it is OK, so we move
ahead?

Autokey had 7 YEARS of real-world testing and engineering done on it
before the spec was started.

It had 3 more YEARS of testing and review before becoming a Standard.

Are you seriously trying to tell me that writing the spec first, then
implementing it, will generally produce a *better* result than 10 years
of actual engineering work that gets turned in to a specification?

> But it is not (strictly) necessary for judging the quality of the

I'm waiting to see where you're headed with this.

> specification can absolutely have gaping holes that just never come up
> at runtime under normal circumstances. They will still be gaping holes.

By the same token, coming up with a spec is independent of *two* things:

- is the spec implementable?
- is the spec sound?

> But neither of those points should prohibit criticism of the result,

Perhaps it goes to how the criticism is phrased, and the claims of the
criticism.

> specification's goals are reached is genuinely independent of that
> choice - and those conditions can be hard to fulfill.

I agree with you, and that's not what I've been seeing from this WG and
the requests being made on drafts and proposals.

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 30 Jul 2018 12:30:22 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 30.07.2018 um 12:05 in Nachricht
<[email-masked]>:

[...]
> of actual engineering work that gets turned in to a specification?

Well, just look at the "key renewal" of autokey: Actually only the certificate is renewed, not the key. I'd call that a major design flaw.
The the key size: There were/are no provisions for using a longer key or different algorithms, so we need a new NTP protocol version to get that.

[...]

Regards,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Jul 2018 03:39:09 -0700

> Well, just look at the "key renewal" of autokey: Actually only the certificate is renewed, not the key. I'd call that a major design flaw.

I'll see if I can get Dave to reply to this.  I never paid that much
attention to it.

> The the key size: There were/are no provisions for using a longer key or different algorithms, so we need a new NTP protocol version to get that.

For the MAC?

You are completely wrong.  We've already supported 16, 20, and 24 octet
MAC lengths.  We've never changed the NTP protocol version for this. We
could allow for even larger MAC sizes now, with no problems.  We have
also long supported a number of different algorithms.

Even today, everybody is saying that 160 bits for a hash is still
sufficient. But if somebody *wanted* to send more, they certainly could.

But perhaps I am misunderstanding you.

---

From: [email-masked]
Date: Mon, 30 Jul 2018 12:52:20 +0200

> engineering testing, and then decide that in theory it is OK, so we move

Don't get me wrong, this whole question is by no means trivial.
But from my point of view: if the theory is good, and it doesn't work in 
practice, then it might still be fixable.
If something happens to work under the right circumstances, but it is 
based on no theory or (worse) only on flawed theory, it is much harder to 
remedy.
 
> of actual engineering work that gets turned in to a specification?

I don't think Autokey is the witness you want to turn to for this.

> - is the spec implementable?

In drafting it, perhaps.
Getting it to standards tracks should hopefully indicate that it is sound 
(I'm aware of the limits of this worldview).
As for the "implementable" part, that can be helped by having it 
implemented (with close feedback loops) while in development.
 
> the requests being made on drafts and proposals.

I mean, this is all highly subjective.
I for one have felt that some proposals amounted to basically leaving it 
to implementors whether they even want to fulfill essential specification 
goals - which I fundamentally disagree with.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 30 Jul 2018 04:03:23 -0700

> practice, then it might still be fixable.

Yes, it might.

> based on no theory or (worse) only on flawed theory, it is much harder to 

Of course.  And the problem is this has never been the situation with NTP.

Dave has very thoroughly put continuous engineering rigor to the effort.
 Has it been perfect?  No.  But please don't attempt to claim that it's
based in any way in no theory or flawed theory.

And LOTS of people, many with serious chops in different aspects of the
code and process, have gone back and forth to make sure that the result
is the best job possible.

Again, that doesn't mean it's perfect.  It doesn't mean there aren't bugs.

But if you try and claim that it was done with no theory or flawed
theory, I'm gonna call you out on that.

> I don't think Autokey is the witness you want to turn to for this.

It's not the only one.

And please don't try and trot out NTS as a shining example of the right
way, either.

> implemented (with close feedback loops) while in development.

In theory I agree with you.  In practice, the theory you describe falls
apart, badly.

> goals - which I fundamentally disagree with.

Got an example?

Personally, I think 5906 should have been Standards Track, with parts of
it being optional to implement.

But this was also in the day when one requirement was to avoid embedding
crypto into an implementation, as that would run afoul of import/export
laws.

We're now in a situation where the new AES-128-CMAC MAC algorithm is
basically REQUIRED, and every time I raise the point about how this will
run afoul of those same import/export requirements, there is a deafening
silence in response.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 30 Jul 2018 14:24:55 +0200

Skickat från min iPhone

> 30 juli 2018 kl. 13:03 skrev Harlan Stenn <[email-masked]>:
> 
> 

... and here is the ”we reject Kings” part. 

References to authority is a pretty clear indication something is seriously wrong with thus line of reasoning.