Re: [xmpp] comments on draft-miller-xmpp-e2e-06
Simon Tennant <simon@buddycloud.com> Fri, 06 June 2014 11:57 UTC
Return-Path: <simon@buddycloud.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C471A0470 for <xmpp@ietfa.amsl.com>; Fri, 6 Jun 2014 04:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMMHac6MZLOH for <xmpp@ietfa.amsl.com>; Fri, 6 Jun 2014 04:57:00 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FF01A0439 for <xmpp@ietf.org>; Fri, 6 Jun 2014 04:56:59 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id b13so1729748wgh.21 for <xmpp@ietf.org>; Fri, 06 Jun 2014 04:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buddycloud.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JcvrCPjhAq2W5Jjr2GKZmutxto5cp3b7y3zx7Raui8E=; b=QCpXKyrZMjUNGH9dj2xWjLfOfBSA/MRwAIUWR3KnSXzMFiXebVIihbmZHsMU3uvtDm r0SY6irHzhcE2BsREj1yQImZK3hSUn/Bz+7wS52otq3SsgobjQgaoFFFrTq6pg2rzac2 doRfQNQO8Mjh8Ml2eEaeqRTUCG80hcRY/S7AU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JcvrCPjhAq2W5Jjr2GKZmutxto5cp3b7y3zx7Raui8E=; b=e/SVNLUarJA5PX2i6BL9qiw39RDy/GFTxlwyj2QcK9JqBqUoW1OFETi21O1TGO5m9R +EVGNf/6wMS8v4ME6Qhh5Q/3zQb1htcXYK2E3aYXtQgBn75waL2EjI8ww/W1VMC32WJY xjPJoRRkUmGUVEXKS8JeMDdRC6JtUW0U+VWzkUxjtAr3HTMxcT+levxB32YxdNahUIT0 xv9uYkQmxctCL83nLdSUufMe3Zp5cFFVv03YN7M5agCFPfPprRcxngAGMMh/N30radq7 O6vCms89NOyUjFSnDi766hxTzYdxB2LwRKYNgqbDodyw24tRcHIOuecf43wd8Kv4spSQ R7wA==
X-Gm-Message-State: ALoCoQnkduvqNVQIskdZvTc996oyo3IXXz1/DVRc+YuhBh691fF8fGMN9GMM/DXcseGFoPUkDyiB
MIME-Version: 1.0
X-Received: by 10.194.92.148 with SMTP id cm20mr4685315wjb.53.1402055811793; Fri, 06 Jun 2014 04:56:51 -0700 (PDT)
Received: by 10.194.109.129 with HTTP; Fri, 6 Jun 2014 04:56:51 -0700 (PDT)
X-Originating-IP: [77.47.7.58]
In-Reply-To: <5328B3CB.5080501@cisco.com>
References: <CF3DFA91.12C98%carl@redhoundsoftware.com> <5319AC20.4090906@cisco.com> <CF3F1DD3.12E2E%carl@redhoundsoftware.com> <5328B3CB.5080501@cisco.com>
Date: Fri, 06 Jun 2014 13:56:51 +0200
Message-ID: <CACEE+iPb=W-CMKuBiygmwnn3JpUA6Nxxuyb2_QE38DLJQ=s4+Q@mail.gmail.com>
From: Simon Tennant <simon@buddycloud.com>
To: Matt Miller <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary="047d7bfd01669e1abd04fb298e6e"
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/b0wFhD6_2jc6xetk5QcSXi7h-a4
Cc: "<xmpp@ietf.org> Group" <xmpp@ietf.org>
Subject: Re: [xmpp] comments on draft-miller-xmpp-e2e-06
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jun 2014 11:57:08 -0000
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 <mamille2@cisco.com> 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" <mamille2@cisco.com> 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 < mamille2@cisco.com > > 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 > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
- [xmpp] comments on draft-miller-xmpp-e2e-06 Carl Wallace
- Re: [xmpp] comments on draft-miller-xmpp-e2e-06 Matt Miller
- Re: [xmpp] comments on draft-miller-xmpp-e2e-06 Carl Wallace
- Re: [xmpp] comments on draft-miller-xmpp-e2e-06 Carl Wallace
- Re: [xmpp] comments on draft-miller-xmpp-e2e-06 Matt Miller
- Re: [xmpp] comments on draft-miller-xmpp-e2e-06 Simon Tennant
- Re: [xmpp] comments on draft-miller-xmpp-e2e-06 Matt Miller