Dave Thaler <> Wed, 07 February 2018 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76C7712D867; Wed, 7 Feb 2018 09:26:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.515
X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6U77zn3t1z0B; Wed, 7 Feb 2018 09:26:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 023DD1270A3; Wed, 7 Feb 2018 09:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9QCfMiV/eEpYd7tI5vy495TCm1331uRDxtpcdUWD1tQ=; b=WHQq6Q2FUvu98PvlGy/QPlicqxwzIiUG2U8aEsPHqgE9763VEpXtfSBn09gxLvvNQVfSJKlYh4biVFD9o8P5VMFMcSrU2Lm2YSmRDWZf3YySYinO6EmKM1JgVd5hLdMlw+eVcSvaq88y3PL6c0K4AFhKuoK080ymG9HExmwWxTo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Wed, 7 Feb 2018 17:26:41 +0000
Received: from ([fe80::a5aa:5aa0:e32d:9321]) by ([fe80::a5aa:5aa0:e32d:9321%3]) with mapi id 15.20.0506.007; Wed, 7 Feb 2018 17:26:41 +0000
From: Dave Thaler <>
To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <>, Hannes Tschofenig <>, "" <>
CC: "" <>
Thread-Topic: [OAUTH-WG] OSCORE
Thread-Index: AQHToB1G/bi42x7glEW+yKQQZgyBfqOZAgKAgAADAICAAANpAIAAJ3cg
Date: Wed, 7 Feb 2018 17:26:41 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-02-07T17:26:42.2465029Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0791; 7:mxnWtYsV2V01qydnqsJd8KFZYJ8E07pxsp8yF0beDvv7Sb4nXgDE/qEh0/agQ3MP8ZnLiL9PsolsbqWvRJBlQmdUAyFM3gXEvNTGAO17q990MCxj+0DI35OoflgSiyXNH3Dv4D4W9+iR6il8rzto9OmDwe1SnLAnBH1d03OqVw3X+9V1IrsMyUv3dJcozRQxsc4nZ/suYrKbypWqwSZWy2t6MRS6jproc7uokRdvxwTO7H2dyux+etw4/4ICvLvy
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 4aafd44c-0e31-4a55-1ec4-08d56e4ff404
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0791;
x-ms-traffictypediagnostic: CY4PR21MB0791:
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(180628864354917)(278428928389397)(89211679590171)(192374486261705)(189930954265078)(219752817060721);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0791; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0791;
x-forefront-prvs: 0576145E86
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(346002)(366004)(39860400002)(376002)(189003)(199004)(51914003)(377424004)(13464003)(966005)(7736002)(3280700002)(478600001)(8990500004)(105586002)(93886005)(66066001)(10090500001)(10290500003)(2900100001)(106356001)(6116002)(575784001)(7696005)(86362001)(8676002)(53546011)(110136005)(6506007)(99286004)(33656002)(3846002)(26005)(76176011)(3660700001)(74316002)(59450400001)(8936002)(81166006)(6346003)(102836004)(81156014)(186003)(5250100002)(2501003)(5660300001)(316002)(22452003)(2950100002)(14454004)(25786009)(5890100001)(4326008)(97736004)(68736007)(2906002)(6436002)(6246003)(229853002)(55016002)(86612001)(6306002)(305945005)(53936002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0791;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-message-info: wUCMIdKF3vtRrp6sntFq2K2bvXV9TMK69eHOpZpM/5/BM9kwvThi1Kz44jVbK0ZgKF7LEYVI/+ry7vZ2b1/kjg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4aafd44c-0e31-4a55-1ec4-08d56e4ff404
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 17:26:41.6384 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0791
Archived-At: <>
Subject: Re: [OAUTH-WG] OSCORE
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Feb 2018 17:26:46 -0000

As Göran said, yes the original rationale was end-to-end communication through proxies where each leg might be CoAP or might be HTTP,
the most common case being a single COAP-to-HTTP or HTTP-to-COAP proxy.   For the subset of HTTP that is mappable to CoAP
(i.e., simple RESTful calls), I'm not aware of any reason it wouldn't work with a simple HTTP proxy where all legs are HTTP.
It would be good if someone could try that and verify it though... maybe a hackathon project.

-----Original Message-----
From: Göran Selander [] 
Sent: Wednesday, February 7, 2018 8:00 AM
To: Hannes Tschofenig <>om>;; Dave Thaler <>
Subject: Re: [OAUTH-WG] OSCORE

Hi Hannes,

Including Dave who may want to provide some background to the use case.

As I said, this was a proposed construction and was straightforward to include in the draft. I’m not the right person to answer whether this is useful for OAuth, but I’m interested in the answer.


On 2018-02-07 15:47, "Hannes Tschofenig" <> wrote:

>Hi Göran,
>Maybe you can then answer the question whether this is useful / 
>applicable to a HTTP. Asked differently, under what conditions does the 
>OSCORE not work for HTTP. This would help the folks in the group, 
>including me, to determine whether this actually something we should be 
>looking into at all. Note that typical applications that use OAuth do 
>not use CoAP -- only HTTP.
>In OAuth we had for several years tried to get HTTP message protection 
>working and we have, unfortunately, failed to find a suitable solution.
>-----Original Message-----
>From: Göran Selander []
>Sent: 07 February 2018 15:37
>To: Hannes Tschofenig;
>Hi Hannes, and all
>Thanks for the announcement.
>To be a little bit more precise, the statement is that a CoAP-mappable 
>HTTP message can be mapped to CoAP (using RFC 8075), protected with 
>OSCORE (as specified in the referenced draft) and transported with HTTP 
>(as exemplified in the referenced draft). The main use case is in 
>conjunction with an HTTP-CoAP translational proxy (RFC 8075), and the 
>mapping would with this construction result in a CoAP-mappable HTTP 
>request being protected by an HTTP client and verified by a CoAP server.
>This functionality was proposed by OCF for their end-to-end REST use 
>cases. Happy to hear any comments on the construction as described in 
>the draft.
>Note that Hannes referenced the wrong version of the draft, here is the
>On 2018-02-07 11:06, Hannes Tschofenig wrote:
>> Hi guys,
>> You may be interested to hear that a group of people working on 
>> Internet of Things security believe they have found a solution to 
>> deal with the challenges we had in protecting HTTP requests/responses.
>> Here is the draft:
>> 7fb734b0c8589bcd847f1c277%7C1%7C0%7C636536160483223433%7CUnknown%7CTW
>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3
>> D%7C-1&sdata=k4MlHEBM0YayRoq%2B0KjIBdzShfXMSW2EQDK03%2FMCJ%2B0%3D&res
>> erved=0
>> (The draft is mostly focused on CoAP but it is supposed to be 
>> applicable also to HTTP.)
>> Ciao
>> Hannes
>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not the intended 
>> recipient, please notify the sender immediately and do not disclose 
>> the contents to any other person, use it for any purpose, or store or 
>> copy the information in any medium. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> 47f1c277%7C1%7C0%7C636536160483223433%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
>> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=KYCV
>> h3AxIuXfGoA0R4W6poXbhN%2B1jKDAkQgNygIYhmM%3D&reserved=0
>IMPORTANT NOTICE: The contents of this email and any attachments are 
>confidential and may also be privileged. If you are not the intended 
>recipient, please notify the sender immediately and do not disclose the 
>contents to any other person, use it for any purpose, or store or copy 
>the information in any medium. Thank you.