Draft: draft-ietf-lake-edhoc

Commentary: Some updates . Open issues : Still the option to do EAD_x = ead , and make EAD fields mandatory . There is no way padding exactly 26 bytes , is there ? 
 It 's possible if we admit the padding EAD item to be repeatable . In general , a specification defining an EAD item would also define if the item is repeatable . 
 I think we are done now . Let 's merge unless there are further comments . 
  an error in the CDDL ( appendix C.2 ): 
 All , Thanks for good comments . We would like to merge this now . Any final input ? Later we can still phrase the CDDL differently , make global replace of " EAD item " , " randomly generated " , etc . But unless people disagree with the overall change , let 's do it . 
 Merging , in the absence of any quick comments .
Paragraph (version A):
The specification registering a new EAD label needs to describe under
what conditions the EAD item is critical or non-critical.
Paragraph (version B):
Each EAD field, EAD_x for x = 1, 2, 3 or 4, is a CBOR sequence (see
CBOR) of one or more EAD items ead defined in fig-ead-item.  See CDDL
for the CDDL definitions.
Paragraph (version B):
A security application using external authorization data needs to
register a positive ead_label and optionally an associated ead_value
format, for each EAD item it uses (see iana-ead).  Each application
registers its own EAD items and describes the associated processing
and security considerations.  The application may define multiple
uses of certain EAD items, e.g., the same EAD item may be used in
different EDHOC messages with the same application.  Multiple
occurrences of an EAD item in one EAD field may also be specified.
Paragraph (version B):
An EAD item can be either critical or non-critical, determined by the
sign of the ead_label in the EAD item transported in the EDHOC
message.  A negative value indicates that the EAD item is critical
and a non-negative value indicates that this EAD item is non-
critical.  The specification registering a new EAD label needs to
describe under what conditions the EAD item is critical or non-
critical, and thus whether the ead_label is used with negative or
positive sign. ead_label = 0 is used for padding, see padding.
Paragraph (version B):
Multiple occurrences of EAD items with ead_label = 0 are allowed.
Certain padding lengths require the use of at least two such EAD
items.
Paragraph (version A):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected
cipher suite, and the parameters defined in asym-msg3-proc.
Discard the padding PAD_3, if present.
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected
cipher suite, and the parameters defined in asym-msg3-proc.
Paragraph (version A):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected
cipher suite, and the parameters defined in asym-msg4-proc.
Discard the padding PAD_4, if present.
Paragraph (version B):
Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2
and 5.3 of RFC9052, with the EDHOC AEAD algorithm in the selected
cipher suite, and the parameters defined in asym-msg4-proc.
Paragraph (version A):
Implementations MAY support padding of plaintext when sending
messages.  Implementations MUST support padding of plaintext when
receiving messages, i.e., MUST be able to parse padded messages.
Paragraph (version B):
Implementations MUST support EAD.
Paragraph (version B):
EDHOC messages might change in transit due to a noisy channel or
through modification by an attacker.  Changes in message_1 and
message_2 (except Signature_or_MAC_2 when the signature scheme is not
strongly unforgeable) are detected when verifying Signature_or_MAC_2.
Changes to not strongly unforgeable Signature_or_MAC_2, and message_3
are detected when verifying CIPHERTEXT_3.  Changes to message_4 are
detected when verifying CIPHERTEXT_4.
Paragraph (version A):
The fields ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 have
variable length and information regarding the length may leak to an
attacker.  An passive attacker may e.g., be able to differentiating
endpoints using identifiers of different length.  To mitigate this
information leakage an implementation may ensure that the fields have
fixed length or use padding.  An implementation may e.g., only use
fix length identifiers like 'kid' of length 1.  Alternatively padding
may be used to hide the true length of e.g., certificates by value in
'x5chain' or 'c5c'.
Paragraph (version B):
The fields ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 have
variable length, and information regarding the length may leak to an
attacker.  A passive attacker may, e.g., be able to differentiate
endpoints using identifiers of different length.  To mitigate this
information leakage an implementation may ensure that the fields have
fixed length or use padding.  An implementation may, e.g., only use
fixed length identifiers like 'kid' of length 1.  Alternatively,
padding may be used (see padding) to hide the true length of, e.g.,
certificates by value in 'x5chain' or 'c5c'.
Paragraph (version B):
EDHOC itself does not provide countermeasures against Denial-of-
Service attacks.  In particular, by sending a number of new or
replayed message_1 an attacker may cause the Responder to allocate
state, perform cryptographic operations, and amplify messages.  To
mitigate such attacks, an implementation SHOULD rely on lower layer
mechanisms.  For instance, when EDHOC is transferred as an exchange
of CoAP messages, the CoAP server can use the Echo option defined in
RFC9175 which forces the CoAP client to demonstrate reachability at
its apparent network address.  To avoid an additional roundtrip the
Initiator can reduce the amplification factor by padding message_1,
see padding.