Subject: Re: [6tisch] questions about draft-richardson-security-6top

From: Malisa Vucinic <[email-masked]>
Date: Fri, 15 May 2015 18:21:42 -0700

[the rest of the discussion shifted to [6tisch] joining security start and end states]

> On 13 May 2015, at 09:43, Michael Richardson <[email-masked]> wrote:
> 

> So, here, I think you are imagining using some kind of pre-provisioned
> session-resumption ticket to replace the initial TLS handshake.
> I think that this is something that one could imagine: the initial TLS
> handshake is done at the factory, and then, based upon a bearer token,
> the factories' MASAS (see draft-pritikin-anima-bootstrapping-keyinfra-01)
> might return that.
> Is this what you are thinking about?

So this would be a clean way of doing what I had in mind. I guess an obvious concern in this case would be how the initial TLS handshake can be done at the factory during mass production in a scalable manner. 

I was thinking more of something like this: 

Consider the joining node JN_1 which was imprinted with symmetric key K_1. MASA keeps track which JNs were imprinted with which keys. MASA and all of its nodes use the recommended ticket format from Section 4 of RFC 5077. Nodes get shipped, deployed. 

1. JN_1 initiates the join process with the local network, sends its IDevID via JA to the JCE. 

2. JCE asks MASA about JN_1 over https. MASA’s factory sold the nodes to the owner of JCE so MASA already knows that JCE is the rightful owner of JN_1. 

3. Then, MASA can generate 48 random bytes to be used as the master secret for session between JCE and JN_1. Obviously, MASA is a trusted third party. MASA generates the rest of the ticket, using as key_name the fingerprint of K_1 and also includes the cipher suite knowing what ciphers JN_1 supports, as it manufactured it after all. MASA encrypts the ticket using K_1. 

4. MASA sends to the JCE the encrypted ticket and the plaintext version of it (this is what an RFC 5077 client possesses anyways, it does however not know K_1). 

5. JCE can now start the abbreviated handshake with JN_1, including the encrypted ticket in ClientHello.

6. JN_1 decrypts the ticket using K_1, takes the session state from the ticket as normally done in RFC 5077 and verifies that it supports the cipher. Then it can continue the abbreviated handshake with JCE.

If MASA decides to share K_1 with JCE, JCE can also generate the session ticket without any involvement of MASA. All in all, by making an assumption on out-of-band exchange of supported ciphers and MASA as a trusted third party, I think one could get the DTLS handshake done in 4-6, instead of 10-12 packets. Does that make sense and do you think it is worth the trouble?