Re: [MMUSIC] Unknown key shares in MMUSIC

Cullen Jennings <fluffy@iii.ca> Fri, 17 March 2017 03:24 UTC

Return-Path: <fluffy@iii.ca>
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 EFE91129BCE for <mmusic@ietfa.amsl.com>; Thu, 16 Mar 2017 20:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.696
X-Spam-Level:
X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 qAkhmiaJjr3g for <mmusic@ietfa.amsl.com>; Thu, 16 Mar 2017 20:24:09 -0700 (PDT)
Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B87129BC8 for <mmusic@ietf.org>; Thu, 16 Mar 2017 20:24:09 -0700 (PDT)
Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E26EB56B2; Thu, 16 Mar 2017 23:24:01 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp13.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9CB3C543D; Thu, 16 Mar 2017 23:24:01 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.24.116.117] ([UNAVAILABLE]. [128.107.241.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Thu, 16 Mar 2017 23:24:01 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CABkgnnXJvyZxmhU94VZAHNjWeaVoeThVBQVTDv0x3rLBtRrn4Q@mail.gmail.com>
Date: Thu, 16 Mar 2017 21:24:00 -0600
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1A400AF-20C7-480F-9005-894434C24171@iii.ca>
References: <CABkgnnXJvyZxmhU94VZAHNjWeaVoeThVBQVTDv0x3rLBtRrn4Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/XkOrwRbEOPQr-e-8B4ry-OXCbBg>
Subject: Re: [MMUSIC] Unknown key shares in MMUSIC
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 17 Mar 2017 03:24:11 -0000

One ID for both TLS and DTLS make sense to me. 

The one thing that is key for perc, is that in the Client Hello, this need to not be encrypted so that the MDD can use it to recognize which KDD is meant to be routed to. Effectively you can think as the MDD as a load balancers for all the KDDs that act as the TLS server and it is using this field much like a normal load balancer might use SNI. So I want to make sure we preserver this property. 

This is probably crazy, but, I wonder if it would make sense to just use the SNI. 




> On Mar 13, 2017, at 5:48 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> After completely failing to remember and take into account feedback
> during the avtcore meeting last time (thanks for the reminder
> Jonathan), I would like to draw the attention of this group to this
> draft:
> 
> https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/
> 
> The latest version builds on the a=dtls-id work in this group.
> However, Jonathan's reminder highlighted a critical shortcoming of
> that: it only works for DTLS.  We still have uses of TLS-over-TCP that
> would not be addressed by the current iteration of the draft (though
> they would have for the previous version).
> 
> One relatively simple solution is to define dtls-id as tls-id instead,
> but that's disruptive.
> 
> I'd like to discuss this issue with an eye to resolving it before or
> at Chicago; I realize that there is a probably a tight agenda, but the
> outcome of that discussion might affect a very-far-advanced
> draft-ietf-mmusic-dtls-sdp-21.
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic