Re: Call for Adoption: Encrypted Content Encoding

For me I'd like to see a few more words, since we know a bit more about
risks associated with at least one form of key management.  Specifically
around automated key management.  Probably this should be its own
subsection, but here at least is a start (consider this an old fashioned
pull request):

<-->snip<-->
It is possible for an attacker to encrypt the content in the public
key(s) of one or more individuals, where a file sharing service or a
blind cache is either broken into or otherwise populated, leading to the
potential infection of one or more recipients who process the content.

There are several different approaches to addressing this problem.  The
first would be for end user systems to apply a high amount of scrutiny
on any such encrypted content, regardless of the sender (since the
sender may have been compromised) in much the same way that unwanted
email messages are retreated today.  A second method would be for the
recipient to have the message scanned for viruses, either on-board or
through some network service.  A third method would be for a model to be
developed where content is attested to by an agent that the publisher
trusts with the content whose signature intermediaries and recipients
might also trust.  These methods are not mutually exclusive.
<-->snip<-->

Eliot

On 12/5/15 9:19 AM, Cory Benfield wrote:
> 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
>> <mailto: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 :)
>>
>> 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
>>
>>
>>
>