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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Oct 2013 11:06:35 +0200

Hi Bert,

thanks for your review comments. A few remarks below.

On 08/07/2013 03:40 AM, Bert Greevenbosch wrote:
> 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.)

I added a paragraph about this issue to the security consideration 
section. TLS luckily has a mechanism for dealing with these types of 
attacks by computing a hash of the handshake messages and exchanging it 
in the TLS Finished message.

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

This is indeed an incorrect wording. Thanks for spotting it.
It should read "In order to indicate the support of raw public keys ..."
The out-of-band refers to the validation of the binding between the 
public key and an entity using that public key.

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

When I think about it you are right that the title could be a bit more 
descriptive.

I changed it to "Using Raw Public Keys in Transport Layer Security (TLS) 
and Datagram Transport Layer Security (DTLS)
>
> 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."

Fixed.

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

Fixed. Yaron, who did the SecDir review, also got confused about it.

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

Fixed.

>
> (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).

Fixed.

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

Fixed.

Ciao
Hannes

> _______________________________________________ apps-discuss mailing
> list [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Bert Greevenbosch <[email-masked]>
Date: Tue, 22 Oct 2013 08:41:13 +0000

Hi Hannes,

Excellent, thanks for addressing my comments!

Best regards,
Bert

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: 18 October 2013 17:07
> To: Bert Greevenbosch; [email-masked]; [email-masked]; draft-
> [email-masked]
> Subject: Re: [apps-discuss] Applications Area Directorate Review of
> draft-ietf-tls-oob-pubkey-09
> 
> Hi Bert,
>