Subject: [apps-discuss] Applications Area Directorate Review of draft-ietf-tls-oob-pubkey-09

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 7 Aug 2013 01:40:54 +0000

Document: draft-ietf-tls-oob-pubkey-09
Title: Out-of-band Public Key Validation for Transport Layer Security (TLS)
Reviewer: Bert Greevenbosch
Review Date: 7 August 2013
IETF Last Call Date: until 16 August 2013
IESG Telechat Date: [include if known]
Summary: Given the goal of reducing network usage and processing cost, the Raw Public Key as defined in a draft indeed does a good job. It alone cannot provide the same level of security as PKI, but I think the "Security Considerations" section indeed addresses the related trade-offs in security sufficiently. I think the draft is close to finalised state, but it needs some changes as proposed below.

Major Issues:

(M1) The certificate negotiation (by including client_certificate_type and server_certificate_type in client_hello and server_hello) brings along some security issues. More specifically, as the hello messages are not integrity protected it allows an adversary to change the certificate format options, especially to create a preference towards a weaker certificate format. I suggest to add text about this, recommending that a receiving party verifies that a certificate is indeed in one of the forms it requested. (I can see deployments were an entity has different certificate requirements for different situations, so not advertising a format does not necessarily mean the entity does not support the format.)

(M2) Page 7: "In order to indicate the support of out-of-band raw public keys ...". Are these keys really out-of-band? It seems that the draft focuses on the delivery of Raw Public Keys (RPKs) within an TLS exchange, so it seems that out-of-band is incorrect here. If out-of-band RPK delivery is supported, then how does this work? Does that need any standardisation or is it proprietary by nature? Maybe it is up to the out-of-band delivery method specification to define the used format. The text on page 7 "If the client hello indicates support of raw public keys in the 'client_certificate_type' extension and the server chooses to use raw public keys then the TLS server MUST place the SubjectPublicKeyInfo structure into the Certificate payload." also seems to point at in-band delivery of RPKs.

Minor Issues:

(m1) The title of the draft is misleading. It seems that the document defines a mechanism for key validation, whereas in fact it defines a format and TLS handshake extension for Raw Public Keys. Validation of the key (authentication, binding) is explicitly left out of scope of the draft. I suggest to change the title, e.g. to "Raw Public Key" or "A TLS extension to support Raw Public Keys".

Nits:

(n1) Page 3, I propose to change "As part of the manufacturing process, the embedded device may be configured with the address and the public key of a dedicated CoAP server, as well as a public key for the client itself." to "As part of the manufacturing process, the embedded device may be configured with the address and the public key of a dedicated CoAP server, as well as a public/private key pair for the client itself."

(n2) The "Certificate" struct is an adaptation of its original form in RFC5246. It would be good to say this explicitly.

(n3) On page 4, change "an DER encoded ASN.1 format" to "a DER encoded ASN.1 format".

(n4) On page 4, figure 3, I suggest to change "Digital Signature Algorithm (DSS)" to "Digital Signature Algorithm (DSA)", although DSA indeed is defined in the Digital Signature Standard (DSS).

(n5) On page 5, figure 4, add a comma behind "client_certificate_type".