Subject: [xmpp] comments on draft-miller-xmpp-e2e-06

From: Carl Wallace <[email-masked]>
Date: Thu, 06 Mar 2014 10:12:33 -0500

Section 1
- This may be in the reqs draft, but seems worth stating here that some
end points for a given recipient may share keys, some may use different
keys, some may have no keys and some may not support encryption or
signature verification at all.

Section 3
- What should the sender do if some end points for a recipient indicate
lack of support for encryption?  Are error responses helpful independent
of confirmation that some end points support encryption?  Is the intent
for messages to only be sent to end points that advertise support?

- Why not include an end point's key in its info results and enable return
of the encrypted SMK (or even CEK) with the encrypted payload (to save a
round trip).  Given a single message could trigger a number of requests
for the SMK, the option to include the encrypted CEK in the payload may be
worthwhile.  Including the encrypted CEK would help with storage too.

- Why is the SID required to be unique for a {sender, recipient, SMK}
tuple?  This would allow for the same SID to be used to name every SMK
used with a recipient.  Suggest unique for each recipient (i.e., SMK's are
uniquely identified by recipient+SID for a given sender).

- Discuss how multiple recipients are handled

- s/optionallly/optionally

- It would be nice to have a summary of new state information the sender
and recipient are required to manage (like SMKs) and significant new
operations (like authorization of key requests where a given recipient may
use a number of different public keys)

- Should include an example of a reply to an encrypted message.
Should/must the same SMK be used in replies?

- Is there any reason pre-placed SMK values cannot be used instead of SMK
values retrieved automatically from the sender?

Section 4
- How is the public key used to verify signatures published to the
recipients?  If not included in the payload, should be available a la the
SMK.  This would be useful, at a minimum, when the signer uses a
certificate from a PKI the recipient trusts.

- s/Playload/payload

- Include some text indicating users MUST be able to determine if a
message was authenticated

- Should data be presented to the user when the timestamp is not
acceptable?  There are guidelines for invalid signatures, but not for
unacceptable timestamps.  Same comment on 3.3.5 too.

- May want to distinguish between successful authentication vs successful
verification

Section 5
- Should describe how the entity requesting a key gets the SID

- Should make it more clear that a new CEK is generated in order to
encrypt the SMK, then the CEK is encrypted under the public key.

Section 9
- The requirement for the sender to be online would seem like sufficient
grounds for including encrypted CEKs in the payload.

Section 11
- Offline storage may be another reason to include encrypted CEKs in a
payload.  Perhaps the solution should be to encrypt for each of a
recipient's known keys plus an SMK that could be used by end points using
a different, not-yet-known-to-the-sender key.

- Need to address authorization for SMK release.

- Include some guidance on SMK lifetime.

---

From: Matt Miller <[email-masked]>
Date: Fri, 7 Mar 2014 11:23:12 +0000

Thank you very much for the feedback!

I'll incorporate your suggestions as soon as I can.

On 3/6/14, 3:12 PM, Carl Wallace wrote:
> Section 1 - This may be in the reqs draft, but seems worth stating
> here that some end points for a given recipient may share keys,
> some may use different keys, some may have no keys and some may not
> support encryption or signature verification at all.
> 

We did discuss reviving the e2e-reqs draft in the WG session on
Tuesday, but it would be important to include this.

> Section 3 - What should the sender do if some end points for a
> recipient indicate lack of support for encryption?  Are error
> responses helpful independent of confirmation that some end points
> support encryption?  Is the intent for messages to only be sent to
> end points that advertise support?

There is little (read: nothing) that can be said on what existing
"legacy" end-points ought to do.  I tried to say something on what
existing clients already do, to the best of my knowledge.  Many (most)
drop anything they don't understand, so getting errors could very well
be impossible unless the applications were specifically updated to
"anti-support" this specification.  It's also possible I'm missing the
point here, too (-:

The intention is not for the sending end-point to only send to other
supporting end-points.  Indeed, I want this to be compatible with
[CARBONS] and [MUC] where the possible.  To that end, most clients try
to do something if there is a body, and this document could suggest
that sending end-points include an appropriate generic "this message
is protected" body.

> 
> - Why not include an end point's key in its info results and enable
> return of the encrypted SMK (or even CEK) with the encrypted
> payload (to save a round trip).  Given a single message could
> trigger a number of requests for the SMK, the option to include the
> encrypted CEK in the payload may be worthwhile.  Including the
> encrypted CEK would help with storage too.

The encrypted CEK is included in each message with -06.

Including an encrypted SMK is a possibility, although I start to worry
about the size of the overall stanza.  If it's absolutely known that
the message will be delivered to a single end-point it shouldn't get
too large, but I am assuming that servers will start multiplexing chat
messages (a la [CARBONS]) which means the benefits of including the
encrypted SMK are unrealized if only there's only a single instance of
the encrypted SMK; including multiple SMKs can be very problematic
(e.g., many server deployments reject very large stanzas).

> 
> 
> - Why is the SID required to be unique for a {sender, recipient,
> SMK} tuple?  This would allow for the same SID to be used to name
> every SMK used with a recipient.  Suggest unique for each recipient
> (i.e., SMK's are uniquely identified by recipient+SID for a given
> sender).
> 

I'm not sure what you're trying to say here (it could be due to me
responding on the last day of an IETF meeting).  Can you provide an
example of what your concern here is?

> - Discuss how multiple recipients are handled

That is a very good point.  There is some text there, but it is fairly
weak.  I was considering a form of ASCII sequence diagram of the
general flow -- would that better help to explain things?

> - s/optionallly/optionally

Fixed in working copy.

> - It would be nice to have a summary of new state information the
> sender and recipient are required to manage (like SMKs) and
> significant new operations (like authorization of key requests
> where a given recipient may use a number of different public keys)

That is a very good suggestion.  Do you think you could provide some
text to get it started?

> Should/must the same SMK be used in replies?

That is not a bad idea.  I'll look into it.

> - Is there any reason pre-placed SMK values cannot be used instead
> of SMK values retrieved automatically from the sender?
> 

Is there any additional concern here beyond the point a few above?

> Section 4 - How is the public key used to verify signatures
> published to the recipients?  If not included in the payload,
> should be available a la the SMK.  This would be useful, at a
> minimum, when the signer uses a certificate from a PKI the
> recipient trusts.
> 

These are good points, and it ought to be included.  The JWS structure
does allow for inclusion of the jwk (or jku, or x5c, or x5t, or x5u)
which would be the key used to sign the content.  I'll add more
clarity on this point.

> - s/Playload/payload

Fixed in working copy.

> - Include some text indicating users MUST be able to determine if
> a message was authenticated
> 

That is a good point.

> acceptable?  There are guidelines for invalid signatures, but not
> for unacceptable timestamps.  Same comment on 3.3.5 too.
> 

I have been hesitant on dictating what to display to users.  I don't
want to tie the hands of implementations, and it's rather difficult to
independently verify that a given implementation complies without some
sort of officiating body (which we definitely don't want).

> - May want to distinguish between successful authentication vs
> successful verification
> 

Noted.

> Section 5 - Should describe how the entity requesting a key gets
> the SID
> 

I thought I had said that in here, but I'll clarify it further.

> - Should make it more clear that a new CEK is generated in order
> to encrypt the SMK, then the CEK is encrypted under the public
> key.
> 

You have this reversed: the SMK is used to encrypt the CEK, and the
recipient's public key is used to encrypt the SMK.  It is completely
possible that I was not consistent here.

> Section 9 - The requirement for the sender to be online would seem
> like sufficient grounds for including encrypted CEKs in the
> payload.
> 

Encrypted CEKs are in the payload in -06.

> Section 11 - Offline storage may be another reason to include
> encrypted CEKs in a payload.  Perhaps the solution should be to
> encrypt for each of a recipient's known keys plus an SMK that could
> be used by end points using a different,
> not-yet-known-to-the-sender key.
> 

You mean encrypted SMKs here.

One idea that had been discussed outside the meeting was to try and
use [PEP] as a way to do this, but we didn't spend a lot of time
thinking about the mechanics and implications here.

> - Need to address authorization for SMK release.

I have pretty much hand-waved over this part.  One idea that came to
light this week was to provide fingerprints for the recipients' public
keys, somehow.  Suggestions for improvements are welcome.

> - Include some guidance on SMK lifetime.

There is *some* guidance in section 11.2, but I admit it is rather
vague.  Could you provide more specific suggestions?

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

[CARBONS] XEP-0280: Message Carbons <
http://xmpp.org/extensions/xep-0280.html >
[MUC] XEP-0045: Multi-User Chat <
http://xmpp.org/extensions/xep-0045.html >
[PEP] XEP-0163: Personal Eventing Protocol <
http://xmpp.org/extensions/xep-0163.html >

---

From: Carl Wallace <[email-masked]>
Date: Fri, 07 Mar 2014 07:28:17 -0500

On 3/7/14, 6:23 AM, "Matt Miller" <[email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>

It¹s also worth noting the sender may have multiple end points with the
same properties.  If the same SMK were used in replies, it creates kind of
a odd scenario where both parties could be providing the SMK for the
asking.  

>that sending end-points include an appropriate generic "this message

I¹ve not yet looked, but I had wondered if it would be possible to define
the signature format so a non-supporting client could still display the
text (similar to cleartext email vs opaque).  This probably brings a can
of canonicalization worms though.

>The encrypted CEK is included in each message with -06.

I made this error a couple of times.  What I meant was encrypted CEK for a
key already held by the end point, to avoid to the need for a round trip
to get the SMK, to remove the online requirement for the sender at
recipient reading time and to simplify future use of stored encrypted
messages.  The CEK could also be encrypted under the SMK to bootstrap
unknown end points.

>(e.g., many server deployments reject very large stanzas).

Do you know what the threshold is?

>example of what your concern here is?

Assume a sender has used two SMKs while communicating with a given
recipient: sender+recipient+SMK1 and sender+recipient+SMK2.  The current
text requires the SID to be unique "for a given (sender, recipient, SMK)
tuple².  That allows for the same SID to be used for either SMK1 or SMK2.
I am suggesting the SID should be unique for each recipient, from a
sender¹s perspective.

>general flow -- would that better help to explain things?

That would help.

>That is a very good suggestion.  Do you think you could provide some

Sure.  Will try to send something next week.

>Is there any additional concern here beyond the point a few above?

No, just looking for another place to not use of a key already know to the
receiver.  

>sort of officiating body (which we definitely don't want).

I thought these UI notes were more reminders to developers to make sure
user¹s could determine checks had been performed.

>possible that I was not consistent here.

I thought when the SMK is communicated to the end point, it is also
encrypted under a content encryption key (referred to as a CMK in the
text), that is then encrypted using the end point¹s public key.  If that
is correct there are four keys at work: the CEK for the stanza (CEK1), the
SMK to encrypt the CEK, the CEK to encrypt the SMK (CEK2) and the
recipient¹s public key to encrypt CEK2.

>Encrypted CEKs are in the payload in -06.

I tried to clarify in a reply comment above.  This applies to the next few
comments too.  Read ³encrypted CEKs² are ³CEKs encrypted using a key
already possessed by the recipient².  I think I was consistent in misusing
the term ³encrypted CEKs² in my comments in this way, and introduced the
CEK term in my comments where it does not appear in the draft:-)

>vague.  Could you provide more specific suggestions?

As above, will try to send some text next week.

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>Comment: GPGTools - https://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBCgAGBQJTGawgAAoJEDWi+S0W7cO1Jo4H/R8AvTt1WBMIwvBD1U8JNBaP
>M88uMewtHGoQ/NbizCPnNS8DTMQyMxs/z6w66WDBnNNuCFhjqgh5G4X7X9elnFzI
>VezIMKsr5Jc6dlN/9jRgWdQtEuqqmuGKfMHaAoNdqph5pP+zWSx5yhMbcb/wN7Uu
>6+JdY4GB9Yz3xBrwQTBZnkRqqTKKL34/WoX42j9Vy2JgFLyRMu3xoW6xg99622Ol
>VJxXRs7X9uERB0Dn8xTW2NTnRIN82g4WZuuaJLOkGDFQaienaBwQTHhogjaHFcNv
>aTCnQhipI8Io4gLdT3uFzn84oZDYhBCSGyclegAXesthI9gnO3I671YUfTJl9xo=
>=G0xx
>-----END PGP SIGNATURE-----

---

From: Carl Wallace <[email-masked]>
Date: Fri, 14 Mar 2014 09:19:25 -0400

On 3/7/14, 6:23 AM, "Matt Miller" <[email-masked]> wrote:

><snip>

Here¹s some text as a starting point:

Existing XMPP clients will need to maintain additional state information
and incorporate new user interfaces to support end-to-end encryption and
authentication.  Changes for sending clients include:

- Generate session master keys (SMKs)
- Store SMKs for use during active sessions
- Store SMKs to provide to peers and to support reading of saved messages
(may require use of storage key)
- Accept requests for SMKs
- Release SMKs to authorized requestors (where SMK may be requested from
multiple resources each using different means to authenticate)
- Generate content encryption keys (CEK)
- Use SMK and CEK values to encrypt XMPP stanzas
- Generate signing key (optional)
- Use signing key to sign XMPP stanzas

Changes for receiving clients include:

- Send request for SMK to peers
- Store SMK for use during active session
- Use SMK to decrypt CEK used to decrypt XMPP stanzas
- Store session master keys retrieved from peers to support reading of
saved messages (may require use of storage key)
- Provide indication to users when encryption is in use
- Retrieve keys required to verify signatures on signed XMPP stanzas
- Verify signatures and display indication of success/failure to user
- Store keys required to verify signature to support reading of saved
messages (may require use of storage key)

>><snip>

I did not generate any text for this yet because the use of SMKs still
seems unsettled to me.  Some issues:

- including a CEK encrypted for each known end point key plus under an SMK
potentially exceeds size threshold used by some servers
- having each end-point request SMKs from the sender generates additional
traffic
- a sender that communicates with a large number of peers must maintain a
large SMK database for an undetermined period of time
- the sender must be available for a recipient to decrypt messages sent
under an SMK that has not previously been retrieved (this is possibly not
acceptable for all cases where XMPP may be used)
- SMK usage complicates storage of encrypted messages (recipients could
re-encrypt the CEK under a storage key or maintain a database of encrypted
SMKs)

---

From: Matt Miller <[email-masked]>
Date: Tue, 18 Mar 2014 14:59:55 -0600

On 3/7/14, 5:28 AM, Carl Wallace wrote:
>>>> Section 1 - This may be in the reqs draft, but seems worth
>>>> stating here that some end points for a given recipient may
>>>> share keys, some may use different keys, some may have no
>>>> keys and some may not support encryption or signature
>>>> verification at all.
>>>> 
> 
>> It¹s also worth noting the sender may have multiple end points
>> with the same properties.  If the same SMK were used in replies,
>> it creates kind of a odd scenario where both parties could be
>> providing the SMK for the asking.
> 

Good point.

> 
>>>> Section 3 - What should the sender do if some end points for
>>>> a recipient indicate lack of support for encryption?  Are
>>>> error responses helpful independent of confirmation that some
>>>> end points support encryption?  Is the intent for messages to
>>>> only be sent to end points that advertise support?
> 
> existing clients already do, to the best of my knowledge.  Many
> (most) drop anything they don't understand, so getting errors could
> very well be impossible unless the applications were specifically
> updated to "anti-support" this specification.  It's also possible
> I'm missing the point here, too (-:
> 
> The intention is not for the sending end-point to only send to
> other supporting end-points.  Indeed, I want this to be compatible
> with [CARBONS] and [MUC] where the possible.  To that end, most
> clients try to do something if there is a body, and this document
> could suggest that sending end-points include an appropriate
> generic "this message is protected" body.
> 
>> I¹ve not yet looked, but I had wondered if it would be possible
>> to define the signature format so a non-supporting client could
>> still display the text (similar to cleartext email vs opaque).
>> This probably brings a can of canonicalization worms though.
> 

There is an XSF XEP that covers this using a different technology, and
calls it opportunistic signatures.

My experience has been that opportunistic signatures opens a very
large can of worms, which is why I avoided it in my draft.  There are
additional considerations for <iq/>s, since the expectation is for
there to be a single child element (except for type='error', where
there is also an <error/> in the parent's namespace).

We could decide to remove signatures from this draft almost entirely,
and leave it as someone else's exercise to deal with in the general
case.  In this scenario, I envision keeping some form of signature is
to aid in authenticating PFS key exchanges, but then it can be
specific to the keyreq then.

> 
>>>> 
>>>> - Why not include an end point's key in its info results and
>>>> enable return of the encrypted SMK (or even CEK) with the
>>>> encrypted payload (to save a round trip).  Given a single
>>>> message could trigger a number of requests for the SMK, the
>>>> option to include the encrypted CEK in the payload may be
>> I made this error a couple of times.  What I meant was encrypted
>> CEK for a key already held by the end point, to avoid to the need
>> for a round trip to get the SMK, to remove the online requirement
>> for the sender at recipient reading time and to simplify future
>> use of stored encrypted messages.  The CEK could also be
>> encrypted under the SMK to bootstrap unknown end points.
> 
> 
> Including an encrypted SMK is a possibility, although I start to
> worry about the size of the overall stanza.  If it's absolutely
> known that the message will be delivered to a single end-point it
> shouldn't get too large, but I am assuming that servers will start
> multiplexing chat messages (a la [CARBONS]) which means the
> benefits of including the encrypted SMK are unrealized if only
> there's only a single instance of the encrypted SMK; including
> multiple SMKs can be very problematic (e.g., many server
> deployments reject very large stanzas).
> 

The threshold is different for different deployments /-:

There are some without any limit, which means the system crashes if it
runs out of memory trying to deal with an extremely large stanza.
Another I'm aware of has a limit of 40KB, and will drop the connection
on anything bigger.

I don't know how common any particular limit is, though.  And worse,
there's no real way to detect prior to trying.

> 
> 
>>>> 
>>>> 
>>>> - Why is the SID required to be unique for a {sender,
>>>> recipient, SMK} tuple?  This would allow for the same SID to
>>>> be used to name every SMK used with a recipient.  Suggest
>>>> unique for each recipient (i.e., SMK's are uniquely
>>>> identified by recipient+SID for a given sender).
>>>> 
> 
> responding on the last day of an IETF meeting).  Can you provide
> an example of what your concern here is?
> 
>> Assume a sender has used two SMKs while communicating with a
>> given recipient: sender+recipient+SMK1 and sender+recipient+SMK2.
>> The current text requires the SID to be unique "for a given
>> (sender, recipient, SMK) tuple².  That allows for the same SID to
>> be used for either SMK1 or SMK2. I am suggesting the SID should
>> be unique for each recipient, from a sender¹s perspective.
> 
> 

I see your point now.

> That is a very good point.  There is some text there, but it is
> fairly weak.  I was considering a form of ASCII sequence diagram of
> the general flow -- would that better help to explain things?
> 
>> That would help.
> 
> 
>>>> 
>>>> - It would be nice to have a summary of new state information
>>>> the sender and recipient are required to manage (like SMKs)
>>>> and significant new operations (like authorization of key
>>>> requests where a given recipient may use a number of
>>>> different public keys)
> 
> That is a very good suggestion.  Do you think you could provide
> some text to get it started?
> 
>>>> - Should include an example of a reply to an encrypted
>>>> message. Should/must the same SMK be used in replies?
>>>> 
> 
>>>> - Is there any reason pre-placed SMK values cannot be used
>>>> instead of SMK values retrieved automatically from the
>>>> sender?
>>>> 
> 
>> No, just looking for another place to not use of a key already
>> know to the receiver.
> 
> 
>>>> published to the recipients?  If not included in the
>>>> payload, should be available a la the SMK.  This would be
>>>> useful, at a minimum, when the signer uses a certificate from
>>>> a PKI the recipient trusts.
>>>> 
> 
> These are good points, and it ought to be included.  The JWS
> structure does allow for inclusion of the jwk (or jku, or x5c, or
> x5t, or x5u) which would be the key used to sign the content.  I'll
> add more clarity on this point.
> 
>>>> - s/Playload/payload
>>>> 
> 
> Fixed in working copy.
> 
>>>> - Include some text indicating users MUST be able to
>>>> determine if a message was authenticated
>>>> 
> 
> That is a good point.
> 
>>>> - Should data be presented to the user when the timestamp is
>>>> not acceptable?  There are guidelines for invalid signatures,
>>>> but not for unacceptable timestamps.  Same comment on 3.3.5
>>>> too.
>>>> 
> 
> I have been hesitant on dictating what to display to users.  I
> don't want to tie the hands of implementations, and it's rather
> difficult to independently verify that a given implementation
> complies without some sort of officiating body (which we definitely
> don't want).
> 
>> I thought these UI notes were more reminders to developers to
>> make sure user¹s could determine checks had been performed.
> 

I'm sure we can come up with something that's not exactly normative
language.

> 
>>>> - May want to distinguish between successful authentication
>>>> vs successful verification
>>>> 
> 
> Noted.
> 
>>>> Section 5 - Should describe how the entity requesting a key
>>>> gets the SID
>>>> 
> 
>>>> - Should make it more clear that a new CEK is generated in
>>>> order to encrypt the SMK, then the CEK is encrypted under the
>>>> public key.
>>>> 
> 
> You have this reversed: the SMK is used to encrypt the CEK, and
> the recipient's public key is used to encrypt the SMK.  It is
> completely possible that I was not consistent here.
> 
>> I thought when the SMK is communicated to the end point, it is
>> also encrypted under a content encryption key (referred to as a
>> CMK in the text), that is then encrypted using the end point¹s
>> public key.  If that is correct there are four keys at work: the
>> CEK for the stanza (CEK1), the SMK to encrypt the CEK, the CEK to
>> encrypt the SMK (CEK2) and the recipient¹s public key to encrypt
>> CEK2.
> 

You are absolutely correct; sorry for my own confuzzlement!

> 
>>>> Section 9 - The requirement for the sender to be online would
>>>> seem like sufficient grounds for including encrypted CEKs in
>>>> the payload.
>>>> 
> 
>> I tried to clarify in a reply comment above.  This applies to the
>> next few comments too.  Read ³encrypted CEKs² are ³CEKs encrypted
>> using a key already possessed by the recipient².  I think I was
>> consistent in misusing the term ³encrypted CEKs² in my comments
>> in this way, and introduced the CEK term in my comments where it
>> does not appear in the draft:-)
> 
> 
> 
>>>> Section 11 - Offline storage may be another reason to
>>>> include encrypted CEKs in a payload.  Perhaps the solution
>>>> should be to encrypt for each of a recipient's known keys
>>>> plus an SMK that could be used by end points using a
>>>> different, not-yet-known-to-the-sender key.
>>>> 
> 
> One idea that had been discussed outside the meeting was to try
> and use [PEP] as a way to do this, but we didn't spend a lot of
> time thinking about the mechanics and implications here.
> 
> 
> I have pretty much hand-waved over this part.  One idea that came
> to light this week was to provide fingerprints for the recipients'
> public keys, somehow.  Suggestions for improvements are welcome.
> 

- -- 
- - m&m