W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

RE: Call for Adoption: Encrypted Content Encoding

From: Martin Thomson <martin.thomson@gmail.com>
Date: Sat, 5 Dec 2015 06:25:28 +1100
Message-ID: <CABkgnnXpW6Op4Pep=DUPy9ejd1iiBtFndj1DjRGgRzAzHQuBUw@mail.gmail.com>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Mark Nottingham <mnot@mnot.net>, grahame@healthintersections.com.au, HTTP Working Group <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Eliot Lear <lear@cisco.com>, Cory Benfield <cory@lukasa.co.uk>
I suppose that the very top of the security considerations section wasn't
obvious enough for folks:
https://martinthomson.github.io/http-encryption/#rfc.section.6 :)
On Dec 5, 2015 5:56 AM, "Mike Bishop" <Michael.Bishop@microsoft.com> wrote:

> Likewise on the non-normative text.  The draft shouldn't specify how the
> key to decrypt the content is obtained.  This is a building block for a
> larger solution which would have to describe how/where clients obtain keys
> securely and validate them -- this draft isn't something you'd implement
> stand-alone.  Pointing out that when you use this building block in a
> system, that's something you have to handle properly is a reasonable
> cautionary note to add.
> -----Original Message-----
> From: Eliot Lear [mailto:lear@cisco.com]
> Sent: Friday, December 4, 2015 5:01 AM
> To: Cory Benfield <cory@lukasa.co.uk>; Poul-Henning Kamp <
> phk@phk.freebsd.dk>; Mike Bishop <Michael.Bishop@microsoft.com>;
> grahame@healthintersections.com.au
> Cc: Mark Nottingham <mnot@mnot.net>; HTTP Working Group <
> ietf-http-wg@w3.org>
> Subject: Re: Call for Adoption: Encrypted Content Encoding
> Hi Cory,
> On 12/4/15 11:53 AM, Cory Benfield wrote:
> > (Replying to Poul-Henning, but this is a question for Mike and Grahame
> as well):
> >
> > Earlier in this thread I raised a concern I have about the way this
> draft accesses keys. In particular, it does not appear to specify any
> requirement that keys be tied to specific origins or in some way limited in
> scope: a conforming implementation would be able to have a single global
> registry of keys that can be used to decrypt content coming from anywhere.
> >
> > I believe this represents a security risk and should either be addressed
> in Section 6, or this draft should be accompanied by another that specifies
> key management in this case.
> I'm not particularly certain of your specific concern, but I would suggest
> that at least some non-normative mention of key management would be a
> helpful addition.
> Eliot
Received on Friday, 4 December 2015 19:25:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC