Re: Call for Adoption: Encrypted Content Encoding

So to be clear, Martin: Eliot and Mike wanted something like the text you have. I wanted something substantially stronger than that. =)

> On 4 Dec 2015, at 19:25, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> 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 <https://martinthomson.github.io/http-encryption/#rfc.section.6> :)
> 
> On Dec 5, 2015 5:56 AM, "Mike Bishop" <Michael.Bishop@microsoft.com <mailto: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 <mailto:lear@cisco.com>]
> Sent: Friday, December 4, 2015 5:01 AM
> To: Cory Benfield <cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>>; Poul-Henning Kamp <phk@phk.freebsd.dk <mailto:phk@phk.freebsd.dk>>; Mike Bishop <Michael.Bishop@microsoft.com <mailto:Michael.Bishop@microsoft.com>>; grahame@healthintersections.com.au <mailto:grahame@healthintersections.com.au>
> Cc: Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>>; HTTP Working Group <ietf-http-wg@w3.org <mailto: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
> 
> 
>