Subject: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-05.txt

From: [email-masked]
Date: Tue, 01 Mar 2016 01:06:10 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol of the IETF.

        Title           : UDP Checksum Complement in the Network Time Protocol (NTP)
        Author          : Tal Mizrahi
	Filename        : draft-ietf-ntp-checksum-trailer-05.txt
	Pages           : 13
	Date            : 2016-03-01

Abstract:
   The Network Time Protocol (NTP) allows clients to synchronize to a
   time server using timestamped protocol messages. To facilitate
   accurate timestamping, some implementations use hardware-based
   timestamping engines that integrate the accurate transmission time
   into every outgoing NTP packet during transmission. Since these
   packets are transported over UDP, the UDP checksum field is then
   updated to reflect this modification. This document proposes an
   extension field that includes a 2-octet Checksum Complement, allowing
   timestamping engines to reflect the checksum modification in the last
   2 octets of the packet rather than in the UDP checksum field. The
   behavior defined in this document is interoperable with existing NTP
   implementations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ntp-checksum-trailer-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-checksum-trailer-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 01 Mar 2016 11:40:12 +0000

I have some recommendations on changes I'd like to see in this document:

- The extension header Field Type should be: 0x2005
  This follows the convention of using the high-order bits as flag bits
  and low-order bits as the opcode.  In this case the 0x2000 bit means
  "This extension field does not require a subsequent MAC".
  This is important because we want to make it easy for a client that
  does not know about this extension field to know that the subsequent
  MAC is not needed.  The unknown (to an older client) extension field
  can be safely ignored in this case.

- the extension field length should not be specified at this time.
  There are enough ways to tell the difference between an old-style
  MAC and this extension field, and there are cases where 28 bytes
  will conflict with an old-style MAC.

- I propose an *additional* implementation using the same Field Type, in
which:

- - the Accurate Timestamp Engine does not touch the original content of
the packet at all, so the NTP packet using this method  MAY contain a MAC.

- - the Accurate Timestamp Engine adds the described extension field,
consisting of:
- - - the Field Type (0x2005)
- - - the packet length
- - - 4 octets of an unsigned fractional NTP timestamp containing the
accurate timestamp correction offset
- - - any 0x00 padding octets
- - - the checksum complement

The reasoning for this alternative implementation is that while the
original proposal is backward compatible, it PROHIBITS the use of
authentication.  While this may be tolerable in some environments, it is
not tolerable in others.

With my alternative, the original packet is unchanged so a MAC is
allowed.  To benefit from the accurate timestamp engine either updated
client software will be required or hardware on the receiving side will
need to update the incoming packet to adjust the base packet header.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 03 Mar 2016 06:12:15 +0000

Upon further reflection, I'd like to clarify my last message on this topic.

I request the following advice to be given to IANA:

I recommend the following, and if it is difficult to accomplish at this
stage then don't worry about it:

 - the extension field length should not be specified.
   There are enough ways to tell the difference between an old-style
   MAC and this extension field, and there are cases where 28 bytes
   will conflict with an old-style MAC.

This is an experimental RFC, and as such the document is fine.

If this proposal is to advance beyond the experimental stage, I'd like
the other points I raised to be part of that future discussion.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Thu, 3 Mar 2016 14:19:42 -0500

>  - the extension field length should not be specified.

The extension field length MUST be specified. That's not an option.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 3 Mar 2016 11:45:06 -0800

> The extension field length MUST be specified. That's not an option.

The extension field length must exist.

There is no need to require it to be 28 octets.

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

---

From: Greg Dowd <[email-masked]>
Date: Thu, 3 Mar 2016 20:24:51 +0000

I have to admit I haven't reread the draft lately so it may be an ignorant question but why does IANA need to record/specify the length?  If it is a TLV, the type is specified but the length is in the object.  I understand constraints (like must be greater than x and less the y) but why IANA controlled?

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+greg.dowd=[email-masked]] On Behalf Of Danny Mayer
Sent: Thursday, March 03, 2016 11:20 AM
To: Harlan Stenn; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-05.txt

EXTERNAL EMAIL

On 3/3/2016 1:12 AM, Harlan Stenn wrote:
> I recommend the following, and if it is difficult to accomplish at 
> this stage then don't worry about it:
>

Danny

---

From: Danny Mayer <[email-masked]>
Date: Thu, 3 Mar 2016 16:51:57 -0500

> I have to admit I haven't reread the draft lately so it may be an ignorant question but why does IANA need to record/specify the length?  If it is a TLV, the type is specified but the length is in…

The extension field length is in the extension field. That has nothing
to do with IANA. Maybe I misunderstood your question?

Danny

---

From: Greg Dowd <[email-masked]>
Date: Thu, 3 Mar 2016 22:49:57 +0000

Let me restate my question.  I will assume I misread Harlan's post and that his two declarations were independent.  The first targeting IANA and the second targeting the draft itself?  So I will remove IANA from my question.  The current proposal proposes a length of 28 octets although only 16 bits are necessary.  Actually, all of this is a little fuzzy to me.  Probably because there is this chicken and egg problem.

5905 says minimum extension size is 16 bytes.  That is because 5905 states that extensions MUST be followed by a MAC.  This is all normative.

Draft-ietf-ntp-entension-field-07 says that extensions do NOT have to be followed by a MAC.  Having been involved in the process, I would kind of debate that the language in 5905 was accidental or in error at the time but whatever.  Has an errata been filed against 5905 to fix up these issues?  This draft also says that an extension that does NOT have a following MAC MUST be at least 28 bytes so that it can be distinguished.

The checksum-trailer draft says it MUST be EXACTLY 28 bytes.  But that isn't required by this functionality.  Basically, this draft wants to define a 16 bit value and encode it in a TLV style extension that meets the requirements of extensions as defined by the relevant protocol docs.

Can you clarify what you mean by extension field length must be defined in the checksum trailer draft?  My main reason for asking is that the concept of a TLV seems to be taking a bit of a beating.  And in the very first draft of something different than autokey :-)  First, we've got Harlan talking about using the high order bit of the type field to distinguish MAC or non-MAC following and now you talking about hardcoding the length.  If that is the case, the value of using a TLV is diminishing more quickly than I had hoped.

That is why I echo Harlan's sentiment on length as I understood it.  Basically, I would lean towards IANA registration of a Type value.  Then, an extension defined with the length = 16 bits plus enough padding to create a valid extension.

Now, on the offhand statement that the high order bit of the type value could be used to distinguish MAC or non-MAC.  I don't see that in the ntp-extension draft.  So, is it necessary or not?  If it is, then we should probably include that in the ntp-extension draft.  Then, either IANA only controls 15 bits or the checksum-trailer draft should request BOTH versions, MAC and non-MAC.

Because the checksum-trailer is manipulating timestamps, these may absolutely need to have a MAC.  Whether that is practical currently is not the issue but it needs to be allowed.  

I'm fully supportive of all the technology but the paperwork seems a little fuzzy.

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: Thursday, March 03, 2016 1:52 PM
To: Greg Dowd; Harlan Stenn; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-05.txt

EXTERNAL EMAIL

> I have to admit I haven't reread the draft lately so it may be an ignorant question but why does IANA need to record/specify the length?  If it is a TLV, the type is specified but the length is in…

The extension field length is in the extension field. That has nothing to do with IANA. Maybe I misunderstood your question?

Danny
> From: ntpwg 
> [mailto:ntpwg-bounces+greg.dowd=[email-masked]] On Behalf 
> Of Danny Mayer
>> If this proposal is to advance beyond the experimental stage, I'd 
>> like the other points I raised to be part of that future discussion.
>>
>
>

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 3 Mar 2016 17:19:32 -0800

On 3/3/16 2:49 PM, Greg Dowd wrote:
> Let me restate my question.  I will assume I misread Harlan's post
> and that his two declarations were independent.

Those two declarations were independent.

> The first targeting
> IANA and the second targeting the draft itself?

Yes.

> So I will remove
> IANA from my question.  The current proposal proposes a length of 28
> octets although only 16 bits are necessary.  Actually, all of this is
> a little fuzzy to me.  Probably because there is this chicken and egg
> problem.

My understanding is that Tal chose a length of 28 octets to make sure
this extension field could not be confused with a MAC.  I believe:

- that is not really correct - I believe an SHA1 MAC will be 28 bytes long

- it doesn't matter:
- - there are other ways to determine if data after the base packet is
    an extension field or a MAC.
- - the *worst* case is that this data matches both a MAC and this new
    extension field.

If it's really just a MAC then we don't care if it matches this
extension field.  If it's really just an extension field and it also
matches a MAC then it's up to the implementation to decide what to do if
that "sham" MAC matched a valid symmetric key (it can't be autokey if
the payload is really just a checksum complement) or it didn't.

This is pretty much why I think it's wrong to mandate a 28-byte length
for this EXPERIMENTAL RFC.  It can be as long as anybody wants it to be,
as the sole purpose of it is to be a checksum complement.

> 5905 says minimum extension size is 16 bytes.  That is because 5905
> states that extensions MUST be followed by a MAC.  This is all
> normative.

I'll re-read this, too.  I think the shortest extension field would be
4 bytes long, especially since I'm about to submit a proposal that says
the 4-byte CRYPTO-NAK is an extension field where the field type is
0x0000 and the length is 0x0000 instead of the expected 0x0004.

Again, I'll be reading 5906 tonight to get a better understanding.

I may dig in to more of Greg's comments below later tonight.

H
--

> Draft-ietf-ntp-entension-field-07 says that extensions do NOT have to
> be followed by a MAC.  Having been involved in the process, I would
> kind of debate that the language in 5905 was accidental or in error
> at the time but whatever.  Has an errata been filed against 5905 to
> fix up these issues?  This draft also says that an extension that
> does NOT have a following MAC MUST be at least 28 bytes so that it
> can be distinguished.

> The checksum-trailer draft says it MUST be EXACTLY 28 bytes.  But
> that isn't required by this functionality.  Basically, this draft
> wants to define a 16 bit value and encode it in a TLV style extension
> that meets the requirements of extensions as defined by the relevant
> protocol docs.
> 
> Can you clarify what you mean by extension field length must be
> defined in the checksum trailer draft?  My main reason for asking is
> that the concept of a TLV seems to be taking a bit of a beating.  And
> in the very first draft of something different than autokey :-)
> First, we've got Harlan talking about using the high order bit of the
> type field to distinguish MAC or non-MAC following and now you
> talking about hardcoding the length.  If that is the case, the value
> of using a TLV is diminishing more quickly than I had hoped.
> 
> That is why I echo Harlan's sentiment on length as I understood it.
> Basically, I would lean towards IANA registration of a Type value.
> Then, an extension defined with the length = 16 bits plus enough
> padding to create a valid extension.
> 
> Now, on the offhand statement that the high order bit of the type
> value could be used to distinguish MAC or non-MAC.  I don't see that
> in the ntp-extension draft.  So, is it necessary or not?  If it is,
> then we should probably include that in the ntp-extension draft.
> Then, either IANA only controls 15 bits or the checksum-trailer draft
> should request BOTH versions, MAC and non-MAC.
> 
> Because the checksum-trailer is manipulating timestamps, these may
> absolutely need to have a MAC.  Whether that is practical currently
> is not the issue but it needs to be allowed.
> 
> -----Original Message----- From: Danny Mayer [mailto:[email-masked]] 
> Sent: Thursday, March 03, 2016 1:52 PM To: Greg Dowd; Harlan Stenn;
> [email-masked] Cc: [email-masked] Subject: Re: [ntpwg] I-D
> Action: draft-ietf-ntp-checksum-trailer-05.txt
> 
> EXTERNAL EMAIL
> 
> 
>> I have to admit I haven't reread the draft lately so it may be an
>> ignorant question but why does IANA need to record/specify the
>> length?  If it is a TLV, the type is specified but the length is in
>> the object.  I understand constraints (like must be greater than x
>> and less the y) but why IANA controlled?
>> 
> 
> The extension field length is in the extension field. That has
> nothing to do with IANA. Maybe I misunderstood your question?
> 
> Danny
>> 
>> -----Original Message----- From: ntpwg 
>> [mailto:ntpwg-bounces+greg.dowd=[email-masked]] On
>> Behalf Of Danny Mayer Sent: Thursday, March 03, 2016 11:20 AM To:
>> Harlan Stenn; [email-masked] Cc: [email-masked] Subject: Re:
>> [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-05.txt
>> 
>> EXTERNAL EMAIL
>> 
>> 
>>> - The extension header Field Type should be: 0x2005 This follows
>>> the convention of using the high-order bits as flag bits and
>>> low-order bits as the opcode.  In this case the 0x2000 bit means 
>>> "This extension field does not require a subsequent MAC". This is
>>> important because we want to make it easy for a client that does
>>> not know about this extension field to know that the subsequent 
>>> MAC is not needed.  The unknown (to an older client) extension
>>> field can be safely ignored in this case.
>>> 
>>> I recommend the following, and if it is difficult to accomplish
>>> at this stage then don't worry about it:
>>> 
>>> There are enough ways to tell the difference between an
>>> old-style MAC and this extension field, and there are cases where
>>> 28 bytes will conflict with an old-style MAC.
>>> 
>> _______________________________________________ ntpwg mailing list 
>> [email-masked] http://lists.ntp.org/listinfo/ntpwg 
>> _______________________________________________ ntpwg mailing list 
>> [email-masked] http://lists.ntp.org/listinfo/ntpwg
>> 
>> 
> 
>

---

From: Danny Mayer <[email-masked]>
Date: Thu, 3 Mar 2016 22:11:30 -0500

On 3/3/2016 5:49 PM, Greg Dowd wrote:
> and
that his two declarations were independent. The first targeting IANA and
the second targeting the draft itself? So I will remove IANA from my
question. The current proposal proposes a length of 28 octets although
only 16 bits are necessary. Actually, all of this is a little fuzzy to
me. Probably because there is this chicken and egg problem.

One of the problems with the MAC field is that it does not contain a
length so you have to guess whether something beyond the end of the
basic packet is a MAC or an extension field. We are trying to figure out
if we have enough information to do that. I think that we are going to
end up with a best guess.

One result of this is that we are preparing a MAC extension field to
replace the MAC field at the end of a packet. This will have a length
field and will obsolete the existing MAC.
> 5905 says minimum extension size is 16 bytes. That is because 5905
states that extensions MUST be followed by a MAC. This is all normative.
> Draft-ietf-ntp-entension-field-07 says that extensions do NOT have
be followed by a MAC. Having been involved in the process, I would kind
of debate that the language in 5905 was accidental or in error at the
time but whatever. Has an errata been filed against 5905 to fix up these
issues? This draft also says that an extension that does NOT have a
following MAC MUST be at least 28 bytes so that it can be distinguished.

The draft explicitly update RFC5905 to make it clear that having a MAC
is optional and if an extension field requires a MAC it should
explicitly say so in the document that defines it.

> that
isn't required by this functionality. Basically, this draft wants to
define a 16 bit value and encode it in a TLV style extension that meets
the requirements of extensions as defined by the relevant protocol docs.

No but Tal was trying to get around the problem of uncertainty of
whether or not a MAC was present.

> Can you clarify what you mean by extension field length must be
defined in the checksum trailer draft?

All extension fields no matter what the usage is need to have a length
part. It's part of the definition of an extension field. That's part of
RFC5905 and the extension field draft.

> My main reason for asking is that the concept of a TLV seems to be
> taking a bit of a beating.

I have no idea what you mean by TLV.

> And in the very first draft of something different than autokey :-) 
> type field to distinguish MAC or non-MAC following and now you talking
> about hardcoding the length.

I don't know why he wants that. If an extension field requires a MAC it
should specify it in the extension field document that specifies what
the extension field is. All new extension field will need to use the
proposed MAC extension field and the old MAC will be deprecated so we
will have only extension fields and all extension fields have length fields.

> If that is the case, the value of using a TLV is diminishing more
> quickly than I had hoped.
>

I have no idea what this means.

> That is why I echo Harlan's sentiment on length as I understood it.
Basically, I would lean towards IANA registration of a Type value. Then,
an extension defined with the length = 16 bits plus enough padding to
create a valid extension.

I don't understand what you are trying to say.

> Now, on the offhand statement that the high order bit of the type
value could be used to distinguish MAC or non-MAC. I don't see that in
the ntp-extension draft. So, is it necessary or not? If it is, then we
should probably include that in the ntp-extension draft. Then, either
IANA only controls 15 bits or the checksum-trailer draft should request
BOTH versions, MAC and non-MAC.

No, it doesn't need a bit. All we will have are extension fields and
either the extension field needs a MAC extension field or it doesn't and
either way you will be able to tell.

> Because the checksum-trailer is manipulating timestamps, these may
absolutely need to have a MAC. Whether that is practical currently is
not the issue but it needs to be allowed.

Actually it's impossible to have a MAC of any kind in this packet since
the checksum-trailer is used to update the transmit timestamp when it
gets sent out after the MAC has been computed. The checksum trailer is
to enable it to fix-up the UDP checksum so that it can be accepted by
the receiver but since any MAC is computed using the original timestamp,
the MAC check will now failed when received.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 3 Mar 2016 22:07:11 -0800

> end up with a best guess.

I can't imagine this is a huge problem.  The first word is the keyid.
We know, based on the value there, if it's a symmetric key or an autokey.

We know from the remaining length what algorithm the sender used, unless
it's an unknown implementation and the sender added extra padding.

We can tell from the keyid we see what we think the algorithm is and
therefore what the length should be.

I just don't see any problem yet.  And this is an experimental proposal
anyway.  If problems are discovered we can hope/expect them to be reported.

Yes.

> explicitly say so in the document that defines it.

But 28 bytes is not a distinguishing length, from what I've seen.  SHA1
gives a 28 byte MAC, and other algorithms will give *longer* MACs.

> whether or not a MAC was present.

See above.  I think the 28 byte length piece is neither necessary nor
needed.

> will have only extension fields and all extension fields have length fields.

Is it a bug or a feature that MAC protection (old- or new-style) is
being made optional?

If it's really a feature, then we don't need the bits that indicate "I
need no MAC after me", or "I am a MAC".

I currently think making the MAC optional is not that useful.

I don't see that the cost of a high-order bit for "No following MAC is
required" and another high-order bit for "This extension field contains
a MAC" is too high a price to pay.

How many extension fields do we expect to use?

Even if the answer is "more than 250", these high-order bits can be
interpreted as listed only if the low-order nibble is in the known
range, which would  give us what looks like plenty of space.

And we can completely change the Field Type spec for NTPv5, so the above
concerns about how to allocate Field Types is really only an issue for
NTPv4.

To summarize again, what to do about unknown extension fields?  The
choices pretty much boil down to "ignore them" or "ignore the entire
packet".

In the past, the only extension field we had was autokey, which required
a MAC.  This extension PROHIBITS a MAC.  That's why I am requesting a
Field Type that has a way that the high-level packet scanning code can
see if an extension field requires (and now, provides) a MAC.

Old code MAY have problems with these new packets.  Nothing we can do
about that.  But it's "their" choice to run this new code so they'll
understand the ramifications of this choice.

> either way you will be able to tell.

Please defend your position.  I disagree with it.  What if somebody
sends a packet that has an otherwise unknown Field Type but they set
these bits correctly?  That extra information makes it a lot easier to
properly process the packet, even if this unknown extension field is
present.

I think we need the bits for "No following MAC needed" and "I contain a
MAC".

If we're actually going to start adding more extension fields this is
important.

For example, there is value in providing a MAC (old- or new-style) for
the first 6 packets in the NTS dance, until enough information has been
conveyed that the NTS Field Type changes from 0x0004 for these initial
packets to 0x1004 once the extension field contains a MAC.  Assuming I
have the values right - my notes on this are not handy.

Likewise, autokey Field Types are 0x0N02, so aside from the fact that
any NTPv4 implementation will know that autokey needs a MAC, the lack of
the 0x2000 bit is a backward-compatible way to "reinforce" this requirement.

The new "MAC in an extension field" will use 0x1003, which uses 0x1000
to indicate "this extension field contains a MAC".  That's not going to
prevent anybody from putting an old-style MAC a the end of the packet
anyway, if they choose.  Won't hurt.

> the MAC check will now failed when received.

Which is why I offered my suggestion, for later.  My suggestion allows
the preceding packet information to include a MAC, and the only issue is
whether or not it's possible to have the FPGA module take the base
packet, put the timestamp adjustment in an appended extension field, and
then perhaps sign the overall packet again, in a way that also handles
the checksum complement.  But even if no MAC is covering the timestamp
adjustment, I think that the correction will be small enough that we'll
be able to detect tampering.

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 04 Mar 2016 08:23:47 +0100

Hi!

I wonder: I was taught an algorithm has the advantage over human language that it has no ambiguities. Would specifying an algorithm for processing of MAC and extension fields in some high-level (pseudo?) language help in this seemingly endless discussion?

I'm not thinking about the C code of the actual implementation. Sometimes when formulating an algorithm, it becomes clear where the documentation is unclear.

Regards,
Ulrich

>>> Danny Mayer <[email-masked]> schrieb am 04.03.2016 um 04:11 in Nachricht

---

From: Hal Murray <[email-masked]>
Date: Thu, 03 Mar 2016 23:29:42 -0800

[email-masked] said:
> The checksum-trailer draft says it MUST be EXACTLY 28 bytes.  But that isn't
> required by this functionality.  Basically, this draft wants to define a 16
> bit value and encode it in a TLV style extension that meets the requirements
> of extensions as defined by the relevant protocol docs.

My reading which may be wrong...

IANA should assign a number for the type.  They don't need to know the 
length.  They probably want to put the RFC number that describes the field 
(and length) into a table, but since they assign RFC numbers they should be 
able to handle that.

The length needs to be specified in the RFC that tells you how to use the 
field.

The length should be in the packet so code that doesn't understand this 
particular field type can skip over it.

There is a backward compatibility mess with old MACs which don't have TLV 
type structure.  That may require the length to be something other than what 
seems like the obvious one.  Or use another TLV item for padding.  Or...

I don't understand the issues about being followed by a MAC.

------

Somebody asked about TLV.  It's Type, Length, Value.  The type and length are 
fixed format.  The size of the value is whatever the length says.  One reason 
for that structure is so you can skip fields you don't understand.

-----

[email-masked] said:
> One result of this is that we are preparing a MAC extension field to replace
> the MAC field at the end of a packet. This will have a length field and will
> obsolete the existing MAC. 

That seems like a sensible approach.  Checking my understanding...

Grandfather in a few specific lengths as old format MACs.  Any other length 
requires TLV structure for the whole extension.  If you end up with one of 
the magic reserved lengths you have to add some padding.

-- 
These are my opinions.  I hate spam.

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 04 Mar 2016 09:42:15 +0000

Hi Ulrich,

"Ulrich Windl" writes:
> Hi!
> 
> I wonder: I was taught an algorithm has the advantage over human
> language that it has no ambiguities. Would specifying an algorithm for
> processing of MAC and extension fields in some high-level (pseudo?)
> language help in this seemingly endless discussion?

I don't think so.  One of the benefits of specifying the algorithm
out-of-band is that an observer will have difficulty identifying it.

In fact one problem with the current MAC scheme is that one can easily
deduce the algorithm based on the number of bytes in the payload.  This
makes for an attack vector, and we have a way to fix this in an upcoming
draft.

> I'm not thinking about the C code of the actual
> implementation. Sometimes when formulating an algorithm, it becomes
> clear where the documentation is unclear.

Does the above information help any?

H
--

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 4 Mar 2016 11:29:22 +0100

> makes for an attack vector, and we have a way to fix this in an upcoming

Hm, are there so many different lengths that hiding that information
would slow down the search more than adding a few bits to the key? How
do you propose to hide it, truncation of the hash to some constant
length?

-- 
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Fri, 4 Mar 2016 14:37:19 -0500

> I think we need the bits for "No following MAC needed" and "I contain a

There is nothing needed in the extension field itself. When you receive
a packet you read each extension field into a list. If one of them is a
MAC extension field you validate the digest and either get confirmation
or failure and you put that in some location. Then you process each
extension field and if it is known you perform whatever you need to do
with it. If the extension field requires a MAC then you check that the
packet has a valid digest. If it requires it and the MAC is missing or
fails validation you either ignore the extension or drop the packet
altogether. If you have an unknown extension field you either ignore it
or drop the packet.

At no point do you need further information added to the extension
field. Either you recognize the extension field and know whether or not
it needs authentication or you don't recognize it and authentication
doesn't matter.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 4 Mar 2016 11:51:10 -0800

Danny, what if you don't recognize that extension field?

Your approach seems more complicated and intricate to me.

I prefer more separation between the layers. 

Sent from my iPhone - please excuse brevity and typos

> On Mar 4, 2016, at 11:37 AM, Danny Mayer <[email-masked]> wrote:
>

---

From: Danny Mayer <[email-masked]>
Date: Fri, 4 Mar 2016 15:18:13 -0500

Between which layers?

When you do initial processing you just extract the extension fields
with their ID for later processing. You don't do anything with them at
that point. After you have the list you then go through them and make
decisions on what to do with them. That's when you worry about whether
or not any of them are unknown and how to handle that situation.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 4 Mar 2016 13:02:20 -0800

My proposal is an attempt to make future growth and development easier, as it makes some valuable information easily available.

What cost is there in doing this? Note that "I don't see the value in it" is not really a cost. 

Your proposal makes things actively harder moving forward, as you seem to be assuming that 1) you are always running the latest software, or 2) what I don't know is of no value. 

> On Mar 4, 2016, at 12:18 PM, Danny Mayer <[email-masked]> wrote:
> 
> Between which layers?
>

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 05 Mar 2016 02:41:05 +0000

> do you propose to hide it, truncation of the hash to some constant

Two things.

First, we could pad the exsting MAC to an arbitrary length today, and
solve that aspect of the problem.

But second, this does nothing to make it easier to detect a MAC v. an
extension field.  If the MAC was a TLV it would not be an issue.  But
traditionally, it's never been a TLV.

The proposal Danny and I are working on will create a new extension
field for the MAC, and that solves both of these problems.  But it's not
backward-compatible.  It's not backward-INcompatible either.

H

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 4 Mar 2016 18:56:45 -0800

Danny,

I agree with you from certain white-box perspectives.

Show me how your position is still valid from "higher-altitude",
black-box perspectives.

H

---

From: Danny Mayer <[email-masked]>
Date: Fri, 4 Mar 2016 22:01:57 -0500

[I change the subject line - this is not about checksum trailer]

On 3/4/2016 4:02 PM, Harlan Stenn wrote:
> My proposal is an attempt to make future growth and development
easier, as it makes some valuable information easily available.

Unfortunately you haven't demonstrated in what way it would make future
growth and development easier. So that needs to be explained.

> 
> What cost is there in doing this? Note that "I don't see the value
> in
it" is not really a cost.

The cost is that you are adding complexity where none is needed.

> 
> Your proposal makes things actively harder moving forward, as you
> seem
to be assuming that 1) you are always running the latest software, or 2)
what I don't know is of no value.

No. I can add to this.

For existing systems they will only recognize autokey extension field
and the non-extension field MAC. Using a bit in the extension field
makes no difference to these servers anyway so there is no advantage to
them. They won't recognize any other extension field and they will try
to validate it as a MAC which will fail. For a newer system which can
understand newer extension fields and which receives a packet like this
it can recognize an autokey extension field and for autokey it knows
there's a MAC. A system that only sends a MAC (without an extension
field) I think, I would need to check, it could only be a symmetric key
and the validation is through the authentication keys which use a key id
< 16535. All of these cases would be handled so adding bits to an
extension field to indicate a MAC does not provide any advantage.

Did I miss something? Probably. But that can be further clarified.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 4 Mar 2016 19:40:28 -0800

Danny,

Originally, "If there is an extension field the MUST be a MAC", where
there was only 1 class of extension field (autokey) and we had at most 1
extension field in the packet.

We're now to the point where:

- there can be multiple extension fields.
- some will require MAC protection.
- some will require NO MAC protection.
- some will *be* MAC extensions.
- NTS, for example, will sometimes want or require MAC protection,
  and will sometimes provide MAC protection.
- some clients will understand these new fields, some will not.

I want to see a high-level hint as to what each extension field is
expecting.  If a client doesn't understand the new packet types, they
won't understand these new hints either.  Nothing gained, nothing lost.

If a client at least understands these hints, then the client at least
has the opportunity to make a better decision about whether or not to
ignore or drop an incoming packet that contains newer incoming extension
fields that it does *not* understand.

If we do not have these hints then we deny the client information that
is likely very useful regarding what to do.  You seem to be assuming and
coming from the POV that all knowledge comes from the sender, and that
the client should just do what the sender wants.  I think that's a bad
way to proceed.  Let's give the client some knowledge so it at least has
the opportunity to consider this sort of information.

Your approach requires information/state knowledge that is known
throughout the packet parsing and analysis process.  It is complicated
in that regard.  I'm trying to share the load a bit, for sanity
checking.  Similar to why folks are using "opaque data pointers" more
and more.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Mar 2016 10:07:33 +0100

> solve that aspect of the problem.

If the hash was padded to 64 bytes with random data to allow SHA512
and hide the length with smaller hashes, with MD5 and no extension
fields the padding would waste up to 40% of the bandwidth. I don't
think it's worth it, given how little value hiding the length has.

> backward-compatible.  It's not backward-INcompatible either.

An extension field for the old NTPv3 MAC would be nice. It would allow
authentication to cover only part of the packet and extension fields
for corrections from HW timestamping, NTP-aware switches/routers, etc,
could be still included. As you say, this would be an incompatible
change, so I'd like to see some discussion on how it would work with
old servers and clients.

I'm slightly worried about confusion from having different MAC
extension fields as the NTS drafts already introduced a new "MAC"
field for the 128-bit HMAC.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 07 Mar 2016 09:34:46 +0000

> think it's worth it, given how little value hiding the length has.

That's why we're planning on making this padding optional, and also
letting the admin override the default padding.

This way folks can decide for themselves how much to use.

> change, so I'd like to see some discussion on how it would work with

Old server need the old MAC.

New servers would use the new MAC, perhaps in conjunction with a new
extension field that says "I am the last extension field" so if
something comes after it we'd know it was an old-style MAC.

There are still cases where folks might also want to append an old-style
MAC to a packet.

Danny, how close are we to releasing the first draft of the new
proposal?

> field for the 128-bit HMAC.

The NTS MAC is built-in and internal.  If that was given and used, there
would ordinarily be no need for additional MAC protection, after the
first 6 NTS packets have been exchanged.  This is because NTS cannot
"protect" the first 6 packets because the authentication data has not
been fully exchanged at that point.

This is one of the reasons I want those flag bits in the Field Type.

---

From: Hal Murray <[email-masked]>
Date: Mon, 07 Mar 2016 02:19:52 -0800

[email-masked] said:
> extension field that says "I am the last extension field" so if something
> comes after it we'd know it was an old-style MAC. 

Why is that case interesting?  Why would a new server want an old-style MAC?

I'd expect that new servers would use TLV style for the whole extension.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 07 Mar 2016 10:26:58 +0000

> Why is that case interesting?  Why would a new server want an old-style MAC?

It wouldn't.  But a new instance can talk with an old instance.

H

---

From: Hal Murray <[email-masked]>
Date: Mon, 07 Mar 2016 03:03:15 -0800

> It wouldn't.  But a new instance can talk with an old instance.

I don't understand how a new instance is going to talk to an old instance 
without using old format packets.  So why is the format of new style packets 
interesting when discussing old servers?

Are there any new style extension fields in use now?  Are there half-new 
servers out there?

The case that makes sense to me is to grandfather the old lengths for autokey 
and shared key of various types.  Any other extension length must use new 
style TLV format.  We would need a dummy field type so you can add padding to 
change the length if whatever you want to send ends up with one of the 
reserved lengths.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 7 Mar 2016 11:40:30 -0500

> checking.  Similar to why folks are using "opaque data pointers" more

Actually I'm ignoring the sender for now because it knows what it's
going to send and how it's going to send since it needs to be based on
the way that the receiving server expects to see the extended data. For
the sender there's no guessing involved.

We have basically 3 types of packet extensions to handle on the
receiving end:

1) autokey extension field and/or MAC (not extension field)
2) extension fields only (MAC EF included)
3) both old and new extension fields and possibly both old and new MAC's

The only uncertainty is whether or not there is an old-style MAC. The
sender will likely not know whether or not the receiving server can
handle the new extension fields and MAC EF so it may send both styles
and therefore we cannot eliminate 3 easily. The bigger issue with this
is that the receiver may not be able to handle anything except type 1
and may misinterpret the MAC.

So Type 1 can have no MAC hint indicator but autokey automatically
requires it. The other case is symmetric key which has a MAC but no
extension field.

Type 2 doesn't need anything special since the MAC EF is the last EF so
even if another EF needs a MAC if cannot do anything without getting to
the MAC EF so you don't gain anything by having a MAC hint.

Type 3 is a combination of Types 1 and 2 and can get horribly
complicated and a MAC hint doesn't help you.

Unknown extension fields need to be dealt with separately since it
doesn't matter whether or not they need a MAC. There needs to be a
policy decision on whether to ignore just the unknown EF or drop the
whole packet. My currently instincts on this is that the default should
be to ignore the unknown EF and not drop the packet. Multiple unknown
EF's would be a bigger concern.

Does any of this help?

If not can you explain how a MAC hint would help the processing given
that you don't know until you reach the end of the packet whether or not
a MAC (of either type) is present?

Danny