Subject: Re: [xmpp] Self Introduction

From: Jon Kristensen <[email-masked]>
Date: Fri, 01 Mar 2013 15:29:29 +0100

On 02/28/2013 11:30 PM, Richard Barnes wrote:
> Could you clarify what you mean by "repudiability"?  Do you mean that, 
> post-hoc, it is impossible to tell which of the parties holding a 
> symmetric key generated a given stanza?

Yes, that is what I mean. :-)

> The current system is explicitly *compatible* with this notion of 
> repudiability.  As Matt says, in the current scheme, the sender makes 
> up a random symmetric key and wraps it in the recipient's public key. 
>  The message is then encrypted under the symmetric key.  So the sender 
> and the receiver share a symmetric key, and either of them can modify 
> the message to be whatever they want.

Good!

> No.  Compromise of the recipient's private key would expose all of the 
> session keys.  If you want forward secrecy, you need to do DH.

I see.

At this point, it seems to me that OTR/Yabasta provides two things that 
Miller's protocol does not: weak anonymity (a passive attacker can't 
tell what public key is being used) and perfect forward secrecy. I'm 
also thinking about the possibility of providing strong authentication 
(an active attacker can't tell what public key is being used) if the 
public keys are already known. (I'm not yet sure about the deniability 
feature.)

Speaking of an alternative key negotiation method, I'm thinking about 
the value of standardizing something like "Authenticated Diffie-Hellman 
Shared Secret Negotiation", which would work something like 
<https://github.com/jonkri/yabasta-protocol/#authenticated-key-exchanges>, 
except also being flexible (in terms of what prime numbers, signing 
credentials, and what crypto, signing, and hash functions to use).

Also, I think that Diffie-Hellman key exchanges might be difficult to 
make compatible with requirement of securing multiple end-points, since 
they include a random and secret number on both sides.

Jon

---

From: Richard Barnes <[email-masked]>
Date: Fri, 1 Mar 2013 22:35:57 -0500

> Miller's protocol does not: weak anonymity (a passive attacker can't tell
> what public key is being used) and perfect forward secrecy. I'm also
> thinking about the possibility of providing strong authentication (an
> active attacker can't tell what public key is being used) if the public
> keys are already known. (I'm not yet sure about the deniability feature.)
>

It actually wouldn't be that hard to add PFS to Matt's proposal, just by
doing the key exchange inside of an anonymous DH exchange.

> Speaking of an alternative key negotiation method, I'm thinking about the
> value of standardizing something like "Authenticated Diffie-Hellman Shared
> Secret Negotiation", which would work something like <
> https://github.com/jonkri/**yabasta-protocol/#**
> authenticated-key-exchanges<https://github.com/jonkri/yabasta-protocol/#authenticated-key-exchanges>>,
> Also, I think that Diffie-Hellman key exchanges might be difficult to make
> compatible with requirement of securing multiple end-points, since they
> include a random and secret number on both sides.

It's not that different from using RSA.  The sender already does
per-recipient public key operations, in order to wrap the symmetric key for
each recipient.  In the DH case, the sender would just do a DH operation to
generate a key encryption key, then encrypt the symmetric key with that key.

--Richard

---

From: Jon Kristensen <[email-masked]>
Date: Sun, 03 Mar 2013 23:02:28 +0100

On 03/01/2013 03:29 PM, Jon Kristensen wrote:
> At this point, it seems to me that OTR/Yabasta provides two things 
> that Miller's protocol does not: weak anonymity (a passive attacker 
> can't tell what public key is being used) and perfect forward secrecy. 
> I'm also thinking about the possibility of providing *strong 
> anonymity* (an active attacker can't tell what public key is being 
> used) if the public keys are already known. (I'm not yet sure about 
> the *forgeability* feature.)

I don't know what I was doing when I wrote the above text. I've added 
two corrections in bold.

In addition to the Perfect Forward Secrecy requirement, which as 
mentioned should be relatively straight-forward to add to Miller's 
protocol, I would like see support for something like weak anonymity (an 
active man-in-the-middle attack is necessary in order to reveal the 
public keys (while they are being exchanged)) and strong anonymity (not 
even an active man-in-the-middle attack can reveal the public keys used 
(for example, during the key requests)). The way I imagine strong 
anonymity to work, is that every key request is performed with a 
(rotating) public key identifier that cannot be linked with to the 
public key in question.

If these features could be added, I would see no reason to continue 
developing the Yabasta protocol.

Jon

---

From: Richard Barnes <[email-masked]>
Date: Sun, 3 Mar 2013 19:23:47 -0500

You suggestions for how to add them would be most welcome :)

On Sunday, March 3, 2013, Jon Kristensen wrote:

> thinking about the possibility of providing *strong anonymity* (an active
> attacker can't tell what public key is being used) if the public keys are
> already known. (I'm not yet sure about the *forgeability* feature.)
>
>
> I don't know what I was doing when I wrote the above text. I've added two
> corrections in bold.
>
> In addition to the Perfect Forward Secrecy requirement, which as mentioned
> should be relatively straight-forward to add to Miller's protocol, I would
> like see support for something like weak anonymity (an active
> man-in-the-middle attack is necessary in order to reveal the public keys
> (while they are being exchanged)) and strong anonymity (not even an active
> man-in-the-middle attack can reveal the public keys used (for example,
> during the key requests)). The way I imagine strong anonymity to work, is
> that every key request is performed with a (rotating) public key identifier
> that cannot be linked with to the public key in question.
>

---

From: Jon Kristensen <[email-masked]>
Date: Mon, 04 Mar 2013 03:24:31 +0100

Sure thing, I will start to look into it as soon as I find the time. :-)

Jon

On 03/04/2013 01:23 AM, Richard Barnes wrote:
>>     At this point, it seems to me that OTR/Yabasta provides two
>>     things that Miller's protocol does not: weak anonymity (a passive
>>     attacker can't tell what public key is being used) and perfect
>>     forward secrecy. I'm also thinking about the possibility of
>>     providing *strong anonymity* (an active attacker can't tell what
>>     public key is being used) if the public keys are already known.
>>     (I'm not yet sure about the *forgeability* feature.)
>
>     I don't know what I was doing when I wrote the above text. I've
>     added two corrections in bold.
>
>     protocol, I would like see support for something like weak
>     anonymity (an active man-in-the-middle attack is necessary in
>     order to reveal the public keys (while they are being exchanged))
>     and strong anonymity (not even an active man-in-the-middle attack
>     can reveal the public keys used (for example, during the key
>     requests)). The way I imagine strong anonymity to work, is that
>     every key request is performed with a (rotating) public key
>     identifier that cannot be linked with to the public key in question.
>
>     If these features could be added, I would see no reason to
>     continue developing the Yabasta protocol.
>
>     Jon
>

---

From: Jon Kristensen <[email-masked]>
Date: Thu, 14 Mar 2013 03:41:39 +0100

Mr. Barnes:

Here's an initial idea. :-)

What do you think about standardizing a simple, unauthenticated, 
Diffie-Hellman key exchange, for use with any XMPP protocol? This would 
be a two-way process (an IQ set/result pair) which could be used to 
produce a shared secret between two parties. In regards to Miller's 
proposal, this shared secret could be used to derive encryption keys in 
order to protect the public keys.

The Diffie-Hellman process would look something like this:

   1. Alice selects a safe prime (p), a generator (g)*, a minimum bit 
length value for the random values used (l), and a shared secret 
identifier (i).
   2. Alice generates a random secret (at least l bits long), As, and 
calculates a Diffie-Hellman public value based on this secret, Ap = 
g^(As) mod p.
   3. Alice sends Ap, p, g, l, and i to Bob.
   4. Bob verifies that p is an acceptable safe prime, that g is an 
acceptable generator, and that l is of an acceptable size.
   5. Bob generates a random secret (at least l bits long), Bs, and 
calculates a Diffie-Hellman public value based on this secret, Bp = 
g^(Bs) mod p.
   6. Bob sends Bp to Alice.
   7. Alice and Bob calculates the shared secret s = (Bp)^(As) mod p = 
(Ap)^(Bs) mod p.

The shared secret (s) would be serialized as an unbounded, unsigned, and 
big-endian integer, with no leading \00 bytes.

An encryption key could now be derived from that shared secret by 
hashing s, taking as many bits as needed. Multiple keys, IV values, and 
so on, could be derived by hashing \00 + s, \01 + s, \02 + s, etc. 
However, how these derived values would be produced would be up to the 
application utilizing the Diffie-Hellman key exchange.

In Miller's protocol's key exchange mechanism, the shared secret 
identifier and (for example) the hash function to be used to produce the 
encryption keys, could be specified in the <keyreq /> element. Thus, by 
protecting the sensitive key request content, it seems to me that both 
weak anonymity and (perfect) forward secrecy could be provided.

Strong anonymity could be provided by delivering a protected identifier 
as part of the key request response, that can be used to request the key 
again in the future. This identifier would then be used by Alice and Bob 
to look up the appropriate key pair, prohibiting even an active attacker 
to expose the public keys. I'm not exactly sure how to expire these 
identifiers, but I'll defer commitment to that for now.

Thanks!

Jon

*) The number 2 can apparantly always be used as a generator, and I 
don't know of any reason of why we would want the flexibility to choose 
something else.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 14 Mar 2013 01:39:49 -0400

It's even simpler than that: Alice and Bob each generate a JWK representing
a DH or ECDH key, the exchange them in an IQ.

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-08

On Wednesday, March 13, 2013, Jon Kristensen wrote:

> Diffie-Hellman key exchange, for use with any XMPP protocol? This would be
> a two-way process (an IQ set/result pair) which could be used to produce a
> shared secret between two parties. In regards to Miller's proposal, this
> shared secret could be used to derive encryption keys in order to protect
> the public keys.
>
> length value for the random values used (l), and a shared secret identifier
> (i).
> calculates a Diffie-Hellman public value based on this secret, Ap = g^(As)
> mod p.
> calculates a Diffie-Hellman public value based on this secret, Bp = g^(Bs)
> mod p.
> An encryption key could now be derived from that shared secret by hashing
> s, taking as many bits as needed. Multiple keys, IV values, and so on,
> could be derived by hashing \00 + s, \01 + s, \02 + s, etc. However, how
> these derived values would be produced would be up to the application
> utilizing the Diffie-Hellman key exchange.
>
> protecting the sensitive key request content, it seems to me that both weak
> anonymity and (perfect) forward secrecy could be provided.
>
> Strong anonymity could be provided by delivering a protected identifier as
> part of the key request response, that can be used to request the key again
> in the future. This identifier would then be used by Alice and Bob to look
> up the appropriate key pair, prohibiting even an active attacker to expose
> the public keys. I'm not exactly sure how to expire these identifiers, but
> I'll defer commitment to that for now.
>
> Thanks!
>
> Jon
>
> *) The number 2 can apparantly always be used as a generator, and I don't
> know of any reason of why we would want the flexibility to choose something
> else.
>
>> thinking about the possibility of providing *strong anonymity* (an
>> keys are already known. (I'm not yet sure about the *forgeability*feature.)
>>
>>
>> active man-in-the-middle attack is necessary in order to reveal the public
>> keys (while they are being exchanged)) and strong anonymity (not even an
>> active man-in-the-middle attack can reveal the public keys used (for
>> example, during the key requests)). The way I imagine strong anonymity to
>> work, is that every key request is performed with a (rotating) public key

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Mar 2013 10:20:36 -0400

Perhaps the participants in this thread would consider changing the subject field to something more descriptive of the thread?

(And before anyone says it, yes, I realize DH, etc, does something that one might characterize as introductions ... :-)  )

Thanks!

Ben.

On Mar 14, 2013, at 1:39 AM, Richard Barnes <[email-masked]> wrote:

> It's even simpler than that: Alice and Bob each generate a JWK representing a DH or ECDH key, the exchange them in an IQ. 
> 
> What do you think about standardizing a simple, unauthenticated, Diffie-Hellman key exchange, for use with any XMPP protocol? This would be a two-way process (an IQ set/result pair) which could be used to produce a shared secret between two parties. In regards to Miller's proposal, this shared secret could be used to derive encryption keys in order to protect the public keys.
> 
>   1. Alice selects a safe prime (p), a generator (g)*, a minimum bit length value for the random values used (l), and a shared secret identifier (i).
>   2. Alice generates a random secret (at least l bits long), As, and calculates a Diffie-Hellman public value based on this secret, Ap = g^(As) mod p.
>   4. Bob verifies that p is an acceptable safe prime, that g is an acceptable generator, and that l is of an acceptable size.
>   5. Bob generates a random secret (at least l bits long), Bs, and calculates a Diffie-Hellman public value based on this secret, Bp = g^(Bs) mod p.
>   7. Alice and Bob calculates the shared secret s = (Bp)^(As) mod p = (Ap)^(Bs) mod p.
> 
> The shared secret (s) would be serialized as an unbounded, unsigned, and big-endian integer, with no leading \00 bytes.
> 
> An encryption key could now be derived from that shared secret by hashing s, taking as many bits as needed. Multiple keys, IV values, and so on, could be derived by hashing \00 + s, \01 + s, \02 + s, etc. However, how these derived values would be produced would be up to the application utilizing the Diffie-Hellman key exchange.
> 
> In Miller's protocol's key exchange mechanism, the shared secret identifier and (for example) the hash function to be used to produce the encryption keys, could be specified in the <keyreq /> element. Thus, by protecting the sensitive key request content, it seems to me that both weak anonymity and (perfect) forward secrecy could be provided.
> 
> Strong anonymity could be provided by delivering a protected identifier as part of the key request response, that can be used to request the key again in the future. This identifier would then be used by Alice and Bob to look up the appropriate key pair, prohibiting even an active attacker to expose the public keys. I'm not exactly sure how to expire these identifiers, but I'll defer commitment to that for now.
> 
> Thanks!
> 
> Jon
> 
> *) The number 2 can apparantly always be used as a generator, and I don't know of any reason of why we would want the flexibility to choose something else.
> 
>>> At this point, it seems to me that OTR/Yabasta provides two things that Miller's protocol does not: weak anonymity (a passive attacker can't tell what public key is being used) and perfect forward secrecy. I'm also thinking about the possibility of providing strong anonymity (an active attacker can't tell what public key is being used) if the public keys are already known. (I'm not yet sure about the forgeability feature.) 
>> 
>> I don't know what I was doing when I wrote the above text. I've added two corrections in bold.
>> 
>> In addition to the Perfect Forward Secrecy requirement, which as mentioned should be relatively straight-forward to add to Miller's protocol, I would like see support for something like weak anonymity (an active man-in-the-middle attack is necessary in order to reveal the public keys (while they are being exchanged)) and strong anonymity (not even an active man-in-the-middle attack can reveal the public keys used (for example, during the key requests)). The way I imagine strong anonymity to work, is that every key request is performed with a (rotating) public key identifier that cannot be linked with to the public key in question.
>> 
>> If these features could be added, I would see no reason to continue developing the Yabasta protocol.
>> 
>> Jon
> 
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Jon Kristensen <[email-masked]>
Date: Thu, 14 Mar 2013 21:52:50 +0100

On 03/14/2013 06:39 AM, Richard Barnes wrote:
> It's even simpler than that: Alice and Bob each generate a JWK 
> representing a DH or ECDH key, the exchange them in an IQ.
>

Thank you for pointing me in the right direction!

Please correct me if I'm wrong, but the way I see it is this:

In order to provide authentication and (weak) anonymity, we would have 
to exchange

 1. unauthenticated Diffie-Hellman key exchange <keyreq /> stanzas, used
    to negotiate a first shared secret, and
 2. encrypted (with the first shared secret) <keyreq /> stanzas (which
    wraps the long-lived public keys) to negotiate a second shared secret.

The second shared secret would be the symmetric key used for encrypting 
the following stanzas. This would protect the long-lived public key from 
a passive attacker, and provide perfect forward secrecy. Also, any 
entity could perform additional unauthenticated Diffie-Hellman key 
exchanges (this time, however, encrypted) to redo the procedure, and add 
yet another "PFS layer".

As there seems to be some patent-related uncertainty surrounding 
elliptic curve cryptography[1], I would like to see support for regular 
Diffie-Hellman keys.

Looking at the IANA JSON Web Key Types registry key types[2], there 
appear to only be two key types defined: `EC' (Elliptic Curve [DSS] key 
type) and `RSA' (RFC3447 key type). Could perhaps `DH' be added to this 
table?

Would `alg' (refer to the the JSON Web Encryption algorithm section[3]) 
be something like `DH+A128KW'?

All-in-all, would something like the following JWK representation be 
suitable for the Diffie-Hellman public key exchanges?

{
   "kty": "DH",
   "public-key": "...",
   "prime": "...",
   "generator": "...",
   "use": "enc",
   "alg": "DH+A128KW"
}

[1]: http://en.wikipedia.org/wiki/ECC_patents
[2]: 
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-5.1
[3]: 
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4.1

Jon