Subject: [Ntp] Encrypted extension fields in NTS

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Mar 2019 15:36:20 +0100

There are some clarifications planned for the NTS-for-NTP draft.

I'd like to ask for a clarification about encrypted extension fields
in the "NTS Authenticator and Encrypted Extension Fields Extension
Field". The draft currently says:

      P: The plaintext SHALL consist of all (if any) NTP extension
      fields to be encrypted.  The format of any such fields SHALL be
      in accordance with RFC 7822 [RFC7822].  If multiple extension
      fields are present they SHALL be joined by concatenation.

I assume that means the minimum length of a single EF is 16 octets.
But what about requirements specific to the last EF in the packet?
We know there is no MAC in the authenticator field, so the last EF
doesn't have to be at least 28 octets long in order to avoid an
ambiguity, but it would not be strictly following RFC 7822.

I think the draft should make it clear if this is required or not.

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Tue, 26 Mar 2019 16:15:29 +0100

> I think the draft should make it clear if this is required or not.

This is a good point. We should certainly allow 16-octet encrypted
extensions, but I don't see a reason to even stop there, since
encrypted extensions could be made arbitrarily short without any risk
of ambiguity. How about the following text?

P: the plaintext SHALL consist of all (if any) NTP extension fields to
be encrypted; if multiple extension fields are present they SHALL be
joined by concatenation. Each such field SHALL be formatted in
accordance with RFC 7822 [RFC7822], except that, contrary to the RFC
7822 requirement that fields have a minimum length of 16 or 28 octets,
encrypted extension fields MAY be arbitrarily short (but still MUST be
a multiple of 4 octets in length).

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Mar 2019 16:25:53 +0100

> a multiple of 4 octets in length).

Works for me. I like it.

Thanks,

-- 
Miroslav Lichvar

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 26 Mar 2019 17:18:28 +0100

I’m also ok with the language. I’m only have one question. I hope 
you will excuse if it is very naive. If the authenticator tag get 
decrypted you have to pass its contents to the parser in order to 
interpret them. If it is going to be a issue if the EF are smaller than 
16 octets?

Dieter Sibold
[email-masked]

On 26 Mar 2019, at 16:25, Miroslav Lichvar wrote:

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Daniel Franke <[email-masked]>
Date: Tue, 26 Mar 2019 18:01:55 +0100

The outer NTS Authenticator and Encrypted Extension Fields EF still
has to be fully-compliant with RFC 7822. The Additional Padding at the
end of it could always be used to ensure this if it were necessary. In
practice it should never be necessary because the nonce and the
authenticator will always bring the EF to its needed length. Since
it's already possible for there to be *no* encrypted extensions,
allowing short ones isn't going to cause there to be exceptions where
there weren't any before.

OTOH, I suppose it's possible that you could be using an AEAD with an
extremely short N_MAX and authenticator. Such an AEAD couldn't
possibly be secure, but still there's nothing in RFC 5116 preventing
it from existing. So I guess theoretical exceptions do exist already,
and I should add a remark about it. I'm pretty sure I already had this
covered in earlier drafts, but it appears to have gotten dropped in
one of the many revisions of this language. So how about adding the
following paragraph after the paragraph specifying Additional Padding
length:

Senders are always free to include more Additional Padding than
mandated by the above paragraph. Theoretically, it could be necessary
to do so in order to bring the extension field to the minimum length
required by RFC 7822. This should never happen in practice because any
reasonable AEAD algorithm will have a nonce and an authenticator long
enough to bring the extension field to its required length already.
Nonetheless, implementers are advised to explicitly handle this case
and ensure that the extension field they emit is of legal length.

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 26 Mar 2019 18:24:46 +0100

I’m afraid, I didn’t made my question clear. Sorry. What I wanted to 
ask is following:
If the receiver decrypts the encrypted authenticator it will obtain at 
least one EF. These decrypted EFs must be passed to the parser for the 
EFs, correct? If the EF are shorter than the 16 octets (e.g. 12 octets) 
as required in RFC7822 will this lead to problems in the interpretation 
of the EF?

- Dieter

Dieter Sibold
[email-masked]

---

From: Watson Ladd <[email-masked]>
Date: Wed, 27 Mar 2019 10:10:35 +0100

> as required in RFC7822 will this lead to problems in the interpretation

I believe the answer is that none of these can be MACs, so the parsing
issues are solved. Whether or not existing code will be easy to use
this way is another question.

---

From: "Dieter Sibold" <[email-masked]>
Date: Wed, 27 Mar 2019 10:18:25 +0100

Thanks Watson,
that answers my question and I support Daniels suggested clarification.

Dieter Sibold
[email-masked]

On 27 Mar 2019, at 10:10, Watson Ladd wrote:

>>> On Tue, Mar 26, 2019 at 5:18 PM Dieter Sibold 
>>> <[email-masked]>
>>> wrote:
>>>>
>>>>>> P: the plaintext SHALL consist of all (if any) NTP extension 
>>>>>> fields
>>>>>> to
>>>>>> encrypted extension fields MAY be arbitrarily short (but still 
>>>>>> MUST
>>>>>> be