Re: [secdir] [Last-Call] [DNSOP] Secdir last call review of draft-ietf-dnsop-server-cookies-04

[Stephen Farrell <[e-mail]>]

Hiya,

On 02/12/2020 22:07, Willem Toorop wrote:
> 
> 
> Op 02-12-2020 om 22:49 schreef Stephen Farrell:
>>
>> Hiya,
>>
>> On 02/12/2020 21:38, Willem Toorop wrote:
>>> Op 02-12-2020 om 21:37 schreef Stephen Farrell:
>>>
>>> <snip>
>>>
>>>>> ad 2) we need a value that’s synchronized well enough and monotonic.
>>>>> I honestly don’t see any value in using 64-bit value here. Using
>>>>> unixtime has a value in itself, it’s a well-known and there’s a
>>>>> little room for any implementer to make a mistake in an
>>>>> implementation. The interoperability is more important than the
>>>>> actual value of the counter. It’s write only counter, nobody is going
>>>>> to interpret it after it has been generated, and it’s wide enough to
>>>>> prevent brute forcing.
>>>>
>>>> So what happens after 2038? That's really not v. far in the
>>>> future any more.
>>>
>>> The draft states that `All comparisons involving these fields MUST
>>> use "Serial number arithmetic", as defined in [RFC1982]'. So it can not
>>> be used to compare differences larger than 68 years, but comparisons of
>>> cookie timestamps are more in the "hours" order of magnitude.
>>
>> Sorry for being dim, but is clear what value to put
>> in those 4 octets in say 2039 such that different
>> implementations will do the right thing
> Well the text does specify an "32-bit unsigned number of seconds elapsed
> since 1 January 1970 00:00:00 UTC", so because of the "unsigned" the
> wrap to 0 is only in 2106, not 2038.

Ah. I missed that "unsigned." (Does that mean implementers
might also?)

> But even then, in 2106, it should not be a problem to check the age of a
> cookie because of the rfc1982 comparison (which takes care of the wrap)
> and the fact that Server Cookies will not be older than hours (and not
> years).

So the buggy case would be where a server re-constructs
the input to the hash after some kind of round-trip of
the octets (to e.g. struct tm or something and then back
to time_t and to network byte order) at which point you could
I think get failures depending on who implemented what
incorrectly. That kind of thing has been seen before (even
if it seems a bit mad;-)

FWIW, I'd say it's worth a few more words to try reduce
the probability of such failures happening, e.g. maybe
just highlighting the "unsigned/2106" point you made
above would be enough. But, if the WG don't want to do
that, that's also fine by me.

Cheers,
S.


> 
> Cheers,
> -- Willem
> 
>> I did glance
>> at rfc1982, so there may be very far-sighted text
>> in there that I missed:-) And it may even be fine
>> for this purpose if different servers differ by a
>> second or so at that point, but even if so, it may
>> be a bad plan to leave that unspecified in case
>> other timestamps use the same code.
>>
>> Cheers,
>> S.
>>
>>>
>>> Cheers,
>>> -- Willem
>>>
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>>>
>>>>> Cheers, Ondřej -- Ondřej Surý — ISC (He/Him)
>>>>>
>>>>>> On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker
>>>>>> <[e-mail]> wrote:
>>>>>>
>>>>>> Reviewer: Stephen Farrell Review result: Has Issues
>>>>>>
>>>>>> I see two issues here worth checking:
>>>>>>
>>>>>> 1. I don't recall SipHash being used as a MAC in any IETF standard
>>>>>> before. We normally use HMAC, even if truncated. Why make this
>>>>>> change and was that checked with e.g. CFRG? (And the URL given in
>>>>>> the reference gets me a 404.)
>>>>>>
>>>>>> 2. Is it really a good idea to use a 32 bit seconds since
>>>>>> 1970-01-01 in 2020? I'd have thought that e.g. a timestamp in hours
>>>>>> since then or seconds since some date in 2020 would be better.
>>>>>>
>>>>>> Here's a couple of nits too: - section 1: what's a "strong
>>>>>> cookie"? - "gallimaufry" - cute! but not sure it'll help readers to
>>>>>> learn that word.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________ DNSOP mailing list
>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/dnsop
>>>>>
>>>>
>>>> _______________________________________________
>>>> DNSOP mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>>
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>