[Lake] Review of draft-serafin-lake-ta-00

[Marco Tiloca <[e-mail]>]

Hi all,

I have reviewed this document, and I believe it sets a good ground for 
facilitating peer authentication and other processes combined with an 
EDHOC session.

Please find below some detailed comments. Hope this helps!

Best,
/Marco


[Section 1]

* The second paragraph uses the formulations "hints about which TAs" and 
"hints of TAs", while the abstract says "hints about Trust Anchors of 
trusted third parties".

   This becomes clearer in the last paragraph of Section 1, when saying 
that "the TA includes the public key of the CA".

   Perhaps it's good to early align the formulations of the second 
paragraph with that of the abstract, and turn the two sentences above 
into "hints about which TAs of trusted third parties" and "hints of TAs 
of trusted third parties".

* It says

   "However, the same scheme can be applied to hints about other trusted 
third parties, ..."

   Consistent with previous sentences, I think this should be

   "However, the same scheme can be applied to hints about TAs of other 
trusted third parties, ..."

* It says

   "This document defines an EDHOC EAD item containing hints about 
certain type of TAs, and enables the extension to other kind of hints 
and TAs through the registration of the appropriate IANA parameters."

   Consistent with the previous sentences, shouldn't it be as follows 
instead?

    "This document defines an EDHOC EAD item containing hints about TAs 
of certain types of trusted third parties, and enables the extension to 
other kinds of hints and other kinds of trusted third parties through 
the registration of the appropriate IANA parameters."

* It says

   "a hash of an X.509 certificate containing the CA root public key (x5t)"

   I think it would more correct to say

   "a hash of an X.509 certificate (x5t) containing the CA root public key"


[Section 1.1]

* Please list the terms and concepts that readers are expected to be 
familiar with.


[Section 2.1]

* s/defined in Section 5./defined in Section 5.2.

* I guess you also want one entry with label 0 and being reserved.

* It says

   "to use for authentication credentials in EDHOC."

   I guess it means

   "to use for verifying authentication credentials in EDHOC."

* "The positive of the CBOR label ... sent to the sender."

   Even though it says "CBOR label", talking of "label in the EAD item" 
can be confusing.

   With reference to Figure 1, one might understand that you are 
referring to ead_label (hence, to TBD1 or -TBD1) within ead_ta_hint.

   Instead, I guess you don't mean ead_label, but instead the map key 
within ta_hint_map. If that's correct, it's better to rephrase as:

   "When the label is used with positive value (+1), the indicated trust 
anchors are to be used for verifying the authentication credentials from 
the sender. When the label is used with negative value (-1), the 
indicated trust anchors are supported by the sender and SHOULD be used 
in authentication credentials sent to the sender."

* It says

   "are supported by the sender and SHOULD be used in authentication 
credentials sent to the sender."

   I think you mean that the sender should send authentication 
credentials that are possible to verify by means of the specified trust 
anchors. Is that correct?


[Section 2.2]

* It says

   "... is a byte string containing a CBOR map with..."

   It should say

   "... is a byte string with value the binary representation of a CBOR 
map including ..."

* Is the EAD label TBD1 always intended to be used as non-critical? I 
suppose so, as this is all about giving hints.

* It should be said that the integer values for the map key of 
ta_hint_map are taken from the new registry defined in Section 5.2.

* It says:

   "Table 2 provides examples of COSE header_maps used as TA hint types."

   I think you mean

   "Table 2 provides examples of TA hint types specified within 
header_map like the corresponding COSE header parameters."

* Also based on the later examples in Section 3, header_map as a single 
CBOR map might be limiting, due to the required uniqueness of its map keys.

   As relevant for a ta_hint_map element that has negative map key, a 
peer cannot use the same hint type (e.g., x5t) for indicating multiple 
TAs that have the same advertised purpose (e.g., trust anchor of EDHOC 
authentication credential (-1)).

   Maybe it's better to generalize header_map to be a CBOR sequence 
composed of pairs. In each pair, the first element is taken from the 
COSE Header Parameter registry, while the second element is the intended 
hint consistent with the type indicated in the first element.

* Table 2 does not include COSE header parameters that identify 
credentials by value (e.g., 5chain). It would be good to motivate why 
this is not needed and instead all hints are provided by reference.

* Even though application policies can play a large role, it would be 
good to explain more in detail what actions are triggered by the EAD 
item on the message recipient, when the map key is a negative integer. 
This includes what the following EDHOC message specifies in the 
ID_CRED_X field.


[Section 3.2]

* It says:

   "An EDHOC peer may include hints about its supported TAs for 
authentication by including a ta_hint_map with label -1 in an 
appropriate EAD field: EAD_1 related to the AUTH_CRED_R and EAD_2 for 
AUTH_CRED_I. This informs the other peer about what TAs to use in its 
credentials in the next EDHOC message."

   This is a high-level explanation and can be moved to Section 3.0.


[Section 5.2]

* It says:

   "The value to be used to identify this type of authority. ... for the 
same type of authority but ..."

   Based on the terminology used in Section 2.1, doesn't the label 
identify a "purpose"? The word "authority" appears here for the first time.

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se