Re: [xmpp] key+data object encryption (regarding draft-miller-3923bis-01)

"Ben Schumacher" <Ben.Schumacher@webex.com> Fri, 02 April 2010 17:07 UTC

Return-Path: <Ben.Schumacher@webex.com>
X-Original-To: xmpp@core3.amsl.com
Delivered-To: xmpp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB463A6A07 for <xmpp@core3.amsl.com>; Fri, 2 Apr 2010 10:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.312
X-Spam-Level:
X-Spam-Status: No, score=-101.312 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx27JEUyfX74 for <xmpp@core3.amsl.com>; Fri, 2 Apr 2010 10:07:27 -0700 (PDT)
Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id 56C083A69B7 for <xmpp@ietf.org>; Fri, 2 Apr 2010 10:07:24 -0700 (PDT)
Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Apr 2010 10:07:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: from 66.114.169.8 ([66.114.169.8]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.12]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Apr 2010 17:07:44 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD287.02F5513E"
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
Content-class: urn:content-classes:message
Date: Fri, 02 Apr 2010 10:07:43 -0700
Message-ID: <952A4B1F81123B479292D4B5FDC00D8503BA5FC5@SRV-EXSC03.webex.local>
In-Reply-To: <69FD2C6F-316E-44EE-8436-81E081A68CE8@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [xmpp] key+data object encryption (regarding draft-miller-3923bis-01)
Thread-Index: AcrShwL1J6FIb+M/SYeWtqVbx6Crdg==
References: <734EAEEA-B1DD-4899-80CC-CE9C90DB9776@cisco.com> <952A4B1F81123B479292D4B5FDC00D8503BA5F61@SRV-EXSC03.webex.local> <678467D6-0F2B-4C2F-B8EA-4677728B90D1@cisco.com> <952A4B1F81123B479292D4B5FDC00D8503BA5F79@SRV-EXSC03.webex.local> <69FD2C6F-316E-44EE-8436-81E081A68CE8@cisco.com>
From: Ben Schumacher <Ben.Schumacher@webex.com>
To: xmpp@ietf.org
X-OriginalArrivalTime: 02 Apr 2010 17:07:58.0485 (UTC) FILETIME=[0B432C50:01CAD287]
Subject: Re: [xmpp] key+data object encryption (regarding draft-miller-3923bis-01)
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 02 Apr 2010 17:07:28 -0000

On 3/31/10 8:47 AM, Matt Miller wrote:
>> You'll want to specify a fixed size for N, or including some sizing
>> information in the decoded bytes. You might also consider versioning in
>> your format for the decoded bytes to handle future adjustments to the
>> protocol. You could do this by adding a simple message header, with than
>> includes a single byte for version (apologies for my hackneyed ABNF):
>>
>> plaintext    = header-part / stanza-part
>>
>> header-part  = tag / version / stamp-part
>> tag          = "xmpp-objec"
>> version      = 2*HEXDIG           ; network byte order (NBO) version
>> stamp-part   = stamp-length / stamp-string
>> stamp-length = 4*HEXDIG           ; NBO length of stamp-string
>> stamp-string = *VCHAR             ; a known format is likely preferable
>> (ISO-8601),
>>                                     ; but knowing the length frees you
>> from making an
>>                                     ; assumption about precision
>>
>> stanza-part  = stanza / stanza-end
>> stanza       = *CHAR              ; UTF-8 encoded, naturally
>> stanza-end   = NUL
>>
>> This would all, of course, be encrypted. The ending NUL gives your XML
>> parser an easily identifiable ending point to the stanza, but you could
>> also include a length for the stanza in the format.
>>
>> Let me know if any of that doesn't make sense.
>>      
> I don't see a benefit of including versioning information here.  All of this is defined as the (encrypted and encoded) character content of a namespaced XML structure.  Wouldn't it be better to version this via the namespace instead?
>
>    
Matt-

The outside XML can be tampered with since there's no ability to verify 
it's integrity (HMAC's obviously difficult to apply to the work on the 
container stanza). Putting the version in the encrypted payload gives 
you an extra level of security to validate that what's on the container 
matches what's in the payload. Further, if you have some known "phrase" 
that the encrypted payload always begins with, you have a quick way to 
check and ensure that your decryption was successful before spinning up 
your XML parser.

You could always just put a plain text version of the namespace as the 
first N characters of the encrypted payload, but I think something 
that's more deterministic (a known length) would be desirable.

Cheers,
Ben