Re: Call for Adoption: Encrypted Content Encoding

Old-fashioned pull requests are great.  I'm just not sure that this is
right.  I don't think that you have provided enough context.

On 8 December 2015 at 01:51, Eliot Lear <lear@cisco.com> wrote:
> <-->snip<-->
> It is possible for an attacker to encrypt the content in the public key(s)

I can't make sense of this statement.  Is the intent to describe a
scenario where malware is encrypted so that only the intended victim
can decrypt it?  And that the victim relies on some intermediation for
defense against this kind of thing?  Why not say that?

Of course, you need to approach this in a more careful fashion.  Your
model - if I'm right - presumes a lot about where malware
countermeasures are best deployed.  There's an unrecognized
architectural question that you are implying a particular answer to.
Having the text acknowledge that this is a choice is important, unless
you want to open that up for debate.

> 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.

Note that there isn't any context in the draft that suggests that this
applies to blind caching (a very specific concept) or even file
sharing.

>
> 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.

I don't see any practical difference between the first and second
suggestions here.

> 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.

Your third method seems impractical given that no such system exists.

> <-->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> 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> 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 Monday, 7 December 2015 20:58:05 UTC