Subject: Partial Encryption

From: Grahame Grieve <[email-masked]>
Date: Tue, 11 Apr 2017 06:53:45 +1000

We are getting strong push-back against the use of RESTful APis in
healthcare, particularly in Europe, because there is no support for partial
encryption - that is, where the content is encrypted (and signed) but the
headers are not. SSL does both, obviously. (note: this is in b2b context).

There are some RFCs floating around for encrypting and signing the http
body, instead of (or as well as) using SSL - but these don't seem to have
any penetration.

So I'm increasingly seeing discussion around tunneling RESTful APIs across
SOAP (pr higher level profiles on soap like ebMS), purely for the reason
that they protect the body but not the headers.

I'm interested in whether anyone here can give me a sense of perspective on
where we are - why is content encryption not flying like transport
encryption?

And don't ask stupid questions like, how actually useful are the headers?
This discussion isn't really about functionality but about the ability of
large government backbone administrators to tick the box that they'll have
the control they need, while being able to tick the box that they've
protected the patient's privacy and the healthcare provider's need for
reliability

Grahame

-- 
-----
http://www.healthintersections.com.au / [email-masked]
/ +61 411 867 065

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Apr 2017 08:59:07 +1000

Hi Grahame,

You might want to have a look at:
  http://httpwg.org/http-extensions/draft-ietf-httpbis-encryption-encoding.html
... along with the implementation list at:
  https://github.com/httpwg/wiki/wiki/EncryptedContentEncoding

Cheers,

P.S. Anticipating people's questions as "stupid" doesn't help the level of discourse here. Please refrain from doing so. Thanks.

> On 11 Apr 2017, at 6:53 am, Grahame Grieve <[email-masked]> wrote:
> 
> We are getting strong push-back against the use of RESTful APis in healthcare, particularly in Europe, because there is no support for partial encryption - that is, where the content is encrypted (and signed) but the headers are not. SSL does both, obviously. (note: this is in b2b context).
> 
> There are some RFCs floating around for encrypting and signing the http body, instead of (or as well as) using SSL - but these don't seem to have any penetration.
> 
> So I'm increasingly seeing discussion around tunneling RESTful APIs across SOAP (pr higher level profiles on soap like ebMS), purely for the reason that they protect the body but not the headers. 
> 
> I'm interested in whether anyone here can give me a sense of perspective on where we are - why is content encryption not flying like transport encryption? 
> 
> And don't ask stupid questions like, how actually useful are the headers? This discussion isn't really about functionality but about the ability of large government backbone administrators to tick the box that they'll have the control they need, while being able to tick the box that they've protected the patient's privacy and the healthcare provider's need for reliability 
> 
> Grahame
> 
> 
> -- 
> -----
> http://www.healthintersections.com.au / [email-masked] / +61 411 867 065

--
Mark Nottingham   https://www.mnot.net/

---

From: Grahame Grieve <[email-masked]>
Date: Tue, 11 Apr 2017 10:53:54 +1000

hi Mark

thanks. I'll work harder on getting the irony tone correct; in fact, those
questions themselves are not-stupid; it's the answers that usually are :-(

I've read that draft, but it doesn't seem to have any traction?

Grahame

On Tue, Apr 11, 2017 at 8:59 AM, Mark Nottingham <[email-masked]> wrote:

> P.S. Anticipating people's questions as "stupid" doesn't help the level of
> discourse here. Please refrain from doing so. Thanks.
>
>
>
> > So I'm increasingly seeing discussion around tunneling RESTful APIs
> across SOAP (pr higher level profiles on soap like ebMS), purely for the
> reason that they protect the body but not the headers.
> >
> > I'm interested in whether anyone here can give me a sense of perspective
> on where we are - why is content encryption not flying like transport
> encryption?
> >
> > And don't ask stupid questions like, how actually useful are the
> headers? This discussion isn't really about functionality but about the
> ability of large government backbone administrators to tick the box that
> they'll have the control they need, while being able to tick the box that
> they've protected the patient's privacy and the healthcare provider's need
> for reliability
> >
> > Grahame
> >
> >
> > --
> > -----

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Apr 2017 10:56:53 +1000

> On 11 Apr 2017, at 10:53 am, Grahame Grieve <[email-masked]> wrote:
> 
> hi Mark
> 
> thanks. I'll work harder on getting the irony tone correct; in fact, those questions themselves are not-stupid; it's the answers that usually are :-(

:) No worries. I probably needed more coffee when I read it too.

> I've read that draft, but it doesn't seem to have any traction?

It has some -- see the implementation list. Because it's part of WebPush, it'll end up in browsers too (and I think already is getting in there), although it's not clear how/if it'll be exposed generically. 

Cheers,

---

From: John Gates <[email-masked]>
Date: Mon, 10 Apr 2017 20:31:09 -0500

I totally get it on the compliance and checking the box statement.  There
are some tough roads ahead on actually making something like this happen
and be routable.  I think that may be what's really holding this type of
encryption back.

Best Regards,

John Gates, CISSP

*Let’s Connect!*

<https://twitter.com/johngatesIII>   <http://www.linkedin.com/in/JohnGates>

*This email may contain information that is confidential or attorney-client
privileged and may constitute inside information. The contents of this
email are intended only for the recipient(s) listed above. If you are not
the intended recipient, you are directed not to read, disclose, distribute
or otherwise use this transmission. If you have received this email in
error, please notify the sender immediately and delete the transmission.
Delivery of this message is not intended to waive any applicable
privileges.*

On Mon, Apr 10, 2017 at 7:56 PM, Mark Nottingham <[email-masked]> wrote:

>
> > On 11 Apr 2017, at 10:53 am, Grahame Grieve <
> [email-masked]> wrote:
> >
> > hi Mark
> >
> > thanks. I'll work harder on getting the irony tone correct; in fact,
> those questions themselves are not-stupid; it's the answers that usually
> are :-(
>
> It has some -- see the implementation list. Because it's part of WebPush,
> it'll end up in browsers too (and I think already is getting in there),
> although it's not clear how/if it'll be exposed generically.
>
> Cheers,
>
> >
> > Grahame
> >
> >
> >
> > P.S. Anticipating people's questions as "stupid" doesn't help the level
> of discourse here. Please refrain from doing so. Thanks.
> >
> >
> >
> > > On 11 Apr 2017, at 6:53 am, Grahame Grieve <
> [email-masked]> wrote:
> > >
> > > There are some RFCs floating around for encrypting and signing the
> http body, instead of (or as well as) using SSL - but these don't seem to
> have any penetration.
> > >
> > > I'm interested in whether anyone here can give me a sense of
> perspective on where we are - why is content encryption not flying like
> transport encryption?
> > >

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 11 Apr 2017 16:08:47 +1200

> and be routable.  I think that may be what's really holding this type of

Routability should not be an issue. It is just another content-encoding
as far as the middleware is concerned. If all the browsers add support
it should have less impact than SDCH.

There will be issues with software that screws around with content to
force-gzip everything. Those are thankfully not all that common, and the
government services in question should be a good reason to quash that
type of bad behaviour.

Amos