The “external_aad” field appears in the Sig_structure, Enc_structure, and MAC_structure. Many other cryptographic specs have gotten along fine without this, and are simpler as a result. Is its inclusion warranted by common use cases, or is this an edge case not satisfying the 80/20 rule for inclusion? The simpler way of achieving this is to include these values as part of the payload.
Note also that some places in the spec prohibit supplying this value. For instance, 5.4 (Encryption algorithm for AE algorithms) includes the instruction “Verify that there was no external additional authenticated data supplied for this operation.” That makes me think that having external_aad at all is a likely source of implementation and usage errors and interoperability problems.
Per discussion at the f2f meeting: This is a required feature for the CoAP world so that headers in the message can be integrity protected without having to duplicate them
The “external_aad” field appears in the Sig_structure, Enc_structure, and MAC_structure. Many other cryptographic specs have gotten along fine without this, and are simpler as a result. Is its inclusion warranted by common use cases, or is this an edge case not satisfying the 80/20 rule for inclusion? The simpler way of achieving this is to include these values as part of the payload.
Note also that some places in the spec prohibit supplying this value. For instance, 5.4 (Encryption algorithm for AE algorithms) includes the instruction “Verify that there was no external additional authenticated data supplied for this operation.” That makes me think that having external_aad at all is a likely source of implementation and usage errors and interoperability problems.