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

Benjamin Kaduk <kaduk@mit.edu> Wed, 07 August 2019 03:31 UTC

Return-Path: <kaduk@mit.edu>
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 E933A1200B9; Tue, 6 Aug 2019 20:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 4DUBUbvUaJhn; Tue, 6 Aug 2019 20:31:15 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 469F412004A; Tue, 6 Aug 2019 20:31:14 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x773VADW011258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Aug 2019 23:31:12 -0400
Date: Tue, 6 Aug 2019 22:31:09 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Martin Thomson <mt@lowentropy.net>
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>
Message-ID: <20190807033109.GP59807@kduck.mit.edu>
References: <156502247647.24440.17878436939662954486.idtracker@ietfa.amsl.com> <071b74eb-cab2-4a82-9d02-bf86c96d4f41@www.fastmail.com> <20190806193209.GK59807@kduck.mit.edu> <42a62093-9b2a-4be0-80a0-c4bda3529deb@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42a62093-9b2a-4be0-80a0-c4bda3529deb@www.fastmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/DZ0hKQ49sd0cQlwx4CySY-Vc65I>
Subject: Re: [MMUSIC] Benjamin Kaduk's Discuss on draft-ietf-mmusic-sdp-uks-06: (with DISCUSS and COMMENT)
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:31:18 -0000

On Wed, Aug 07, 2019 at 01:09:39PM +1000, Martin Thomson wrote:
> 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.

(I quote liberally from
https://github.com/martinthomson/sdp-uks/blob/cf6084c44581c794e93bda174e2bc6883fada26e/draft-ietf-mmusic-sdp-uks.md
in the following.)

It's quite obvious to you and me, but it's probably poor form to produce
statements of the form "an implementation MUST do X" with implied "except
in cases that are forbidden by the base protocol".  So, a standalone
paragraph of "In TLS 1.3, the <foo> extension MUST be sent in
the EncryptedExtensions message." still sounds like anything sending EE
that implements this document must include the <foo> extension, even though
you and I know that the intent is really "In TLS 1.3, the server's
responses to ClientHello extensions can either be in the ServerHello or
EncryptedExtensions, and this extension doesn't go in the ServerHello."
(To some extent, even this is redundant given the column in the registry,
though I don't mind the extra emphasis.)

On the other hand, "An endpoint that does not produce an identity binding
MUST generate an empty external_id_hash extension in its ClientHello or -
if a client provides the extension - in ServerHello or EncryptedExtensions"
is better about qualifying when it's allowed by the underlying protocol to
"do X", though a truly adversarial reader might claim that it is saying
that "all endpoints producing an identity binding MUST generate a
ClientHello".

> > 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 fine leaving this out of scope, though I'd wordsmith your proposed text
to clarify that "such a signaling system" is one that can defend against
the attack being described.

> 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.

Oh, sure -- SIP is going to take some time to evolve, and I'm not trying to
force everything overnight.

-Ben