[Ace] Comments on draft-selander-ace-cose-ecdhe-04

[Jim Schaad <[e-mail]>]

Here is a large number of comments on the draft.  Some are technical and
some are just editorial.  I have gone through this list, in part, with
Francesca once.  Significant portions of the document are not reviewed
either because they seemed to be similar to others or I just did not worry
about them. 

*  Use SIGMA-I for both the asym and sym version of the protocol.  This is
going to make the two versions more alike which makes implementation easier
as well as protecting the id values which are sent in the symmetric key
variant.  The key id may or may not leak any useful information, but long
term ids sent in the message definitely does.

* The use of the words 'unique' and 'uniquely' are highly problematical and
need to be justified at any location where they are being used.  The problem
is going to be that 1) if the identifier is really short (and thus reduces
the transmission size) then collisions are going to be likely and 2) the
entity that can check for a collision is not usually going to be the one
that issues the identity and thus there is no way for enforcement of the
requirement of uniqueness.  The only possible place where I can think that
uniqueness is going to be an issue is for the shared key identifiers.

* Consider case where rather than sending an encrypted CWT access token
rather than a shared secret identifier.  (Maybe also for the asymmetric key
identifier?  I have not thought this case through.)

* The current protocol description assumes that the signature algorithm is
going to be the same for both entities.  There is no reason to assume this
always going to be true.  The negotiation should be a set of algorithms that
the party understands rather than attempting to agree on a single common
one.  This means that Sig_Arr would be sent both directions and would be a
list of acceptable algorithms.

* I am not sure that the following is a good idea or not, do you want to
save message bytes for the case of only a default algorithm is listed, in
which case the array of algorithms could be omitted.

* Section 4.1.1 - Reverse the order of the fields SIG_arr and MAC_arr in
alg_arr so that the same indexes can be used for both the symmetric and
asymmetric cases.

* Section 4.1.1 & 5.1.1 - Problem in that the same message names are used
but the contents are not the same.  Merge the definitions together so that
there is only one.  

* Section 4.1.2 - I would like to see if we can get rid of the nonce-array
element.  
    -- In message #2 asym - these can be moved to the PartyU_nonce and
PartyV_nonce fields in the recipient structure.
   -- In message #3 asym - This would be both identification and replay
detection.  Putting PartyV_nonce in the kid would work for identification, I
am not sure what replay detection you are looking for but combining the
nonce and the authentication tag might be a better detection than the pair
of nonce values.

* Section 4.2.1 - You should be using ECDH-SS rather than -ES for the
algorithm.  This is really using short lived static keys rather than
ephemeral keys from the perspective of the COSE messaging structure.  The
key is being used in more than one message and thus COSE does not view this
as a pure ephemeral.

* Section 4.2.1 - The tag "E_V" should be "static key" (-2)

* Section 4.2.3 - in pay1_3_rpk, ID_V should be ID_U.  Same issue for C_V in
pay1_3_cert

* Section 4.2.3 - combine pay1_3_rpk and pay1_3_cert into a single structure
with an alternative option "ID_U: bstr / C_U:bstr" in the last line as the
only difference is where the content comes from and not the structure of the
array.

* Section 4.3 - Change the way that PartyUInfo and PartyVInfo are filled out
as follows:
  - PartyUInfo SHALL contain: nonce shall be equal to N_U when deriving keys
K_U* and N_V when deriving keys K_V*
  - PartyVInfo SHALL contain: nonce shall be equal to N_V when deriving keys
K_U* and N_V when deriving keys K_U*

* Section 4.3 - for SuppPubInfo, I do not think that you need to do the hash
of the field rather than just using the raw field for the 'other'.   With
the above change, the strings "PartyU" and "PartyV" are not needed.

* If this is going to be used, then Appendix B should be part of the main
document.  

* Appendix B - Is there only a single address that this would be posted to?
Why not post to uri-path: "resource-name/edhoc/"

* Appendix B - how do I combine this with an authentication tag.  

* Appendix B - how do I combine this with an OSCON rather than an OSCOAP
message?

* Appendix B - how does the OSCOAP post know which location to link to if
there are multiple possible outstanding edhoc destinations or sessions?

Editorial:

Section 1 - You need to be consistent about the term 'pre-shared key' vs
'pre-shared secret'.  In many times a 'key' is going to be considered to be
of a specific length and potentially attached to an algorithm while a
'secret' can be a variable length item and is probably what you are thinking
about.

Section 1 - s/either pre-shared keys, raw public keys, or X.509
certificates/either a pre-shared secret, a raw public key or an X.509
certificate/ - use singular on these as only one of these is used for a
single set of messages.  

Section 2 - The working appears to say that the overview is coming in three
different sections (2, 4.3 and 5.3).  The overview should be in one place.
I don't know if this is a document organization or merely a sentence
punctuation problem.

Section 2 - In the paragraph starting /ECHOC is build on/ You should say
that "We defined two varieties of ECDHOC one using Async key s for
authentication and one using symmetric secrets for authentication"

Section 2 - s/MAC:ed/MACed/

Section 2 - para /ECDHOC is build on/ It is not clear which document
'Section 5' is referring to sentence re-write is called for

Section 2 - The paragraph starting /EDHOC used with symmetric keys/ looks
like it should be divided in two parts one before Figure 1 and one before
Figure 2 in the current text.  Otherwise it is not clear what these apply
too.  If the change to SIGMA-I is done then this may be less of an issue.

Section 2 - You are stating that you have a symmetric key case, but the
pictures do not reflect this as they are all using Sig(V: as a function.
This change should also discuss how using MAC(Ka: affects the security
levels of the document.  Needs to talk about the fact that this is a lesser
authentication and depends on the fact that Ka is going to be shared between
only two parties and reflection is a potential problem.  Not sure how I
would exploit this attack right now.

Section 5.1.1 - Swap the order of KID and ALG_U - while these are maps,
making them the same order helps for doing comparisions

Section 5.1.1 - Place the shared secret in as the salt for the KDF done by
the ECDH-SS algorithm rather than having the kid_psk in the unprotected
header field.  Still may need to do an id of it some place but move up to
the recipient field to do so.

Section 5.1.1 - Is there a reason to make the MAC algorithm for the
innermost and outermost MACs be the same esp if the PSK already specifies a
MAC alg to use.

Section 5.1.2 - Swap order of KID and ID_V in pay1_2_psk to match the asym
case.

Section 5.1.2 - why specify ALG_V for the psk but not for the asym payload?

Section 5.1.2 - what is the value of doing the authentication on the psk
identifier?  This is not a security based item and you should have failed
long before now if you did not get the correct key.

Section 5.1.3 - in pay1_3_psk - s/ID_V/ID_U/

Section 5.2 - See comment on swapping the nonce values from above

Section 5.2 - Do I have access to the ID_V field at the correct time?  Does
adding this add any value and if not why include it.  It is not part of the
asym key derivations.
Section 2 - last sentence is redundant.

Section 3 - Move all MTI statements to a single section where it is clear
that all required algorithms are given one or more MTIs.  You might need to
specify more than one if you want to have fail over on an algorithm
breakage.

Section 3- The definition on how to form keys is targeted at one key type.
I would make this more general so that it can apply to multiple key types.
Example text might be:

COSE keys used as ephemeral keys should contain only the minimal elements
for interoperability.  This means that labels such as 'alg' are not present.
When multiple values of a field can be used, the shorter version SHOULD be
used.  Thus, for 'EC2' keys, the value of 'y' SHOULD be a Boolean rather
than a binary string.

Section 4 - sentence s/Subsequent traffic .../ You should be clear what
subsequent traffic you are talking about here.  Is this traffic in the EDHOC
protocol or in the protocols that are going to use the established keys?

Section 4 - I would like to suggest the following reorg for the document
   Section X - Message #X - overview of what the message is going to
accomplish - where it maps in the SIGMA-I protocol
   Section X.1 - Message structure - The CDDL description for the message
   Section X.2 - Message creation - 
       Section X.2.1 - For Async - 
       Section X.2.2 - For sync - use these two sections iff the differences
are large
   Section X.3 - Message Processing Party->Message #X
   Section X.4 - Message Processing Message #X --> Party
            Again .3 and .4 can have subsections if the differences are
large
   I would put the two key derivations (Section 5) steps as Section 5.1 and
5.2 (in protocol and post protocol)

Section 4.1.1 - I would add a note just to be explicit - that Message 1 does
not have any security applied to it and note that the fields will be
validated later.

Section 4.3.4 - s/COSE_MAC0 is computed/COSE_CMAC0 is re-constructed/

Section 4.3.4 - /verify that the nonce has not/   which nonce is being
referred to in this item

Section 5 - What is the purpose of having the ID_U and ID_V fields for
symmetric keys.  This makes sense for asym because it is used to identify
which public keys are being used. That is not done for the sym case.  What
type of info should go here?

Section 5 - Need to talk about how to go from shared secret to K_VMP
someplace.  I am not sure that the OSCOAP key derivation technique is always
correct esp of these PSK is a key rather than a secret.

Section 7 - The last paragraph appears to me to be a vacuous statement.  I
don't know what steps to take to deal with this issue.

Future Items:

* Chaining the shared secret based on a successful running of the EDHOC
algorithm.

* Discussions of a server using the same ephemeral key for multiple runs of
the protocol.  Affects the PFS property, but this may be acceptable if the
window is small (i.e. a couple of hours).

* Rules on replay of messages seems to be needed.  These rules may need to
be modified by the difference between a reliable and an un-reliable
transport.