Re: [core] Review of draft-hartke-core-e2e-security-reqs-01

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Klaus Hartke [mailto:[e-mail]]
> Sent: Wednesday, August 03, 2016 8:23 AM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; [e-mail] WG
> <[e-mail]>
> Subject: Re: [core] Review of draft-hartke-core-e2e-security-reqs-01
> 
> Hi Jim,
> 
> thanks a lot for your review. Comments inline below.
> 
> Klaus
> 
> 
> Jim Schaad wrote:
> 
> > 2. Section 2.1.1 - Should "client receives a response" include
> >
> >     * (Threat ?) The proxy returns a stale or outdated response based
> > on data it previously obtained from the origin server or some fourth party.
> >
> >                I'm thinking of both out of date caches and poisoned caches.
> > Note that these are valid from a security point of view, but not 'fresh'
> 
> This is a part of (Threat 1:) The proxy spoofs a response.
> 
> In the mitigation section (2.1.1.1.) we define that a response is valid from a
> security point of view only if it is fresh.
> 
> (We use the term "authentic" instead of "valid" though, because "valid" is
> already used in the context of cache validation.)
> 
> I've expanded the text with your suggestion:
> 
>       *  (Threat 1:) The proxy spoofs a response.  For example, the
>          proxy could return a stale or outdated response based on data
>          it previously obtained from the server or some fourth party, or
>          could craft an illicit response itself.
> 

My problem with this is that I view a spoof as different.  To me a spoof implies the attempt to create a new message that will pass muster as oppose to doing something like a replay.  It would probably be better to use a different term.  I'll try and remember to ponder on this.

Jim