Last Call Review of draft-ietf-tls-oob-pubkey-09

Request Review of draft-ietf-tls-oob-pubkey
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-08-16
Requested 2013-08-02
Authors Paul Wouters, Hannes Tschofenig, John Gilmore, Samuel Weiler, Tero Kivinen
Draft last updated 2013-08-08
Completed reviews Genart Early review of -09 by Christer Holmberg (diff)
Genart Telechat review of -10 by Christer Holmberg (diff)
Secdir Last Call review of -09 by Yaron Sheffer (diff)
Opsdir Telechat review of -10 by Linda Dunbar (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Review review-ietf-tls-oob-pubkey-09-secdir-lc-sheffer-2013-08-08
Reviewed rev. 09 (document currently at 11)
Review result Has Nits
Review completed: 2013-08-08


I have reviewed this document as part of the security directorate's 

ongoing effort to review all IETF documents being processed by the IESG. 

These comments were written primarily for the benefit of the security 

area directors. Document editors and WG chairs should treat these 

comments just like any other last call comments.

This document adds into TLS support for bare public keys (as opposed to 

keys wrapped in certificates). The main use case cited is constrained 

devices that get their trust anchors in an out-of-band manner (e.g. - 

horror - embedded in their software) as a set of trusted public keys.

Summary: this document is almost ready for publication, but needs 

several clarifications and text improvements. Since some of the missing 

pieces revolve around authentication, we may even need another last call 

if (as discussed in Berlin) the document is to be merged or coordinated 

with the Channel ID work.


• 1: "an out-of-band mechanism is also used to bind the public key to 

the entity presenting the key" - this text is strange. Obtaining the 

public key can be OOB, but binding to the TLS identity is part of the 

protocol negotiation. This sentence sounds as if we're trying to avoid a 

"MUST authenticate".

• More generally, if the peer has an OOB way to obtain the public key 

(it has to have one, otherwise it wouldn't be able to bind it to an 

identity), why are we sending the full public key in the handshake, 

rather than only a fingerprint? Reading further (in the Acknowledgements 

section) it would appear this question has already been discussed in the 

WG. Shouldn't this option, or the interaction with "cached info", be 

mentioned here?

• 3, Fig. 1: why do we support a sequence of public keys? What is the 

semantics? If the semantics is that you can authenticate using *one* of 

the provided keys, then why not support mixing public keys and 

certificates, or RSA with ECDSA public keys?

• 3: "These extension MUST be omitted if the client only supports X.509 

certificates" (note the typo, should be "this") - this is IMO 

overspecified, especially since the client can send a list of length 1 

containing only the X.509 identifier.

• "The 'server_certificate_type' in the client hello indicates the type 

of certificates" - this is probably a typo, and should be "types", i.e. 

a list.

• In the two paragraphs discussing the semantics of the extensions, the 

word "supported" is used very loosely, sometimes referring to what you 

can send and sometimes to what you can accept. I suggest to clarify this 

point, and I suspect that the last sentence ("if the server does not 

send...") which is currently unclear will have to be corrected.

• 4.1: " MUST include the 'client_certificate_type' and 

'server_certificate_type' extensions" - do you really have to include 

both extensions? What if only the server presents a public key?

• 4.2, bullet #2: does the server need to have a cert type in common 

with the client, or just in common with the types that the client 

specified in the "server cert type" extension?

• 5, Fig. 8: does the client really have to indicate support of the 

server sending an X.509 cert? What if the client omits the 

server_certificate_type extension?

• 6: what exactly is meant by "to check the status of that binding"?

• 7: at least in the HTML version of this draft, the 

value/description/reference lines appear *before* the introductory sentence.