[Bug 26401] Key message destinationURL usage is not reflected in examples

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26401

--- Comment #12 from Joe Steele <steele@adobe.com> ---
(In reply to Mark Watson from comment #11)
> (In reply to Joe Steele from comment #10)
> > (In reply to Mark Watson from comment #9)
> > > Perhaps we need some information in the security considerations about the
> > > need to protect initData ?
> > 
> > This is a good idea. However we already have some text in section 7.1.3
> > Tracking to address this (see "Encryption of user identifiers"). Maybe we
> > should expand that text to specifically discuss when identifiers are sent as
> > part of a key request message?
> > 
> 
> The attack is that the message is routed to the wrong place, which is a
> security issues. One of the things an attacker could do once they've
> achieved this might be to abuse identifiers in the messages, which would be
> a privacy issue.
> 
> We should address the underlying security issue (mis-routing of messages) -
> it would still be an issue even if the identifiers were not present.

I agree that we should address the potential mis-routing issue. However, it
really should not matter whether the messages are routed correctly or not. My
suggestion would be to add some text that requires encryption whenever
identifiers are included in messages. Maybe even require that the keys used
only be known to the targeted server(s) although that may be hard to spec well.
If this recommendation was followed, it would make abusing identifiers much
harder.  A MiTM should not be able to derive any useful information from the
key request without owning the keys.

This was part of the point I was trying to make in bug 26332. If an attacker
can send you to an alternate URL, there is no reason they can't send you to an
alternate *secure* URL (secure in the sense that the browser will accept the
server certificate). So the message still needs to be encrypted within that
SSL/TLS channel to ensure privacy for the user.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 26 August 2014 18:12:41 UTC