Subject: [Dtls-iot] Certificate Profiling

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 Mar 2015 17:04:50 +0200

Hi all,

Section 6.3 of draft-ietf-dice-profile-10 discusses the recommendations
for use with certificates.
While the current text restricts the use of certificates quite a bit I
got feedback that the current text still leaves several aspects untouched.

Here is a proposal of further recommendations:

* TLS/DTLS offers a lot of freedom for using ECC curves. I would suggest
to restrict the use of RFC4492-defined ECC ciphersuites to named curves
only.

We could furthermore say that the current recommendation is to use
secp256r1 since this is also what is recommended in CoAP. Furthermore,
the CoAP specification recommends the use of uncompressed points.

We should note that standardization for Curve25519 (for ECDHE) is
ongoing (see draft-irtf-cfrg-curves-01) and support for it will likely
be required in the near future.

From the content in Table 1 it should be obviously that the used ECDSA
keys in a certificate are signed with with an ECDSA and that's true not
only for the end-entity certificates but all other certificates in the
chain, including the CA certs have to have that property. There are
various types of algorithms that are used for digital certificates and
we make use of ECDSA for signing certificates. I believe it is
worthwhile to point this out again and make readers aware of this
circumstance since most CA certs today are actually signed with RSA or DSA.

* The algorithm for verifying the service identity, as described in RFC
6125, is essential for ensuring proper security when certificates are used.

It basically says the following:

  1.  The client constructs a list of acceptable reference identifiers
      based on the source domain and, optionally, the type of service
      to which the client is connecting.

  2.  The server provides its identifiers in the form of a PKIX
      certificate.

  3.  The client checks each of its reference identifiers against the
      presented identifiers for the purpose of finding a match.

  4.  When checking a reference identifier against a presented
      identifier, the client matches the source domain of the
      identifiers and, optionally, their application service type.

I would like to stress the point that certificate usage without
comparing the reference identifier against the presented certificate
ruins the security.

It would be useful to state that this algorithm description and the text
in RFC 6125 assumes that fully qualified DNS domain names are used. This
would be the case for servers that are located in the cloud but not
necessarily true for servers located somewhere in the local network that
do not have their names in the DNS. It would also not be true for
devices that use EUI-64 names, as suggested for clients.

It might also be useful to say whether a DNS-ID, SRV-ID, URI-ID, or a
CN-ID is used. The preference is for DNS-IDs and URI-IDs and my
recommendation for the document would be:

 a) MUST NOT use CN-IDs
 b) MUST NOT contain wildcards
 c) MUST NOT include more than one DNS-ID

Regarding the use of DNS names we also have to support internationalized
domain names even though that is not stated anywhere.

Anything else that would be worthwhile to mention?

What are your thoughts?

Ciao
Hannes

---

From: Michael StJohns <[email-masked]>
Date: Mon, 30 Mar 2015 17:48:01 -0400

> to restrict the use of RFC4492-defined ECC ciphersuites to named curves
rfc5480 effectively does this.

> the CoAP specification recommends the use of uncompressed points.

I think this is a good default and close to what's available or will be 
available hardware wise.

> be required in the near future.

this may be a non-starter until there is also an ecdsa equivalent also 
standardized - unless you mean to use this only for ECDHE part of the 
key negotiation rather than something bound into a certificate?

More later.

Mike

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 31 Mar 2015 14:14:15 +0200

Hi Mike,

thanks for your quick response.

> rfc5480 effectively does this. 

Yes, saying that only named curves are used and then pointing to RFC
5480 (and to secp256r1 in particular).

> I think this is a good default and close to what's available or will be

Good to hear.

> key negotiation rather than something bound into a certificate?

It would only be an informational reference to the ongoing work to give
an early warning to implementers that there is something coming.

The work on ed25519 is in progress as well but not as far along as
Curve25519.

Ciao
Hannes