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, 6 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