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

On Mon, Jan 7, 2019 at 6:47 AM Aanchal Malhotra <aanchal4@bu.edu> wrote:

>
>
> On Fri, Jan 4, 2019 at 12:53 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>>
>> On Fri, Jan 4, 2019 at 9:49 AM Aanchal Malhotra <aanchal4@bu.edu> wrote:
>>
>>> HI Eric,
>>>
>>>
>>>
>>> On Fri, Jan 4, 2019 at 12:25 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jan 4, 2019 at 8:24 AM Aanchal Malhotra <aanchal4@bu.edu>
>>>> wrote:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> Thanks for the comments.
>>>>>
>>>>> On Sat, Nov 17, 2018 at 5:59 PM Eric Rescorla <ekr@rtfm.com> 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.
>>>>>
>>>>
>>>> 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".
>>>>
>>>
>>> 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:
>>>
>>
>> Well, I'm not quite sure why you think truncating is bad in this case,
>> but ignoring that.
>>
>> "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?
>>>
>>
>> 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 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."
>

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

>> -Ekr
>>
>>
>>>> -Ekr
>>>>
>>>> _______________________________________________
>>>> ntp mailing list
>>>> ntp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ntp
>>>>
>>>