From mamille2@cisco.com  Tue Jan 24 07:46:46 2012
Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466FA21F85E0 for <xmpp@ietfa.amsl.com>; Tue, 24 Jan 2012 07:46:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EOKGgPPRMaa for <xmpp@ietfa.amsl.com>; Tue, 24 Jan 2012 07:46:45 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 505B521F8597 for <xmpp@ietf.org>; Tue, 24 Jan 2012 07:46:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=9294; q=dns/txt; s=iport; t=1327420005; x=1328629605; h=from:subject:date:message-id:to:mime-version; bh=mDR/CTAko+Zk+Q2owaTvUIlQgH5E3fF58ThBLES60iU=; b=eXGBk5x1yiAWD2Wnqm+mwOcDE0OTa/ycJcngd5TvYiOXdwHVMeEArFgU u5y5roAJyxLwy39I9Nohwyecc+uRXg69+u77P8jSLiacqE3LfAkf4J8lQ 76RJ2odVstGpzkVvAm+S0XmxPEnUDzSVfIS01uoJG3Zq2v/25YB4O7ia/ Q=;
X-Files: smime.p7s : 2214
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAG7RHk+rRDoJ/2dsb2JhbABCrjCBBYILAYFJbiKgJYEnAZ4oiREMCQIBCgIigk4PCA8XUwEBCAMBAQ6CWmMEiD+Fe4M3gyySbg
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000";  d="p7s'?scan'208";a="26901587"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 24 Jan 2012 15:46:44 +0000
Received: from dhcp-64-101-72-218.cisco.com (dhcp-64-101-72-218.cisco.com [64.101.72.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0OFkiax026666 for <xmpp@ietf.org>; Tue, 24 Jan 2012 15:46:44 GMT
From: Matt Miller <mamille2@cisco.com>
Content-Type: multipart/signed; boundary=Apple-Mail-15--926987495; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 24 Jan 2012 08:47:26 -0700
Message-Id: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com>
To: xmpp@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 24 Jan 2012 15:46:46 -0000

--Apple-Mail-15--926987495
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

In working more on the end-to-end encryption proposals, I have some =
concerns about the current direction.  To recap the =
proposal-in-progress:

* sender encrypts stanza using message cipher
* for each known-good public key for the recipient, sender encrypts =
message key
* sender generates a single stanza, which contains the encrypted data + =
all message key encryptions:

<message  xmlns=3D'jabber:client'
         from=3D'juliet@capulet.net/balcony'
         id=3D'6410ed123'
         to=3D'romeo@montague.net'
         type=3D'chat'>
 <e2e   xmlns=3D"urn:ietf:params:xml:ns:xmpp-objenc:0">
   <key    cipher-algo=3D"RSAES-OAEP-SHA-256-MFG1"
           id=3D"recipient-key-1">
     OPfr4zudqiEeLcOQazZJIB6B9gx3zrVbyHKTU8a/aDb0wiZevztxxCi8hto0+Qw
     Foyhcupj547WbFZJNlB2dsAPhlJzeH9SuGLJShjhbkOyKjmqZLLCZr3OQtJjcTU
     sAVj7IZZsOOPDmwsb4Dxv5sz+icsDpi5l+5APfthDaoHbcrvz2pA1CJ5IFQoob4
     a0i0WevcAFyB+vWXsRqQCxjn5sHdb6G4vjQ/m1lzTWahzKvi56pNUm7ll18oI8L
     mPi1VWUEqH3aayGLVlJ9fhBDSSpW4jTQ/ts1nzPJwVlKdTqdgNBusFEhrRMhJD5
     1JdLOhxx+Ov2Xbs22++XQ1tS8/A=3D=3D
   </key>
   <key    cipher-algo=3D"RSAES-OAEP-SHA-256-MFG1"
           id=3D"recipient-key-2">
     OPfr4zudqiEeLcOQazZJIB6B9gx3zrVbyHKTU8a/aDb0wiZevztxxCi8hto0+Qw
     Foyhcupj547WbFZJNlB2dsAPhlJzeH9SuGLJShjhbkOyKjmqZLLCZr3OQtJjcTU
     sAVj7IZZsOOPDmwsb4Dxv5sz+icsDpi5l+5APfthDaoHbcrvz2pA1CJ5IFQoob4
     a0i0WevcAFyB+vWXsRqQCxjn5sHdb6G4vjQ/m1lzTWahzKvi56pNUm7ll18oI8L
     mPi1VWUEqH3aayGLVlJ9fhBDSSpW4jTQ/ts1nzPJwVlKdTqdgNBusFEhrRMhJD5
     1JdLOhxx+Ov2Xbs22++XQ1tS8/A=3D=3D
   </key>
   <data   cipher-algo=3D"AES-256-CBC-PKCS5-WITH-IV"
           mac-algo=3D"HMACSHA256"
           mac-data=3D"HSGmwUFd4sESB+O12S32xsXVvMnO4gjRPaQITIrjWbs=3D">
     a8zpjgRcO1VHZ9CoqU19/jB7nn58Gzu5/sQm8YQe4F9zz+YKUfqTS9LaHcqdAwa
     z8BG1a24Z72VYb5Ptjh7nQ19f5QQdA/P4lZ3oqeTJTsA4DkhvJaSUhrjYib/NOk
     3lkMoatR/OSbfvhPdqXQ/dutLuRFjkilXGVwNWkgLm3iSnKUiYSdUzWvj88RgR3
     ldVHFeyrdgufU9qu/FyO6MZXjfEtD80O+3ZBbESqllzmYFXnfkzBrhfi14iCba6
     /b5Io5zhFUyWaq5e6qq2z72a+1bjeWkG8F9XBiMkyaxkB64wAS0o6aDpWdir5Oi
     +Rnms4LV/wxL4Is/oe8Fo9xR3UmrdlAiaehdGBh+EnJGqprKa9eccOKqSu7/lJQ
     ObAdJGEOeAVs8JEkQkxw+qR8edkEDuv6ZXN7JCWQx9LNaiiwsfAzApJJbqfrtDx
     koQ3JaBbxQ+8FE3TM0E4Tbr9V8NDZC8abgBramlpUBfgknJvLYMTzx1lnsiCUxo
     6ezC0xqV
   </data>
 </e2e>
</message>

The concerns I have are:

* it makes the public key management problem worse, not better
* it makes for a very large stanza, most of which has no use to the =
recipient(s)

So, an approach I'm starting to look at is the following alternative:

* sender encrypts stanza using message cipher
* sender generates a single stanza, which contains the encrypted data =
ONLY:

<message  xmlns=3D'jabber:client'
         from=3D'juliet@capulet.net/balcony'
         id=3D'6410ed123'
         to=3D'romeo@montague.net'
         type=3D'chat'>
 <e2e   xmlns=3D"urn:ietf:params:xml:ns:xmpp-objenc:1">
   <data   cipher-algo=3D"AES-256-CBC-PKCS5-WITH-IV"
           mac-algo=3D"HMACSHA256"
           mac-data=3D"HSGmwUFd4sESB+O12S32xsXVvMnO4gjRPaQITIrjWbs=3D">
     a8zpjgRcO1VHZ9CoqU19/jB7nn58Gzu5/sQm8YQe4F9zz+YKUfqTS9LaHcqdAwa
     z8BG1a24Z72VYb5Ptjh7nQ19f5QQdA/P4lZ3oqeTJTsA4DkhvJaSUhrjYib/NOk
     3lkMoatR/OSbfvhPdqXQ/dutLuRFjkilXGVwNWkgLm3iSnKUiYSdUzWvj88RgR3
     ldVHFeyrdgufU9qu/FyO6MZXjfEtD80O+3ZBbESqllzmYFXnfkzBrhfi14iCba6
     /b5Io5zhFUyWaq5e6qq2z72a+1bjeWkG8F9XBiMkyaxkB64wAS0o6aDpWdir5Oi
     +Rnms4LV/wxL4Is/oe8Fo9xR3UmrdlAiaehdGBh+EnJGqprKa9eccOKqSu7/lJQ
     ObAdJGEOeAVs8JEkQkxw+qR8edkEDuv6ZXN7JCWQx9LNaiiwsfAzApJJbqfrtDx
     koQ3JaBbxQ+8FE3TM0E4Tbr9V8NDZC8abgBramlpUBfgknJvLYMTzx1lnsiCUxo
     6ezC0xqV
   </data>
 </e2e>
</message>

* Recipient requests message cipher information, providing its public =
key:

<iq xmlns=3D"jabber:client"
    from=3D"romeo@montegue.net/garden"
    id=3D"41a313f2bc"
    to=3D"juliet@capulet.net/balcony"
    type=3D"get">
  <keyreq xmlns=3D"urn:ietf:params:xml:ns:xmpp-objenc:1">
    <pubkey>
        OPfr4zudqiEeLcOQazZJIB6B9gx3zrVbyHKTU8a/aDb0wiZevztxxCi8hto0+Qw
        Foyhcupj547WbFZJNlB2dsAPhlJzeH9SuGLJShjhbkOyKjmqZLLCZr3OQtJjcTU
        sAVj7IZZsOOPDmwsb4Dxv5sz+icsDpi5l+5APfthDaoHbcrvz2pA1CJ5IFQoob4
        a0i0WevcAFyB+vWXsRqQCxjn5sHdb6G4vjQ/m1lzTWahzKvi56pNUm7ll18oI8L
        mPi1VWUEqH3aayGLVlJ9fhBDSSpW4jTQ/ts1nzPJwVlKdTqdgNBusFEhrRMhJD5
        1JdLOhxx+Ov2Xbs22++XQ1tS8/A=3D=3D
    </pubkey>
  </keyreq>
</iq>

* If accepted, sender provides message cipher information, encrypted =
using provided public key:

<iq xmlns=3D"jabber:client"
    from=3D"juliet@capulet.net/balcony"
    id=3D"41a313f2bc"
    to=3D"romeo@montegue.net/garden"
    type=3D"result">
  <keyreq xmlns=3D"urn:ietf:params:xml:ns:xmpp-objenc:1">
    <msgkey cipher-algo=3D"RSAES-OAEP-SHA-256-MFG1">
        OPfr4zudqiEeLcOQazZJIB6B9gx3zrVbyHKTU8a/aDb0wiZevztxxCi8hto0+Qw
        Foyhcupj547WbFZJNlB2dsAPhlJzeH9SuGLJShjhbkOyKjmqZLLCZr3OQtJjcTU
        sAVj7IZZsOOPDmwsb4Dxv5sz+icsDpi5l+5APfthDaoHbcrvz2pA1CJ5IFQoob4
        a0i0WevcAFyB+vWXsRqQCxjn5sHdb6G4vjQ/m1lzTWahzKvi56pNUm7ll18oI8L
        mPi1VWUEqH3aayGLVlJ9fhBDSSpW4jTQ/ts1nzPJwVlKdTqdgNBusFEhrRMhJD5
        1JdLOhxx+Ov2Xbs22++XQ1tS8/A=3D=3D
    </msgkey>
  </keyreq>
</iq>

I think this one deals with the key management problem better than my =
original proposal, and still has a chance to survive offline (e.g. the =
recipient comes online before the sender goes offline).  It's more =
individual stanzas, but less irrelevant data per stanza, which I think =
is an acceptable tradeoff.

I'm starting on a draft for my current direction; the specifics still =
need to be fleshed out, but I think this provides enough information we =
can start talking about it.


Thoughts?

- m&m

Matt Miller - <mamille2@cisco.com>
Collaboration Software Group - Cisco Systems, Inc.




--Apple-Mail-15--926987495
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNDE1NDcy
N1owIwYJKoZIhvcNAQkEMRYEFOW5oY2/smj9X5rl27zimMGFda33MIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQAa83V8S1yzCPx8pR4l/TuemqlX6omZLMOmmN3p2m51hrM559zw4y+wltqL
JLvA9IEY6Zm15GXM6scWLyAUUAxNbC2BtIsfkVTZ2KbXtu3lreYeneEKuxMNw9NTY4B74V+OlCA9
sws39OJGjs2cOkMcqvs/pYPCvBBfOLYGYyY7ivkeSNGGUeDQg+0n5+Q0afWSLc3f4qiRmXhf+L0y
PsACGWT8suk5LwkuZxRJh2GrJ/wMhMYL/lGatJlstrlReqdohsNq6XfOxMQo5u+BeT9Stz6s3AL+
hpALMchJ5lqaE7G0/2G8JctguPOI7u+t0pz4fkbVL28cDYnZZ5Ac+LAzAAAAAAAA

--Apple-Mail-15--926987495--

From ben@nostrum.com  Tue Jan 24 08:09:38 2012
Return-Path: <ben@nostrum.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC031F0C3E for <xmpp@ietfa.amsl.com>; Tue, 24 Jan 2012 08:09:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHzhIgUxZHZJ for <xmpp@ietfa.amsl.com>; Tue, 24 Jan 2012 08:09:38 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0078921F851E for <xmpp@ietf.org>; Tue, 24 Jan 2012 08:09:37 -0800 (PST)
Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0OG9aS0007924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jan 2012 10:09:37 -0600 (CST) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com>
Date: Tue, 24 Jan 2012 10:09:37 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <45FB1DCF-85F1-4275-A9D1-A3A8DC8A5850@nostrum.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com>
To: Matt Miller <mamille2@cisco.com>
X-Mailer: Apple Mail (2.1251.1)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 24 Jan 2012 16:09:38 -0000

(As individual, with apologies in advance if I rehash things already =
discussed)

On Jan 24, 2012, at 9:47 AM, Matt Miller wrote:

> I think this one deals with the key management problem better than my =
original proposal,

Can you elaborate on that?

> and still has a chance to survive offline (e.g. the recipient comes =
online before the sender goes offline).

That's not really an offline case then, is it? (Assuming the key request =
is e2e--does it have to be?)

>  It's more individual stanzas, but less irrelevant data per stanza, =
which I think is an acceptable tradeoff.

I infer from your overall wording we are talking about single-recipient =
cases, right? I don't recall, is MUC in scope?

The amount of data is based on the number of public keys per target =
recipient, right? And the relevancy of that data is based on whether the =
recipient tries to read the message using any particular public key? How =
many public keys do we expect, on average, a recipient to have?=20

>=20
> I'm starting on a draft for my current direction; the specifics still =
need to be fleshed out, but I think this provides enough information we =
can start talking about it.
>=20
>=20
> Thoughts?


From mamille2@cisco.com  Tue Jan 24 11:24:04 2012
Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540C711E809D for <xmpp@ietfa.amsl.com>; Tue, 24 Jan 2012 11:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJils5heMYxy for <xmpp@ietfa.amsl.com>; Tue, 24 Jan 2012 11:24:03 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 99E7211E8072 for <xmpp@ietf.org>; Tue, 24 Jan 2012 11:24:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6037; q=dns/txt; s=iport; t=1327433043; x=1328642643; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=OaQRBHEPkXWoF5d3fHVpKMRKEtxicIBEWwuuRTLD/S0=; b=Z9EtwKu3NC9xhbYIARUlffbY47H0Li4eT7EeOKOlcJu6koalLZ9wSm0S nFcAn5X6ANtblVRvqK+gkSN7Vcz4w9AuLw0vOC5jt1PZt7imiLs+krr+b Peab2ZRsymg1HP8e4avTRlsi5Gnh4VVZXVaCVvH8j8bdl/x5NEMVBx04l k=;
X-Files: smime.p7s : 2214
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAA0FH0+rRDoJ/2dsb2JhbABCrjWBBYFyAQEBAwESAWYFCwsYLgJVBhMih1qaAgGeGYkRDAkCAQoCIoJODwgPF1MBAQgDAQEQBoJSYwSIP4V7hmOSbg
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000";  d="p7s'?scan'208";a="26939565"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 24 Jan 2012 19:23:52 +0000
Received: from dhcp-64-101-72-218.cisco.com (dhcp-64-101-72-218.cisco.com [64.101.72.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0OJNpwD015827; Tue, 24 Jan 2012 19:23:51 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-1--913959398; protocol="application/pkcs7-signature"; micalg=sha1
From: Matt Miller <mamille2@cisco.com>
In-Reply-To: <45FB1DCF-85F1-4275-A9D1-A3A8DC8A5850@nostrum.com>
Date: Tue, 24 Jan 2012 12:24:35 -0700
Message-Id: <9866D7A2-A534-433A-9FCD-F3E43C968530@cisco.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <45FB1DCF-85F1-4275-A9D1-A3A8DC8A5850@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1084)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 24 Jan 2012 19:24:04 -0000

--Apple-Mail-1--913959398
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 24, 2012, at 09:09, Ben Campbell wrote:

> (As individual, with apologies in advance if I rehash things already =
discussed)
>=20
> On Jan 24, 2012, at 9:47 AM, Matt Miller wrote:
>=20
>> I think this one deals with the key management problem better than my =
original proposal,
>=20
> Can you elaborate on that?

I think it's better because, instead of the sender guessing which of the =
recipient's public keys to use, the send is told by the recipient which =
key (or maybe keys) to use.

It doesn't completely solve the problem, but it narrows the window of =
possibilities.

>=20
>> and still has a chance to survive offline (e.g. the recipient comes =
online before the sender goes offline).
>=20
> That's not really an offline case then, is it? (Assuming the key =
request is e2e--does it have to be?)
>=20

I'm not sure I would necessarily qualify the key request as e2e, but am =
willing to accept different interpretations.

>> It's more individual stanzas, but less irrelevant data per stanza, =
which I think is an acceptable tradeoff.
>=20
> I infer from your overall wording we are talking about =
single-recipient cases, right? I don't recall, is MUC in scope?
>=20

I have been concentrating on single-recipient, where "single-recipient" =
refers to the concept of a user (or something similar), which can have =
multiple end-points that represent or approximate that user.

I don't remember if MUC is strictly in scope, either.  At this point, =
I'm trying to not preclude it, and hoping for the best.

> The amount of data is based on the number of public keys per target =
recipient, right? And the relevancy of that data is based on whether the =
recipient tries to read the message using any particular public key? How =
many public keys do we expect, on average, a recipient to have?=20
>=20

The amount of data is based on the number of public keys per target =
recipient.  I don't have hard numbers here, but I have a need for at =
least 5 (desktop + mobile phone + tablet + 2 XMPP-enabled web apps), and =
the last two are ephemeral enough that it's possible to approach 10's of =
keys; the web-app needs to generate and publish a key-pair because it =
can't utilize any previous.

I'm not entirely sure how much of a problem size will really be, but I =
am concerned about the amount of wasted effort on the part of the sender =
(lots of encryption =3D=3D lots of cycles, lots of wasted encryption =3D=3D=
 lots of wasted cycles).  It could be an interesting attack...


- m&m

Matt Miller - <mamille2@cisco.com>
Collaboration Software Group - Cisco Systems, Inc.




--Apple-Mail-1--913959398
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNDE5MjQz
NVowIwYJKoZIhvcNAQkEMRYEFL97AuGb7qXStK8NEvCblohev4Q1MIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQCc76ap6SWVhWm9EQ0i11GvHEZXTTVZVthNcrYGfqP4RMIdua9ubFieLLud
JuBq0b4UQ/NWsO1wLAntwvGHtWlMTXhkuEHsGISq+SJznY37W51bxpUI3ipMgh43leiAkEet9ux8
ry8USFINrEGLXPppLqUm/caurk49Gj1MWi4dOGeB10ZWgOiGjBd71QsMSMhUgNDtTOrpgKKwME1N
vAkr0wzFXY33wu572l5A6+VTQ7JC/xC7cd6pO/BazD5cxlv8gptNrlKWinxegT8Kj1yZq8lf2BNO
hTMazxhItTC+hZjfpfTsl3qTmbuSu09bFU5V+fAQmtE39lwKMWONWILMAAAAAAAA

--Apple-Mail-1--913959398--

From holler@ahsoftware.de  Wed Jan 25 20:00:00 2012
Return-Path: <holler@ahsoftware.de>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B85811E80CD for <xmpp@ietfa.amsl.com>; Wed, 25 Jan 2012 20:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.739
X-Spam-Level: *
X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[AWL=0.370,  BAYES_20=-0.74, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+MDnj23pDGc for <xmpp@ietfa.amsl.com>; Wed, 25 Jan 2012 20:00:00 -0800 (PST)
Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFF811E809B for <xmpp@ietf.org>; Wed, 25 Jan 2012 19:59:59 -0800 (PST)
Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 3ABCBA8367; Thu, 26 Jan 2012 04:59:58 +0100 (CET)
Received: from eiche.ahsoftware (p57B2050F.dip0.t-ipconnect.de [87.178.5.15]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 2D3D3A8363 for <xmpp@ietf.org>; Thu, 26 Jan 2012 04:59:57 +0100 (CET)
Received: by eiche.ahsoftware (Postfix, from userid 65534) id B04A03FDA6; Thu, 26 Jan 2012 04:59:55 +0100 (CET)
Received: from [192.168.208.6] (unknown [192.168.208.6]) by eiche.ahsoftware (Postfix) with ESMTP id 80D493FDA6 for <xmpp@ietf.org>; Thu, 26 Jan 2012 03:59:53 +0000 (UTC)
Message-ID: <4F20CFD0.3070206@ahsoftware.de>
Date: Thu, 26 Jan 2012 05:00:16 +0100
From: Alexander Holler <holler@ahsoftware.de>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110501 Thunderbird/3.3a3
MIME-Version: 1.0
To: xmpp@ietf.org
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com>
In-Reply-To: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 04:00:00 -0000

On 24.01.2012 16:47, Matt Miller wrote:
> * sender encrypts stanza using message cipher
> * sender generates a single stanza, which contains the encrypted data ONLY:
...
> * Recipient requests message cipher information, providing its public key:
...
> * If accepted, sender provides message cipher information, encrypted using provided public key:


> Thoughts?

If a recipient has to dial back, than why sending any encrypted data at
all in the first step? A digest or something similiar would be enough
for the recipient to pull the message later on.

Regards,

Alexander

From stpeter@stpeter.im  Wed Jan 25 20:11:25 2012
Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5255B21F85EE for <xmpp@ietfa.amsl.com>; Wed, 25 Jan 2012 20:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.652
X-Spam-Level: 
X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBvDO1VSkUbx for <xmpp@ietfa.amsl.com>; Wed, 25 Jan 2012 20:11:24 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 220F821F85B7 for <xmpp@ietf.org>; Wed, 25 Jan 2012 20:11:20 -0800 (PST)
Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 601D940058; Wed, 25 Jan 2012 21:21:07 -0700 (MST)
Message-ID: <4F20D267.5070109@stpeter.im>
Date: Wed, 25 Jan 2012 21:11:19 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Alexander Holler <holler@ahsoftware.de>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <4F20CFD0.3070206@ahsoftware.de>
In-Reply-To: <4F20CFD0.3070206@ahsoftware.de>
X-Enigmail-Version: 1.3.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 04:11:25 -0000

On 1/25/12 9:00 PM, Alexander Holler wrote:
> On 24.01.2012 16:47, Matt Miller wrote:
>> * sender encrypts stanza using message cipher
>> * sender generates a single stanza, which contains the encrypted data ONLY:
> ...
>> * Recipient requests message cipher information, providing its public key:
> ...
>> * If accepted, sender provides message cipher information, encrypted using provided public key:
> 
> 
>> Thoughts?
> 
> If a recipient has to dial back, than why sending any encrypted data at
> all in the first step? A digest or something similiar would be enough
> for the recipient to pull the message later on.

Interesting. That would be similar to IM2000:

http://cr.yp.to/im2000.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From holler@ahsoftware.de  Wed Jan 25 20:24:40 2012
Return-Path: <holler@ahsoftware.de>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7320F21F8513 for <xmpp@ietfa.amsl.com>; Wed, 25 Jan 2012 20:24:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.625
X-Spam-Level: 
X-Spam-Status: No, score=0.625 tagged_above=-999 required=5 tests=[AWL=1.115,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc0jOEq7awpV for <xmpp@ietfa.amsl.com>; Wed, 25 Jan 2012 20:24:39 -0800 (PST)
Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC0C21F8507 for <xmpp@ietf.org>; Wed, 25 Jan 2012 20:24:39 -0800 (PST)
Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 79564A8366; Thu, 26 Jan 2012 05:24:38 +0100 (CET)
Received: from eiche.ahsoftware (p57B207EC.dip0.t-ipconnect.de [87.178.7.236]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id E5759A8366 for <xmpp@ietf.org>; Thu, 26 Jan 2012 05:24:36 +0100 (CET)
Received: by eiche.ahsoftware (Postfix, from userid 65534) id E5BCE3FDCA; Thu, 26 Jan 2012 05:24:34 +0100 (CET)
Received: from [192.168.208.6] (unknown [192.168.208.6]) by eiche.ahsoftware (Postfix) with ESMTP id 97DC43FDA6; Thu, 26 Jan 2012 04:24:33 +0000 (UTC)
Message-ID: <4F20D598.9050504@ahsoftware.de>
Date: Thu, 26 Jan 2012 05:24:56 +0100
From: Alexander Holler <holler@ahsoftware.de>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110501 Thunderbird/3.3a3
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <4F20CFD0.3070206@ahsoftware.de> <4F20D267.5070109@stpeter.im>
In-Reply-To: <4F20D267.5070109@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 04:24:40 -0000

On 26.01.2012 05:11, Peter Saint-Andre wrote:
> On 1/25/12 9:00 PM, Alexander Holler wrote:
>> On 24.01.2012 16:47, Matt Miller wrote:
>>> * sender encrypts stanza using message cipher
>>> * sender generates a single stanza, which contains the encrypted data ONLY:
>> ...
>>> * Recipient requests message cipher information, providing its public key:
>> ...
>>> * If accepted, sender provides message cipher information, encrypted using provided public key:
>>
>>
>>> Thoughts?
>>
>> If a recipient has to dial back, than why sending any encrypted data at
>> all in the first step? A digest or something similiar would be enough
>> for the recipient to pull the message later on.
> 
> Interesting. That would be similar to IM2000:
> 
> http://cr.yp.to/im2000.html

Thinking further it will end in a pubsub-extension. ;)

Regards,

Alexander


From gdt@ir.bbn.com  Thu Jan 26 05:15:49 2012
Return-Path: <gdt@ir.bbn.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A3021F86E8 for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 05:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.045
X-Spam-Level: 
X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.555,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZjMYHOdOo0u for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 05:15:48 -0800 (PST)
Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [IPv6:2001:4978:1fb:6400::d2]) by ietfa.amsl.com (Postfix) with ESMTP id 96DF121F86E1 for <xmpp@ietf.org>; Thu, 26 Jan 2012 05:15:48 -0800 (PST)
Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 161A353B3; Thu, 26 Jan 2012 08:15:48 -0500 (EST)
From: Greg Troxel <gdt@ir.bbn.com>
To: Matt Miller <mamille2@cisco.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com>
OpenPGP: id=32611E25
X-Hashcash: 1:20:120126:mamille2@cisco.com::9sPeKTIl6M1ZXS0m:000000000000000000000000000000000000000000038UV
X-Hashcash: 1:20:120126:xmpp@ietf.org::L5PKMTfuFbRK/Vc2:0000957p
Date: Thu, 26 Jan 2012 08:15:48 -0500
In-Reply-To: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> (Matt Miller's message of "Tue, 24 Jan 2012 08:47:26 -0700")
Message-ID: <rmik44ea9kr.fsf@fnord.ir.bbn.com>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 13:15:49 -0000

--=-=-=
Content-Type: text/plain


An additional concern is the lack of perfect forward secrecy.  Given
that xmpp is often interactive, PFS seems achievable.  And, it seems to
me that e2e encryption without PFS risks appearing to give users more
confidentiality than they actually get.



--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (NetBSD)

iEYEARECAAYFAk8hUgQACgkQ+vesoDJhHiVThQCfUT77MtZ5y5qWBVWe5FVoH+XJ
vyIAoIqEMuT0vYE04riaYgbM7ovyuYjd
=9/rU
-----END PGP SIGNATURE-----
--=-=-=--

From mamille2@cisco.com  Thu Jan 26 06:59:13 2012
Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A96021F84BF for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 06:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lub+bYRFKj91 for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 06:59:12 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B100C21F84B9 for <xmpp@ietf.org>; Thu, 26 Jan 2012 06:59:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=3928; q=dns/txt; s=iport; t=1327589952; x=1328799552; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=YJf21eA9/vfry5N3XmQTQKGLtX8oDvfUn8HbJTqat0I=; b=l8ggs9NH/7wb1QytLmlWDKg7qQ+SmNiVxbCvGt9EDaKLBSYFDV2/ZsF0 6FeKQHCNNZyc/cluYSS7qsz5nKob+Kykfw9Y6n0W32hons6wmCfcjIlHR z0RC9KjnZ/NdGoVXcaWMOJFdDg2JsgGrkQ4xMA7nCk6aXErs1FUme5PqI 4=;
X-Files: smime.p7s : 2214
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANdpIU+rRDoG/2dsb2JhbABCrkuBBYFyAQEBAwESAWYQCw44AlUGEyKHWplRAZ5DiSIODhABCAEGBAMDBAcYAwECgnAaAg4CBnUHBgUBH4JaYwSIP4V9hmOScQ
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000";  d="p7s'?scan'208";a="27259208"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 26 Jan 2012 14:59:12 +0000
Received: from dhcp-64-101-72-224.cisco.com (dhcp-64-101-72-224.cisco.com [64.101.72.224]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0QExBdm020854; Thu, 26 Jan 2012 14:59:11 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-1--757036123; protocol="application/pkcs7-signature"; micalg=sha1
From: Matt Miller <mamille2@cisco.com>
In-Reply-To: <rmik44ea9kr.fsf@fnord.ir.bbn.com>
Date: Thu, 26 Jan 2012 07:59:58 -0700
Message-Id: <88AFC593-BE91-4FF6-8CDE-9B83EF3A9A40@cisco.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <rmik44ea9kr.fsf@fnord.ir.bbn.com>
To: Greg Troxel <gdt@ir.bbn.com>
X-Mailer: Apple Mail (2.1084)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 14:59:13 -0000

--Apple-Mail-1--757036123
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 26, 2012, at 06:15, Greg Troxel wrote:

>=20
> An additional concern is the lack of perfect forward secrecy.  Given
> that xmpp is often interactive, PFS seems achievable.  And, it seems =
to
> me that e2e encryption without PFS risks appearing to give users more
> confidentiality than they actually get.
>=20
>=20

The concern is noted.  I don't think there's enough with my latest =
strawman to declare PFS failure or success yet.


- m&m

Matt Miller - <mamille2@cisco.com>
Collaboration Software Group - Cisco Systems, Inc.




--Apple-Mail-1--757036123
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNjE0NTk1
OFowIwYJKoZIhvcNAQkEMRYEFHyaywkQOrvOwhcUAm0n82FJxqbhMIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQCT14gC6MVllGpmBJuymJBUnijQ9LoGGTbknwzyu95h4Ogj/jRJkNHyjTbM
WVrTJ+yytIQEyRWzaqpjCAdsnfNgBvyo1VyWtrZ1PdtvwQOFVXhy77iGDXakJzzcfiJtzt8wQSWf
sa2/wNYQraazf1ounJEpwosrUFt/d3DL4zfRaImqh+x4IwD9y5UD/FGHXEkSz2IXcg+wjdLxIlOm
sMFz5sxc4xQ7/wnkgpkPpLtLDa0KU1mj1kjG6f60jY+AkhVIsMv+tE1gb4whASURD46arSXy4uQI
VJ2f157yW2LPflde79YRrRtckTsdOnruGZI+M/pM5fKzP5lYe6E+oeR0AAAAAAAA

--Apple-Mail-1--757036123--

From mamille2@cisco.com  Thu Jan 26 07:20:09 2012
Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C60621F8620 for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 07:20:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.582
X-Spam-Level: 
X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2PwKNhdqGqu for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 07:20:08 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9EE21F8617 for <xmpp@ietf.org>; Thu, 26 Jan 2012 07:20:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=4894; q=dns/txt; s=iport; t=1327591208; x=1328800808; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=/7aKeB5J23hv7SL+EgrDPQRlByXpHBDJoAa6F6f6040=; b=XtF9hUgeMpQzkyWxtP2NaqZyIlCqk7SRkO0zFtNzJC0J3b1JQPhvvFaQ jSuTGtZkSGwL24BZLb2XX6uiiYc7L2m9VZEFPQpluF9XzqEt544njb4uJ c1FJAT+liFJ8vHV94ewe4niDwexirscI3WPAgfqEBl/vyoosJzW6GCcRQ g=;
X-Files: smime.p7s : 2214
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAI9uIU+rRDoI/2dsb2JhbABCrkuBBYFyAQEBAwESAWYFCwsYLgJVBhMih1oImTwBnkKJIg4OEAEIAQYEAwMEBxsDgnAaAg4CBnUHBgUBHwmCUWMEiD+FfYZjknE
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000";  d="p7s'?scan'208";a="27261791"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 26 Jan 2012 15:20:08 +0000
Received: from dhcp-64-101-72-224.cisco.com (dhcp-64-101-72-224.cisco.com [64.101.72.224]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0QFK7cK002743; Thu, 26 Jan 2012 15:20:08 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-5--755779685; protocol="application/pkcs7-signature"; micalg=sha1
From: Matt Miller <mamille2@cisco.com>
In-Reply-To: <4F20CFD0.3070206@ahsoftware.de>
Date: Thu, 26 Jan 2012 08:20:54 -0700
Message-Id: <9DD11482-8E87-497F-8AC4-B76496B263E0@cisco.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <4F20CFD0.3070206@ahsoftware.de>
To: Alexander Holler <holler@ahsoftware.de>
X-Mailer: Apple Mail (2.1084)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 15:20:09 -0000

--Apple-Mail-5--755779685
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 25, 2012, at 21:00, Alexander Holler wrote:

> On 24.01.2012 16:47, Matt Miller wrote:
>> * sender encrypts stanza using message cipher
>> * sender generates a single stanza, which contains the encrypted data =
ONLY:
> ...
>> * Recipient requests message cipher information, providing its public =
key:
> ...
>> * If accepted, sender provides message cipher information, encrypted =
using provided public key:
>=20
>=20
>> Thoughts?
>=20
> If a recipient has to dial back, than why sending any encrypted data =
at
> all in the first step? A digest or something similiar would be enough
> for the recipient to pull the message later on.
>=20

Part of my reasoning is the follow-on <message/>s as other end-points =
for the recipient (and possibly the sender!) become available.  I would =
like the flow for "cold start" to be as similar to "arrives in the =
middle" as possible.  And, yes, I do realize that wording probably makes =
it sound scarier that it actually is.

This is because there are XMPP technologies in development and use that =
fork messages across all available non-negative resources, such as =
Carbons[1].  There's also MUC[2], which it would be nice if the e2e work =
extended into it without significant changes.


- m&m

Matt Miller - <mamille2@cisco.com>
Collaboration Software Group - Cisco Systems, Inc.

[1] XEP-0280: Message Carbons <http://xmpp.org/extensions/xep-0280.html>
[2] XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>


--Apple-Mail-5--755779685
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNjE1MjA1
NVowIwYJKoZIhvcNAQkEMRYEFHvb32BAqaw9ZG32kilfO1rlThcxMIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQB6rvDagkeG+mHpq7zpnVPgfdzMjrKw4ZRljkWVaXrrbAhEEnOGLYX2sk8v
JPVupAnC3odBvXS27eZoFn/55iReX60RG1Q8TToIArOpuvgrDtncEUG3gq7iJiZhKMQEyj6FghsW
ktMXzecNl/PEqKAWh4WXFdkUlVKGGKk0e565HO9Q4JuDNzEnoHXkON0njmZiWs5+uQqrURvSnZnr
dVOfD35vFlSL2eGIW5niGTSR9Ci3WedmqGb8hajklTEuN6wbkfTnR1yQckJQ3s/CRFzD9QDEC6on
V6l5gnKcvhL0QStc6GQ5QCmSVFH2smN/I+iIe2y7maxf8E4Zq2glwHnwAAAAAAAA

--Apple-Mail-5--755779685--

From rbarnes@bbn.com  Thu Jan 26 07:21:24 2012
Return-Path: <rbarnes@bbn.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF43821F8617 for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 07:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.026
X-Spam-Level: 
X-Spam-Status: No, score=-106.026 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmEXuftxiRs0 for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 07:21:23 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id F31CE21F863F for <xmpp@ietf.org>; Thu, 26 Jan 2012 07:21:22 -0800 (PST)
Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:59286) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1RqR8a-000EQt-Gf; Thu, 26 Jan 2012 10:21:20 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <88AFC593-BE91-4FF6-8CDE-9B83EF3A9A40@cisco.com>
Date: Thu, 26 Jan 2012 10:21:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6B0D079-5406-4633-BF13-603B725AB9A3@bbn.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <rmik44ea9kr.fsf@fnord.ir.bbn.com> <88AFC593-BE91-4FF6-8CDE-9B83EF3A9A40@cisco.com>
To: Matt Miller <mamille2@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 15:21:25 -0000

I wonder if PFS is actually worth the cost in this case.  It seems like =
in the great majority of cases, the private key is going to reside on =
the same device as possible plaintext message logs.  So if an attacker =
gets access to the private key (other than by cryptanalysis) then he =
could have stolen the logs anyway.  Even without PFS, then, the security =
considerations are the same as before -- if you want forward secrecy, =
delete the messages.

OTOH, the cost is an additional RTT with each recipient with a few KB of =
crypto payload.  Seems like that could get expensive quickly.

Just a thought,
--Richard



On Jan 26, 2012, at 9:59 AM, Matt Miller wrote:

>=20
> On Jan 26, 2012, at 06:15, Greg Troxel wrote:
>=20
>>=20
>> An additional concern is the lack of perfect forward secrecy.  Given
>> that xmpp is often interactive, PFS seems achievable.  And, it seems =
to
>> me that e2e encryption without PFS risks appearing to give users more
>> confidentiality than they actually get.
>>=20
>>=20
>=20
> The concern is noted.  I don't think there's enough with my latest =
strawman to declare PFS failure or success yet.
>=20
>=20
> - m&m
>=20
> Matt Miller - <mamille2@cisco.com>
> Collaboration Software Group - Cisco Systems, Inc.
>=20
>=20
>=20
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp


From gdt@ir.bbn.com  Thu Jan 26 07:27:58 2012
Return-Path: <gdt@ir.bbn.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF5D21F8599 for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 07:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Level: 
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.370,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mn0SxEYiORRx for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 07:27:58 -0800 (PST)
Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [IPv6:2001:4978:1fb:6400::d2]) by ietfa.amsl.com (Postfix) with ESMTP id CD21D21F8596 for <xmpp@ietf.org>; Thu, 26 Jan 2012 07:27:57 -0800 (PST)
Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id CE53553B3; Thu, 26 Jan 2012 10:27:56 -0500 (EST)
From: Greg Troxel <gdt@ir.bbn.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <rmik44ea9kr.fsf@fnord.ir.bbn.com> <88AFC593-BE91-4FF6-8CDE-9B83EF3A9A40@cisco.com> <D6B0D079-5406-4633-BF13-603B725AB9A3@bbn.com>
OpenPGP: id=32611E25
X-Hashcash: 1:20:120126:mamille2@cisco.com::sP62EVVZ+q11YXpC:000000000000000000000000000000000000000000002JT
X-Hashcash: 1:20:120126:rbarnes@bbn.com::eCF+SNm5L0XRt3v7:0026zS
X-Hashcash: 1:20:120126:xmpp@ietf.org::VB1uCjHfh8tuuY8m:0000319G
Date: Thu, 26 Jan 2012 10:27:56 -0500
In-Reply-To: <D6B0D079-5406-4633-BF13-603B725AB9A3@bbn.com> (Richard L. Barnes's message of "Thu, 26 Jan 2012 10:21:19 -0500")
Message-ID: <rmiobtq8ow3.fsf@fnord.ir.bbn.com>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (berkeley-unix)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 15:27:58 -0000

--=-=-=
Content-Type: text/plain


"Richard L. Barnes" <rbarnes@bbn.com> writes:

> I wonder if PFS is actually worth the cost in this case.  It seems
> like in the great majority of cases, the private key is going to
> reside on the same device as possible plaintext message logs.  So if
> an attacker gets access to the private key (other than by
> cryptanalysis) then he could have stolen the logs anyway.  Even
> without PFS, then, the security considerations are the same as before
> -- if you want forward secrecy, delete the messages.

Agreed - obviously you have to not keep logs.  I was thinking of the no
log case, since I don't log xmpp.

That raises the question of whether there should be the equivalent of an
X-No-Archive: flag to ask that counterparties not log.  Obviously that's
not enforceable, but it may make sense for an implementation that
doesn't respect that to be deemed noncompliant.

> OTOH, the cost is an additional RTT with each recipient with a few KB
> of crypto payload.  Seems like that could get expensive quickly.

With pairwise chat (vs conferencing), the cost seems quite low (in my
own use of OTR), one extra RTT per conversation/client restart.  With
multiparty conferencing, then it could be more expensive, and the
security gains of PFS are perhaps illusory anyway.  (Sorry if I jumped
into a multi-party thread with two-party assumptions.)

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (NetBSD)

iEYEARECAAYFAk8hcPwACgkQ+vesoDJhHiVFrQCfaPVOvtSA7UdQaCkwpPdY6+uz
UQMAoKpLYyY9u1AaNRKRUZXV9n+ij7G1
=5cjC
-----END PGP SIGNATURE-----
--=-=-=--

From rbarnes@bbn.com  Thu Jan 26 07:38:09 2012
Return-Path: <rbarnes@bbn.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDBB21F865A for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 07:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.074
X-Spam-Level: 
X-Spam-Status: No, score=-106.074 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dkf13ZfEEM3J for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 07:38:09 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9C821F8644 for <xmpp@ietf.org>; Thu, 26 Jan 2012 07:38:09 -0800 (PST)
Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:59349) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1RqROq-000EgT-1m; Thu, 26 Jan 2012 10:38:08 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <9866D7A2-A534-433A-9FCD-F3E43C968530@cisco.com>
Date: Thu, 26 Jan 2012 10:38:07 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <AD921ED7-4B41-4905-9779-7B15BF9317FB@bbn.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <45FB1DCF-85F1-4275-A9D1-A3A8DC8A5850@nostrum.com> <9866D7A2-A534-433A-9FCD-F3E43C968530@cisco.com>
To: Matt Miller <mamille2@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 15:38:10 -0000

>>> I think this one deals with the key management problem better than =
my original proposal,
>>=20
>> Can you elaborate on that?
>=20
> I think it's better because, instead of the sender guessing which of =
the recipient's public keys to use, the send is told by the recipient =
which key (or maybe keys) to use.

It seems like these two mechanisms don't necessarily have to be mutually =
exclusive.  You can send to recipients for which you have cached keys =
immediately, then keep this "I would like the key" interface open to =
allow additional recipients. =20

In the first case, maybe you could optimize a little over the base case =
with the following pattern:

1. Sender sends message keys to each recipient with a known key, along =
with a digest of the message they go along with.
<key cipher-algo=3D"RSAES-OAEP-SHA-256-MFG1"
     id=3D"recipient-key-1"
     msgid=3D"580CCA51-9AA7-4BB0-817D-ADB3C1A9EFBC"
     digest=3D"di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc">
...
</key>

2. Sender sends message content multicast to all recipients
<data id=3D"580CCA51-9AA7-4BB0-817D-ADB3C1A9EFBC"
      cipher-algo=3D"AES-256-CBC-PKCS5-WITH-IV"
      mac-algo=3D"HMACSHA256"
      mac-data=3D"HSGmwUFd4sESB+O12S32xsXVvMnO4gjRPaQITIrjWbs=3D" >
...
</data>

That way:
  * Key blocks only get sent to target recipients
  * No additional stanzas for key exchange when keys known

--Richard=

From holler@ahsoftware.de  Thu Jan 26 08:05:33 2012
Return-Path: <holler@ahsoftware.de>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D130921F85FC for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 08:05:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.253
X-Spam-Level: 
X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=0.743,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhO-bMUTia7c for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 08:05:33 -0800 (PST)
Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2308E21F864F for <xmpp@ietf.org>; Thu, 26 Jan 2012 08:05:33 -0800 (PST)
Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 9003EA8369; Thu, 26 Jan 2012 17:05:31 +0100 (CET)
Received: from eiche.ahsoftware (p57B207EC.dip0.t-ipconnect.de [87.178.7.236]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id C9635A8369 for <xmpp@ietf.org>; Thu, 26 Jan 2012 17:05:30 +0100 (CET)
Received: by eiche.ahsoftware (Postfix, from userid 65534) id 2F6953FDD2; Thu, 26 Jan 2012 17:05:28 +0100 (CET)
Received: from krabat.ahsoftware (unknown [192.168.207.2]) by eiche.ahsoftware (Postfix) with ESMTP id EA3383FCD4; Thu, 26 Jan 2012 16:05:18 +0000 (UTC)
Message-ID: <4F2179BD.8060808@ahsoftware.de>
Date: Thu, 26 Jan 2012 17:05:17 +0100
From: Alexander Holler <holler@ahsoftware.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Matt Miller <mamille2@cisco.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <4F20CFD0.3070206@ahsoftware.de> <9DD11482-8E87-497F-8AC4-B76496B263E0@cisco.com>
In-Reply-To: <9DD11482-8E87-497F-8AC4-B76496B263E0@cisco.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 16:05:33 -0000

Am 26.01.2012 16:20, schrieb Matt Miller:
>
> On Jan 25, 2012, at 21:00, Alexander Holler wrote:
>
>> On 24.01.2012 16:47, Matt Miller wrote:
>>> * sender encrypts stanza using message cipher
>>> * sender generates a single stanza, which contains the encrypted data ONLY:
>> ...
>>> * Recipient requests message cipher information, providing its public key:
>> ...
>>> * If accepted, sender provides message cipher information, encrypted using provided public key:
>>
>>
>>> Thoughts?
>>
>> If a recipient has to dial back, than why sending any encrypted data at
>> all in the first step? A digest or something similiar would be enough
>> for the recipient to pull the message later on.
>>
>
> Part of my reasoning is the follow-on<message/>s as other end-points for the recipient (and possibly the sender!) become available.  I would like the flow for "cold start" to be as similar to "arrives in the middle" as possible.  And, yes, I do realize that wording probably makes it sound scarier that it actually is.
>
> This is because there are XMPP technologies in development and use that fork messages across all available non-negative resources, such as Carbons[1].  There's also MUC[2], which it would be nice if the e2e work extended into it without significant changes.

Hmm, carbon is new for me, thanks for the pointer. Have to read that.

But in regard to MUC I don't see a problem (at a first glance) if just 
hashes would send around, while leaving the content on the senders 
server until the recipient actually decides to fetch it.

But I've missed the beginning of the discussion about e2e, and don't 
know what are all the targets of it.

The problem (with the im2000-concept) would be to decide how long the 
content is stored, but that looks for me somewhat comparable to decide 
how long the message cipher is available (and to whom) in your approach.

Regards,

Alexander

From mamille2@cisco.com  Thu Jan 26 09:37:50 2012
Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D8021F86D1 for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 09:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.584
X-Spam-Level: 
X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYFgwgDY7xNv for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 09:37:50 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2E59B21F84AA for <xmpp@ietf.org>; Thu, 26 Jan 2012 09:37:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5783; q=dns/txt; s=iport; t=1327599470; x=1328809070; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=l17nF69ri8PxlrCJ9cQRD3NyGOphIg5pWbpDWz2dWKQ=; b=fmwXKjf3MmNZA+qeI+6h4wsDYLqxBlZfFf+gIP3GCQGCGXUCpR3NnBxX 3dA7iPEAeK2NQiBjdY6IACoSgCQpIyTdrzyYPJf6FP7nd2ebcS7LmTRKn n6dvvMIYd7AlMW9ADMHN1S0Z84uMXL2GAB7UYdsQcQUmOVQt3/GTjekXj E=;
X-Files: smime.p7s : 2214
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EACSOIU+rRDoJ/2dsb2JhbABCrkuBBYFyAQEBAwESAWYFCwsYLgJVBhMih1qZPgGeRokiDg4QAQgBBgQDAwQHHoJwGgIOAgZ1BwYFAR8JglFjBIg/hX2GY5Jx
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000";  d="p7s'?scan'208";a="27106805"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 26 Jan 2012 17:37:50 +0000
Received: from dhcp-64-101-72-224.cisco.com (dhcp-64-101-72-224.cisco.com [64.101.72.224]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0QHbnKY006913; Thu, 26 Jan 2012 17:37:49 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-12--747517957; protocol="application/pkcs7-signature"; micalg=sha1
From: Matt Miller <mamille2@cisco.com>
In-Reply-To: <4F2179BD.8060808@ahsoftware.de>
Date: Thu, 26 Jan 2012 10:38:36 -0700
Message-Id: <B306E405-4AF2-4AD7-A24E-5677BACF957D@cisco.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <4F20CFD0.3070206@ahsoftware.de> <9DD11482-8E87-497F-8AC4-B76496B263E0@cisco.com> <4F2179BD.8060808@ahsoftware.de>
To: Alexander Holler <holler@ahsoftware.de>
X-Mailer: Apple Mail (2.1084)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 17:37:50 -0000

--Apple-Mail-12--747517957
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 26, 2012, at 09:05, Alexander Holler wrote:

> Am 26.01.2012 16:20, schrieb Matt Miller:
>>=20
>> On Jan 25, 2012, at 21:00, Alexander Holler wrote:
>>=20
>>> On 24.01.2012 16:47, Matt Miller wrote:
>>>> * sender encrypts stanza using message cipher
>>>> * sender generates a single stanza, which contains the encrypted =
data ONLY:
>>> ...
>>>> * Recipient requests message cipher information, providing its =
public key:
>>> ...
>>>> * If accepted, sender provides message cipher information, =
encrypted using provided public key:
>>>=20
>>>=20
>>>> Thoughts?
>>>=20
>>> If a recipient has to dial back, than why sending any encrypted data =
at
>>> all in the first step? A digest or something similiar would be =
enough
>>> for the recipient to pull the message later on.
>>>=20
>>=20
>> Part of my reasoning is the follow-on<message/>s as other end-points =
for the recipient (and possibly the sender!) become available.  I would =
like the flow for "cold start" to be as similar to "arrives in the =
middle" as possible.  And, yes, I do realize that wording probably makes =
it sound scarier that it actually is.
>>=20
>> This is because there are XMPP technologies in development and use =
that fork messages across all available non-negative resources, such as =
Carbons[1].  There's also MUC[2], which it would be nice if the e2e work =
extended into it without significant changes.
>=20
> Hmm, carbon is new for me, thanks for the pointer. Have to read that.
>=20
> But in regard to MUC I don't see a problem (at a first glance) if just =
hashes would send around, while leaving the content on the senders =
server until the recipient actually decides to fetch it.
>=20

That sounds like a pretty radical change to the XMPP infrastructure.  =
I'd really like to avoid that if at all possible.

> But I've missed the beginning of the discussion about e2e, and don't =
know what are all the targets of it.
>=20
> The problem (with the im2000-concept) would be to decide how long the =
content is stored, but that looks for me somewhat comparable to decide =
how long the message cipher is available (and to whom) in your approach.
>=20

There might be some comparisons, and we can see glance in occasionally =
on where that's going.


- m&m

Matt Miller - <mamille2@cisco.com>
Collaboration Software Group - Cisco Systems, Inc.




--Apple-Mail-12--747517957
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNjE3Mzgz
NlowIwYJKoZIhvcNAQkEMRYEFAzcONpaHWOjCHUxr08tyapwhCAWMIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQClB2oi4rpyUdOfOPtjuwoGndii86QZ9n7diCPPTGkpO8CgC4Zg8ExXnEhq
gtwutrLKJOdZ6oiu70mNfqgE0fUdQD2YZqHMMPmJ8VN5K2fxem1gYFz+IemDynwckrdsSe71w/yq
pNiyCqOvJyemT5vTMn1zTOsRa5ZA5uGo0hSwGRTgC+t53uWhP65cjH0ow2e7amhU370IP/QClH7B
5OeQOSYCclKGtuZ39W5qlejp5KtP7zftoxs2NAvyhZORxl97Re0cJhc0kC+O7hoPNunQytOeuvJj
lVSeuYgcbskTVl5g+OoByjKNY3MQ9524bA18XXWzhp+rze8H9n5jttstAAAAAAAA

--Apple-Mail-12--747517957--

From mamille2@cisco.com  Thu Jan 26 13:37:13 2012
Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC1F21F8471 for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 13:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.585
X-Spam-Level: 
X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhg8ojpIemYE for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 13:37:12 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF0221F8462 for <xmpp@ietf.org>; Thu, 26 Jan 2012 13:37:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5152; q=dns/txt; s=iport; t=1327613832; x=1328823432; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=0bNgyK63d8dQe1aQL4zk7eFmuMtMFao6DVatzFoGRv8=; b=CljXrfV11U4M3bKteiB8k57kF39UpJtoW9kIlWM6YN3IGRvjcBgT75LL ci+kJk0ynAfsZLPMEF0ZR0OBKhaauZKaj4Xq7tCNKamyzkzAbgfZMEy/O 0ZqpzicHI4CKVcTJUBhNU0OOjywx0kIEzZPanKElLhajsrtcJX3eXO/UN 8=;
X-Files: smime.p7s : 2214
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAHDGIU+rRDoG/2dsb2JhbABCrk6BBYFyAQEBBBIBZhALRgJVBhMioScBnjuJIg4OEAEIAQYEAwMEBxsDgnAaAg4CBnUHBgUBgnljBIg/hX2GY5Jx
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000";  d="p7s'?scan'208";a="27321971"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 26 Jan 2012 21:37:12 +0000
Received: from dhcp-64-101-72-224.cisco.com (dhcp-64-101-72-224.cisco.com [64.101.72.224]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0QLbBfZ027621; Thu, 26 Jan 2012 21:37:12 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-16--733155909; protocol="application/pkcs7-signature"; micalg=sha1
From: Matt Miller <mamille2@cisco.com>
In-Reply-To: <AD921ED7-4B41-4905-9779-7B15BF9317FB@bbn.com>
Date: Thu, 26 Jan 2012 14:37:58 -0700
Message-Id: <0A8832E6-82D4-4141-83CF-94D2234EF72E@cisco.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <45FB1DCF-85F1-4275-A9D1-A3A8DC8A5850@nostrum.com> <9866D7A2-A534-433A-9FCD-F3E43C968530@cisco.com> <AD921ED7-4B41-4905-9779-7B15BF9317FB@bbn.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
X-Mailer: Apple Mail (2.1084)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 21:37:13 -0000

--Apple-Mail-16--733155909
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 26, 2012, at 08:38, Richard L. Barnes wrote:

>>>> I think this one deals with the key management problem better than =
my original proposal,
>>>=20
>>> Can you elaborate on that?
>>=20
>> I think it's better because, instead of the sender guessing which of =
the recipient's public keys to use, the send is told by the recipient =
which key (or maybe keys) to use.
>=20
> It seems like these two mechanisms don't necessarily have to be =
mutually exclusive.  You can send to recipients for which you have =
cached keys immediately, then keep this "I would like the key" interface =
open to allow additional recipients. =20
>=20
> In the first case, maybe you could optimize a little over the base =
case with the following pattern:
>=20
> 1. Sender sends message keys to each recipient with a known key, along =
with a digest of the message they go along with.
> <key cipher-algo=3D"RSAES-OAEP-SHA-256-MFG1"
>     id=3D"recipient-key-1"
>     msgid=3D"580CCA51-9AA7-4BB0-817D-ADB3C1A9EFBC"
>     digest=3D"di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc">
> ...
> </key>
>=20
> 2. Sender sends message content multicast to all recipients
> <data id=3D"580CCA51-9AA7-4BB0-817D-ADB3C1A9EFBC"
>      cipher-algo=3D"AES-256-CBC-PKCS5-WITH-IV"
>      mac-algo=3D"HMACSHA256"
>      mac-data=3D"HSGmwUFd4sESB+O12S32xsXVvMnO4gjRPaQITIrjWbs=3D" >
> ...
> </data>
>=20
> That way:
>  * Key blocks only get sent to target recipients
>  * No additional stanzas for key exchange when keys known
>=20
> --Richard

This seems reasonable.  As long as we're not relying on keys being =
known-good (which the original proposal did).


- m&m

Matt Miller - <mamille2@cisco.com>
Collaboration Software Group - Cisco Systems, Inc.




--Apple-Mail-16--733155909
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNjIxMzc1
OVowIwYJKoZIhvcNAQkEMRYEFFMXpPK3qNFlJ9Rjz3yUst6IMWinMIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQA2Kvb2oWNZRJtITSstaJfIc3Dxvz4Y3+ylqqMOjsG5jJPQn4FydbZAMzsq
Mp8vz7TvV+Yhks+De6oEaW6B29YhTh3ZQnmsIYFTXgxz0dTvaOquDKKMq75ORRmXselZ/TbLf0lt
7O7RSVQHjNNi2UT1M0vBTxDX6T7vfeGH+8g2jN68Ff++dS8+wT0T4g/fpnvmjM97fFoAImGqMSMI
0agZa8Y6t0TII+SrP0RV9vgCuUJLFmYtle4O22YH5KQxAVieZ3kXW3ZZuijNyQe8EQHDufhSbtkp
DqjAd2kINRMQHzjslsoIhEwjAGvUz07IitVVNZvVJ5zacio2BSuz9AF1AAAAAAAA

--Apple-Mail-16--733155909--

From rbarnes@bbn.com  Thu Jan 26 13:44:56 2012
Return-Path: <rbarnes@bbn.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA84621F875D for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 13:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.177
X-Spam-Level: 
X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqHCYrxjGstu for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 13:44:56 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 45CFA21F8749 for <xmpp@ietf.org>; Thu, 26 Jan 2012 13:44:56 -0800 (PST)
Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:63280) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1RqX7l-0003BX-SY; Thu, 26 Jan 2012 16:44:54 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <0A8832E6-82D4-4141-83CF-94D2234EF72E@cisco.com>
Date: Thu, 26 Jan 2012 16:44:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <774E153D-3F1C-43BB-8AE8-060C9D9EBBF2@bbn.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <45FB1DCF-85F1-4275-A9D1-A3A8DC8A5850@nostrum.com> <9866D7A2-A534-433A-9FCD-F3E43C968530@cisco.com> <AD921ED7-4B41-4905-9779-7B15BF9317FB@bbn.com> <0A8832E6-82D4-4141-83CF-94D2234EF72E@cisco.com>
To: Matt Miller <mamille2@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 21:44:56 -0000

For what definition of "good"?  Are you worried about someone =
unauthorized getting a message, or someone getting a message with a key =
the can no longer use (e.g., rollover, different device)?

The first definition is definitely a type of goodness we should require =
(key belongs or belonged to the right party). I agree the second is more =
difficult; that's where the dialback mechanism would be helpful ("Oops, =
you used the wrong key").

I do have to say, though, that the dialback mechanism does creep me out =
a little bit.  You need to know that the person asking for a key is the =
right person -- it's  not secure to just accept a public key because it =
came in a message from someone, but if you already know a key for =
someone you could have just used it in the first place.  So there's a =
residual need for some other authentication step here to bootstrap the =
public key distribution.

--Richard



On Jan 26, 2012, at 4:37 PM, Matt Miller wrote:

>=20
> On Jan 26, 2012, at 08:38, Richard L. Barnes wrote:
>=20
>>>>> I think this one deals with the key management problem better than =
my original proposal,
>>>>=20
>>>> Can you elaborate on that?
>>>=20
>>> I think it's better because, instead of the sender guessing which of =
the recipient's public keys to use, the send is told by the recipient =
which key (or maybe keys) to use.
>>=20
>> It seems like these two mechanisms don't necessarily have to be =
mutually exclusive.  You can send to recipients for which you have =
cached keys immediately, then keep this "I would like the key" interface =
open to allow additional recipients. =20
>>=20
>> In the first case, maybe you could optimize a little over the base =
case with the following pattern:
>>=20
>> 1. Sender sends message keys to each recipient with a known key, =
along with a digest of the message they go along with.
>> <key cipher-algo=3D"RSAES-OAEP-SHA-256-MFG1"
>>    id=3D"recipient-key-1"
>>    msgid=3D"580CCA51-9AA7-4BB0-817D-ADB3C1A9EFBC"
>>    digest=3D"di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc">
>> ...
>> </key>
>>=20
>> 2. Sender sends message content multicast to all recipients
>> <data id=3D"580CCA51-9AA7-4BB0-817D-ADB3C1A9EFBC"
>>     cipher-algo=3D"AES-256-CBC-PKCS5-WITH-IV"
>>     mac-algo=3D"HMACSHA256"
>>     mac-data=3D"HSGmwUFd4sESB+O12S32xsXVvMnO4gjRPaQITIrjWbs=3D" >
>> ...
>> </data>
>>=20
>> That way:
>> * Key blocks only get sent to target recipients
>> * No additional stanzas for key exchange when keys known
>>=20
>> --Richard
>=20
> This seems reasonable.  As long as we're not relying on keys being =
known-good (which the original proposal did).
>=20
>=20
> - m&m
>=20
> Matt Miller - <mamille2@cisco.com>
> Collaboration Software Group - Cisco Systems, Inc.
>=20
>=20
>=20


From mamille2@cisco.com  Thu Jan 26 14:02:28 2012
Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EBB21F858A for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 14:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.587
X-Spam-Level: 
X-Spam-Status: No, score=-8.587 tagged_above=-999 required=5 tests=[AWL=2.012,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkJVSzv-S6wH for <xmpp@ietfa.amsl.com>; Thu, 26 Jan 2012 14:02:28 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2C521F857A for <xmpp@ietf.org>; Thu, 26 Jan 2012 14:02:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6806; q=dns/txt; s=iport; t=1327615347; x=1328824947; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=G9OhG1TIfpUT5WbtAhxD5H9tTTxeqk/JLSxUM/tWDuw=; b=P8YrcHoNfVpKxEi5E7Y9bRefrfKjizMqOze0CoM8kRZkq2GOvjYkwkoG asT1jtZ0GlMNWaWbALhiQ8CYeNR27VYB1lAfS/MQNRviyHUpHIcE5C3xH soXc0k47j8QpYHYhhZxf2O3e7OemsfE3BtPMAVie+743GSzhSefeVC+70 M=;
X-Files: smime.p7s : 2214
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAEDMIU+Q/khM/2dsb2JhbABCrk6BBYFyAQEBAwESAWYFCwsYLgJVBhMih1qZPQGePYkiDg4QAQgBBgQDAwQHgw4aAg4CBnUHBgUBgnljBIg/hX2GY5Jx
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000";  d="p7s'?scan'208";a="127756244"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 26 Jan 2012 22:02:26 +0000
Received: from dhcp-64-101-72-224.cisco.com (dhcp-64-101-72-224.cisco.com [64.101.72.224]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0QM2Oje025515; Thu, 26 Jan 2012 22:02:25 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-17--731642987; protocol="application/pkcs7-signature"; micalg=sha1
From: Matt Miller <mamille2@cisco.com>
In-Reply-To: <774E153D-3F1C-43BB-8AE8-060C9D9EBBF2@bbn.com>
Date: Thu, 26 Jan 2012 15:03:11 -0700
Message-Id: <21194B8B-56E9-4EC1-B4A9-2B819DEBA45D@cisco.com>
References: <4C952ED1-E0DA-48DF-B8CB-FDD95276888A@cisco.com> <45FB1DCF-85F1-4275-A9D1-A3A8DC8A5850@nostrum.com> <9866D7A2-A534-433A-9FCD-F3E43C968530@cisco.com> <AD921ED7-4B41-4905-9779-7B15BF9317FB@bbn.com> <0A8832E6-82D4-4141-83CF-94D2234EF72E@cisco.com> <774E153D-3F1C-43BB-8AE8-060C9D9EBBF2@bbn.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
X-Mailer: Apple Mail (2.1084)
Cc: xmpp@ietf.org
Subject: Re: [xmpp] Some Thoughts on E2E Directions
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Jan 2012 22:02:28 -0000

--Apple-Mail-17--731642987
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jan 26, 2012, at 14:44, Richard L. Barnes wrote:

> For what definition of "good"?  Are you worried about someone =
unauthorized getting a message, or someone getting a message with a key =
the can no longer use (e.g., rollover, different device)?
>=20
> The first definition is definitely a type of goodness we should =
require (key belongs or belonged to the right party). I agree the second =
is more difficult; that's where the dialback mechanism would be helpful =
("Oops, you used the wrong key").
>=20

I am most concerned with the latter case.  This is a case that can =
happen in web-based applications, a lot.

> I do have to say, though, that the dialback mechanism does creep me =
out a little bit.  You need to know that the person asking for a key is =
the right person -- it's  not secure to just accept a public key because =
it came in a message from someone, but if you already know a key for =
someone you could have just used it in the first place.  So there's a =
residual need for some other authentication step here to bootstrap the =
public key distribution.
>=20

Well, some mitigation can be done with the addresses; if the 'from' =
bare-JID of the keyreq doesn't match the 'to' bare-JID of the data =
stanza (or 'me' in the case of Carbons), the request MUST be rejected.  =
After that, I'm open to suggestions.


- m&m

Matt Miller - <mamille2@cisco.com>
Collaboration Software Group - Cisco Systems, Inc.




> On Jan 26, 2012, at 4:37 PM, Matt Miller wrote:
>=20
>>=20
>> On Jan 26, 2012, at 08:38, Richard L. Barnes wrote:
>>=20
>>>>>> I think this one deals with the key management problem better =
than my original proposal,
>>>>>=20
>>>>> Can you elaborate on that?
>>>>=20
>>>> I think it's better because, instead of the sender guessing which =
of the recipient's public keys to use, the send is told by the recipient =
which key (or maybe keys) to use.
>>>=20
>>> It seems like these two mechanisms don't necessarily have to be =
mutually exclusive.  You can send to recipients for which you have =
cached keys immediately, then keep this "I would like the key" interface =
open to allow additional recipients. =20
>>>=20
>>> In the first case, maybe you could optimize a little over the base =
case with the following pattern:
>>>=20
>>> 1. Sender sends message keys to each recipient with a known key, =
along with a digest of the message they go along with.
>>> <key cipher-algo=3D"RSAES-OAEP-SHA-256-MFG1"
>>>   id=3D"recipient-key-1"
>>>   msgid=3D"580CCA51-9AA7-4BB0-817D-ADB3C1A9EFBC"
>>>   digest=3D"di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc">
>>> ...
>>> </key>
>>>=20
>>> 2. Sender sends message content multicast to all recipients
>>> <data id=3D"580CCA51-9AA7-4BB0-817D-ADB3C1A9EFBC"
>>>    cipher-algo=3D"AES-256-CBC-PKCS5-WITH-IV"
>>>    mac-algo=3D"HMACSHA256"
>>>    mac-data=3D"HSGmwUFd4sESB+O12S32xsXVvMnO4gjRPaQITIrjWbs=3D" >
>>> ...
>>> </data>
>>>=20
>>> That way:
>>> * Key blocks only get sent to target recipients
>>> * No additional stanzas for key exchange when keys known
>>>=20
>>> --Richard
>>=20
>> This seems reasonable.  As long as we're not relying on keys being =
known-good (which the original proposal did).
>>=20
>>=20
>> - m&m
>>=20
>> Matt Miller - <mamille2@cisco.com>
>> Collaboration Software Group - Cisco Systems, Inc.
>>=20
>>=20
>>=20
>=20


--Apple-Mail-17--731642987
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNjIyMDMx
MVowIwYJKoZIhvcNAQkEMRYEFAmkZBpDKN+F1H5vvrZ0+orl+NeJMIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQCXI6K7EQNvb6cBlA5lSPCt86QFDd2QbUukEzZn0ZqVvkf5hV5/SOPZ91mM
2YoH5Wkv2PU2s3yezuygUHpqnxvmcxPXJk3BnqYdigROhTmqHDGidVsDGJsifwWRadOeQjnWdFc/
QXA6bq8qW2VLSGuVe/mF1UPH/lUJdLTpbrEzQXaxL0yKV1Tt4oGkyMX8W7WWuiWzTLLEOJxlDQ7o
qKUjAb9GrdYgiQxd7PAD1sVJdqnilzycTh3+3IsVVCJQu4ywoq1ZVy/MfgljICtfMujPnQZaucDA
qnlx7TaJIwaRXf0sklPgTjFpjKwDXjzCN2XMEOYocS97SSVmtIGylwanAAAAAAAA

--Apple-Mail-17--731642987--

From mamille2@cisco.com  Fri Jan 27 12:04:40 2012
Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8621F8670 for <xmpp@ietfa.amsl.com>; Fri, 27 Jan 2012 12:04:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.141
X-Spam-Level: 
X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhwPMZCA0BYu for <xmpp@ietfa.amsl.com>; Fri, 27 Jan 2012 12:04:39 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8124221F8663 for <xmpp@ietf.org>; Fri, 27 Jan 2012 12:04:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6465; q=dns/txt; s=iport; t=1327694679; x=1328904279; h=from:subject:date:message-id:to:mime-version; bh=BAf6r4c7ztFlGNYdxF9ux2ZnwE1o/7HsRoqrDWMjclE=; b=Q9+/sd7cIU7CuImnZdv3rDkWetYKNSSYAYmFPOi0Eb7kMCKvrFv6OhnM Ein3OLOTmdBw1kqgJqJ0nKmZfyEc3x9ImxUm6Qgr/86dyIR4TivUVJxle DHGQl/8dmlCiJT+rsHc8yim7FWT7dqUteZ4kK9YZTSNMfJycxlmfcj5m4 Q=;
X-Files: smime.p7s : 2214
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAOsCI0+rRDoH/2dsb2JhbAA7Ca5TgQWCCwGBSW4bB4dimD6BJwGeP4hpMA4OEAEIAQYEAwMEBx6CcBoCDgIGdQcGBQEKBQMFKYI5YwSIP4V6hmGSbQ
X-IronPort-AV: E=Sophos;i="4.71,582,1320624000";  d="p7s'?scan'208";a="27527248"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 27 Jan 2012 20:04:35 +0000
Received: from dhcp-64-101-72-224.cisco.com (dhcp-64-101-72-224.cisco.com [64.101.72.224]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0RK4Ydl008387 for <xmpp@ietf.org>; Fri, 27 Jan 2012 20:04:34 GMT
From: Matt Miller <mamille2@cisco.com>
Content-Type: multipart/signed; boundary=Apple-Mail-13--652311627; protocol="application/pkcs7-signature"; micalg=sha1
Date: Fri, 27 Jan 2012 13:05:22 -0700
Message-Id: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com>
To: xmpp@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [xmpp] Ponderings on Domain Name Assertions (DNA)
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Jan 2012 20:04:40 -0000

--Apple-Mail-13--652311627
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I've been asked to (attempt to) revive DNA, so here are some thoughts I =
have after reviewing what's been said and done.

To restate the problem:  How to determine that a multi-domain hosting =
service is authorized for a given domain, in a manner that allows =
connections to a hosting service be shared for multiple domains.

An example:

* denmark.lit hosts an XMPP service for its users
* montegue.lit has XMPP service that is hosted at shakespeare.lit
* capulet.lit has XMPP service that is hosted at shakespeare.lit
* shakespeare.lit hosts XMPP services (plural) for others (possibly =
including itself)...
* denmark.lit wants to talk to montegue.lit, but wants to be sure that =
shakespeare.lit really is the actual host.

I think this can (should?) also apply to the users at a domain; how does =
romeo@montegue.lit know that the servers for shakespeare.lit hosts his =
domain.

Solution:

The solution talked about to date has been to develop a protocol =
framework to assert (or challenge) an domain from a set of possible =
proof types.  It is assumed that all connections are secured via TLS, =
although not trusted until the assertions are accepted.  Since part of =
the proving happens in protocol, it means that the end-points suspend =
disbelief about the certificates until this additional validation =
completes.

There are two basic use cases (I am not a playwright, so no critiques of =
the dialogue):

1) "asserting": A server connects to another server, and asserts it is =
authorized for a domain

  (1.0 denmark.lit: I can accept your assertions!)
   1.1 montegue.lit: I am montegue.lit!
   1.2 denmark.lit: prove it, using one of these forms... (possible =
optimization: accepted because of other channels)
   1.3 proving ...
   1.4 denmark.lit: Accepted (or rejected)

2) "challenging": A server (or client) is connected to another server, =
and challenges if it is authorized for a domain ("Are you X?")

  (2.0 montegue.lit: I can assert my identity!)
   2.1 denmark.lit: Are you montegue.lit?  Prove it, using one of these =
forms...
   2.2 proving ...
   2.3 denmark.lit: Accepted (or rejected)

Here, "proving" is a protocol exchange of proof-specific details.  In =
practice, this might look a lot like SASL...

There are a couple prooftypes that have been discussed (on- or off-list) =
so far, plus some other avenues that can be investigated:

* .well-known from HTTPS
* attribute certificates
* DANE
* "dialback without dialback"[1]

This list is not complete; it's expected that new prooftypes can be =
added over time.

As for documenting this, I'll be looking at starting at least two =
drafts: the protocol framework and the HTTPS/.well-known prooftype.  =
I'll later look into another draft for the attribute certificate =
prooftype, and help Peter Saint-Andre for a DANE prooftype.


- m&m

Matt Miller - <mamille2@cisco.com>
Collaboration Software Group - Cisco Systems, Inc.

[1] Dave Cridland - "Dialback. Now without Dialback" =
<http://blog.dave.cridland.net/?p=3D116>=

--Apple-Mail-13--652311627
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw
ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x
MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt
YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd
/kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk
cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO
7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV
jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv
NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN
BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+
SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9
N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT
xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx
s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B
PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2
FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc
/6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg
b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph
p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD
VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo
b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg
ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEyNzIwMDUy
M1owIwYJKoZIhvcNAQkEMRYEFCYIVkiSJQ3jH6RHGCho6mvIgfVGMIGRBgkrBgEEAYI3EAQxgYMw
gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw
IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0
QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD
QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq
hkiG9w0BAQEFAASCAQA0X85EPpXb0FDJ2PRr58pB9g4SiZopRwrX3xImwzVDvNfMeC+MWiX9WHlG
ULPnNQCcNgs1M5IZ8fltKMeFkLG729ruh9fxQonQQrcdT+jZhagPZFlHY/GZy0kGsgFCaPeBbI0D
6kBLIr7dOFa0CQ+End2N9cvidPtkSBiZpvQfctahdofQDHH+g/NMMlheD3wRi3kITvSl8vRWxRNA
U3uIvf/FWXQEOVjd5h4pu9uVZ7/BOsdDSfT6kibc5HuIJYh27P+/QkPg8w31WMSUW/xZx0YtBZpQ
Jgcu5KThdnCtf919s5Zjo1tQT5DCIn6gONSpnt54N6tLYyjOIwdiIosXAAAAAAAA

--Apple-Mail-13--652311627--

From fippo@mail.symlynx.com  Sat Jan 28 01:05:35 2012
Return-Path: <fippo@mail.symlynx.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92EE21F8473 for <xmpp@ietfa.amsl.com>; Sat, 28 Jan 2012 01:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyZG+bghlDti for <xmpp@ietfa.amsl.com>; Sat, 28 Jan 2012 01:05:35 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 0B61821F8472 for <xmpp@ietf.org>; Sat, 28 Jan 2012 01:05:33 -0800 (PST)
Received: from [192.168.0.100] (109.58.62.181.bredband.tre.se [109.58.62.181]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q0S95D0C004947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <xmpp@ietf.org>; Sat, 28 Jan 2012 10:05:29 +0100
Message-ID: <4F23BA44.4010707@mail.symlynx.com>
Date: Sat, 28 Jan 2012 10:05:08 +0100
From: Philipp Hancke <fippo@mail.symlynx.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: xmpp@ietf.org
References: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com>
In-Reply-To: <67986F0A-D907-4C52-A44C-D0B16C7E2AEA@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] Ponderings on Domain Name Assertions (DNA)
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 28 Jan 2012 09:05:36 -0000

Matt Miller wrote:
[...]
> [1] Dave Cridland - "Dialback. Now without Dialback"<http://blog.dave.cridland.net/?p=116>

If you re-read that carefully (neither Dave or I understood the full 
implications of that, see XEP-0288 0.2 for some more hints) you might 
notice that this "dialback" is used as a framework.

It works different from your approach like this:
(client is the s2s tls client, server the s2s tls server)
1) client: I would like to send stanzas from montague.lit denmark.lit
2) server checks it hosting denmark.lit and check (by any means 
available, with the lowest possible proof being certificate equality
3) server notifies client that it can start sending (or not).

The advantage is that this is reusing what currently works:
dialback (assuming that you have tls on all connections you can replace 
the XEP-0185 stuff with certificate equality and skip <db:verify/> at 
all), multiplexing and bidi.
It even enables us to get rid of what does not work (SASL EXTERNAL).
It is limited in the sense that it does not allow any in-band 
challenge/response.

Depends on a good specification of dialback though :-p

philipp
-- 
<http://goo.gl/voEzk>