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

Roman Shpount <roman@telurix.com> Mon, 11 November 2019 18:59 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A99F1200F8 for <mmusic@ietfa.amsl.com>; Mon, 11 Nov 2019 10:59:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 JvrgjK6bzvcq for <mmusic@ietfa.amsl.com>; Mon, 11 Nov 2019 10:59:07 -0800 (PST)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 E03481208ED for <mmusic@ietf.org>; Mon, 11 Nov 2019 10:59:06 -0800 (PST)
Received: by mail-pl1-x630.google.com with SMTP id g8so3969893plt.4 for <mmusic@ietf.org>; Mon, 11 Nov 2019 10:59:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lFmw6ipAwL19dSPjd2i8sxGVBkVKLipvEfnPEbKr8jg=; b=Vanmz+DPgjMQKQLnoKQauJfjtLDy2gBeGwrUa4dmYN82LF2iodsMeKp8oJxJ/ySzOM wHhaoTI9HWjRt11d+kIMHzmuc84jrCHFgDigEDGYBwvlUwChYjz0jHns0BkIdJQytVQG /eHHqGx9kC1SMHmp+MEj/3V83rQR3eOIlwTngKakgK/XeqgZ8IAqi8ba1rmTcXpYEr4z NYwGTMvQrvIB1cLaD6a/kbipU0PBBuLQxlqhEHJwYRyrxmoC7fWhBytcQJUaRMd97KPC ttfQTYZl6zwds6v9pVQw2YTZwMqsLRqKEjeWDrkeiC7EEC+too6n82wNCVXVnqRZHgMC rzLQ==
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=lFmw6ipAwL19dSPjd2i8sxGVBkVKLipvEfnPEbKr8jg=; b=pRGtptSYYfK3umxhG6EHIxqL0cKc5CR107tz7OAdDPmFjxHsufYwLCFZ0kB2x/+9uc tKXH0NSv8evbK/fgAJIr9LPihSOw7p84o75h2kqIJy6rAkEdrIpucsr5KM7+QFXrdi3o cLMlf5d6e3BWMxGdVqgUi8PNBkqeScdT5QRi9pRdiRKw+guFGOWfWH8s+5b+dccUIh78 /4TJBm19G2y+nlVLsMfVa2Pdepl7SZfzh5FPCUMKLQgTyXAc1Ov/7gb+exh7q8gPOOGx Dk4gvPF1xqqgUQcgI2ByB/+dfcH802tUxUQ6tDghFhJaPkWyYqnw02oR+97vDxsyYGCd 1G9Q==
X-Gm-Message-State: APjAAAW7R+RJwE2FJoDSJGQMRKDqbw3Yg8zjOtsQmIq2glbjculIm7yR N5GEzoRALHAjicoUJRRCECntVQ==
X-Google-Smtp-Source: APXvYqwbOGx/KET1xhmnX3BKyCyvq0jzS/Y0ZYKt9rJGnNfp93q68VtLggAA25Q7kKQdf9/Q88yRfg==
X-Received: by 2002:a17:902:8f94:: with SMTP id z20mr27278661plo.21.1573498746223; Mon, 11 Nov 2019 10:59:06 -0800 (PST)
Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com. [209.85.210.174]) by smtp.gmail.com with ESMTPSA id m65sm572782pje.3.2019.11.11.10.59.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Nov 2019 10:59:05 -0800 (PST)
Received: by mail-pf1-f174.google.com with SMTP id 193so11236539pfc.13; Mon, 11 Nov 2019 10:59:04 -0800 (PST)
X-Received: by 2002:a17:90b:110f:: with SMTP id gi15mr690084pjb.128.1573498744529; Mon, 11 Nov 2019 10:59:04 -0800 (PST)
MIME-Version: 1.0
References: <CA+m752++Frkcq00Lcg0x6is+cWtg2NNf6unWdEiaG1JwTfNMQw@mail.gmail.com> <df740bf1-304f-4123-8cd0-e0eb1a9dd089@www.fastmail.com> <CA+9kkMAA2Oz4UA7DFjp76JLjdeRk8tOsg7attr_p0Tdz7e0gwA@mail.gmail.com> <CAD5OKxt-yx82U02s5W9kHx+WGdiB3mWjZ1uM2TQTEi2F5K+Psg@mail.gmail.com> <CAOJ7v-0J7YSM405hyCfbmez9KTY=h8cNFAdM-i5ccFA-57D0dA@mail.gmail.com>
In-Reply-To: <CAOJ7v-0J7YSM405hyCfbmez9KTY=h8cNFAdM-i5ccFA-57D0dA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 11 Nov 2019 13:58:53 -0500
X-Gmail-Original-Message-ID: <CAD5OKxt1X6ixoHCGeefc2jAezSZeKv3JL4OjmgT5FGSBRAUjdA@mail.gmail.com>
Message-ID: <CAD5OKxt1X6ixoHCGeefc2jAezSZeKv3JL4OjmgT5FGSBRAUjdA@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, Alex Drake <alexdrake@google.com>, RTCWeb IETF <rtcweb@ietf.org>, Qingsi Wang <qingsi=40google.com@dmarc.ietf.org>, mmusic <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b8eccd059716b948"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/9CMa-I7xURqL6I-p5KlfG3FUyeg>
Subject: Re: [MMUSIC] [rtcweb] Draft new: draft-wang-mmusic-encrypted-ice-candidates
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 18:59:10 -0000

On Tue, Nov 5, 2019 at 7:13 PM Justin Uberti <juberti@google.com> wrote:

>
> On Tue, Nov 5, 2019 at 1:30 PM Roman Shpount <roman@telurix.com> wrote:
>
>> One thing that I thought would make all DNS in ICE candidate work better
>> is some sort of "addrtype" candidate extension.
>>
>> It would work like:
>> a=candidate:1 1 UDP 2130706431 203.0.113.141 8998 typ host addrtype inipv4
>> a=candidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns4
>> a=candidate:1 1 UDP 2130706431 foo.bar.com 8998 typ host addrtype dns6
>> a=candidate:1 1 udp 2122262783 <(212)%20226-2783>
>> 1f4712db-ea17-4bcf-a596-105139dfd8bf.local 54596 typ host  addrtype dns6
>>
>> This way client would know which DNS request (A or AAAA) should be used
>> to resolve the DNS name in the candidate. c= and m= line can also be
>> generated unambiguously if address type is specified in the candidate and
>> is not determined during resolution time.
>>
>
> I think this might be useful, but it seems separate from the encryption
> proposal, so let's discuss that in its own thread.
>

We will need to update ice-sip-sdp to allow DNS (including mdns and
encrypted candidates). I think adding addrtype should address most of the
issues with the existing DNS ice-candidates. We just need to make sure that
people who care about DNS in ice candidate review it.

 For encrypted candidate, distribution of the actual encryption key can be
>> implementation specific, but there should be some way to identify which key
>> is used to encrypt the candidates. This will likely require additional
>> candidate extension, such as "keyid":
>>
>> a=candidate:1 1 UDP 2130706431 2122262783 <(212)%20226-2783>
>> 8c9bd03bb7a5a76a5803eebc688f0388.fa991acbdf116f6b72fd3a781174cd58.local 8998
>> typ host addrtype dnsipv6 keyid foo.bar.com
>>
>> This way you do not need an additional gTLD and encrypted candidate can
>> be identified using the extra candidate extension.
>>
>
> Not sure we need a keyid, but marking the encrypted candidate type somehow
> in the candidate-attribute seems like a good thing to consider.
>

What I am concerned about are graceful key updates in the enterprise. This
might require several keys to be operational at the same time with one key
used for encryption and multiple keys used to de-crypt.

Furthermore, local addresses before encryption should be prefixed with some
>> random nonce so that encrypted local addresses cannot be used for
>> fingerprinting.
>>
>
> This is already described in the draft - the ice-pwd value is used for the
> IV, which ensures the encryption output will be different across
> PeerConnections.
>

Clear. I missed it on the first read.

Finally, probably in W3C we need to discuss if any API updates are required
>> to enable encryption in ICE candidates. I think an additional option to
>> createOffer/createAnswer that specifies which key to use for candidate
>> encryption would probably be the best solution. Distributing actual keys
>> can then be done via enterprise policies or keys can be pre-provisioned
>> with web browsers via some sort of enrollment mechanism.
>>
>>
>> Can you explain more as to why? We don't want app developers to have to
> care about this, or else this solution will never get off the ground.
>

I guess we can get away without the API and keep key management completely
outside of JavaScript.
_____________
Roman Shpount