Hi Hannes, From: Hannes Tschofenig [mailto:[email protected]] > [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 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. _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
