Re: [ntpwg] Antw: Re: I-D Action: draft-ietf-ntp-checksum-trailer-05.txt

[Miroslav Lichvar <[e-mail]>]

On Sat, Mar 05, 2016 at 02:41:05AM +0000, Harlan Stenn wrote:
> Miroslav Lichvar writes:
> > On Fri, Mar 04, 2016 at 09:42:15AM +0000, Harlan Stenn wrote:
> > > In fact one problem with the current MAC scheme is that one can easily
> > > deduce the algorithm based on the number of bytes in the payload.  This
> > > makes for an attack vector, and we have a way to fix this in an upcoming
> > > draft.
> > 
> > Hm, are there so many different lengths that hiding that information
> > would slow down the search more than adding a few bits to the key? How
> > do you propose to hide it, truncation of the hash to some constant
> > length?
> 
> Two things.
> 
> First, we could pad the exsting MAC to an arbitrary length today, and
> solve that aspect of the problem.

If the hash was padded to 64 bytes with random data to allow SHA512
and hide the length with smaller hashes, with MD5 and no extension
fields the padding would waste up to 40% of the bandwidth. I don't
think it's worth it, given how little value hiding the length has.

> The proposal Danny and I are working on will create a new extension
> field for the MAC, and that solves both of these problems.  But it's not
> backward-compatible.  It's not backward-INcompatible either.

An extension field for the old NTPv3 MAC would be nice. It would allow
authentication to cover only part of the packet and extension fields
for corrections from HW timestamping, NTP-aware switches/routers, etc,
could be still included. As you say, this would be an incompatible
change, so I'd like to see some discussion on how it would work with
old servers and clients.

I'm slightly worried about confusion from having different MAC
extension fields as the NTS drafts already introduced a new "MAC"
field for the 128-bit HMAC.

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg