Hi Tony thanks for sharing your thoughts.
It sounds a bit like you want to use public key crypto but without the overhead of certificates. If that's true then you might find https://tools.ietf.org/html/rfc7250 useful. Ciao Hannes On 10/26/2017 05:03 PM, Tony Putman wrote: > Hi all, > > > > I've recently started working in the IoT space and wish to standardize > > our transport security by introducing the use of DTLS. It seems that the > > usual practice is to use PSK for mutual authentication, but I'm not > > happy with this solution. A breach of server security allows not only > > server impersonation, but also, due to the PSK symmetry, client > > impersonation. > > > > We are already using static ECDH keys for authentication (at the > > application layer), so I looked for a way to make use of these in DTLS > > and came up with the following solution using (D)TLS 1.2: > > > > Assume the client is provisioned with an Id, a corresponding private key > > 'c_id' and a corresponding server public key 'S_id' (the server key may > > be different for each Id or it may be common across all clients); the > > server has a list of client public keys 'C_id' and corresponding server > > private key(s) 's_id'. This OOB pre-provisioning corresponds to that of > > a symmetric PSK. > > > > The TLS 1.2 message exchange is identical to that for a TLS_(EC)DHE_PSK > > handshake as in RFC4279. This solution applies to both DH/DHE keys and > > to ECDH/ECDHE keys. The IoT solutions will typically use ECDH/ECDHE, so > > the following explanation focuses on the EC variant. The messages are: > > > > Client Server > > ------ ------ > > ClientHello -----> > > ServerHello > > ServerKeyExchange > > <----- ServerHelloDone > > ClientKeyExchange > > ChangeCipherSpec > > Finished -----> > > ChangeCipherSpec > > <----- Finished > > Application Data <----> Application Data > > > > The way this differs from TLS_ECDHE_PSK is only in the generation of > > the premaster secret. Suppose the ECDHE keys are 'a' (private) and 'A' > > (public) from the server; and 'b' (private) and 'B' (public) from the > > client. Then the client and server form the premaster secret in a struct > > with the following information (where [x]Y represents multiplication of > > the point 'Y' by the scalar 'x'): > > Client Premaster: [b]A || [c_id]A || [b]S_id > > Server Premaster: [a]B || [a]C_id || [s_id]B > > > > The first term provides PFS even if both client and server static > > private keys become known; the second term provides client > > authentication even if server keys are compromised; and the third term > > provides server authentication even if client keys are compromised. > > > > My questions to the list are: > > ============================= > > 1. Has anything similar to this been proposed before (I found nothing)? > > 2. Can anyone see a problem with this formulation? > > 3. Is there any interest in this (I would be happy to write an ID)? > > > > The reason that I advocate this for IoT devices over signature schemes > > is that the code for ECDH will already have to be present if modern > > key agreement methods with PFS are to be used. So this solution uses > > fewer resources than ECDHE together with a signature scheme in terms of > > code space and RAM, and improves execution speed (I believe ECDH is about > > twice as fast as equivalent signature generation/checking). Also, fewer > > messages are needed and the messages are smaller (even if using raw keys). > > > > A constraint not made explicit above is that the (EC)DHE keys must use > > the same group/curve parameters as define the preshared keypairs. Since > > the ClientHello does not contain any client information, this means the > > server endpoint (e.g. as defined by SNI) can only support a single form > > of preshared keypair. This could be improved on in TLS 1.3. > > > > I don't believe that this constraint is serious, because this method is > > designed to be used in the same scenarios as PSK; that is, where client > > and server have an OOB method of receiving authentication credentials > > from a common source. In this situation, the server is unlikely to be > > serving clients which use multiple types of preshared keypairs, though > > it does mean that if the keypair format is changed (e.g. strengthened) > > during the life of an IoT product then a new server endpoint will have > > to be defined for the upgraded products. > > > > Additionally, this method is proposed to prevent the leaking of client > > credentials if the server is compromised. This means that the client > > private key must be high-entropy: this method is not suitable for keys > > derived from passwords or other low-entropy sources. > > > > Lastly, I have had a look at extending this to TLS 1.3 and it seems > > pretty straightforward; however, there is no urgency and I feel we can > > defer that to after the TLS 1.3 draft has been approved. > > > > Regards, > > Tony > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
