Subject: Re: [Ntp] Eric Rescorla's No Objection on draft-ietf-ntp-mac-05: (with COMMENT)

From: Aanchal Malhotra <[email-masked]>
Date: Fri, 4 Jan 2019 11:24:08 -0500

Hi Eric,

Thanks for the comments.

On Sat, Nov 17, 2018 at 5:59 PM Eric Rescorla <[email-masked]> wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-ntp-mac-05: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3591
>
>
>
> COMMENTS
> S 3.
> >      If authentication is implemented, then AES-CMAC as specified in RFC
> >      4493 [RFC4493] SHOULD be computed over all fields in the NTP header,
> >      and any extension fields that are present in the NTP packet as
> >      described in RFC 5905 [RFC5905].  The MAC key for NTP MUST be at
> >      least 128 bits long AES-128 key and the resulting MAC tag MUST be at
> >      least 128 bits long as stated in section 2.4 of RFC 4493 [RFC4493].
>
> Is there a way for either of these values to be > 128 bits? If not,
> maube just say "must be 128 buts:
>

How about the following?
"The MAC key for NTP MUST be 128 bits long AES-128 key and the resulting
MAC tag MUST be at least 128 bits long as stated in section 2.4 of RFC 4493
[RFC4493]."

This is to make sure that the MAC tag is not truncated to < 128 bits.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Jan 2019 09:24:01 -0800

> This is to make sure that the MAC tag is not truncated to < 128 bits.

As I understand it, this text is specifying just AES-CMAC (otherwise the
text about it being an AES key doesn't make sense) and AES-CMAC has a 128
bit output. And thus the "at least 128 bits" text  doesn't do anything and
just says "MUST be 128 bits".

-Ekr

---

From: Aanchal Malhotra <[email-masked]>
Date: Fri, 4 Jan 2019 12:48:31 -0500

HI Eric,

On Fri, Jan 4, 2019 at 12:25 PM Eric Rescorla <[email-masked]> wrote:

>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html

I see what you are saying but here is what I am worried about. Section 2.4
of RFC 4493 says the following:

"It is possible to truncate the MAC. According to [NIST-CMAC
<https://tools.ietf.org/html/rfc4493#ref-NIST-CMAC>], at least a 64-bit MAC
should be used as protection against guessing attacks. "

And I do not want to NTP MAC tag to be truncated to < 128 bits. So here is
a possible rephrasing:

"The MAC key for NTP MUST be 128 bits long AES-128 key and the resulting
MAC tag MUST be 128 bits long as stated in section 2.4 of RFC 4493
[RFC4493]. Truncation as permitted in Section 2.4 of RFC 4493 MUST not be
used. "

What do you think?

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Jan 2019 09:52:30 -0800

On Fri, Jan 4, 2019 at 9:49 AM Aanchal Malhotra <[email-masked]> wrote:

> <https://tools.ietf.org/html/rfc4493#ref-NIST-CMAC>], at least a 64-bit
> MAC should be used as protection against guessing attacks. "
>

Well, I'm not quite sure why you think truncating is bad in this case, but
ignoring that.

> [RFC4493]. Truncation as permitted in Section 2.4 of RFC 4493 MUST not be

This just seems redundant. You can't use truncation and have the MAC be !=
128 bits, and your first sentence says it's 128 bits long.

-Ekr

---

From: Aanchal Malhotra <[email-masked]>
Date: Mon, 7 Jan 2019 09:46:54 -0500

On Fri, Jan 4, 2019 at 12:53 PM Eric Rescorla <[email-masked]> wrote:

>>>> "The MAC key for NTP MUST be 128 bits long AES-128 key and the
>>>> resulting MAC tag MUST be at least 128 bits long as stated in section 2.4
>>>> of RFC 4493 [RFC4493]."
>>>>
>> I see what you are saying but here is what I am worried about. Section
>> 2.4 of RFC 4493 says the following:
>>
>> And I do not want to NTP MAC tag to be truncated to < 128 bits. So here
>> is a possible rephrasing:
>>
>

I want to make the point clear but also agree that redundancy is bad. So
how about the following:

"The MAC key for NTP MUST be 128 bits long AES-128 key.  Truncation as
permitted in Section 2.4 of RFC 4493 [RFC4493] MUST not be used and
therefore the resulting MAC tag MUST be 128 bits long."

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Jan 2019 07:44:21 -0800

On Mon, Jan 7, 2019 at 6:47 AM Aanchal Malhotra <[email-masked]> wrote:

>>>> As I understand it, this text is specifying just AES-CMAC (otherwise
>>>> the text about it being an AES key doesn't make sense) and AES-CMAC has a
>>>> 128 bit output. And thus the "at least 128 bits" text  doesn't do anything
>>>> and just says "MUST be 128 bits".
>>>>
>>>
>> Well, I'm not quite sure why you think truncating is bad in this case,
>> but ignoring that.
>>
>> This just seems redundant. You can't use truncation and have the MAC be
>> != 128 bits, and your first sentence says it's 128 bits long.
>>
>

I think you're overindexing on this and the point is clear. Lots of MACs
have truncation features, and we regularly specify the length without any
extra emphasis on not truncating. In which protocol have you seen (a) the
MAC length explicitly specified and (b) people truncating anyway?

-Ekr