[saag] errata dilemma for HOTP: An HMAC-Based One-Time Password Algorithm

[Paul Wouters <[e-mail]>]

I looked at some erratas (to do my part of reducing our list) and noticed
this interesting errata:

https://www.rfc-editor.org/errata/eid6756

It talks about the HOTP algorithm and the errata proposal points out:

Section 5.3 says:

Let OffsetBits be the low-order 4 bits of String[19]

It should say:

Let OffsetBits be the low-order 4 bits of the last byte of String

For the HMAC-SHA1 case, the last byte is string[19], but for the newer
SHMAC-SHA2 cases this is not true.
These are specified in RFC 6238 where it states:


   TOTP implementations MAY use HMAC-SHA-256 or HMAC-SHA-512 functions,
   based on SHA-256 or SHA-512 [SHA2
<https://datatracker.ietf.org/doc/html/rfc6238#ref-SHA2>] hash
functions, instead of the
   HMAC-SHA-1 function that has been specified for the HOTP computation
   in [RFC4226 <https://datatracker.ietf.org/doc/html/rfc4226>].

The main issue now is if anyone has implemented the 6238 TOTP with the SHA2
variant, did they interpret the reference to RFC 4226 as to be using the
19th byte of the HMAC-SHA2 string or the last byte? This might have already
caused interoperability issues. But issuing an errata (whether for 4226 or
6238) might cause people to again write non-interoperable implementations.

That is, I honestly don't know if rejecting or accepting an errata on this
topic might make things better or worse.

Does anyone know some implementers of this? If so, which flavour did they
use? Or do they try both to work around this issue?

Should we do a short Update: for 6238 that tells people to "try both" to
resolve this issue?

Paul