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

[Rene Struik <[e-mail]>]

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) 
> <[e-mail] <mailto:[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]]*On 
>> Behalf Of*Jonathan Simon
>> *Sent:*vendredi 31 octobre 2014 00:31
>> *To:*[e-mail] <mailto:[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]