[Ntp] Fwd: Re: ietf-ntp-extension-field document

[Harlan Stenn <[e-mail]>]

Juergen said he sent this to the list about 11 hours' ago, but I didn't
see it. Here's what he sent me.


-------- Forwarded Message --------
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1]) by chessie.everett.org
(Postfix) with SMTP id 573F0B864 for <[e-mail]>; Mon, 11 Dec
2017 18:58:42 +0000 (UTC)
Received: from mailout01.t-online.de (mailout01.t-online.de
[194.25.134.80]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA
(256/256 bits)) (No client certificate requested) by chessie.everett.org
(Postfix) with ESMTPS id B3A0DB837 for <[e-mail]>; Mon, 11 Dec
2017 18:58:41 +0000 (UTC)
Received: from fwd24.aul.t-online.de (fwd24.aul.t-online.de
[172.20.26.129]) by mailout01.t-online.de (Postfix) with SMTP id
8483B42E4280 for <[e-mail]>; Mon, 11 Dec 2017 19:58:39 +0100 (CET)
Received: from [192.168.1.11]
(Vgg5KvZJZh4-c8JQpBsTxcbo41unGRk+hRSn5k7nSIWyinM2IySMfsCxuu39JDSQC7@[217.81.146.20])
by fwd24.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384
encrypted) esmtp id 1eOTHi-0pEs1g0; Mon, 11 Dec 2017 19:58:38 +0100
Subject: Re: ietf-ntp-extension-field document
To: Harlan Stenn <[e-mail]>
References: <[e-mail]>
From: juergen perlinger <[e-mail]>
Message-ID: <[e-mail]>
Date: Mon, 11 Dec 2017 19:58:37 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <[e-mail]>
Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
boundary="QX8JtU5rrQhV5Tfg0d44kTKmKFAlsV4jE"
X-ID: Vgg5KvZJZh4-c8JQpBsTxcbo41unGRk+hRSn5k7nSIWyinM2IySMfsCxuu39JDSQC7
X-TOI-MSGID: 570a02aa-8c6b-4f87-a6cd-e58d5fdd5b3b
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Mon Dec 11 18:58:42 2017
X-DSPAM-Confidence: 0.9899
X-DSPAM-Improbability: 1 in 9809 chance of being spam
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: 3974,5a2ed56213612127916444

Hello Harlan!

I finally found the time to read through the proposal and rfc7822.


First, to disambiguate an EF from a legacy MAC by requiring the MAC (+
key identifier) be <= 24 bytes and all extension fields > 24 bytes
(which effectively becomes >= 28 under the alignment rule) is bad for
the reasons you stated: Making longer hashes impossible, and causing
waste for possibly shorter EFs.

The latter becomes especially painful when considering the fact that a
packet should fit the network MTU size: several short EFs cause a rapid
bloat with pad bytes.

So IMO the new proposal is superior to the old RFC7822.


With respect to the EF length field and the least significant two bits:
-----------------------------------------------------------------------

If the we ever plan to use them for anything, the proper wording would
go along the line of:

"The two least significant bits of the the EF length field are reserved.
They  MUST be ignored in the computation of the field length when
dissecting a packet, and they MUST be set to zero when assembling a packet."

Otherwise it would make sense to state that the two least significant EF
length bits MUST be zero.

(IMHO it would make more sense to permit *any* size of an EF and require
the assembling/dissecting stages to do the alignment on DWORD
boundaries, but doing so now would probably cause too much
controversial issues.)


About parsing ambiguities:
--------------------------

IMHO a packet that uses EFs and legacy mac SHOULD use the LAST-EF
indicator. This still leaves a mess on the dissecting side, since we
have to live with the ambiguities caused by legacy instances of NTPD. It
just might reduce the hit frequency.


About multiple hash-EFs:
------------------------

We have two options here:
1st) Any hash EF contains all data (except non-hash EFs, of course) up
to and including its key identifier. This makes the hash calculation
somewhat easier.

2nd) EFs containing a hash are NOT part of other hashes. This is a bit
more symmetric.

Note that we have to parse the packet anyway to skip EFs that should not
be hash-secured, so the algorithmic effort is nearly the same for both
variants.


Hashing of EF headers:
----------------------

In general: Is the EF header part of *all* EFs part of the hash? This
would protect all EF headers from tampering (and therefore the chain we
follow when dissecting the message!). Only the payload of non-secured
EFs would be skipped in this case.

Maybe I just didn't find that point, but I think we should be rather
clear about this.


About Crypto-NAK:
-----------------

I know this will not happen, but this recipe for disaster should be done
with. This *unauthenticated* packet can cause an authenticated
communication to fail, and it is easy enough to inject into a network to
facilitate a DoS attack.

All attempts to make Crypto-NAK in its current form secure are in vain.



(Oh, and there's at least one instance of 'thru' as short form of
'through'. Not sure if that's good style for an RFC... but remember I'm
no native speaker ;)

I just hope I didn't stir the waters too much :)

Cheers,
	Pearly