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

[Jonathan Simon <[e-mail]>]

For minimal, there's a link key and a DTLS session to establish. Maybe
something else I'm missing.

In a typical WirelessHART network, there are multiple end-to-end CCM*
security sessions,  run-time slotframes and links, mesh-under routing
information, set one or more timing parents, a bunch of timers (e.g. for
statistics collection)  -  somewhere ~ 5-600 bytes, but it isn't
necessarily as compact as CoAP could be.

Jonathan

On Mon, Nov 3, 2014 at 6:09 PM, Rene Struik <[e-mail]> wrote:

>  Hi Jonathan:
>
> Do you have some ballpark numbers for the size of configuration info to
> play around with? Please see below (my Que to you of Fri Oct 31, 2014).
>
> Best regards, Rene
>
> On 10/31/2014 12:26 PM, Rene Struik wrote:
>
> 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
> <http://cp.mcafee.com/d/FZsScxMOrhohvKUeLuVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKr73DSnDS7-LOr0VBBPHTbFIEEYMY--OPORQr8FGEEFYG7DR8OJMddECQPt-jpoKMC--OCrKr01i-rL00s4O-NIjAp_01oVelb4OZfIT6kOSmrz7UjNmx6ZXLes3zsqjyT8HTxYMkh4-ndIKfe3zobZ8Qg6BJOsGm9BWvpKcFBziWq806V-VEVd40BYpCy2AxjW6y3o86y0hHa4E4jh0WvkNgS-Ur0gdCUmki>
> 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) <
> [e-mail]> wrote:
>
>   Hello Jonathan:
>
> Are you suggesting that we define a “6LoWPAN compression” for a
> certificate?
>
>  Cheers,
>
> Pascal
>
>   *From:* 6tisch-security [mailto:[e-mail]
> <[e-mail]>] *On Behalf Of *Jonathan Simon
> *Sent:* vendredi 31 octobre 2014 00:31
> *To:* [e-mail]
> *Subject:* [6tisch-security] X.509 Cert sizes and joining flows
>
>  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
> <http://cp.mcafee.com/d/k-Kr3x8pdEI8I3DXKce6XCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVJYwyUO-M_R-juoKODRXBQSnzhPP0VNZ5zBHFShjlhhpVkffGhBrwqrhdECXYyMCY-ehojd79KVI05bVKY01MjbX6NehDY05zAVkIjbQ-PspjbppKcvxf5q4rTKCPMedHj9JAfzc5mBiRundEIILK6Mmd96y0QJKjBiNcLjXdNBcIqnjh00TfTd79Ew4LzcQgkAavgQgr10Qg2dpgB0yq87jWCa6TT3u8qvt4qz>
>
>  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
>
>
>
>
> This body part will be downloaded on demand.
>
>
>
> --
> email: [e-mail] | Skype: rstruik
> cell: [phone] | US: [phone]
>
>
>
> --
> email: [e-mail] | Skype: rstruik
> cell: [phone] | US: [phone]
>
>


-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
[phone]
[phone] FAX
[e-mail]

**LINEAR TECHNOLOGY CORPORATION**
*****Internet Email Confidentiality Notice*****
 This e-mail transmission, and any documents, files or previous
e-mail messages attached to it may contain confidential information that
is legally privileged. If you are not the intended recipient, or a
person responsible for delivering it to the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of any of
the information contained in or attached to this transmission is
STRICTLY PROHIBITED. If you have received this transmission in error,
please immediately notify me by reply e-mail, or by telephone at (510)
400-2936, and destroy the original transmission and its attachments without
reading or saving in any manner. Thank you.