[saag] Re: [Technical Errata Reported] RFC6238 (8672)

[Bob Beck <[e-mail]>]

My two cents:

1) We should probably just reference POSIX and not Wikipedia,  (https://pubs.opengroup.org/onlinepubs/9799919799/ section 4.19) for [UT]

  Since the T is dependent on "current unix time” - just making it a 64 bit value won’t save you for a current time in which the platform won’t give you the correct value. For whatever reason.  Sure, that reason we could be 32_bit time_t in 3028,  Or it could be a platform that won’t give you a posix time after the year 3000 in some situations,  We can also have platforms which got the bad idea bear visitation blessing them with unsigned 32 bit time_t and now you would need to say something cautioning the implementor about that when they are subtracting values. Implementors need to know their platform imitations, and sizes of integer values, and I don’t think we want to be in the business of guessing all the potential problems. 

So IMO:

2) Remove the first sentence of the fourth paragraph of section 4.2

The algorithm already specifies what that value has to be. If the implementor doesn’t provide it correctly for any given time, it’s not going to work, and that’s expected.

> On Dec 12, 2025, at 12:19, Paul Wouters <paul.wouters=[e-mail]> wrote:
> 
> I believe this is correct. If anyone disagrees, please speak up.
> 
> Paul
> 
> 
> ---------- Forwarded message ---------
> From: RFC Errata System <[e-mail] <mailto:[e-mail]>>
> Date: Sat, Dec 6, 2025 at 12:45 PM
> Subject: [Technical Errata Reported] RFC6238 (8672)
> To: <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>
> Cc: <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>
> 
> 
> The following errata report has been submitted for RFC6238,
> "TOTP: Time-Based One-Time Password Algorithm".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8672
> 
> --------------------------------------
> Type: Technical
> Reported by: Taylor H <[e-mail] <mailto:[e-mail]>>
> 
> Section: 4.2. Description
> 
> Original Text
> -------------
> The implementation of this algorithm MUST support a time value T larger than a 32-bit integer when it is beyond the year 2038.
> 
> Corrected Text
> --------------
> The implementation of this algorithm MUST feed the time value T as a 64-bit big-endian integer into the HMAC algorithm. Also the calculation "T = (Current Unix time - T0) / X" must be performed on 64-bit integers the prevent the year-2106-bug or year-2038-bug.
> 
> or just
> 
> The implementation of this algorithm MUST feed the time value T as a 64-bit big-endian integer into the HMAC algorithm.
> 
> Notes
> -----
> The wording "larger than a 32-bit integer" is useless in the context. Using anything else than 64-bit big-endian integer results in bogus output and failure to login. The mention of the year 2038 is confusing and essentially off-topic in the light of above ie the fact that not using 64-bit big-endian integer breaks the thing immediately.
> 
> Also code line
> 
> int offset = hash[hash.length - 1] & 0xf;
> 
> does something presumably correct but not mentioned anywhere in RFC6238 nor in the linked RFC4226. In the light of the substantial number of severe faults beyond simple typo, it would be best to publish a new RFC fully replacing both RFC6238 and RFC4226.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC6238 (draft-mraihi-totp-timebased-08)
> --------------------------------------
> Title               : TOTP: Time-Based One-Time Password Algorithm
> Publication Date    : May 2011
> Author(s)           : D. M'Raihi, S. Machani, M. Pei, J. Rydell
> Category            : INFORMATIONAL
> Source              : IETF - NON WORKING GROUP
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> saag mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]