6. Error Handling

This section preserves the RFC text for BUSA-TLS, including TLS 1.3 HKDF key schedule changes, Mandatory Audio Component, MAC derivation, alert handling, implementation notes, security considerations, and IANA considerations.

Original RFC Text

6.  Error Handling

   BUSA-TLS defines two new TLS alerts:

     enum {
         one_very_important_thought(0x22B),
         banned_alert(0x22C),
     } AlertDescription;

   one_very_important_thought(0x22B) is a warning alert.  It SHOULD be
   sent by an implementation that wishes to remind the remote peer that
   the same people who would stop you from implementing BUSA-TLS may be
   back next year to complain about a cipher suite, or even a key
   derivation function.  The alert code is assigned in reference to
   Boards of Canada's "One Very Important Thought" track [BOCMAXIMA].

   banned_alert(0x22C) is a fatal alert.  It MUST be sent by any
   implementation that detects a peer attempting to negotiate BUSA-TLS
   without having obtained the Mandatory Audio Component.  Detection of
   such a peer is left as an exercise for the implementation, as the
   cryptographic result of using a zero-byte IKM (i.e., vanilla behavior
   per [RFC8446]) will simply appear as an incorrect Finished MAC and
   produce a decrypt_error.  The banned_alert code is therefore largely
   ceremonial.

   Neither alert code is assigned by IANA (see Section 10).
   Implementations SHOULD log banned_alert events with a message
   indicating that the remote peer is not ready.