Re: [MMUSIC] Unknown key shares in MMUSIC

Martin Thomson <martin.thomson@gmail.com> Fri, 17 March 2017 01:40 UTC

Return-Path: <martin.thomson@gmail.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 DB1AC129B9B for <mmusic@ietfa.amsl.com>; Thu, 16 Mar 2017 18:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 IfNLWxwPjEN1 for <mmusic@ietfa.amsl.com>; Thu, 16 Mar 2017 18:40:56 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 1B4DF129BB5 for <mmusic@ietf.org>; Thu, 16 Mar 2017 18:40:56 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id 1so54332559qkl.3 for <mmusic@ietf.org>; Thu, 16 Mar 2017 18:40:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wLnyoZOaOtR+eIrnDr3Wc6YLJASu41XXLbZPY6PCqA8=; b=jxS547s+x8+bLkV9gVCjbo0i67Xv1+ZBf+4X9cJmiuOwWgeIzJgRX7A8/1+IVgvWRP ZTsfbyZvqLqRUy3VyTLrgQam0CnUSknHTkOQ+0eOSs7I+LOgj3OBbwXGQjmVxPw+q6+S hUPvOfpjEzszhhql/lUo3BvWw0+BsfijaetwlSrKx1FazV5CWaqqimkoFGv6+MNM0Czv muvUFb+/g257X5k1IKrSzcqc+tYAsICilYcM/vDfxJneRn1zfXvmF5U+ogd+9USPWQ+8 +DTSdCx1Vi9P7UQzZM1hNlppqE1Ebat3c4yPoon583BHv+7kR3scpIr0y1wLNhVT9FAN KrWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wLnyoZOaOtR+eIrnDr3Wc6YLJASu41XXLbZPY6PCqA8=; b=aJBEkI9ulZuyFIWNsFuXELeMABDNtjuDMrhIZ5OPfBlURAOfAwK4MPK64a5BiHqaM/ LPGDag61HkOL/mXYBlTtUoEJ564VTiL3nu6W2GWA8zyObrCiuD2NmkdkqPiW5Tp2qAV3 cMpdRUMwh/vL/bWCAu9sP1FemKfuJwwgeIkIazELiQeAyk/luVgWMjL96VzrViKqz7q6 9ZaIl6CyI0Vm4ocvq/UO1oZU3vhFmcbojklW+kVFiny8a28pZgQ9sJRC9qtXyKThpQBe Y04vaQyXniM/b8BhxI95JIBSAhCQ0+scI5qyg3UXTOlgIDVsWaRadablGs+cntHt7UDZ E+Uw==
X-Gm-Message-State: AFeK/H0ovg7y7Lj1w43jjLOFkyXFRZmwUsHjADjvIzYPN+4iIANQu0YveA4xG1Ot0cxJaZlOJtCGcTLk2Fo1vg==
X-Received: by 10.55.136.2 with SMTP id k2mr7685578qkd.316.1489714855318; Thu, 16 Mar 2017 18:40:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.27.194 with HTTP; Thu, 16 Mar 2017 18:40:54 -0700 (PDT)
In-Reply-To: <CAD5OKxtmz8cP+hmJF6bq7VTX5SOduS5=U-e17iCiAs12KOa5MQ@mail.gmail.com>
References: <CABkgnnXJvyZxmhU94VZAHNjWeaVoeThVBQVTDv0x3rLBtRrn4Q@mail.gmail.com> <CAD5OKxtmz8cP+hmJF6bq7VTX5SOduS5=U-e17iCiAs12KOa5MQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 17 Mar 2017 12:40:54 +1100
Message-ID: <CABkgnnVrx8qfD0AfOVb7AfS_7+8tGyohc8cSZ79dkBaReC8R_Q@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/yMZuLj4Uad6-nKA0aURzsVtxYh4>
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 01:40:58 -0000

On 17 March 2017 at 03:14, Roman Shpount <roman@telurix.com> wrote:
> Alternatively we can keep dtls-id the way it is currently defined and define
> tls-id to be used for TLS-over-TCP  in the new draft.

I could accept tls-id.  But if tls-id and dtls-id are the same and
have similar semantics, then one attribute makes more sense.  Using a
"tls"-named attribute in DTLS isn't going to cause any real problems.

> I would also prefer a more generic name for the TLS extension itself. It
> does not have to be related to SDP, so some sort of endpoint_id would work
> better then sdp_dtls_id.

The point is to explicitly tie the TLS negotiation to the SDP.  I was
operating on the basis that SDP has a somewhat unique authentication
arrangement and that there weren't many other examples like it.

If you think that this could be made more general and applied to
protocols that don't use SDP, that's probably true.  But I can't think
of a protocol that uses the same basic mechanisms for authentication.

I'd be open to a change if you could name an example.  I don't like
building a general purpose mechanism with exactly one user; an example
would help in choosing the right semantics.