Re: Call for Adoption: Encrypted Content Encoding

Hi Martin,

Thanks for the comments.  I'll take another pass at this based on your
feedback.  With that in mind, please see below.

On 12/7/15 9:57 PM, Martin Thomson wrote:
> 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?

Maybe partially that in as much as an end system confers trust on an
intermediary (think dropbox.com or some such), but as much that the
intermediary itself might be unwittingly participating in a malware
attack, in which case its resources are misappropriated.

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

I'm not quite certain what you're saying.  I'm happy to acknowledge an
unrecognized architectural question so long as we can state state that
clearly (whatever it is) ;-)
>
>> 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.

What got me going were these two use cases that got discussed up
thread.  I think they're fine use cases, but they pose certain risks
that would be worth highlighting.  They can be mitigated as discussed
below.  Perhaps the wording should be more general?

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

The 2nd remediation might be a specific means of the 1st to be fair. 
But as Cory mentioned upthread, maybe be a little more cautious about
opening such files automatically, but rather posting an appropriate
warning.  Apple does this for any code that they would execute, for
instance.  The precise mitigation will depend on the client
application.  Think non-browser for things to get weird.  That's why I
didn't get into details.  Implementers will need to think about it.

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

It may be, but you have also done some work that could be the basis of
such a system, which again I mentioned up thread.  I'd be happy to
suggest more when that draft gets adopted :-)

Eliot