Subject: Re: [Ntp] WGLC for draft-ietf-ntp-mac

From: Matthew Van Gundy <[email-masked]>
Date: Tue, 27 Feb 2018 18:09:25 -0500

Hi All,

Forgive me if this has been discussed and I missed it.  But, to
improve quantum resistance should the draft recommend AES-256 over
AES-128?  I realize that the RFC 4493 construction specifically uses
AES-128, but is there any barrier to using AES-256?

Similarly, the draft says that the "MAC tag SHOULD be 128 bits long"
but doesn't describe any situations where the MAC tag would be another
length.  Given that a tags that are not an integer multiple of 32-bit
words violate RFC 5905 and it appears that MAC tags that are not
128-bits in length also violate RFC 5905.  (In practice ntp.org's ntpd
handles MAC tags up to 160-bits in length gracefully, but RFC 5905 appears
to restrict MAC tag length to 128-bits.)

If there are situations where the MAC tags MAY be a length other than
128-bits, it would probably be useful to articulate the criteria for
acceptable MAC tag lengths.

Cheers,
Matt

On Wed, Aug 09, 2017 at 04:53:43AM +0000, Karen O'Donoghue wrote:
> Folks,
> 
> This begins a three week working group last call (WGLC) for "Message Authentication Code for the Network Time Protocol"
> https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/
> 
> Please review and provide comments to the mailing list by no later than 31 August 2017. Earlier comments and discussion would be appreciated. Please note that the chairs will be using this WGLC to determine consensus to move this document forward to the IESG.
> 
> Also, as a reminder, we have migrated the working group mailing list to IETF infrastructure. Please respond to [email-masked]<mailto:[email-masked]>.
> 
> Regards,
> Karen and Dieter

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

-- 
Matthew Van Gundy, Technical Leader
Advanced Security Initiatives Group
Cisco Systems, Inc.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 28 Feb 2018 12:47:15 +0000

Most everybody seems to think that 160 bits of digest is all that will
ever be needed.

I'm perfectly happy making sure longer digests are supported.
-- Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Daniel Franke <[email-masked]>
Date: Wed, 28 Feb 2018 08:51:30 -0500

The block size of AES is 128 bits, regardless of whether a 128- or 256-bit
key is used, and therefore the output of AES-CMAC is always 128 bits.
160-bit digests are already supported by RFC7822, but there's no way to
make AES-CMAC produce one.

---

From: Matthew Van Gundy <[email-masked]>
Date: Wed, 28 Feb 2018 17:04:13 -0500

Hi Daniel,

> make AES-CMAC produce one.

Understood.  Thanks for reminding me that RFC7822 explicitly updates the
acceptable digest sizes to be 4, 20, or 24 octets long (inclusive of
the 4 octet key id).  Given that, should I interpret "the resulting
MAC tag SHOULD be 128 bits long" as, "When using draft-ietf-ntp-mac-03
authentication, the MAC tag must be either 0-bits (Crypto-NAK) or
128-bits (AES-CMAC) long.  Otherwise, see RFC 7822."?

>>> AES-128, but is there any barrier to using AES-256?

Do you happen to know the rationale for recommending AES-128 over
AES-256?  It seems like it would be appropriate to default to the more
secure variant since implementations MAY always choose AES-128 as long
as they understand the security implications of doing so.

Thanks,
Matt

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 28 Feb 2018 18:05:19 -0800

> 128-bits (AES-CMAC) long.  Otherwise, see RFC 7822."?

Please note that some of us think 7822 was not quite right, and have
been trying to fix it:

 https://tools.ietf.org/id/draft-stenn-ntp-extension-fields-05.txt

> as they understand the security implications of doing so.

I think the intent was to specify a minimum acceptable limit/digest.

And just to be sure I've said it, one of the nice things about MD5 was
that it was not considered "crypto" and could be freely exported or
imported.  The same cannot be said of AES-128-CMAC, or several other
mechanisms.

H
--

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