Re: [secdir] SecDir review of draft-ietf-tls-oob-pubkey-09

[Hannes Tschofenig <[e-mail]>]

Hi Yaron,

thanks for the review.

A few remarks below.

On 08/06/2013 07:52 PM, Yaron Sheffer wrote:
> 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.
>
> Details
>
> • 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".

That's the best wording I came up with.

I believe the term "authentication" does not really capture some of the 
scenarios well enough.

Take the definition of authentication (from the handbook of applied 
cryptography):

"
Entity authentication is the process whereby one party is assured 
(through acquisition of corroborative evidence) of the identity of a 
second party involved in a protocol, and that the second has actually 
participated (i.e., is active at, or immediately prior to, the time the 
evidence is acquired).
"

For example, think about many of the cases where a fingerprint is 
printed on the back of your device. There, a human verifies it 
(out-of-band) but I am not sure I would call this 'identity'.

But maybe I am interpreting the term 'authentication' a bit too strictly 
here.




> • 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?

I added a note about this aspect into the introduction and 'yes' this 
issue was discussed and the group made the decision to put the 
functionality into two separate documents. I would see it as a document 
management type of action. The argument was that the fingerprinting 
approach was broader applicability beyond just raw public key and that's 
obviously correct.

> • 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?

The description may be a bit misleading. The message of Figure 1 is that 
we carry the raw public key in the Certificate payload. We have to carry 
it somewhere and that's what we do. In fact, that's not what we came up 
with but this was already done by prior work on the PGP stuff. You could 
call this part of the write-up background material but I had to include 
it since otherwise we have this dependency with the PGP document, which 
we wanted to avoid.

I did, however, change the writeup of the section to improve 
readability. I hope it is clearer now.

> • 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.

You are right. I have been wondering myself whether I had gone a bit too 
far here.


> • "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.

Good catch. Yes, it should be types.

> • 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.

I changed the wording in an attempt to improve clarity.

> • 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?

I changed it. Yes, it is not useful to send an empty extension.

> • 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?

Bullet 2 talks about certificate type.

For example, if the server only supports X.509 certificates and the 
client only raw public keys then there is obviously a problem.

> • 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?

As currently specified, it has to indicate the supported certificate 
types (even if it is a X.509 certificate). Of course, we could say that 
if the client only supports an X.509 certificate for the 
server_certificate_type extension then it can be omitted.


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

With X.509 certificates the binding between the public key and the 
identity is accomplished with the cert and the revocation mechanism. 
Since this is now done out-of-band the security ADs wanted to have a 
sentence added that this binding has to be fresh.

Does this make sense?


> • 7: at least in the HTML version of this draft, the
> value/description/reference lines appear *before* the introductory
> sentence.

You are right. Interesting. It is correct in the TXT version.

Ciao
Hannes

>
> Thanks,
> Yaron
>