[Teep] OTrP Proposal - Removing Redundant Message Layer

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 24 May 2017 05:49 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809DA126D45 for <teep@ietfa.amsl.com>; Tue, 23 May 2017 22:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifA4lhbeg9OY for <teep@ietfa.amsl.com>; Tue, 23 May 2017 22:49:42 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D79F124BFA for <teep@ietf.org>; Tue, 23 May 2017 22:49:42 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id e127so57530791wmg.1 for <teep@ietf.org>; Tue, 23 May 2017 22:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=nZBHwgpG+TOsMbUJDbWBaGd0dlB55d8+ID8Y9NXVYqQ=; b=OQOVf68dE6qAHFeR6G+huxtvvC8+DP78jfTAPH/P/7HtO9mvVtCWqPqE/aXLqr5RH+ 1P1WfiCJNNtS9FMNuZXrEQJkP8AEn50RTAgv347fXCD4+7XC8aarCRT0wvMCbZzgBEVr mMiXT0jIYwIjsZJrHrHdCKCzv9WW4bwVgKCbXu6j42RUOguc2YfxF0pUEcKaQfhvgLo+ qZHZh0Q87fuBzDO67XKqaYyvvMK2AZ66G9SdkF++D3f0G1TsbgoRS1BSOz8spWTreTzu E+DlHfrX0THn0WfUfA985gIyK1wVkOk+AgSVVLsNefRPjaLhc/urNWJINm2XQyxaxybh JdqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=nZBHwgpG+TOsMbUJDbWBaGd0dlB55d8+ID8Y9NXVYqQ=; b=p6mwklUM1oa5qjjZ/zjDa6mP1IcufEBluWwdzvcKX59hiTu6waZqzE35umMv6z3BpI fYMgzd2JTZl8D51Mun2hk+9sQkXZ3+9+EEXk+FaoKSrKeEAaWit83YAAU7kg9ddomokQ c/9I6KpxNfOauT4SfbLqQIR5zle1xSjgiOr9DBoahRh252RXPOuDkW0FHCZsd/uCyLlD 969CoAboqUaU4/ifXKJP+f8BTmcCCex4Z8fFB2XQ2EoUENGSQEtEgXqJCA05DhTdPbu2 gsaw342laktFZRSrGCnr8ebRBd3OlojEIj5jsy6f6jM91e71GqWYV5NIa2Dm6YadfjfN DI4w==
X-Gm-Message-State: AODbwcB2VjqYe5YapeRaovX1kB8eWQc+jfydYM1qSccfwV8tV6rot426 RMcrbhVj1cu7mKz6
X-Received: by 10.223.133.182 with SMTP id 51mr18710967wrt.86.1495604980908; Tue, 23 May 2017 22:49:40 -0700 (PDT)
Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id m14sm4659832wmi.2.2017.05.23.22.49.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 22:49:40 -0700 (PDT)
To: teep@ietf.org
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <9ce8a049-496b-489e-177c-754f4b3dd70e@gmail.com>
Date: Wed, 24 May 2017 07:49:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/ynm-ZRnBuYsBE6SmrVFiI6VJHRs>
Subject: [Teep] OTrP Proposal - Removing Redundant Message Layer
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 May 2017 05:49:44 -0000

Hi TEEers,

As an alternative (or maybe a complement) to the session-key proposal
https://mailarchive.ietf.org/arch/msg/teep/qs-4aXf2Fx9mrBOz6Kj8f1Mk7G8
you may consider evaluating an alternative to JOSE for signatures.

The JOSE standards stack is awesome but was designed for the needs of OpenId and such rather than security protocols in general. Another corner stone for the JOSE work was that there is no such thing as JSON canonicalization which is why data is dressed in Base64URL.  However, the latter changed with the advent of EcmaScript version 6 which specifies an exact method for serializing JavaScript/JSON objects which is already implemented in most Browsers, Node.js, as well as in Android* and Java* in general.  In fact (modulo floating point), it works flawlessly in most other platforms as well.

Now to the actual issue.  I have taken the liberty analyzing the consequences of using JWS in OTrP:

https://tools.ietf.org/html/draft-pei-opentrustprotocol-03#section-7.4

             "The top element " <name>[Signed][Request | Response]" cannot be
              fully trusted to match the content because it doesn't participate the
              signature generation.  However, a recipient can always match it with
              the value associated with the property "payload".  It purely serves to
              provide a quick reference for reading and method invocation."

SIDE-EFFECT: JWS introduces additional signature verification steps


https://tools.ietf.org/html/draft-pei-opentrustprotocol-03#section-8.2.1.3

Top level message object:
             {
                  "CreateSDResponse": {
                    "payload":"<CreateSDTBSResponse JSON>",
                    "protected": {
                       "<BASE64URL of signing algorithm>"
                    },
                    "signature": "<signature contents signed by TEE device private   key (BASE64URL)>"
                  }
                }

Payload:
              {
                  "CreateSDTBSResponse": {
                    "ver": "1.0",
                    "status": "<operation result>",
                    "rid": "<the request ID received>",
                    "tid": "<the transaction ID received>",
                    "content": ENCRYPTED {
                      "reason":"<failure reason detail>", // optional
                      "did": "<the device id received from the request>",
                      "sdname": "<SD name for the domain created>",
                      "teespaik": "<TEE SP AIK public key, BASE64 encoded>",
                      "dsi": "<Updated TEE state, including all SD owned by    this TSM>"
                    }
                  }
               }

SIDE-EFFECT: JWS forces you adding artificial message layers in order to get a reasonable message structure.

By combining ES6 Serialization, JSON Web Algorithms (JOSE/JWA) and JSON Web Key (JOSE/JWK), you can stay pretty close to JOSE while getting away from the current two-level messaging scheme in addition to having header information in clear: https://cyberphone.github.io/doc/security/jsonsignatures.html

Although not on any IETF standard track, this is not a research project, JCS (JSON Cleartext Signature) is fully documented and supported by an extensive set of test vectors and working code.

Cheers,
Anders
Co-inventor of signed JavaScript/JSON objects
https://github.com/cyberphone/openkeystore#openkeystore

* Through third-party libraries