Found 2 records.

Status: Verified (2)

RFC 5776, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", April 2010

Errata ID: 2155
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: ALfred Hoenes
Date Reported: 2010-04-09
Verifier Name: Sean Turner
Date Verified: 2011-03-28

Section 6.2.1,pg.52 says:

|  o  direct time synchronization response: Upon receiving a response, a
      receiver who has no pending request MUST immediately drop the
      packet.  If this receiver has previously issued a request, he
|     first checks the Group MAC (if applicable), then the "t_r" field,
|     to be sure it is a response to his request, and finally the
      digital signature.  A replayed packet will be dropped during these
      verifications, without compromising the TESLA component.

It should say:

|  o  Direct time synchronization response: Upon receiving a response, a
      receiver who has no pending request MUST immediately drop the
      packet.  If this receiver has previously issued a request, he
|     first checks the "t_r" field, to be sure it is a response to his 
|     request, then the Group MAC (if applicable), and finally the
      digital signature.  A replayed packet will be dropped during these
      verifications, without compromising the TESLA component.

Notes:

Rationale:
a) [supplemental, editorial] capitalization after preceding full stop;
b) conflict with reasonable specification in section 4.2.2.1:
the "t_r" field match with an 'open' request is a very lightweight
operation, and an attacker needs to be on-path and fast or *very*
lucky to happen to pass this check; so performing the more costly
Group MAC verification operation _only_ if the packet "t_r" matches
an open request significantly reduces the workload an attacker can
impose on the receiver; thus, the order of operations specified in
Section 4.2.2.1 is an important detail of the overall anti-DoS
strategy and should not be contradicted by the Security
Considerations section.

Errata ID: 2156
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-04-09
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 3.3.2 says:

[[  first paragraph  ]]

   The bootstrap information message (with the in-band bootstrap scheme)
|  and direct time synchronization response message (with the indirect
   time synchronization scheme) both need to be signed by the sender.
   [...]

It should say:

   The bootstrap information message (with the in-band bootstrap scheme)
|  and direct time synchronization response message (with the direct
   time synchronization scheme) both need to be signed by the sender.
   [...]

Notes:

Rationale: most likely a typo, but confusing:
why would the _indirect_ schem use the _direct_ scheme's messages?

Report New Errata