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

[Matt Miller <[e-mail]>]

On Mar 17, 2010, at 14:00 , Ben Schumacher wrote:

> Have we considered using Encrypt-then-MAC, instead of the
> MAC-then-Encrypt for your message authentication? Both methods ought to
> provide a good assurance that the message hasn't been tampered with, but
> the Encrypt-then-MAC method can provide an added level of protection
> against software bugs in your decryption code [1].
> 
> Your message would them become something akin to:
> 
> N = current timestamp
> R = session cipher input (e.g. key + IV)
> S = stanza
> a = HMAC(N || UTF8-Encode(S), R)
> T = a || encrypt(R, N || UTF8-Encode(S))
> 
> Where || detonates concatenation.

This makes sense to me.  I'll look at updating the draft to incorporate this unless there's strong objections.

> 
> 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?


- m&m