Re: comments on draft-miller-xmpp-e2e-06

Hi Matt,

A few high-level questions:

   - Do I understand it correctly that all keys are session based and there
   isn't a pgp style key that the user publishes in a directory? I guess I'm
   not clear on how the keys are created or exchanged or looked up for
   contacts.
   - How would this handle me sending a <message> to an offline contact? Or
   retrieving encrypted messages after being offline for a while?
   - Could this work for component to component  / user to component
   messages?
   - Are keys always session based? Would it be possible to hook into other
   key directories?

S.

ᐧ


On 18 March 2014 21:59, Matt Miller <[email protected]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 3/7/14, 5:28 AM, Carl Wallace wrote:
> >
> >
> > On 3/7/14, 6:23 AM, "Matt Miller" <[email protected]> wrote:
> >
> > 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.
> >
> >> 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?
> >
> > 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.
> >
> >> 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
> >>>> worthwhile.  Including the encrypted CEK would help with
> >>>> storage too.
> >
> > 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.
> >
> >
> > 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).
> >
> >> Do you know what the threshold is?
>
> 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).
> >>>>
> >
> > 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?
> >
> >> 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.
>
> >>>> - 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?
> >
> >> That would help.
> >
> >
> >>>>
> >>>> - 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?
> >
> >> Sure.  Will try to send something next week.
> >
> >
> >>>>
> >>>> - Should include an example of a reply to an encrypted
> >>>> message. 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?
> >
> >> No, just looking for another place to not use of a key already
> >> know to the receiver.
> >
> >
> >>>> 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.
> >
> >>>> - 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
> >>>>
> >
> > 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.
> >
> >> 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.
> >>>>
> >
> > 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:-)
> >
> >
> >
> >>>> 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?
> >
> >> As above, will try to send some text next week.
>
> - --
> - - m&m
>
> Matt Miller < [email protected] >
> Cisco Systems, Inc.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTKLPLAAoJEDWi+S0W7cO1L3IH/igYVs7+S4bJACRXkzVqUDqr
> AUiIg/Ply3x04Cf06O0oCmRmfdxe9GhNv3CRbs07tETihZY31PV0Nez+BkHkVpN2
> jcTE2ACDYbChGZAb55F8ThBNHWuDZfKJuRN0F+Elfckl9GVkCuwDiGj9TPLXvnbS
> 1KUdoFr0OQSwF8qaLMPdX3N/1/7srTmM84bkHL0RYpT4sihlzbWwYydr0/NKYSqy
> L1Zn33Yw8RQpKjrtqOw5I7CrhN/qTytTD6srZNnqR/W68+MmDfb1y4RYfqnYX8Qy
> NPuDdk/hME42hSkUoJqSGEKez0iClmSTakNserA3vjl6cn3cRUYZWRzoKBk43vI=
> =36MU
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> xmpp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/xmpp
>



-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp