Re: [secdir] secdir review of draft-ietf-ice-trickle-16

Peter Saint-Andre <stpeter@mozilla.com> Wed, 21 February 2018 23:56 UTC

Return-Path: <stpeter@mozilla.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECD01200E5 for <secdir@ietfa.amsl.com>; Wed, 21 Feb 2018 15:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 rFukJbieHJ0a for <secdir@ietfa.amsl.com>; Wed, 21 Feb 2018 15:56:17 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 28C68120724 for <secdir@ietf.org>; Wed, 21 Feb 2018 15:56:17 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id a17so1351114pff.8 for <secdir@ietf.org>; Wed, 21 Feb 2018 15:56:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=c8F6KZpOe0zxESool/xSpnqku28ADNVuM6Ky1o6d3Cg=; b=ZYy/WWeJx6isZ3YKY3hxLszvidIEskj0VhAYUorEwiNzYZmxjaFZDvhLUjYRWQ53Nb Xbm86pg97B5mq/PnxIvt+xuiT/4FhpbfenPLhxSQ3QP2Qb1ArUixLi4KQ7Um0oqFZdD0 nwg0xmvE9YZ4948apLHteYwskEFbCWG7ip/pM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=c8F6KZpOe0zxESool/xSpnqku28ADNVuM6Ky1o6d3Cg=; b=i2LLgD1c/saQmP7TmwNf7+WCTzw9j7PnCBbWKKTKo09ENljxoTLTIHhlu0MADjKBci c0skiWTypjZXHQ+Fe9z7K0FmVU0EIF0zItYfwCQQg0g4HxmJt09E33/A7p634VYH6Jlk o0j5VfLO5dS4OA9xX6HOiLqYqgKAgzqQ1T4u2NWQ32NGy3DJdQrnBcm3m6bKpNy+KytS 8U4s/J8sQsiADjonKTfxIiyL3VlmF2sLCRMjOJIlFNislLjdaEl/VU90+ppVvPtzS4qO Yt7jAuaibRK9nM1J+Os5U3qQpRzYBh/TWo1nSnz/I7FiI79JxzEnnj+vha5SY2I7hk09 1+Yw==
X-Gm-Message-State: APf1xPCcRzk8uSM8Lk8FHUttUtFeQSYYS7OHqgg0zQ3OK9pKB0XWXQNm BPqRrP+mMTYIE1ui5VVi3UqV5w==
X-Google-Smtp-Source: AH8x225SA55+iVdF28Rdj8QMwsarU/KUq1orgeFhUXSSLNdQnl+JMzezD5dJME0z/z7ne24tMKEuqw==
X-Received: by 10.99.121.5 with SMTP id u5mr4045135pgc.444.1519257376578; Wed, 21 Feb 2018 15:56:16 -0800 (PST)
Received: from dragon.local ([2620:101:80f4:224:38da:32b0:3821:d1f4]) by smtp.gmail.com with ESMTPSA id e13sm59180229pgt.82.2018.02.21.15.56.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 15:56:15 -0800 (PST)
To: David Mandelberg <david+work@mandelberg.org>, iesg@ietf.org, secdir@ietf.org, draft-ietf-ice-trickle.all@ietf.org
References: <02c7b2a3-6e15-7a1c-7781-19cd3c8656ab@mandelberg.org>
From: Peter Saint-Andre <stpeter@mozilla.com>
Message-ID: <28d45621-7f57-5f76-d85e-ab220fe4061d@mozilla.com>
Date: Wed, 21 Feb 2018 15:56:13 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <02c7b2a3-6e15-7a1c-7781-19cd3c8656ab@mandelberg.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OWl4WYXM6Qonqz7RIibVv6VedmUiDvOJe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/nRrmIH19IvAvlIsQFRDNPRz3GJY>
Subject: Re: [secdir] secdir review of draft-ietf-ice-trickle-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Feb 2018 23:56:20 -0000

On 2/21/18 2:09 PM, David Mandelberg wrote:
> Hi,

Hi David, thanks for the review.

> The summary of the review is: ready with nits.
> 
> (nit) Section 2: What is a "ufrag pair"? Is it short for username
> fragment pair? I might have just missed it, but I don't see a definition
> in the referenced terminology.

Perhaps it's a term of art, but in draft-ietf-ice-rfc5245bis it's called
the "Username Fragment and Password" so I suggest we use that.

> (nit) Section 15: If I understand correctly, the signaling protocol also
> needs to guarantee that the end-of-candidates indication is not
> re-ordered with respect to any trickled candidates. Is that correct? Is
> it worth adding to the requirements?

Good catch - in-order delivery applies here as well.

OLD
   o  A signaling protocol MUST deliver each trickled candidate not more
      than once and in the same order it was conveyed (see Section 8).

NEW
   o  A signaling protocol MUST deliver each trickled candidate or
      end-of-candidates indication not more than once and in the same
      order it was conveyed (see Section 8).

We might want to also modify the text in Section 8, as follows:

OLD
   When candidates are trickled, the signaling protocol MUST deliver
   each candidate to the receiving Trickle ICE implementation not more
   than once and in the same order it was conveyed.  If the signaling
   protocol provides any candidate retransmissions, they need to be
   hidden from the ICE implementation.

NEW
   When candidates are trickled, the signaling protocol MUST deliver
   each candidate (and any end-of-candidates indication as described in
   Section 8.2) to the receiving Trickle ICE implementation not more
   than once and in the same order it was conveyed.  If the signaling
   protocol provides any candidate retransmissions, they need to be
   hidden from the ICE implementation.

Peter