Subject: [Ace] Independent I-D for new TLS authentication (triple-ECDH)

From: Tony Putman <[email-masked]>
Date: Wed, 6 Dec 2017 14:41:49 +0000

Hi,

I recently produced an I-D for a TLS authentication method using pre-shared ECDH asymmetric keys, which I believe will be useful for constrained environments.  IMHO the key benefits are:
- a breach of server security does not result in client impersonation (unlike PSK)
- a single EC algorithm is used (ECDH), though it is used several times
- static public keys are not exchanged, so protocol messages are smaller

I would like to know if people working with constrained devices agree with me that these are useful benefits and whether people feel that this is worth pursuing.

The draft is at https://datatracker.ietf.org/doc/draft-putman-tls-preshared-ecdh/

Thanks,
Tony

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 6 Dec 2017 16:04:37 +0100

On 2017-12-06 15:41, Tony Putman wrote:
> Hi,
> 
> I recently produced an I-D for a TLS authentication method using 
> pre-shared ECDH asymmetric keys, which I believe will be useful for 
> constrained environments.  IMHO the key benefits are:
> 
> I would like to know if people working with constrained devices agree 
> with me that these are useful benefits and whether people feel that this 
> is worth pursuing.
> 
> The draft is at 
> https://datatracker.ietf.org/doc/draft-putman-tls-preshared-ecdh/
> 
> Thanks,
> 
> Tony
> 
> 

Hi Tony,

could you explain the differences between your draft and the (D)TLS 
handshake with raw public keys (https://tools.ietf.org/html/rfc7250)?

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Dec 2017 15:06:43 +0000

Hi Tony,

If I understand your idea correctly then you have just re-invented the raw public key concept defined in https://tools.ietf.org/html/rfc7250

Ciao
Hannes

From: Ace [mailto:[email-masked]] On Behalf Of Tony Putman
Sent: 06 December 2017 14:42
To: [email-masked]
Subject: [Ace] Independent I-D for new TLS authentication (triple-ECDH)

Hi,

Thanks,
Tony

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Tony Putman <[email-masked]>
Date: Wed, 6 Dec 2017 15:32:59 +0000

Ludwig, Hannes,

The differences with RFC7250 are twofold:
 1. The raw public keys are not exchanged in the handshake sequence. Even with cached info (RFC7924), a fingerprint of the certificate (or raw public key) is exchanged. Also, a ClientVerify message is needed if mutual authentication is required (which is automatic with 3ECDH). These extra elements add to the size of the handshake exchange. They also identify the sender (whereas my draft encrypts the client identity), which can be an issue if privacy of the session endpoints is important. 

 2. ECDH cannot be used as a raw public key; instead ECDSA or EdDSA is needed. But ECDH is also needed if the handshake includes perfect forward secrecy (highly recommended/mandatory, depending on usage). Therefore the client has to implement two algorithms and may need to implement fast versions of both of them to reduce latency in session establishment. Using 3ECDH, the client only needs a single algorithm; if EdDSA is needed anyway (e.g. for code signing), then a slow version may be used which saves code-space and data-space. 
-- 
Tony

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
> Hi Tony,
> 
> https://www.ietf.org/mailman/listinfo/ace

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Dec 2017 15:42:46 +0000

Hi Tony,

Remarks below.

-----Original Message-----
From: Tony Putman [mailto:[email-masked]]
Sent: 06 December 2017 15:33
To: Ludwig Seitz; Hannes Tschofenig
Cc: [email-masked]
Subject: RE: [Ace] Independent I-D for new TLS authentication (triple-ECDH)

Ludwig, Hannes,

[Hannes] It is true that the raw public keys are exchanged unless you use cached info where only the fingerprint of the client side raw public key is provided. For the privacy aspect you are also correct for TLS / DTLS 1.2 but 1.3 changes this procedure.

[Hannes] It is true that the raw public key RFC does not use long-term ECDH keys but instead uses those only in an ephemeral way.  I would consider a design feature rather than a bug.

[Hannes] Thanks for clarifying your design. What I am wondering is, however, whether the issues you raised are a concern in deployments (I haven't heard them) and whether it makes sense to continue working on TLS / DTLS 1.2 when 1.3 is already looming on the horizon where the raw public key mode is nicely integrated as well.

Ciao
Hannes

--
Tony

> From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz Hi
> Tony,
>

---

From: Tony Putman <[email-masked]>
Date: Wed, 6 Dec 2017 16:52:56 +0000

Hi Hannes,

From: Hannes Tschofenig [mailto:[email-masked]]
> [Hannes] It is true that the raw public key RFC does not use long-term ECDH keys
> but instead uses those only in an ephemeral way.  I would consider a design
> feature rather than a bug.

I'm certainly not calling it a bug, but it unavoidably results in the use of two different algorithms. How important this is to people is one of the things that I'm asking about.

> [Hannes] Thanks for clarifying your design. What I am wondering is, however,
> whether the issues you raised are a concern in deployments (I haven't heard
> them)

Internally, I am working with a number of product teams, and their products have different capabilities. What drove me to produce this I-D was a desire to push non-PSK security into the lowest-powered devices possible. So effectively I am trying to minimise the processing costs of (D)TLS authentication. I am curious to know how many people face the same sort of pressures. 

> [Hannes] and whether it makes sense to continue working on TLS / DTLS 1.2 when
> 1.3 is already looming on the horizon where the raw public key mode is nicely
> integrated as well.

I have read up on (D)TLS 1.3, but don't have any practical experience with it yet. Even so, I think that the advantages I enumerated (shorter messages, single algorithm, but not the privacy concerns) are fundamental and will also apply to (D)TLS 1.3. In other words, I believe that 3ECDH authentication will still offer advantages for constrained devices. If there is interest, then I'd be happy to work on the (D)TLS equivalent 3ECDH authentication exchange. 
-- Tony