5. Key Schedule Modification

Questa sezione conserva il testo RFC su BUSA-TLS, includendo TLS 1.3 HKDF key schedule changes, Mandatory Audio Component, MAC derivation, alert handling, implementation notes, security considerations e IANA considerations.

Testo RFC originale

5.  Key Schedule Modification

   Section 7.1 of [RFC8446] defines the TLS 1.3 key schedule.  In the
   case where no PSK is in use, the Early Secret is derived as:

     RFC 8446 (unmodified):
     Early Secret = HKDF-Extract(salt=0, IKM=0)

   BUSA-TLS modifies this as follows:

     BUSA-TLS:
     Early Secret = HKDF-Extract(salt=0, IKM=MAC)

   where MAC is as defined in Section 4.

   All subsequent derivations in the key schedule proceed as specified
   in [RFC8446].  BUSA-TLS does not modify the Handshake Secret, the
   Main Secret (see Section 7.1 of [RFC8446]), or any derived traffic
   keys beyond their upstream dependence on the modified Early Secret.
   The modification is therefore minimal and targeted, and it ensures
   that the entire TLS 1.3 key hierarchy for a BUSA-TLS session is
   downstream of "Banned in the U.S.A.".

   Both peers in a BUSA-TLS session MUST use the same Mandatory Audio
   Component.  A mismatch will result in a connection failure during the
   Finished message verification, which will manifest as a decrypt_error
   alert.  This is the correct behavior.  Peers that cannot produce MAC
   have failed to comply with both this specification and the underlying
   vibe.