Re: [rtcweb] Fwd: New Version Notification for draft-kaufman-rtcweb-security-ui-00.txt

[Alan Johnston <[e-mail]>]

This is a reasonable start to expressing in requirement form some of
the ideas described in draft-johnston-rtcweb-media-privacy and that I
presented on the interim call.  Some additional comments:

At the start, it should be made clear that the UI described is the
browser UI and not anything rendered by the web page.  This is
described in the last requirement of Section 2, but it needs to be
clearly stated up front.

Most of the UI descriptions seem to be described in terms of an
inspector - with additional clicks a user can determine additional
information about the media session, which is reasonable.  However, if
we do allow non-encrypted media sessions (which I really hope we do
not - this goes against the current direction of web security in
moving from http to https), then the encrypted/non encrypted state
needs to be visible as much as possible, in the same way that a user
does not need to click anything to see if http or https is in use.  Of
course, full screen modes and other considerations can limit this.

"  If the transmission is encrypted, the "security characteristics" MUST
   include an indication as to the source of the keying material,
   particularly whether the keying material was delivered out-of-band
   (from a server) or was generated as a result of a pairwise
   negotiation."

I think I understand and agree with this requirement.  However, I
think we can do better in our description of the keying material.  I
think the distinction we are after is whether the keying material was
derived directly between the browsers, or between the browser and the
server.

"   If possible for the cryptosystem in use, the "security
   characteristics" MUST include information regarding the authenticity
   of the far station identity.  (For example, in the case of a self-
   signed certificate with RSA key the contents of the certificate and
   the key fingerprint.)"

I'm not sure about this one.  Unless a PKI is in use, I don't think
there is any useful identity information that can be derived.  I've
been told in the past that "self signed certificates" are actually
just containers for a public key, and as such none of the information
is useful.  Also, I don't understand the value in providing a key
fingerprint to a user.  This might be useful for debugging, but it
isn't of use to users.  Ekr has provided a reference in the past why
this is so.

" If possible for the cryptosystem in use, the "security
   characteristics" SHOULD include a Short Authentication String which
   may be used by the user to authenticate the far station identity and
   keying integrity (specifically, the presence or lack of a man-in-the-
   middle that may be in collusion with the service provider to attempt
   to bypass authentication tests) by communicating this string out-of-
   band with the far party."

I think providing a SAS is very important, so I believe this
requirement to be a MUST.  Also, this wording about "if possible"
might be interpreted to mean "if ZRTP is used".  I think having an SAS
is valuable for any keying method that is browser to browser - I don't
think it has any value for broswer to server keying.  Since the SAS is
just an algorithm based on the secret key used, it should be be
possible to derive one for other keying approaches.  However, we will
need help from crypto experts to make sure the SAS is of sufficient
length and derived correctly to make it useful.   I recall with ZRTP
that we were able to utilize such a short SAS due to the hash
commitment design - other keying methods will need a similar analysis.

Looking forward to the discussion of these issues in Quebec City.

- Alan -

On Wed, Jun 29, 2011 at 6:38 PM, Matthew Kaufman
<[e-mail]> wrote:
> I wrote up a first pass at browser requirements for a media security
> inspector in browsers.
> Matthew Kaufman
>
> Begin forwarded message:
>
> From: [e-mail]
> Date: June 29, 2011 4:35:42 PM PDT
> To: [e-mail]
> Cc: [e-mail]
> Subject: New Version Notification for
> draft-kaufman-rtcweb-security-ui-00.txt
>
> A new version of I-D, draft-kaufman-rtcweb-security-ui-00.txt has been
> successfully submitted by Matthew Kaufman and posted to the IETF repository.
>
> Filename: draft-kaufman-rtcweb-security-ui
> Revision: 00
> Title: Client Security User Interface Requirements for RTCWEB
> Creation date: 2011-06-30
> WG ID: Individual Submission
> Number of pages: 4
>
> Abstract:
>   This document calls for a requirement to be imposed on RTCWEB client
>   user interfaces whereby the user may inspect the current media
>   security status.
>
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>