Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates

Qingsi Wang <qingsi@google.com> Tue, 05 November 2019 19:15 UTC

Return-Path: <qingsi@google.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 E539D120A15 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2019 11:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBAD1eCdL9JF for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2019 11:15:30 -0800 (PST)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B501B120A00 for <rtcweb@ietf.org>; Tue, 5 Nov 2019 11:15:30 -0800 (PST)
Received: by mail-ot1-x335.google.com with SMTP id m15so9868321otq.7 for <rtcweb@ietf.org>; Tue, 05 Nov 2019 11:15:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wXixCTnBK1S/W6+rTXf/XE+vR4OKvXBeDN7blCiJovE=; b=PiMJHoBHGj6uD/8ufYSYIiIcZz8wrU7GhscJiqdsey8corS/YvwCT47C7iQJe1P8bb +A8bgeB4kNYrCYOE7CtorV8r34W8qumzj2VqZjYlfCmsf6f+ByvoaPxTPWj2gcJNV5Si +3MmuN1UxnxHaVmpkTQD+DIGPlM31g/Xg1AkR6XPqI283j+VouzSXvqIcS9fp++qFyFo lmt6/BO9xXWErboQsk8F4kaigFbL56YLWhvingWNF2mKXn3vCaKV6bDcPkiqxcNYmrEk I3JkOjWE25ALdWWWuUxZ2sRcz9jytlsO0f7zN1GFVswZjcLyU7gYn4oaXKlPc8O4R11y ed9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wXixCTnBK1S/W6+rTXf/XE+vR4OKvXBeDN7blCiJovE=; b=qNyg2yItKVqgHY5hElrxQ4SHw+bqUjt6I8vV+4BHuaqBwTJxOaCjie1UMgBC2TS7SF wtgQ6Q9kE8g5rHGLzcyNabIrXwp/nK6yyl/sWfvY0LKv138wk8W4bYYPFV2KyaVy66eV nTtAn1llL1o3t48g/e3SNeCFiq2W1MmhK2qNvxI0cyWpgSCpU7CC7MsghGqLq12JfUWA 3K1n8krktT9jZKBUEHQimNwQwVYtYdyunzYF7NT7R+aYxdK6FKVzyuuiVwzusU8Lizc/ 47H4WPjAWrHnXor8HI1wJyJFTW9Us6Ean2O8GcUKcb7Dc/P+Jl7FuVhR0DApP1swTT64 tBOA==
X-Gm-Message-State: APjAAAXKHJQVWWPMPAsKxTYfEXagvzUpWPLfOxPUE0jiwlN7dlzjWxqn L2eEx1cuVj6TDs/5Erm1sJY8IW690aFsmxqAVujaf+VXXpE=
X-Google-Smtp-Source: APXvYqz8WoiKVwKW1pQJkp8/zvZExiwbUsAOyuyml4RiWH9efFydvO8iBbi/DxgtDi9UHc+rwyjM1mVVjdNw53EwKvs=
X-Received: by 2002:a9d:52a:: with SMTP id 39mr22944092otw.133.1572981329694; Tue, 05 Nov 2019 11:15:29 -0800 (PST)
MIME-Version: 1.0
References: <CA+m752++Frkcq00Lcg0x6is+cWtg2NNf6unWdEiaG1JwTfNMQw@mail.gmail.com> <df740bf1-304f-4123-8cd0-e0eb1a9dd089@www.fastmail.com>
In-Reply-To: <df740bf1-304f-4123-8cd0-e0eb1a9dd089@www.fastmail.com>
From: Qingsi Wang <qingsi@google.com>
Date: Tue, 5 Nov 2019 11:15:18 -0800
Message-ID: <CA+m752LrouhP+MZ0o+mY7RwdjLjKC7OwxUVOaEoEK_43ZWtPMg@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: mmusic <mmusic@ietf.org>, Alex Drake <alexdrake@google.com>, rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006592c205969e416b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/bUuwOiKHIIa5hHqGloIgNfTMckc>
Subject: Re: [rtcweb] [MMUSIC] Draft new: draft-wang-mmusic-encrypted-ice-candidates
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 05 Nov 2019 19:15:33 -0000

Hi Martin,

Thanks a lot for the feedback. We agree a=encrypted-candidate should be
able to achieve an equivalent result as this initial version or even beyond
encrypting IPs, without modifying the core procedure. We'll edit the draft
accordingly with this suggestion.

On the key management, we think this should be deferred to implementations,
given different options to solve this problem. Chrome enterprise policy is
currently an example for such a solution in managed environments, and it
allows admins to push configuration settings to managed endpoints. For
example, policies like AudioCaptureAllowedUrls
<https://cloud.google.com/docs/chrome-enterprise/policies/?policy=AudioCaptureAllowedUrls>
can
set up a whitelist and DeviceKerborosEncryptionTypes
<https://cloud.google.com/docs/chrome-enterprise/policies/?policy=DeviceKerberosEncryptionTypes>
configures certain ciphersuites.

DHCP could be another example of configuring managed endpoints in addition
to Chrome enterprise policy above. TLS-PSK similarly delegates the
communication of PSK among parties outside the spec space. Given the
diversity of applications even in managed environments, the definition of
the key management feels out of the scope for this document, but this draft
can include example implementations for illustration.

As for errors from key rotation, MAC verification will cause such
candidates to be discarded, and clients will fall back to mDNS, STUN, or
TURN as appropriate. If we feel like that we need to solve this problem
more thoroughly, some implementation guidelines can also be included
regarding maintaining a brief key history and using trial decryption as
needed. We'd appreciate suggestions on further improving these guidelines.

Regards,
Qingsi

On Sun, Nov 3, 2019 at 7:36 PM Martin Thomson <mt@lowentropy.net> wrote:

> This draft has the effect of defining a new gTLD.  That's problematic, and
> likely unnecessary.  I would encourage you to look into ways to signal
> these candidates differently.  a=encrypted-candidate might work, for
> instance.  You might be able to encrypt more data than an IP address in the
> process.
>
> I also don't see how key management works here.  The goal of the draft is
> to define a set of entities that you are OK with reading your IP address,
> but I don't see any text that addresses the difficulty of a) identifying
> the entities in that set, and b) getting those entities the necessary
> keys.  Those are the really hard problems in this space.
>
> I don't see how this provides any sort of algorithm agility or ability to
> identify the keys that are in use.  Maybe trial decryption is acceptable in
> this context, but that can get unwieldy fairly rapidly.
>
> On Sat, Nov 2, 2019, at 07:06, Qingsi Wang wrote:
> > Greetings.
> >
> > This draft
> > (
> https://tools.ietf.org/html/draft-wang-mmusic-encrypted-ice-candidates-00)
> proposes a complementary solution to the mDNS candidate detailed in
> draft-ietf-rtcweb-mdns-ice-candidates, specifically for managed networks.
> IPs of ICE candidates are encrypted via PSK and signaled as pseudo-FQDNs in
> this proposal, and it aims to address the connectivity challenge from the
> mDNS technique in these managed environments. The current work on this
> draft is tracked in https://github.com/tQsW/encrypted-ice-candidates.
> >
> > Regards,
> > Qingsi
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>