Dan, What you suggest, namely, DH for both static and ephemeral keys is what OPTLS was about and this approach is now specified in https://tools.ietf.org/html/draft-ietf-tls-semistatic-dh-01.
I was never too happy with the name semi-static for such protocol, and people may think that if static is bad then semi-static is semi-bad :-) So maybe it should be replaced with something else It is essentially a DH-KEM, namely a KEM implemented via DH. It has the advantage over generic KEMs that g^x sent by the client acts as an ephemeral KEM public key (producing g^xy) and also as an encapsulation under the server's public key (producing g^xs). This shaves one full round trip relative to a generic KEM-based protocol (this applies to the protocols with and without client authentication). Hugo On Thu, Sep 10, 2020 at 11:19 AM Dan Brown <danibr...@blackberry.com> wrote: > *From:* TLS <tls-boun...@ietf.org> *On Behalf Of *Salz, Rich > > Do we need a short RFC saying “do not use static DH” ? > > > > Don’t TLS 0-RTT and ESNI/ECH via HPKE use a type of (semi)static ECDH? If > so, then an RFC to ban static (EC)DH in TLS would need to be very clear > about not referring to these use cases of static ECDH. > > > > My 2c. What about combining static ECDH (instead of signatures) with > ephemeral ECDH, e.g. for more fully deniable authentication? (ECMQV does > this.) (Perhaps this is also similar to the KEMTLS proposal for PQC, > https://ia.cr/2020/534 - still need to study that.) > > > ------------------------------ > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > 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
