Network Working Group J. Schaad Internet-Draft March 5, 2019 Intended status: Experimental Expires: September 6, 2019 TLS Handshake in CBOR draft-schaad-ace-tls-cbor-handshake-00 Abstract None Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Schaad Expires September 6, 2019 [Page 1] Internet-Draft TLS Handshake in CBOR March 2019 Table of Contents 1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 4 3. Client Hello . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Server Hello . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Supported Versions . . . . . . . . . . . . . . . . . . . 7 5.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 7 5.4. Certificate Authorities . . . . . . . . . . . . . . . . . 9 5.5. OID Filters . . . . . . . . . . . . . . . . . . . . . . . 9 5.6. Post-Handshake Client Authentication . . . . . . . . . . 9 5.7. Supported Groups . . . . . . . . . . . . . . . . . . . . 9 5.8. Key Share . . . . . . . . . . . . . . . . . . . . . . . . 10 5.8.1. ECDHE Parameters . . . . . . . . . . . . . . . . . . 11 5.9. Pre-Shared Key Exchange Modes . . . . . . . . . . . . . . 11 5.10. Early Data Indication . . . . . . . . . . . . . . . . . . 12 5.11. Pre-Shared Key Extension . . . . . . . . . . . . . . . . 12 5.12. Other Extensions . . . . . . . . . . . . . . . . . . . . 13 6. Server Parameters . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Encrypted Extensions . . . . . . . . . . . . . . . . . . 13 7. Certificate Request . . . . . . . . . . . . . . . . . . . . . 14 8. Authentication Messages . . . . . . . . . . . . . . . . . . . 14 8.1. Certificate . . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Certificate Verify . . . . . . . . . . . . . . . . . . . 15 8.3. Finish . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Record Payload Protection . . . . . . . . . . . . . . . . 16 10. CBOR Slashed Version . . . . . . . . . . . . . . . . . . . . 17 11. Transport with CoAP . . . . . . . . . . . . . . . . . . . . . 17 12. Informational . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Sample Messages . . . . . . . . . . . . . . . . . . 18 A.1. Standard TLS for X25519 and Ed25519 . . . . . . . . . . . 18 A.2. Pre-shared key for authentication w/ ephemeral DH . . . . 20 A.3. Stripped TLS w/ Ed25519 . . . . . . . . . . . . . . . . . 22 A.4. Stripped TLS w/ PSK . . . . . . . . . . . . . . . . . . . 24 Appendix B. Open ideas for ways to make things smaller . . . . . 25 Appendix C. EDHOC issues that worry me . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 1. Summary There are two measures that can be looked at when measuring how good the different options presented below are going to be. Schaad Expires September 6, 2019 [Page 2] Internet-Draft TLS Handshake in CBOR March 2019 o Total Number Of Bytes: The total number of bytes that are needed to perform the key establishment protocol. o Total Number of Messages: The total number of messages that are needed to perform the key establishment protocol. This measure is going to be dependent on which of the transports is being used. For UDP the sizes are going to be from 576 to 1152 in the course of normal events. This means that all of the protocols being looked at can be run in three messages without any problems. For 6LoWPAN L2 however, the packet size is 127 bytes which leads to many more messages needed to be used. One can send approximately 80 bytes of payload in a single message, but if one is using blockwise transfer then the payloads are going to be limited to 64 bytes. Summary of message sizes in bytes. +------------+-----+-----+-------+-------+-------+-------+ | | TLS | TLS | TLS-C | TLS-C | TLS-S | TLS-S | +------------+-----+-----+-------+-------+-------+-------+ | | RPK | PSK | RPK | PSK | RPK | PSK | | | | | | | | | | Message #1 | 122 | 164 | 97 | 134 | 47 | 64 | | | | | | | | | | Message #2 | 306 | 163 | 262 | 143 | 145 | 66 | | | | | | | | | | Message #3 | 205 | 72 | 175 | 54 | 101 | 21 | | | | | | | | | | Total | 633 | 399 | 534 | 331 | 293 | 151 | +------------+-----+-----+-------+-------+-------+-------+ Summary of message sizes in estimated number of messages. +------------+-----+-----+-------+-------+-------+-------+ | | TLS | TLS | TLS-C | TLS-C | TLS-S | TLS-S | +------------+-----+-----+-------+-------+-------+-------+ | | RPK | PSK | RPK | PSK | RPK | PSK | | | | | | | | | | Message #1 | 2 | 3 | 2 | 3 | 1 | 1 | | | | | | | | | | Message #2 | 5 | 3 | 5 | 3 | 3 | 1 | | | | | | | | | | Message #3 | 4 | 1 | 3 | 1 | 2 | 1 | | | | | | | | | | Total | 11 | 7 | 10 | 7 | 6 | 3 | +------------+-----+-----+-------+-------+-------+-------+ Schaad Expires September 6, 2019 [Page 3] Internet-Draft TLS Handshake in CBOR March 2019 2. Handshake Protocol The TLS Handshake message is: struct { HandshakeType msg_type; /* handshake type */ uint24 length; /* remaining bytes in message */ select (Handshake.msg_type) { case client_hello: ClientHello; case server_hello: ServerHello; case end_of_early_data: EndOfEarlyData; case encrypted_extensions: EncryptedExtensions; case certificate_request: CertificateRequest; case certificate: Certificate; case certificate_verify: CertificateVerify; case finished: Finished; case new_session_ticket: NewSessionTicket; case key_update: KeyUpdate; }; } Handshake; For the CBOR encoding make the following changes: o Remove the length field: It is expected that this can be passed down from the record layer. o Make the message type and field be a map. Handshake = handshakeMessage handshakeMessage = { 1 : ClientHello, 2 : ServerHello, 3 : EndOfEarlyData, 4 : EncryptedExtensions, 5 : CertificateRequest, 6 : Certificate, 7 : CertificateVerify, 8 : Finished, 9 : NewSessionTicket, 10 : KeyUpdate } Expected space savings: o 3 bytes for the length Schaad Expires September 6, 2019 [Page 4] Internet-Draft TLS Handshake in CBOR March 2019 3. Client Hello The TLS Client Hello structure is: uint16 ProtocolVersion; opaque Random[32]; uint8 CipherSuite[2]; /* Cryptographic suite selector */ struct { ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ Random random; opaque legacy_session_id<0..32>; CipherSuite cipher_suites<2..2^16-2>; opaque legacy_compression_methods<1..2^8-1>; Extension extensions<8..2^16-1>; } ClientHello; For the CBOR encoding make the following changes: o Remove all of the legacy items - reduction of 5 bytes + lengths?. ClientHello = [ random : bstr .len 32, cipher_suites : [+ int . len 1], // max 2^8-1 extensions : [ + Extension ] ] 4. Server Hello The TLS Server Hello structure is: struct { ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ Random random; opaque legacy_session_id_echo<0..32>; CipherSuite cipher_suite; uint8 legacy_compression_method = 0; Extension extensions<6..2^16-1>; } ServerHello; For the CBOR encoding make the following changes: o Remove all of the legacy fields. Schaad Expires September 6, 2019 [Page 5] Internet-Draft TLS Handshake in CBOR March 2019 ServerHello = [ random : bstr .len 32 cipher_suite : int, extensions : [ + Extension ] ] 5. Extensions The TLS Extenions field is: struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } Extension; enum { server_name(0), /* RFC 6066 */ max_fragment_length(1), /* RFC 6066 */ status_request(5), /* RFC 6066 */ supported_groups(10), /* RFC 8422, 7919 */ signature_algorithms(13), /* RFC 8446 */ use_srtp(14), /* RFC 5764 */ heartbeat(15), /* RFC 6520 */ application_layer_protocol_negotiation(16), /* RFC 7301 */ signed_certificate_timestamp(18), /* RFC 6962 */ client_certificate_type(19), /* RFC 7250 */ server_certificate_type(20), /* RFC 7250 */ padding(21), /* RFC 7685 */ pre_shared_key(41), /* RFC 8446 */ early_data(42), /* RFC 8446 */ supported_versions(43), /* RFC 8446 */ cookie(44), /* RFC 8446 */ psk_key_exchange_modes(45), /* RFC 8446 */ certificate_authorities(47), /* RFC 8446 */ oid_filters(48), /* RFC 8446 */ post_handshake_auth(49), /* RFC 8446 */ signature_algorithms_cert(50), /* RFC 8446 */ key_share(51), /* RFC 8446 */ (65535) } ExtensionType; For the CBOR encoding make the following changes: o Remove items we don't care about o Encode as a map. Schaad Expires September 6, 2019 [Page 6] Internet-Draft TLS Handshake in CBOR March 2019 ExtensionType = ( // 0 : ServerName, // 1 : max_fragment_length, // 5 : status_request, 10 : supported_groups, 13 : signature_algorithms, // 14 : use_srtp, // 15 : heartbeat, // 16 : application_layer_protocol_negoiation, // 18 : signed_certificate_timestamp, // 19 : client_certificate_type, // 20 : server_certificate_type, // 21 : padding, 41 : pre_shared_key, // 42 : early_data, // 43 : supported_versions, // 44 : cookie, 45 : psk_key_exchange_modes, // 47 : certificate_authorities, // 48 : oid_filters, // 49 : post_handshake_auth, // 50 : signature_algoirthms_cert, 51 : key_share ) Extension = ( int, any ) 5.1. Supported Versions Not currently used as we only have one version. If absent it will be assumed to be this version. 5.2. Cookie There is no reason for this extension to be used in CoRE. For the same functionality use [I-D.ietf-core-echo-request-tag]. 5.3. Signature Algorithms The TLS signature algorithm structures are: Schaad Expires September 6, 2019 [Page 7] Internet-Draft TLS Handshake in CBOR March 2019 enum { /* RSASSA-PKCS1-v1_5 algorithms */ rsa_pkcs1_sha256(0x0401), rsa_pkcs1_sha384(0x0501), rsa_pkcs1_sha512(0x0601), /* ECDSA algorithms */ ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), ecdsa_secp521r1_sha512(0x0603), /* RSASSA-PSS algorithms with public key OID rsaEncryption */ rsa_pss_rsae_sha256(0x0804), rsa_pss_rsae_sha384(0x0805), rsa_pss_rsae_sha512(0x0806), /* EdDSA algorithms */ ed25519(0x0807), ed448(0x0808), /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ rsa_pss_pss_sha256(0x0809), rsa_pss_pss_sha384(0x080a), rsa_pss_pss_sha512(0x080b), /* Legacy algorithms */ rsa_pkcs1_sha1(0x0201), ecdsa_sha1(0x0203), /* Reserved Code Points */ private_use(0xFE00..0xFFFF), (0xFFFF) } SignatureScheme; struct { SignatureScheme supported_signature_algorithms<2..2^16-2>; } SignatureSchemeList; One of the differences that may need to be dealt with at this point is the question of keeping the same enumeration as TLS uses or if the enumeration should be changed. For this document the same enumeration is being kept. TLS uses the current two byte format because it separates the hash algorithm from the public key algorithms. For a single algorithm this ends up being 3 bytes for CBOR and 4 bytes for TLS. Each additional algorithm adds 2 bytes until you get to 12 algorithms. If one switched to using integer values from the COSE tables, then one ends up with the same byte count. Schaad Expires September 6, 2019 [Page 8] Internet-Draft TLS Handshake in CBOR March 2019 For the CBOR encoding make the following changes: o None signature_algorithms = bstr 5.4. Certificate Authorities Not used. 5.5. OID Filters Not used. 5.6. Post-Handshake Client Authentication Not used. 5.7. Supported Groups The TLS structure is: enum { /* Elliptic Curve Groups (ECDHE) */ secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), x25519(0x001D), x448(0x001E), /* Finite Field Groups (DHE) */ ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), ffdhe6144(0x0103), ffdhe8192(0x0104), /* Reserved Code Points */ ffdhe_private_use(0x01FC..0x01FF), ecdhe_private_use(0xFE00..0xFEFF), (0xFFFF) } NamedGroup; struct { NamedGroup named_group_list<2..2^16-1>; } NamedGroupList; It makes more sense to change the enumeration from that used by TLS to the COSE EC curve registry as those values are only single byte values and are small. One implication is that all of the Finite Field Groups are dropped, but this should not be a problem. This means a 2 byte value for a single curve in the CBOR version rather Schaad Expires September 6, 2019 [Page 9] Internet-Draft TLS Handshake in CBOR March 2019 than a 4 byte encoding for TLS. Adding a second curve adds one byte for CBOR and 2 bytes for TLS. For the CBOR encoding make the following changes: o Change from a two byte enumeration to the the integer values from the COSE EC curve registry. NamedGroup = { secp256r1: 1, secp384r1: 2, secp521r1: 3, x25519: 4, x448:5 } supported_groups = [ + NamedGroup ] 5.8. Key Share The TLS structure for key share is: struct { NamedGroup group; opaque key_exchange<1..2^16-1>; } KeyShareEntry; struct { KeyShareEntry client_shares<0..2^16-1>; } KeyShareClientHello; struct { NamedGroup selected_group; } KeyShareHelloRetryRequest; struct { KeyShareEntry server_share; } KeyShareServerHello; For the CBOR encoding make the following changes: Schaad Expires September 6, 2019 [Page 10] Internet-Draft TLS Handshake in CBOR March 2019 keyShareEntry = { secp256r1 : CompressedPointRepresentation, secp384r1 : CompressedPointRepresentation, secp521r1 : CompressedPointRepresentation, x25519 : bstr, x448 : bstr, * NamedGroup : any } key_share = KeyShare_ClientHello | KeyShare_HelloRetryRequest | KeyShare_ServerHello KeyShare_ClientHello = [ *keyShareEntry] KeyShare_HelloRetryRequest = NamedGroup KeyShare_ServerHello = keyShareEntry 5.8.1. ECDHE Parameters The TLS structure is: struct { uint8 legacy_form = 4; opaque X[coordinate_length]; opaque Y[coordinate_length]; } UncompressedPointRepresentation; For the CBOR encoding make the following changes: o Switched to compressed points for space savings. CompressedPointReprentation = [ x : bstr, y : bool ] 5.9. Pre-Shared Key Exchange Modes The TLS structure is: enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; struct { PskKeyExchangeMode ke_modes<1..255>; } PskKeyExchangeModes; Changes for CBOR: Schaad Expires September 6, 2019 [Page 11] Internet-Draft TLS Handshake in CBOR March 2019 pskKeyExchangeMode = ( psk_key: 0, psk_dhe_ke:1 } psk_key_exchange_modes = [ + pskKeyExchangeMode] 5.10. Early Data Indication Not used. 5.11. Pre-Shared Key Extension The TLS structure is: struct { opaque identity<1..2^16-1>; uint32 obfuscated_ticket_age; } PskIdentity; opaque PskBinderEntry<32..255>; struct { PskIdentity identities<7..2^16-1>; PskBinderEntry binders<33..2^16-1>; } OfferedPsks; struct { select (Handshake.msg_type) { case client_hello: OfferedPsks; case server_hello: uint16 selected_identity; }; } PreSharedKeyExtension; The changes for CBOR are: pre_shared_key = clientHello_PSK | serverHello_PSK clientHello_PSK = OfferedPsks serverHello_PSK = int OfferedPsks = [ identities : [ +PskIdentity ], binders : bstr ] PskIdentity = ( identity : bstr, ? obfuscated_ticket_age : int ) Schaad Expires September 6, 2019 [Page 12] Internet-Draft TLS Handshake in CBOR March 2019 5.12. Other Extensions TLS struct { select(ClientOrServerExtension) { case client: CertificateType client_certificate_types<1..2^8-1>; case server: CertificateType client_certificate_type; } } ClientCertTypeExtension; struct { select(ClientOrServerExtension) { case client: CertificateType server_certificate_types<1..2^8-1>; case server: CertificateType server_certificate_type; } } ServerCertTypeExtension; CBOR clientCertType = certTypeRequest | certTypeResponse serverCertType = certTypeRequest | certTypeResponse certTypeRequest = [+ cerType] certTypeResponse = certType certType = (x509:0, rawPublicKey:1 } 6. Server Parameters 6.1. Encrypted Extensions The TLS structure is: struct { Extension extensions<0..2^16-1>; } EncryptedExtensions; For CBOR: EncryptedExtensions = [ * Extension ] Schaad Expires September 6, 2019 [Page 13] Internet-Draft TLS Handshake in CBOR March 2019 7. Certificate Request Not Used 8. Authentication Messages 8.1. Certificate TLS enum { X509(0), RawPublicKey(2), (255) } CertificateType; struct { select (certificate_type) { case RawPublicKey: /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; case X509: opaque cert_data<1..2^24-1>; }; Extension extensions<0..2^16-1>; } CertificateEntry; struct { opaque certificate_request_context<0..2^8-1>; CertificateEntry certificate_list<0..2^24-1>; } Certificate; certificate = [ ? certificate_request_context : bstr, certificate_list : [* CertificateEntry] ] CertificateEntry = [ certificate : { 0 : bstr, // cert_data, 1 : bstr // ASN1_subjectPublicKeyInfo }, extensions : [* Extension] ] Schaad Expires September 6, 2019 [Page 14] Internet-Draft TLS Handshake in CBOR March 2019 8.2. Certificate Verify TLS struct { SignatureScheme algorithm; opaque signature<0..2^16-1>; } CertificateVerify; CBOR CertificateVerify = [ algorithm : SignatureScheme, signature : bstr ] 8.3. Finish TLS struct { opaque verify_data[Hash.length]; } Finished; CBOR Finished = bstr 9. Record Protocol 9.1. Record Layer TLS Schaad Expires September 6, 2019 [Page 15] Internet-Draft TLS Handshake in CBOR March 2019 enum { invalid(0), change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion legacy_record_version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; CBOR contentType = ( invalid: 0, change_cipher_spec: 20, alert:21, handshake:22, application_data:23 ) TLSPlaintext = ( type : contentType, fragment : bstr ) 9.2. Record Payload Protection TLS struct { opaque content[TLSPlaintext.length]; ContentType type; uint8 zeros[length_of_padding]; } TLSInnerPlaintext; struct { ContentType opaque_type = application_data; /* 23 */ ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ uint16 length; opaque encrypted_record[TLSCiphertext.length]; } TLSCiphertext; CBOR Schaad Expires September 6, 2019 [Page 16] Internet-Draft TLS Handshake in CBOR March 2019 TLSCiphertext = ( type : application_data, encrypted_record : bstr ) 10. CBOR Slashed Version There are many things that the EDHOC system did that slashed down size that has not been done for the previous version of TLS. If these changes are made then a non-trivial amount of savings can be done that might or might not be considered acceptable in this situation. For the puspose of making things even small we are making the following assumptions: o Remove the random number strings from the system. Since we are always going to do new ephemeral keys on both sides when the protocol is done, then the random numbers are not needed. If new ephemeral keys are not done on both sides, then the perfect forward secrecy requirement is not met. o Trucate all HMAC values to 64-bits. o If the encrypted extensions handshake message is empty, then omit it. o In cases where a single value can be in an array, change the syntax to be either the single value or an array of values. o Change the behavior of some of the extensions by adding additional operations and changing defaults. * Change the default value for client and server certificate type from "certificate" to "RPK" and "reference". * Change the behavior of the curves extension so that if it is omitted, then the cruve offered in the key share is assumed to be the only one supported by the client. 11. Transport with CoAP Transporting the messages w/ CoAP is fairly simple: 1. Message #1 is a POST to a fixed location. 2. Message #2 is the response to the POST. The message returns either Created (2.01) or a TLS Alert message with Bad Request Schaad Expires September 6, 2019 [Page 17] Internet-Draft TLS Handshake in CBOR March 2019 (4.00). If the message is successful, then a Location-Path will be returned as part of the message. 3. Message #3 is a PUT to the returned location path from the above response. 4. Message #4 is either a TLS Alert message with Bad Request (4.00) or an empty Changed (2.04) message. At this point the location path is deleted on the server. 12. Informational [I-D.ietf-core-echo-request-tag] Amsuess, C., Mattsson, J., and G. Selander, "Echo and Request-Tag", draft-ietf-core-echo-request-tag-03 (work in progress), October 2018. Appendix A. Sample Messages A.1. Standard TLS for X25519 and Ed25519 The size of messge #1 is 97 bytes 22, << 1, [ h'0011223344556677889900112233445566778899001122334455 667788990011', / random / [ h'1304' / TLS_AES_128_CCM_SHA256 ], / cipher suites / [ 51, [ 4 / x25519 /, h'00112233445566778899001122334455 66778899001122334455667788990011' ], 13, [ h'0807' / Ed2215 / ], / signature algorithms / 10, [ 4 / secp256r1 / ], 19, [ 1 ] / client_cert_type /, 20, [ 1 ] / server_cert_type /, ] ] >> Message #1 The size of message #2 is 262 bytes. If you directly encode what is below it will be 16 bytes short as there is no provision in the CDDL for the 16 bytes of the MAC appended to the end of the encrypted data. Schaad Expires September 6, 2019 [Page 18] Internet-Draft TLS Handshake in CBOR March 2019 22, << 2, [ h'00112233445566778899001122334455667788990011223344 55667788990011', / random / h'1304', / cipher suite / [ 51, [ 4 / x25519 /, h'001122334455667788990011223344 5566778899001122334455667788990011' ] / key share / ] ] >>, 23, << 4, [ 19, 1, / client_cert_type / 20, 1 / server_cert_type / ], 11, [ [ 1 / rpk /, h'1122334455667788990011223344556677889900112233445566 778899001122334455667788990011223344' ] ], 12, [ h'0807', h'1122334455667788990011223344556677889900112233445566 778899001122334455667788990011223344556677889900112233 4455667788990011223344' ], 13, h'1122334455667788990011223344556677889900112233445566 778899001122' >> Message #2 Size of message #3 is 175 bytes Schaad Expires September 6, 2019 [Page 19] Internet-Draft TLS Handshake in CBOR March 2019 23, << 11, [ [ 1 / rpk /, h'11223344556677889900112233445566778899001122334455 66778899001122334455667788990011223344' ] ], 12, [ h'0807', h'112233445566778899001122334455667788990011223344 55667788990011223344556677889900112233445566778899 001122334455667788990011223344' ], 13, h'1122334455667788990011223344556677889900112233445566 778899001122' >> Message #3 A.2. Pre-shared key for authentication w/ ephemeral DH The size of messge #1 is 97 bytes 22, << 1, [ h'001122334455667788990011223344556677889 9001122334455667788990011', / random / [ h'1304' / TLS_AES_128_CCM_SHA256 ], / cipher suites / [ 51, [ 4 / x25519 /, h'0011223344556677889900112233445 566778899001122334455667788990011' ], 13, [ h'0807' / Ed2215 / ], / signature algorithms / 10, [ 4 / secp256r1 / ], 19, [ 1 ] / client_cert_type /, 20, [ 1 ] / server_cert_type /, ] ] >> Message #1 The size of message #2 is 262 bytes. If you directly encode what is below it will be 16 bytes short as there is no provision in the CDDL Schaad Expires September 6, 2019 [Page 20] Internet-Draft TLS Handshake in CBOR March 2019 for the 16 bytes of the MAC appended to the end of the encrypted data. 22, << 2, [ h'001122334455667788990011223344556677889900112233445 5667788990011', / random / h'1304', / cipher suite / [ 51, [ 4 / x25519 /, h'00112233445566778899001122 33445566778899001122334455667788990011' ] / key share / ] ] >>, 23, << 4, [ 19, 1, / client_cert_type / 20, 1 / server_cert_type / ], 11, [ [ 1 / rpk /, h'1122334455667788990011223344556677889900112233445566 778899001122334455667788990011223344' ] ], 12, [ h'0807', h'1122334455667788990011223344556677889900112233445566 7788990011223344556677889900112233445566778899001122 334455667788990011223344' ], 13, h'112233445566778899001122334455667788990011223344556677 8899001122' >> Message #2 Size of message #3 is 175 bytes Schaad Expires September 6, 2019 [Page 21] Internet-Draft TLS Handshake in CBOR March 2019 23, << 11, [ [ 1 / rpk /, h'11223344556677889900112233445566778899001122334455 66778899001122334455667788990011223344' ] ], 12, [ h'0807', h'1122334455667788990011223344556677889900112233445566 77889900112233445566778899001122334455667788990011223 34455667788990011223344' ], 13, h'1122334455667788990011223344556677889900112233445566778 899001122' >> Message #3 A.3. Stripped TLS w/ Ed25519 The size of messge #1 is 47 bytes 22, << 1, [ 1 / TLS_AES_128_CCM_SHA256_64 /, / cipher suites / [ 1, [ 4 / x25519 /, h'00112233445566778899001122334455 66778899001122334455667788990011' ], 2, 99 / Ed2215 / / signature algorithms / ] ] >> Message #1 The size of message #2 is 146 bytes. The encryption authentication code is added as a separate at the end of the encrypted handshake block. Schaad Expires September 6, 2019 [Page 22] Internet-Draft TLS Handshake in CBOR March 2019 22, << 2, [ 1 / TLS_AES_128_CCM_SHA256_64 /, / cipher suite / [ 1, [ 4 / x25519 /, h'001122334455667788990011223344 5566778899001122334455667788990011' ] / key share / ] ] >>, 23, << 11, [ [ 9 / reference /, h'1122334455' ] / certificate / ], 12, [ 99, h'11223344556677889900112233445566778899001122 3344556677889900112233445566778899001122334455 66778899001122334455667788990011223344' / signature / ], / certificate verify / 13, h'1122334455667788', / finish / h'11223344556677' / encryption authentication code / >> Message #2 Size of message #3 is 102 bytes Schaad Expires September 6, 2019 [Page 23] Internet-Draft TLS Handshake in CBOR March 2019 23, << 11, [ [ 9 / reference /, h'1122334455' ] ], / certificate / 12, [ 99, h'11223344556677889900112233445566778899001122 33445566778899001122334455667788990011223344 5566778899001122334455667788990011223344' ], / certificate verify / 13, h'1122334455667788', / finish / h'1122334455667788' / encryption authentication code / >> Message #3 A.4. Stripped TLS w/ PSK The size of messge #1 is 65 bytes 22, << 1, [ 1, / cipher suites / [ 1, [ 4 / x25519 /, h'001122334455667788990011 2233445566778899001122334455667788990011' ], 2, 99, / signature algorithms / 6, [ h'0102030405', h'0102030405060708' ] ] ] >> Message #1 The size of message #2 is 59 bytes. If you directly encode what is below it will be 16 bytes short as there is no provision in the CDDL for the 16 bytes of the MAC appended to the end of the encrypted data. Schaad Expires September 6, 2019 [Page 24] Internet-Draft TLS Handshake in CBOR March 2019 22, << 2, [ 1, / cipher suite / [ 1, [ 4 / x25519 /, h'0011223344556677889900112233445 566778899001122334455667788990011' ], / key share / 6, 1 ] ] >>, 23, << 13, h'1122334455667788' >> Message #2 Size of message #3 is 12 bytes 23, << 13, h'1122334455667788' >> Message #3 Appendix B. Open ideas for ways to make things smaller The following things can still be considered for shrinking things: o Make the random values optional. This would kill 66 bytes from the first and second messages. o Think of a way to shorten the SKI encoding of the raw public key. o Decode to re-encode the signature and cipher suite numbers o Change some of the default values. For example we could change to RPK being the default certificate type. o Create a HMAC cipher suite which truncates the output for doing finish messages. This is not unusual for the world of IoT and Schaad Expires September 6, 2019 [Page 25] Internet-Draft TLS Handshake in CBOR March 2019 thus should be considered. Halving the length of this saves 17 bytes in message 2 and 3. Appendix C. EDHOC issues that worry me I still need to actually read the current document. From a quick glance through I have the following issues: o It is limited to four cipher suites of which only two are globally defined. o Need to validate that P-256 can do key agreement correctly with only an X coordinate. Author's Address Jim Schaad Email: ietf@augustcellars.com Schaad Expires September 6, 2019 [Page 26]