Re: [Lake] Summary of actions since IETF 109

[Göran Selander <[e-mail]>]

Hi,

We just submitted -03 which contains the updates listed in the mail below. 

Additionally, the new version has a number of editorials. The main change is an updated presentation of the protocol elements addressing issue #40. This changed the structure of section 3, but the content is essentially unchanged. Here is a diff:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-lake-edhoc-03.txt

Göran

On 2020-12-17, 14:33, "Lake on behalf of John Mattsson" <[e-mail] on behalf of john.mattsson=[e-mail]> wrote:

    Hi,

    The following updates has been made based on the issue discussion at IETF 109:


    Agreement/negotiation of parameters (#11, #23):
    --------------------------------------------------------------
    A new appendix that describes the parameters that need to be agreed upon between Initiator and Responder has been added. Currently some overlap between the new appendix and the section “Communication/Negotiation of Protocol Features”.


    Rekeying OSCORE AEAD (#20):
    Forward and backward secrecy (#24):
    --------------------------------------------------------------
    CORE WG discussed rekeying and forward secrecy at IETF 109. The discussion has continued after IETF 109. Preliminary conclusions are that a new CORE draft is needed to specify OSCORE AEAD counters, that RFC 8613 appendix B.2 (or and update) is needed for lightweight rekeying in OSCORE, and that it would be good if lightweight forward secrecy (FS) can be done in EDHOC to avoid changes in OSCORE. We think lightweight FS can be achieved by “hashing” the key PRK_4x3m with the EDHOC-Exporter. The nonce make sure that the “hash-chain” does not have short cycles. The following update has been made in GitHub:

        EHDOC-Exporter-FS( nonce ):	
            PRK_4x3m = Extract( [ "TH_4", nonce ], PRK_4x3m )

    FFS where the nonce comes from (EDHOC, OSCORE) and if it is a counter, a random number, or counter+random number. The use of OSCORE appendix B.2 together with the EHDOC-Exporter-FS function align on a high level with the mechanisms proposed by Karthik 
    https://mailarchive.ietf.org/arch/msg/lake/vkJunXEQZ33HP9YpNByQesEW7l8/


    Distinguish error message (#30):
    --------------------------------------------------------------
    Text on how to distinguish error message has been added. This discussion has spawned several new discussions. Are there a need to distinguish message_1 from message_3 except the connection ID and 5-tuple? Is the error message something the implementor define or should EDHOC define the error messages?


    More ways to Identify certificates ('kid’, ‘c5u’, c5t’) (#32, #33):
    Verification of intended peer (#8):
    --------------------------------------------------------------
    COSE WG have on ongoing discussion on how to identify a certificate with ‘kid’. Request to add ‘c5u’, c5t’ to the EDHOC test vectors. The CBOR certificate draft will add the subjects private key to enable this. We will add text on why SIGMA require a “subject name” and describe the kind of misbinding attacks this mitigates. This is a bit related to ongoing discussion on the security of ‘x5u’ in COSE. 


    Shall we replace HKDF with a more general extract-and-expand to allow KMAC? (#19):
    --------------------------------------------------------------
    Changed from HKDF-Extract and HKDF-Expand to general Extract-and-Expand. For SHA-2, HKDF is used, for SHAKE, KMAC is used. (Note that this does change anything when SHA-256 is used. We are also currently not planning on adding SHAKE cipher suites, but SHAKE (like all other COSE algorithms) can be used with private cipher suites.


    Shall we specify EDHOC in terms of KEM? (#17):
    --------------------------------------------------------------
    We tried to implement EDHOC with the HPKE interfaces. The conclusion is that the signature mode maps quite well to the unauthenticated HPKE interfaces, with the difference that HPKE forces Extract-and-Expand and EDHOC uses Extract and Expand as separate functions and use the intermediate key to derive several keys with Expand. The Static Diffie-Hellman modes does not map well to HPKE as HPKE do GenerateKeyPair() inside Encap(), while EDHOC relies on doing GenerateKeyPair() outside of “Encap()” as an essential optimization. The conclusion is therefore that this change should not be done as it would change the key derivation too much as well as significantly increase message size. We should however consider to future proof EDHOC so it can be updated with PQC KEMs. Unclear if “Static DH” authentication with PQC KEMs provide any benefits compared to PQC signatures. 


    How to do encryption without integrity in message_2 (#34):
    --------------------------------------------------------------
    The agreement from IETF 109 was to specify new modes of AES and ChaCha20 for message_2 similar to TLS 1.3. After trying to implement this we think it is a bad idea as it makes things quite complicated for developers and complicated the specification. In EDHOC it is not enough with AES-ECB and the ChaCha20 block cipher as in TLS 1.3. EDHOC would need AES-CTR and the ChaCha20 stream cipher. This makes the specification a bit complicated and it makes it a bit complicated for developers with a COSE implementation as they have to dig out AES and ChaCha20 and implement stream cipher modes. We would like to bring this up for discussion again. We think both 1 and 2) would be better choices with low complexity for developers.

       1. Generate keystream with HDKF-Expand.
       2. Encrypt like in message_3 and remove the tag (if there is a well-defined tag).


    Register cipher suites with high security (#35):
    --------------------------------------------------------------
    Several independent requests to include a cipher suite compatible with CNSA. One request to add a general non-constrained cipher suite. We have added the following two registered cipher suites to EDHOC. The first one is compatible with CNSA and the second uses the algorithms popular on the web.

       4. A256GCM, SHA-384, P-384, ES384, P-384, A256GCM, SHA-384
       5. A128GCM, SHA-256, X25519, ES256, P-256, A128GCM, SHA-256

    We have also added additional text describing that EDHOC can be used with all COSE algorithms/curves by using the private cipher suites.


    Cheers,
    John

    -- 
    Lake mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lake