Subject: [Atlas] Request signing

From: Phil Hunt <[email-masked]>
Date: Mon, 22 Jan 2018 11:41:19 -0800

A problem that keeps coming up in HTTP is the ability to sign requests/responses. Some see this as additional security, but others see this as beneficial for after-the-fact verification (e.g auditing).

If ATLAS proposes to encapsulate HTTP to prevent interference by intermediaries than it likely would also solve problems that HTTP request signing proposals have not been able to overcome — the possibility that intermediaries may alter HTTP requests for good (or bad) reasons. 

Has this been discussed?

Thanks,

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Jan 2018 16:20:21 -0500

This was the primary goal of SHTTP.  See RFC 2660.  Of course, SHTTP never saw wide-spread deployment.

Russ

> On Jan 22, 2018, at 2:41 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 22 Jan 2018 21:38:25 +0000

Hi Russ, Hi Phil,

You raise good points.

I can only talk about the use cases we have investigated, which are related to Internet of Things deployments.

As an example, consider a Bluetooth Smart device that talks to a cloud based service via a smart phone or tablet. The data needs to be secured from the Bluetooth Smart device to the cloud-based service. Now imagine that the Bluetooth Smart device does not talk IP or HTTP (an assumption that is not unrealistic). The phone / tablet will, however, use HTTPS.

The data, which is encoded using JSON or CBOR, needs to be protected using an AEAD cipher. Whether it is better to re-use the TLS record protocol or whether COSE/JOSE should be re-used for application data protection is something this group needs to find out.

In my example, the challenges you outline below do not surface. I do, however, agree that there has been a long history of failed attempts of “signing” application protocols in face of intermediaries like proxies, and session border controllers.

Ciao
Hannes

From: Atlas [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: 22 January 2018 15:20
To: Phil Hunt
Cc: [email-masked]
Subject: Re: [Atlas] Request signing

Russ

On Jan 22, 2018, at 2:41 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Has this been discussed?

Thanks,

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

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.

---

From: Mark Baugher <[email-masked]>
Date: Mon, 22 Jan 2018 17:14:57 -0800

Hi

> On Jan 22, 2018, at 1:20 PM, Russ Housley <[email-masked]> wrote:
> 

I recall it was a specific solution for a specific protocol.  Can't a generic protocol accomplish that as well?  I see ATLAS as a generic solution that does at least some of what CMS (RFC 5652) does, but ATLAS uses TLS key establishment.  My view of ATLAS comes from working on the problem of end-to-end IoT security, e.g. through middle boxes: Both CMS-style encapsulation and application-level TLS have been proposed for IoT messaging.  To me, a compelling reason for re-using TLS/DTLS is key establishment.  A compelling reason for considering CMS-style encapsulation (COSE,OSCOAP) is adaptation to different application protocols, which may have different needs and require different profiles for what gets exposed between endpoints.

So, can ATLAS provide the sort of function SHTTP provided or that Phil asked about?  I don't know.  I still don't know if using ATLAS for IoT encapsulations like CBOR is a win over COSE.  We know there is a need for this:  COSE lacks key management and that's a lot. Chat protocols took a long time to achieve end-to-end confidentiality and integrity through WhatsApp/Signal (following years of refusal by the industry to deploy CMS for that purpose).  There are other applications that need end-to-end security.  What if we could do that with one protocol that includes both key management and  secure enveloping?

Mark

>> www.independentid.com
>> [email-masked]
> _______________________________________________
> Atlas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/atlas

---

From: Phil Hunt <[email-masked]>
Date: Mon, 22 Jan 2018 13:59:10 -0800

Russ. 

Agreed. The base64 encoding however makes it easy to sign and validate at least from my reading. 

For non-IOT this would be, IMO, a primary use-case for considering ATLAS. 

If i consider industrial iot, i can see value with signed messages. Eg measurement readings (eg of rolling mill output) have increased value if signed so that the measurement can be validated later (eg because accuracy often determines product value). 

Phil

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_atlas&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=MVbDNrxNMqRIgZYYFY9uh9rLy1kIrDf1uWDM3hbw9DY&s=tGSQ5NPOxoSCglrTYkUy-16-YuTnhDjavCcvlbQnpZY&e=