[secdir] Issue with XML Encryption standards from W3C and the use of ECDH

Stefan Santesson <stefan@aaa-sec.com> Fri, 22 March 2019 08:29 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BE635130EB5 for <secdir@ietfa.amsl.com>; Fri, 22 Mar 2019 01:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id szHgPlo8dmJj for <secdir@ietfa.amsl.com>; Fri, 22 Mar 2019 01:29:06 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF234130EA1 for <secdir@ietf.org>; Fri, 22 Mar 2019 01:29:05 -0700 (PDT)
Received: from s554.loopia.se (localhost []) by s554.loopia.se (Postfix) with ESMTP id 6BFC01F17C1E for <secdir@ietf.org>; Fri, 22 Mar 2019 09:29:00 +0100 (CET)
Received: from s645.loopia.se (unknown []) by s554.loopia.se (Postfix) with ESMTP id 4DF5379474F for <secdir@ietf.org>; Fri, 22 Mar 2019 09:29:00 +0100 (CET)
Received: from s473.loopia.se (unknown []) by s645.loopia.se (Postfix) with ESMTP id 3F30F13BF33B for <secdir@ietf.org>; Fri, 22 Mar 2019 09:29:00 +0100 (CET)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s498.loopia.se ([]) by s473.loopia.se (s473.loopia.se []) (amavisd-new, port 10024) with UTF8LMTP id s1zFGhT7CyVW for <secdir@ietf.org>; Fri, 22 Mar 2019 09:28:59 +0100 (CET)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
Received: from [] (gw.aaa-sec.ideon.se []) (Authenticated sender: mailstore2@aaa-sec.com) by s498.loopia.se (Postfix) with ESMTPSA id A42B3449422 for <secdir@ietf.org>; Fri, 22 Mar 2019 09:28:59 +0100 (CET)
User-Agent: Microsoft-MacOutlook/
Date: Fri, 22 Mar 2019 09:28:58 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: secdir@ietf.org
Message-ID: <E782F4EE-F640-4FCE-9AF1-1F0CA009C468@aaa-sec.com>
Thread-Topic: Issue with XML Encryption standards from W3C and the use of ECDH
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/dJDCRV640z9S8ZsoN6Eu9FWEHtU>
Subject: [secdir] Issue with XML Encryption standards from W3C and the use of ECDH
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2019 08:29:09 -0000


I'm looking for anyone with an insight in this issue, anyone experiencing interop issues or anyone willing to seek a solution.

The XML Encryption standard has some errors and lack of specification with regard to the use of the Key Derivation Function ConcatKDF

The example on ECDH use at: https://www.w3.org/TR/xmlenc-core1/#sec-ECDH-ES express the ConcatKDF parameters as AlgorithmID="00" PartyUInfo="" PartyVInfo=""
This is inconsistent with the same specification definition of how to use ConcatKDF and how to specify its parameters: https://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF

Further. ConcatKDF parameters stors bit strings of arbitrary length in chunks of byte data. The bitstring length may not be devisable by 8. Implementers are supposed to strip padding bytes and send the actual bit strings as ConcatKDF input.
Current implementations of ConcatKDF, in particular from Bouncycastle can only handle ConcatKDF input in the form of byte array.

Implementations I have seen have fed ConcatKDF parameters from XML enc directly into ConcatKDF without attempting to strip padding bits and length byte from the data. All implementations must have this right or nothing will work.

There are some serious issues threaten interoperability here:

 - Implementers may be tricked to send illegal parameter values following the example in 5.6.4
 - Implementers are supposed to strip out padding bits, but if they do, they may end up with data they can't use because the result can't be stored in bytes.

Apparently there is a need for further clarifications here, but the XML Security group of W3C is closed and I have found no way to send them feedback.

Is there anyone here who have insights in this issue or know how to solve it?

Stefan Santesson