Re: [rtcweb] Security Architecture -07 review

Martin Thomson <martin.thomson@gmail.com> Thu, 25 July 2013 20:47 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F3C21F9377 for <rtcweb@ietfa.amsl.com>; Thu, 25 Jul 2013 13:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqWkzMlDZC1O for <rtcweb@ietfa.amsl.com>; Thu, 25 Jul 2013 13:47:35 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7CC21F941F for <rtcweb@ietf.org>; Thu, 25 Jul 2013 13:47:34 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id m6so75773wiv.14 for <rtcweb@ietf.org>; Thu, 25 Jul 2013 13:47:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Knm/24P29ox8LUyGXCpKjHR7g8DHBXxpJQVjQGjiRNY=; b=N4w2KFJprbRp80q1ysoAyaldPuWbqKrRiEyigsKJSC8F5sB5Rl8Vu1wJmlYU3QncIa JE5l1QaSOcFMEzl4p9o5XViJT9G1An7yklNytnpRTdKp2WtpJjv199w9kL2sG0CYzMJe bGYlyYfhZSpHRAQnwVxkzu+/+C6HnRl62y9SKagngWBBxaadrh6dSp934sL5LSQytmwk 66I2i3NUaVwKEX9UCdT9xPiqzbNLD99DsXZO2H4l+0nCZEEXxlH/BnlYx3XFkLWMDXwF SCG2QAb//CYyf9KdTMb9EjvKLTBsXdmw5Tv9tU6eFnL01hZTeOd9eA/c2yGoekumOs0U aXtg==
MIME-Version: 1.0
X-Received: by 10.194.110.6 with SMTP id hw6mr32617629wjb.3.1374785253490; Thu, 25 Jul 2013 13:47:33 -0700 (PDT)
Received: by 10.194.60.46 with HTTP; Thu, 25 Jul 2013 13:47:33 -0700 (PDT)
In-Reply-To: <CABkgnnWUZXBRneGnRsA9Xo-rrdw7nAsBR+5SL6SRyjbR+Egfgw@mail.gmail.com>
References: <CABkgnnWUZXBRneGnRsA9Xo-rrdw7nAsBR+5SL6SRyjbR+Egfgw@mail.gmail.com>
Date: Thu, 25 Jul 2013 13:47:33 -0700
Message-ID: <CABkgnnW61-BzZD53XyQfsN9JHnMjp05ktv3ZtF3WBRmOT5g7Zg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [rtcweb] Security Architecture -07 review
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2013 20:47:36 -0000

On 25 July 2013 11:32, Martin Thomson <martin.thomson@gmail.com> wrote:
> Section 5.2:
>    [...]  Note that
>    it is unlikely that browsers would have an X.509 certificate, but
>    servers might.
>
> This is a little over-simplified.  1.  Servers will have an X.509, and
> that will need to be trusted somehow.  2.  Clients will have X.509
> certificates or else DTLS won't work, it's just that it's unlikely to
> be trusted for authentication of a domain name.

Expanding on this a little, with a text proposal.  Sadly, this didn't
turn out to be easy.

OLD:
   In addition, they SHOULD support requests for access that promise
   that media from this grant will be sent to a single communicating
   peer (obviously there could be other requests for other peers).
   E.g., "Call customerservice@ford.com"quot;.
NEW:
   In addition, browsers SHOULD ...
(Editorial only)

OLD:
   The semantics of this request
   are that the media stream from the camera and microphone will only be
   routed through a connection which has been cryptographically verified
   (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP
   handshake) as being associated with the stated identity.
NEW:
   An application that requests access that is limited in this way cannot
   access or modify the acquired media or send media to any destination
   other than the specified identity.  The browser will prevent the media
   from being transmitted over a connection which has a cryptographically
   verified identity (see Section !).
(I don't think that it's necessary to do anything more than cite the
appropriate section.  I would have liked to identify a
peer-authentication section here, but Section 5.6 deals only with the
IdP stuff.  If this were my document, I'd promote 5.6 to a new
top-level section and add a new 5.6 that deals with peer
authentication of both forms.  The existing text regarding domain
name-based authentication is light-to-non-existent.

e.g.
5.6. Peer Authentication

   <First paragraph of the current 5.6 is pretty good>

   Establishing the identity of a communication peer requires that DTLS-SRTP
   be used with X.509 certificates being presented by both peers.  Two
mechanisms
   are then possible:

   Identity provider: Most browsers do not customarily have domain names and
      X.509 certificates for those domains.  [The new] Section 6
describes a mechanism
      whereby a cryptographic assertion binding a self-signed X.509
certificate to
      an identity specific to an identity prover can be created and verified.

   Domain name: An X.509 certificate that contains a subjectAltName containing
      a domain name can be verified using the procedures defined in RFC 6125.
      This option is, however, only likely to be feasible for organizations that
      operate servers, since it depends on use of a domain name.

   <existing paragraph>
   Whatever the underlying technology, the general principle is that the
   party which is being authenticated is NOT the signaling site [...]

Feel free to completely rewrite, or ignore this, I'm not across all
the sensitivities here.  I do think that the IdP stuff is big enough
to get its own section.  I actually still think that it's a big enough
concept that a dedicated document would have been a better choice,
still....

Another possibility is to deal with this a little better in Section
3.1, which I note could use a better term than "Other users" to refer
to media/real-time peers.)

REMOVE:
   Note that
   it is unlikely that browsers would have an X.509 certificate, but
   servers might.
KEEP?:
   Browsers servicing such requests SHOULD clearly
   indicate that identity to the user when asking for permission.  The
   idea behind this type of permissions is that a user might have a
   fairly narrow list of peers he is willing to communicate with, e.g.,
   "my mother" rather than "anyone on Facebook".  Narrow permissions
   grants allow the browser to do that enforcement.
(I'm sure about the 2119 SHOULD here.  I think that there are several
ways to think about this.  For the most part,  I believe that there's
no need to make any sort of normative statement.  Absence of an
indication isn't going to disadvantage users, they just lose the
opportunity to learn about restrictions.  Non-normative text that
suggests the UI is a different matter: applications will appreciate
any feature that increases the chance of a user hitting "allow".)