Subject: [6tisch-security] X.509 Cert sizes and joining flows

From: Jonathan Simon <[email-masked]>
Date: Thu, 30 Oct 2014 16:30:53 -0700

I voiced my concern a while back about certificate exchanges making joining really slow:

http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00023.html

There I assumed a 300-byte compressed cert. Obviously, a 1500-byte cert is going to be 5x worse.

One reason the certs are big is that there is a lot of stuff we don't need, or may not need, or could compress a la 6lo.

Version: could be elided?
Serial number: Maybe this is the EUI of the device (elidable).
Signature:  ~80 bytes for secp256r1 (128-bits protection).  Needs to cover the full expanded X.509 fields.
Issuer: may be compressible?
Validity: 26 bytes - do we need to be able to revoke certs, or could this be handled on an app level.
Subject: can be empty
SubjectPublicKeyInfo: contains an algorithm definition (which can be elided if we only use one) or compressed (if we support a few), and the public key (32 bytes)
IssuerUniqueIdentifier: optional
SubjectUniqueIdentifier: optional
Extensions: optional, but if we don't include a subject we might want to support subjectAltName, again probably in compressed form.
SignatureAlgorithm: can be elided if we only use one or compressed if we support a few
Other fields?

Point is, I think we can get this to fit into 2 packets and I think that should be our target unless there’s a really a compelling reason to include fields.

-- 
Jonathan Simon

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 31 Oct 2014 10:17:24 +0000

Hello Jonathan:

Are you suggesting that we define a "6LoWPAN compression" for a certificate?

Cheers,

Pascal

From: 6tisch-security [mailto:[email-masked]] On Behalf Of Jonathan Simon
Sent: vendredi 31 octobre 2014 00:31
To: [email-masked]
Subject: [6tisch-security] X.509 Cert sizes and joining flows

Point is, I think we can get this to fit into 2 packets and I think that should be our target unless there's a really a compelling reason to include fields.

--
Jonathan Simon

---

From: Jonathan Simon <[email-masked]>
Date: Fri, 31 Oct 2014 08:48:04 -0700

Pascal -

Yes - I don’t know where the effort belongs though.  I think we need a standard way of compressing an X.509 cert with the goal of fitting it in under 200 bytes. Maybe this compressed cert is only used at joining in 6TiSCH, or maybe border routers can compress/decompress along with the 6LoWPAN header so we can use it end-to-end.

— 

Jonathan 

On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

> Hello Jonathan:
>  
> Are you suggesting that we define a “6LoWPAN compression” for a certificate?
>  
> Cheers,
>  
> Pascal
>

---

From: Rene Struik <[email-masked]>
Date: Fri, 31 Oct 2014 12:26:31 -0400

Hi Jonathan:

The join protocol includes (1) authentication; (2) authorization; (3) 
configuration steps.
Without hands tied behind the back with protocol design, I anticipate 
the main communication overhead of the join protocol to be with the 
configuration step (#3) and *not* with the underlying authenticated key 
agreement scheme (#1). Here, configuration relates both to security 
manager to joining node info and vice-verse.

See also item #a of my May 20, 2014 email -- _which is still outstanding 
BTW._
Que - Would you like to take this one on? {as first step, what about 
providing a rough number, say, 1500 bytes [fill in correct number here]}.

Some brief feedback on certificate sizes:
a) certificates should definitely have policy fields, including key 
validity period.
b) certificate compression is of course possible, including that of 
certificate issuer (whether the latter would be prudent remains to be seen).
c) some of your figures are too pessimistic, e.g., P-256 keys are 65 
bytes in uncompressed format; ECDSA signatures are 64-bytes. EUI-64 
could be used as SubjectPublicKey field, but depends on naming issues 
(see item #b of my May 20, 2014 message).
d) there is no absolute need to use X509 certs, which would add 
considerable freedom to cut down overhead.

I estimate one can implement the authentication scheme (#1) with one or 
two 802.15.4e frames in each protocol flow (assuming cert chains of 
length one).

Email of May 20, 2014 with outstanding issues:
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
a) Packet sizes:
get more info on packet sizes configuration parms, as w/HART uses. Note 
RS: during call, Tom Phinney suggested contacting Wally Bratt from HART 
Comm. Foundation for this). Note RS: Shouldn't, e.g., Dust Networks have 
info on packet sizes/structure?; ISA SP100.11a metrics would also help, 
as would ZigBee 2.0 config parms. Does, e.g., Cisco have useful data 
points here?
b) Device Ids:
With industrial control, network manager would look up "tag name" device 
in pre-configured database. Details on tag name syntax, how assigned, 
and how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom 
Phinney could point at tag name syntax and lifecycle aspects here?

On 10/31/2014 11:48 AM, Jonathan Simon wrote:
> Pascal -
>
> Yes - I don’t know where the effort belongs though.  I think we need a 
> standard way of compressing an X.509 cert with the goal of fitting it 
> in under 200 bytes. Maybe this compressed cert is only used at joining 
> in 6TiSCH, or maybe border routers can compress/decompress along with 
> the 6LoWPAN header so we can use it end-to-end.
>
> —
>
> Jonathan
>
> On Oct 31, 2014, at 3:17 AM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> Hello Jonathan:
>> *From:*6tisch-security [mailto:[email-masked]]*On 
>> Behalf Of*Jonathan Simon
>> *Sent:*vendredi 31 octobre 2014 00:31
>> *To:[email-masked] <mailto:[email-masked]>
>> *Subject:*[6tisch-security] X.509 Cert sizes and joining flows
>> <http://cp.mcafee.com/d/k-Kr3x8pdEI8I3DXKce6XCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVJYwyUO-M_R-juoKODRXBQSnzhPP0VNZ5zBHFShjlhhpVkffGhBrwqrhdECXYyMCY-ehojd79KVI05bVKY01MjbX6NehDY05zAVkIjbQ-PspjbppKcvxf5q4rTKCPMedHj9JAfzc5mBiRundEIILK6Mmd96y0QJKjBiNcLjXdNBcIqnjh00TfTd79Ew4LzcQgkAavgQgr10Qg2dpgB0yq87jWCa6TT3u8qvt4qz>
>> One reason the certs are big is that there is a lot of stuff we don't 
>> need, or may not need, or could compress a la 6lo.
>> SubjectPublicKeyInfo: contains an algorithm definition (which can be 
>> elided if we only use one) or compressed (if we support a few), and 
>> the public key (32 bytes)
>> Extensions: optional, but if we don't include a subject we might want 
>> to support subjectAltName, again probably in compressed form.
>> Point is, I think we can get this to fit into 2 packets and I think 
>> that should be our target unless there’s a really a compelling reason 
>> to include fields.
>> -- 
>> Jonathan Simon
>
>
>
> This body part will be downloaded on demand.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Michael Richardson <[email-masked]>
Date: Fri, 31 Oct 2014 14:33:08 -0400

> the 6LoWPAN header so we can use it end-to-end.

There is no reason the certificate compression needs to be in *6lo*
it can be part of DTLS.

A 256 EC public key takes 88 bytes raw.
Running gzip on that file expands it to 114 bytes :-)
(not surprising, it ought be rather random, gzip header overhead)

Turning that into a self-signed certificate with a CN=12347624:

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            86:52:cb:df:30:2c:88:c1
        Signature Algorithm: ecdsa-with-SHA1
        Issuer: CN=12347624
        Validity
            Not Before: Oct 31 18:28:09 2014 GMT
            Not After : Nov 30 18:28:09 2014 GMT
        Subject: CN=12347624
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
            EC Public Key:
                pub:
                    04:4c:24:f9:e5:8d:ee:e5:b9:da:23:51:d2:fb:35:
                    83:4d:71:69:57:ca:78:7e:3c:f9:a7:cc:ed:b5:e3:
                    12:cd:d7:a1:49:9d:7f:0c:b4:47:07:6e:6b:d1:b6:
                    5d:26:90:b5:d9:b5:af:18:d3:42:8d:fc:11:93:58:
                    37:03:be:c9:cc
                ASN1 OID: secp256k1
    Signature Algorithm: ecdsa-with-SHA1
        30:44:02:20:15:a6:93:d1:9f:81:65:53:34:d7:9c:28:81:73:
        d6:39:c6:3d:e1:ed:65:31:67:9c:5a:16:6c:12:ae:f6:09:6f:
        02:20:42:af:3a:07:94:15:cd:c9:f0:9a:b2:65:7c:5e:c6:55:
        61:ee:35:e3:4f:39:53:29:2c:5e:31:15:8b:40:ec:42

428 bytes in base64 format, 275 bytes binary, gzip'ed 274 bytes!
-----BEGIN CERTIFICATE-----
MIIBDzCBuAIJAIZSy98wLIjBMAkGByqGSM49BAEwEzERMA8GA1UEAxMIMTIzNDc2
MjQwHhcNMTQxMDMxMTgyODA5WhcNMTQxMTMwMTgyODA5WjATMREwDwYDVQQDEwgx
MjM0NzYyNDBWMBAGByqGSM49AgEGBSuBBAAKA0IABEwk+eWN7uW52iNR0vs1g01x
aVfKeH48+afM7bXjEs3XoUmdfwy0Rwdua9G2XSaQtdm1rxjTQo38EZNYNwO+ycww
CQYHKoZIzj0EAQNHADBEAiAVppPRn4FlUzTXnCiBc9Y5xj3h7WUxZ5xaFmwSrvYJ
bwIgQq86B5QVzcnwmrJlfF7GVWHuNeNPOVMpLF4xFYtA7EI=
-----END CERTIFICATE-----

I don't think it matters what protocol one uses for join; it won't get a lot
smaller than this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-