Re: [rtcweb] Should consent checks be optimized further?

Martin Thomson <martin.thomson@gmail.com> Wed, 19 March 2014 18:18 UTC

MIME-Version: 1.0
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE22E319CE5@xmb-rcd-x02.cisco.com>
References: <E721D8C6A2E1544DB2DEBC313AF54DE22E319CE5@xmb-rcd-x02.cisco.com>
Date: Wed, 19 Mar 2014 11:18:23 -0700
Message-ID: <CABkgnnXdgYMenHdMh6emZzuLdDRA5PkWo2B6ygq0di_JsFjD7A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YrRMWSgjTGzk5ReH36jIATTaAYE
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Should consent checks be optimized further?
Precedence: list

On 19 March 2014 08:01, Muthu Arul Mozhi Perumal (mperumal)
<mperumal@cisco.com> wrote:
> Should reception of authenticated traffic from the peer on the inverted
> 5-tuple be considered as peer granting consent to send traffic to it? Should
> the browser refrain from performing consent freshness when it continues to
> receive such traffic from the peer?

You forgot to mention another concern here, which is that the receipt
of an authenticated packet is not sufficient if the path has changed.
You need to verify that the peer on the new path has both consented to
receive data AND is in possession of the session keys.  Otherwise, in
combination with source IP/port spoofing, you get an attack that a
victim cannot opt out of.

[rtcweb] Should consent checks be optimized furth… Muthu Arul Mozhi Perumal (mperumal)
Re: [rtcweb] Should consent checks be optimized f… Martin Thomson
Re: [rtcweb] Should consent checks be optimized f… Muthu Arul Mozhi Perumal (mperumal)