Subject: [saag] PQC in ZRTP (RFC6189) and hybrid KEM

From: Johan Pascal <[email-masked]>
Date: Tue, 16 Nov 2021 22:31:44 +0100

Dear Saag,

on Roman's advice, I post on this list to
mention the need for an update to ZRTP in order to support
Post-Quantum Crytography. RFC6189 was an individual submission
and as far as I know no active WG is maintaining this protocol.

ZRTP is based on (EC)DH and requires a deep
rework to support the KEM interface used by the NIST PQ key
exchange algorithms. I started working on this topic, my next
step would be to submit am I-D updating RFC6189 but I'm far from
it so if someone is interested let me know and I can share the
preliminary analysis to start a discussion.

Side note: The PQC version of ZRTP should
actually use an hybrid key exchange using both (EC)DH and PQ-KEM
in parallel. Every protocol using key exchange/encapsulation
algorithm and willing to transition toward PQC have to deal with
this problem so I think it would be more effective to address it
in a specific document that would describe:

- how to implement a KEM from X25519/X448 or
others (EC)DH algorithms

- how to combine the output of two or more
KEMs to provide an hybrid one that would be seen from the
protocol level (like ZRTP for example) as a single KEM.

Some combiners suggestions can be found for
example in this publication https://eprint.iacr.org/2018/903.pdf

The idea would be to avoid repeating the
hybrid KEM description in various documents and focus the
discussions on that specific matter in one central point.

Regards,

Johan

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Nov 2021 13:51:34 -0800

Hi Johann,

As you say, there are some common design questions with any protocol which
wants to graft PQ onto DH in a hybrid mode. There is already a fair amount
of work in this in TLS (
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/), though it
looks less like making ECDH act like a KEM and more often making the KEMs
act like ECDH. I'm honestly not sure how much new work there is to do here;
over in TLS we're mostly waiting for NIST. I do think it would be helpful
to have CFRG or the like specific a PQ algorithm but I'm not sure a generic
algorithm describing hybrid will help that much, as opposed to having that
last mile be protocol specific

Process-wise, the IETF is not maintaining ZRTP, so you would probably need
to do an individual submission or send it to the ISE if you want to update
it.

-Ekr

On Tue, Nov 16, 2021 at 1:32 PM Johan Pascal <[email-masked]>
wrote:

> Dear Saag,
>
> on Roman's advice, I post on this list to mention the need for an update
> to ZRTP in order to support Post-Quantum Crytography. RFC6189 was an
> individual submission and as far as I know no active WG is maintaining this
> protocol.
>
> ZRTP is based on (EC)DH and requires a deep rework to support the KEM
> interface used by the NIST PQ key exchange algorithms. I started working on
> this topic, my next step would be to submit am I-D updating RFC6189 but I'm
> far from it so if someone is interested let me know and I can share the
> Side note: The PQC version of ZRTP should actually use an hybrid key
> exchange using both (EC)DH and PQ-KEM in parallel. Every protocol using key
> exchange/encapsulation algorithm and willing to transition toward PQC have
> to deal with this problem so I think it would be more effective to address
> it in a specific document that would describe:
>
> - how to implement a KEM from X25519/X448 or others (EC)DH algorithms
>
> - how to combine the output of two or more KEMs to provide an hybrid one
> that would be seen from the protocol level (like ZRTP for example) as a
> single KEM.
>
> Some combiners suggestions can be found for example in this publication
> https://eprint.iacr.org/2018/903.pdf
>
> The idea would be to avoid repeating the hybrid KEM description in various
> documents and focus the discussions on that specific matter in one central
> point.
>
> Regards,
>
> Johan
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 18 Nov 2021 22:43:40 +0000

Hi Johan,

ZRTP was never adopted as a working group item, but the draft was presented several times in the AVT working group. You might get useful feedback from AVTCORE.

Colin

> On 16 Nov 2021, at 21:51, Eric Rescorla <[email-masked]> wrote:
> 
> Hi Johann,
> 
> As you say, there are some common design questions with any protocol which wants to graft PQ onto DH in a hybrid mode. There is already a fair amount of work in this in TLS (https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ <https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/>), though it looks less like making ECDH act like a KEM and more often making the KEMs act like ECDH. I'm honestly not sure how much new work there is to do here; over in TLS we're mostly waiting for NIST. I do think it would be helpful to have CFRG or the like specific a PQ algorithm but I'm not sure a generic algorithm describing hybrid will help that much, as opposed to having that last mile be protocol specific
> 
> Process-wise, the IETF is not maintaining ZRTP, so you would probably need to do an individual submission or send it to the ISE if you want to update it.
> 
> -Ekr
> 
> 
> 
> 
> On Tue, Nov 16, 2021 at 1:32 PM Johan Pascal <[email-masked] <mailto:[email-masked]>> wrote:
> Dear Saag,
> 
> on Roman's advice, I post on this list to mention the need for an update to ZRTP in order to support Post-Quantum Crytography. RFC6189 was an individual submission and as far as I know no active WG is maintaining this protocol.
> 
> ZRTP is based on (EC)DH and requires a deep rework to support the KEM interface used by the NIST PQ key exchange algorithms. I started working on this topic, my next step would be to submit am I-D updating RFC6189 but I'm far from it so if someone is interested let me know and I can share the preliminary analysis to start a discussion.
> 
> 
> 
> Side note: The PQC version of ZRTP should actually use an hybrid key exchange using both (EC)DH and PQ-KEM in parallel. Every protocol using key exchange/encapsulation algorithm and willing to transition toward PQC have to deal with this problem so I think it would be more effective to address it in a specific document that would describe:
> 
> - how to combine the output of two or more KEMs to provide an hybrid one that would be seen from the protocol level (like ZRTP for example) as a single KEM.
> 
> Some combiners suggestions can be found for example in this publication https://eprint.iacr.org/2018/903.pdf <https://eprint.iacr.org/2018/903.pdf>
> The idea would be to avoid repeating the hybrid KEM description in various documents and focus the discussions on that specific matter in one central point.
> 
> Regards,
> 
> Johan
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/saag <https://www.ietf.org/mailman/listinfo/saag>

---

From: Johan Pascal <[email-masked]>
Date: Mon, 22 Nov 2021 18:28:08 +0100

Hi,

thanks for your suggestions. I know the work
on hybrid design is already done in TLS and others . While
looking for some documentation on that specific problem I found
several protocols addressing it, each of them with specific
details related to the protocol and that is mainly what led me
to think that a document dedicated to hybrid scheme might make
sense: it would save the next person trying to achieve exactly
what I'm trying to do for ZRTP the work of reading the different
specifications, parting what is protocol related and what is
not. But the hybrid mechanism can be described in the PQC-ZRTP
I-D itself.

Colin, as the problem of updating ZRTP to a
PQ-KEM scheme is mostly security related it made more sense to
me to post it on Saag. The perfect list to discuss it would be
the potential "PQC Agility" WG if it is charted at some point
(https://mailarchive.ietf.org/arch/msg/saag/5uV72m80X9PTGFWFyDY5VrNyK-c/).
Is there any update on this?

Regards,

Johan

On 18/11/2021 23:43, Colin Perkins
wrote:

Hi Johan,

ZRTP was never adopted as a working group item, but
the draft was presented several times in the AVT working group.
You might get useful feedback from AVTCORE.

Colin

On 16 Nov 2021, at 21:51, Eric Rescorla <[email-masked]>
wrote:

Hi Johann,

As you say, there are some common design
questions with any protocol which wants to graft PQ
onto DH in a hybrid mode. There is already a fair
amount of work in this in TLS (https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/),
though it looks less like making ECDH act like a KEM
and more often making the KEMs act like ECDH. I'm
honestly not sure how much new work there is to do
here; over in TLS we're mostly waiting for NIST. I
do think it would be helpful to have CFRG or the
like specific a PQ algorithm but I'm not sure a
generic algorithm describing hybrid will help that
much, as opposed to having that last mile be
protocol specific

Process-wise, the IETF is not
maintaining ZRTP, so you would probably need to do
an individual submission or send it to the ISE if
you want to update it.

-Ekr

On Tue, Nov 16, 2021
at 1:32 PM Johan Pascal <[email-masked]>
wrote:

Dear Saag,

on Roman's
advice, I post on this list to mention the
need for an update to ZRTP in order to support
Post-Quantum Crytography. RFC6189 was an
individual submission and as far as I know no
active WG is maintaining this protocol.

ZRTP is
based on (EC)DH and requires a deep rework to
support the KEM interface used by the NIST PQ
key exchange algorithms. I started working on
this topic, my next step would be to submit am
I-D updating RFC6189 but I'm far from it so if
someone is interested let me know and I can
share the preliminary analysis to start a
discussion.

Side note:
The PQC version of ZRTP should actually use an
hybrid key exchange using both (EC)DH and
PQ-KEM in parallel. Every protocol using key
exchange/encapsulation algorithm and willing
to transition toward PQC have to deal with
this problem so I think it would be more
effective to address it in a specific document
that would describe:

- how to
implement a KEM from X25519/X448 or others
(EC)DH algorithms

- how to
combine the output of two or more KEMs to
provide an hybrid one that would be seen from
the protocol level (like ZRTP for example) as
a single KEM.

Some
combiners suggestions can be found for example
in this publication https://eprint.iacr.org/2018/903.pdf

The idea
would be to avoid repeating the hybrid KEM
description in various documents and focus the
discussions on that specific matter in one
central point.

Regards,

Johan

saag mailing list

[email-masked]

saag mailing list

[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Mon, 22 Nov 2021 22:24:27 +0000

It would be useful to get review from AVTCORE, if only to (try to) ensure the thinking about post-quantum crypto for SRTP aligns with ZRTP, to the extent possible.

Colin

> On 22 Nov 2021, at 17:28, Johan Pascal <[email-masked]> wrote:
> 
> Hi,
> 
> thanks for your suggestions. I know the work on hybrid design is already done in TLS and others . While looking for some documentation on that specific problem I found several protocols addressing it, each of them with specific details related to the protocol and that is mainly what led me to think that a document dedicated to hybrid scheme might make sense: it would save the next person trying to achieve exactly what I'm trying to do for ZRTP the work of reading the different specifications, parting what is protocol related and what is not. But the hybrid mechanism can be described in the PQC-ZRTP I-D itself.
> 
> Colin, as the problem of updating ZRTP to a PQ-KEM scheme is mostly security related it made more sense to me to post it on Saag. The perfect list to discuss it would be the potential "PQC Agility" WG if it is charted at some point (https://mailarchive.ietf.org/arch/msg/saag/5uV72m80X9PTGFWFyDY5VrNyK-c/ <https://mailarchive.ietf.org/arch/msg/saag/5uV72m80X9PTGFWFyDY5VrNyK-c/>). Is there any update on this?
> 
> Regards,
> 
> Johan
> 
> On 18/11/2021 23:43, Colin Perkins wrote:
>> Hi Johan,
>> 
>>> On 16 Nov 2021, at 21:51, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Johann,
>>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Nov 2021 21:47:46 -0800

On Mon, Nov 22, 2021 at 9:28 AM Johan Pascal <[email-masked]>
wrote:

> Hi,
>
> thanks for your suggestions. I know the work on hybrid design is already
> done in TLS and others . While looking for some documentation on that
> specific problem I found several protocols addressing it, each of them with
> specific details related to the protocol and that is mainly what led me to
> think that a document dedicated to hybrid scheme might make sense: it would
> save the next person trying to achieve exactly what I'm trying to do for
> ZRTP the work of reading the different specifications, parting what is
> protocol related and what is not. But the hybrid mechanism can be described
> in the PQC-ZRTP I-D itself.
>
> Colin, as the problem of updating ZRTP to a PQ-KEM scheme is mostly
> security related it made more sense to me to post it on Saag. The perfect
> list to discuss it would be the potential "PQC Agility" WG if it is charted
> at some point (
> https://mailarchive.ietf.org/arch/msg/saag/5uV72m80X9PTGFWFyDY5VrNyK-c/).
Well, discuss it, perhaps, but given that ZRTP is not an IETF protocol, we
generally would not publish this document out of that group.

-Ekr

Regards,
> ZRTP was never adopted as a working group item, but the draft was
> presented several times in the AVT working group. You might get useful
> feedback from AVTCORE.
>
> Colin
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/), though
> it looks less like making ECDH act like a KEM and more often making the
> KEMs act like ECDH. I'm honestly not sure how much new work there is to do
> here; over in TLS we're mostly waiting for NIST. I do think it would be
> helpful to have CFRG or the like specific a PQ algorithm but I'm not sure a
> generic algorithm describing hybrid will help that much, as opposed to
> having that last mile be protocol specific
>
>> The idea would be to avoid repeating the hybrid KEM description in
>> various documents and focus the discussions on that specific matter in one
>> central point.
>>
>> Regards,
>>
>> Johan

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 22 Nov 2021 22:27:12 -0800

> generally would not publish this document out of that group.

Sorry for splitting hairs, but RFC 6189 does have the "represents the
consensus of the IETF community" boilerplate, that would seem to  make it
an IETF protocol by at least some definitions.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Nov 2021 04:16:13 -0800

> an IETF protocol by at least some definitions.

Without taking a position on whether this was hair splitting, ZRTP was not
developed by an IETF WG. It was externally developed and then published
as Informational.

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Nov 2021 12:54:58 +0000

Ben,

this shows that even IETF experts have a hard time differentiating IETF consensus documents from those who aren’t.
I wonder how often people believed that ZRTP was the product of an IETF working group.

A few years have passed since the publication of ZRTP and attacker capabilities have changed. I am wondering whether the security model of ZRTP is still meaningful today.

Ciao
Hannes

From: saag <[email-masked]> On Behalf Of Eric Rescorla
Sent: Tuesday, November 23, 2021 1:16 PM
To: Benjamin Kaduk <[email-masked]>
Cc: IETF SAAG <[email-masked]>
Subject: Re: [saag] PQC in ZRTP (RFC6189) and hybrid KEM

On Mon, Nov 22, 2021 at 10:27 PM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Nov 22, 2021 at 09:47:46PM -0800, Eric Rescorla wrote:
> On Mon, Nov 22, 2021 at 9:28 AM Johan Pascal <[email-masked]<mailto:[email-masked]>>
> wrote:
>
> > Hi,
> >

-Ekr
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: Eric Rescorla <[email-masked]>
Date: Tue, 23 Nov 2021 08:20:01 -0800

On Tue, Nov 23, 2021 at 4:55 AM Hannes Tschofenig <[email-masked]>
wrote:

> Ben,
>
>
>
> this shows that even IETF experts have a hard time differentiating IETF
> consensus documents from those who aren’t.
>
> A few years have passed since the publication of ZRTP and attacker
> capabilities have changed. I am wondering whether the security model of
> ZRTP is still meaningful today.
>

I think at this point we have fairly strong evidence that of in-band
confirmation of SAS codes is fairly subject to impersonation via modern
voice synthesis techniques.

See: https://www.rfc-editor.org/rfc/rfc8826.html#section-4.3.2.2

-Ekr

>
> Ciao
>
> Hannes
>
>
>
>
>
> *From:* saag <[email-masked]> *On Behalf Of * Eric Rescorla
> *Sent:* Tuesday, November 23, 2021 1:16 PM
> *To:* Benjamin Kaduk <[email-masked]>
> *Cc:* IETF SAAG <[email-masked]>
> *Subject:* Re: [saag] PQC in ZRTP (RFC6189) and hybrid KEM
>
>
>
>
>
>
>
> 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: Colin Perkins <[email-masked]>
Date: Tue, 23 Nov 2021 19:22:06 +0000

> On 23 Nov 2021, at 12:16, Eric Rescorla <[email-masked]> wrote:
> On Mon, Nov 22, 2021 at 10:27 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> > On Mon, Nov 22, 2021 at 9:28 AM Johan Pascal <[email-masked] <mailto:[email-masked]>>
> > wrote:
> > 
> > > Hi,
> > >
> > > https://mailarchive.ietf.org/arch/msg/saag/5uV72m80X9PTGFWFyDY5VrNyK-c/ <https://mailarchive.ietf.org/arch/msg/saag/5uV72m80X9PTGFWFyDY5VrNyK-c/>).

It was externally developed, but did get some reasonable amount of review in IETF, and was discussed in WG meetings on several occasions. 

If I remember correctly, this review didn’t change the core security mechanism, but did result in fixes to a number of issues around how ZRTP integrates with RTP and signalling.

-- 
Colin Perkins
https://csperkins.org/

---

From: Jon Callas <[email-masked]>
Date: Tue, 23 Nov 2021 12:22:44 -0800

> On Nov 23, 2021, at 11:22, Colin Perkins <[email-masked]> wrote:
> 

Yeah, there was a lot of going back and forth on many things that were at least layer 9 issues. The result of that being that it's Informational.

> If I remember correctly, this review didn’t change the core security mechanism, but did result in fixes to a number of issues around how ZRTP integrates with RTP and signalling.

That's what I (a co-author) remember as well, too.

Anyway, if someone wants to put PQC into ZRTP anyway, I think it's a great idea, and an Informational Track addendum, I'd be happy to help. Note, however, _help_. If I wanted to do the heavy lifting, I'd have done it, myself. Also, one of the main questions is whether this is still the right time to put it in. The NIST PQC work still seems to be aflutter with this and that.

	Jon

---

From: Johan Pascal <[email-masked]>
Date: Tue, 23 Nov 2021 23:48:04 +0100

Thanks all for your replies,

Ekr, I think ZRTP is still relevant despite
progress in voice synthesis. Yes it is easy to generate a SAS
code impersonating someone voice but then you have to insert it
with the right timing in a live conversation.

This publication
https://nsaxena.engr.tamu.edu/wp-content/uploads/sites/238/2019/12/ss-ccs14-1.pdf
is I think the one addressing the more directly the subject and
indeed prove that speech synthesis can easily fool real people
in the context of SAS comparison. However I don't think they
fully cover the SAS insertion without introducing painful delay
in a live call.

Jon, Colin, I just posted both on this list
and on avtcore a small synthesis of how I plan to modify ZRTP to
use KEM instead of (EC)DH. I have two slightly different
solutions, any comments will be more than welcome.

Regards,

Johan

On 23/11/2021 17:20, Eric Rescorla
wrote:

On Tue, Nov 23, 2021 at 4:55
AM Hannes Tschofenig <[email-masked]>
wrote:

Ben,

this shows that even IETF experts
have a hard time differentiating IETF consensus
documents from those who aren’t.

I wonder how often people believed
that ZRTP was the product of an IETF working group.

A few years have passed since the
publication of ZRTP and attacker capabilities have
changed. I am wondering whether the security model of
ZRTP is still meaningful today.

I think at this point we have fairly strong evidence that
of in-band confirmation of SAS codes is fairly subject to
impersonation via modern voice synthesis techniques.

-Ekr

Ciao

Hannes

From: saag <[email-masked]>
On Behalf Of
Eric Rescorla

Subject: Re: [saag] PQC in ZRTP (RFC6189) and
hybrid KEM

On Mon, Nov 22, 2021 at 10:27
PM Benjamin Kaduk <[email-masked]>
wrote:

On Mon, Nov 22, 2021 at

> > specific problem I found several
protocols addressing it, each of them with

> > specific details related to the
protocol and that is mainly what led me to

> > list to discuss it would be the
potential "PQC Agility" WG if it is charted

> generally would not publish this document
out of that group.

Sorry for splitting hairs, but RFC 6189 does
have the "represents the

consensus of the IETF community" boilerplate,
that would seem to  make it

Without taking a position on
whether this was hair splitting, ZRTP was not

developed by an IETF WG. It
was externally developed and then published

as Informational.

-Ekr

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: Jon Callas <[email-masked]>
Date: Tue, 23 Nov 2021 15:06:02 -0800

> On Nov 23, 2021, at 08:20, Eric Rescorla <[email-masked]> wrote:
> 
> I think at this point we have fairly strong evidence that of in-band confirmation of SAS codes is fairly subject to impersonation via modern voice synthesis techniques.
> 

I don't quite know how to respond because on the one hand, yeah, deep fakes are only going to get better but it's not like that's a problem unique to ZRTP.

This is a place where I've always diverged with my co-authors, and think that the SAS isn't really as cool as they think it is.

However, when one argues against the SAS, there are a number things to keep in mind, because their over-enthusiasm for it tends to distort how to think about it.

In my opinion, the best thing about ZRTP is not the SAS, but its key continuity aspects. Key continuity between calls lets you know a useful thing: that the end point you're talking to now is the same endpoint you were talking to before. Regardless of how you verify the authentication with SAS or whatever, we know this from the cryptography.

This is subtle, because you can verify a call at the beginning. Or you can talk with someone and then decide you want to verify. Or you can end the call, call them back, and then verify. This flexibility makes the attacker's job a lot harder. They can't just spoof the authentication and go away, the spying infrastructure they create has to be brought up and kept active throughout a *history* of calls. This means especially that a deep-faked attacker has a hard job ahead of them.

Another thing to remember is that the SAS doesn't *have* to go through the voice channel. My co-authors, in their enthusiasm, can distract someone from using another mechanism. Sure, if the only thing you have is a voice line and nothing else, it's fine. That's not a MUST, though, it's a MAY. You can use whatever texting system you have (even SMS) with a high degree of security because it's out-of-band from the voice. I know that last flourish I made about SMS is going to annoy some people, so yeah! Use your favorite MLS messenger to send the thing securely. That works too. However, unless you verified *that* transaction by reading off its fingerprint through an out-of-band channel, then it's just as insecure as the ZRTP connection or even the SMS.

And this brings me to the last bit. The reality is that people don't verify connections. Humans just plain suck at that. I can't remember the last time I verified a Signal safety number. Most people I now kinda joke about them, especially in long-standing group chats where someone seems to be getting a new phone all the time.

It's important that we not fall into the security nihilism of saying that verification is hard, therefore this thing is worthless. The verification problem exists throughout most of our systems, not just ZRTP. I probably use a dozen WebRTC sessions a week that never really verify themselves, and for all we know have some totally YOLOed self-signed cert underneath, if anything at all.

The SAS is nice. It's cute. It's got value to it, just not what its proponents are so enthusiastic about. Key continuity is much better because it places a burden on an attacker. And in the real world, we seem to do just fine with a gazillion protocols that don't verify their trust anchors, or create a turtle-tower that extends out of sight.

	Jon

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Nov 2021 07:24:23 +0000

*   It was externally developed, but did get some reasonable amount of review in IETF, and was discussed in WG meetings on several occasions.

Either it is a product of the IETF or it isn’t. Just because you get some feedback does not make it an IETF consensus document. Just think about eTLS: was presented many times, got a lot of feedback.

Ciao
Hannes