Re: [MMUSIC] Benjamin Kaduk's Discuss on draft-ietf-mmusic-sdp-uks-06: (with DISCUSS and COMMENT)

"Martin Thomson" <mt@lowentropy.net> Wed, 07 August 2019 03:09 UTC

Return-Path: <mt@lowentropy.net>
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 0333C1200B2; Tue, 6 Aug 2019 20:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=xHq9DRzP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B8vKY/Ws
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 juCHMYNcTj8P; Tue, 6 Aug 2019 20:09:38 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D841120058; Tue, 6 Aug 2019 20:09:38 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2BF8E21EAF; Tue, 6 Aug 2019 23:09:37 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 06 Aug 2019 23:09:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=r8ENnSIpvuKKTQjoqjk7AbT9L01y k+Zzh8KLFOjZhZA=; b=xHq9DRzPLezL+edVyyeiggRWsfFRTh9PSsCklanLdS44 2yr02yfbjFndhrjnsQRs53whL7JzET0UaULs0vsmwK9rIaED996GyjvOj/rkm6ZE bQ2LnjyI4a45O+0VC86XSYZrix18knrLvaMNq0jyQLuPhVVPMYejLeph/+I8ltrh VvgcUoQeF5PRYYvQE7piiZ0215ZyA0qbGEdqRcwf9vwWqgHwzX5Lls57yS8cWAzZ U/Y8MNM7TosO8qb3Tn5fURbgUXYGXXNPFfrtr6Bjy6+Lsur61nMaqo1+4MOoy84R mwXD9I3drbCaxbjf+WMZ6s44w6PF2g/HidkzND2aBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=r8ENnS IpvuKKTQjoqjk7AbT9L01yk+Zzh8KLFOjZhZA=; b=B8vKY/WsShc29+V/PRusnl SKXEsry0L4dLSoiSjMF79oqBItLU2ZQpx/B7oEXImPEiFuMN0s1TQeQoavnZJNuU OZpvI8Odu5Ui0LnppnBUXFkGQP735y9uj7ecVss0YkW22x64Hz1DtC/wMHuk4QTa VTc2BCcSK09z7iGL+0advjbijcYEylCHwvQ8aJhNTOqZ2GMZYd3kd3nFQEr4TN3u J4h6QCqTgvd0DaKbJ9bDbHEYuRGPCrKn9YESitweeOxMf35FyUN0vRd4miEcAR/T A8d6YJtbZjxLnXzkpEELAAcJBsdlRo2ZwlpLun2tYnpP0vuoyLsOdrULQXOzOYlg ==
X-ME-Sender: <xms:8EBKXUJ88iaWXtOtG_qM9ljvSGB1YH85xC9TXmlwToy6YANe-GAf1Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduuddgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:8EBKXYYp39pr3IhflqUnzzzwq2hus0Be6_7PFVsn3WQ7RFFBNhEQ_g> <xmx:8EBKXfv-he0D3BANZwM4HXZ2SQkaEC4mB-WCVM6i3aEOPLuPY_wlyg> <xmx:8EBKXVschk0sjHNh2G6D03Xxk-E-QX7O4VC27xfLCvUfj7dUvcq-BA> <xmx:8UBKXbomikV2B1_OPNOkHwqfLf6onOwQXnC_b_fOCRQ4ZtH-90NC9w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 675EDE00A2; Tue, 6 Aug 2019 23:09:36 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-808-g930a1a1-fmstable-20190805v2
Mime-Version: 1.0
Message-Id: <42a62093-9b2a-4be0-80a0-c4bda3529deb@www.fastmail.com>
In-Reply-To: <20190806193209.GK59807@kduck.mit.edu>
References: <156502247647.24440.17878436939662954486.idtracker@ietfa.amsl.com> <071b74eb-cab2-4a82-9d02-bf86c96d4f41@www.fastmail.com> <20190806193209.GK59807@kduck.mit.edu>
Date: Wed, 07 Aug 2019 13:09:39 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: "'Benjamin Kaduk'" <kaduk@mit.edu>
Cc: "The IESG" <iesg@ietf.org>, draft-ietf-mmusic-sdp-uks@ietf.org, mmusic <mmusic@ietf.org>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/3ko7RXafHQjiNPdrJMmUGoa8ut8>
Subject: Re: [MMUSIC] =?utf-8?q?Benjamin_Kaduk=27s_Discuss_on_draft-ietf-mmus?= =?utf-8?q?ic-sdp-uks-06=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Wed, 07 Aug 2019 03:09:40 -0000

Pruning aggressively.  PR updated for the easy stuff that didn't require commentary.

On Wed, Aug 7, 2019, at 05:32, Benjamin Kaduk wrote:
> > > Similarly, the current text for the last sentence of Section 3.2 ("In
> > > TLS 1.3, the "external_id_hash" extension MUST be sent in the
> > > EncryptedExtensions message.") can be (mis)read as implying that all
> > > EncryptedExtensions messages sent by TLS servers that implement this
> > > specification must include this extension, which would violate the TLS
> > > extension-negotiation model since it mandates the server sending an
> > > extension without regard to the client having indicated support for the
> > > extension.  Perhaps "MUST NOT be sent in the TLS 1.3 ServerHello message"
> > > conveys the restriction more clearly?
> > > (A similar comment applies to the corresponding statement in Section
> > > 4.3, which interestingly enough already has a "In TLS 1.3, the
> > > "external_session_id" extension MUST NOT be included in a ServerHello."
> > > disclaimer in addition to the problematic sentence.)
> 
> (I'm not sure we quite got all of these in the linked pull request.)

I think that I caught these now.  It seems obvious to me - to the point it doesn't warrant mention - that a server can't send an extension that a client didn't send...  Hence the omission.

> Thanks for helping flesh this out.  Looking back at the text I quoted from
> the document, there are two things that I might want to change (still not
> 100% confident): (1) "unless it is assumed", which is potentially vague
> about who/what is doing the assuming.  Perhaps "unless there is additional
> data exchanged under the assumption that" or similar.  (2) "unless they also
> validate the identity of peers at both layers".  This document describes
> how to validate the identity of the peer at the TLS layer, but I wonder if
> we want some extra reference/guidance on validating the peer's identity at
> the signalling layer.

I've done part of that.  But the latter requires an existence proof.  I don't believe that any signaling system provides the necessary bindings.

In thinking about this, you need channel bindings.  That is, the signaling need to be able to assert not that the peer is the same as the peer at the media layer, but also that the media layer is in the correct place.  So I'm going to say that this is out of scope:

"Such a signaling system, while out of scope for this document, requires that the
signaling layer is authenticated and bound to the TLS connections."

I'm not aware of any such system, as much as it might be desirable.  SIP is still wrestling with the concept of caller identity.  Proper channel bindings seems like a bit much to expect.