Re: [icnrg] [irsg] Final IRSG poll on draft-irtf-icnrg-terminology-05

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 24 September 2019 00:59 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DAC1200DF; Mon, 23 Sep 2019 17:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 CIoqgLNTUEeY; Mon, 23 Sep 2019 17:59:10 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D41120152; Mon, 23 Sep 2019 17:59:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 58955BE4D; Tue, 24 Sep 2019 01:59:07 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31XsnIpSDebh; Tue, 24 Sep 2019 01:59:05 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A010BE39; Tue, 24 Sep 2019 01:59:05 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1569286745; bh=xEciOVarbY4NkTVnxnvLwFcdkePRYg/yiv/iOrunvkw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ejWKOgYw3DehaROMU7jY9NPPXtK+nZ8RzkyUQ7KYFnFZHcRns1aW3Q7GHAe+QaX8m Z0UdiVV4UgLv/TZSD9XVSEEQQMg2cNSbgsmlI1sAY2BVvhBCosfRnu/06Ch2w6438j Ua1japiBdoiT5ie5pjv9s6/WaaoKjnHOMNjQ+3i4=
To: Colin Perkins <csp@csperkins.org>, Internet Research Steering Group <irsg@irtf.org>
References: <6D29C617-B033-47CE-B421-BABE76DC205B@csperkins.org>
Cc: "icnrg@irtf.org" <icnrg@irtf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <d9e570c4-596e-93b1-9431-7a02b912aa8a@cs.tcd.ie>
Date: Tue, 24 Sep 2019 01:59:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <6D29C617-B033-47CE-B421-BABE76DC205B@csperkins.org>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6qAUoD4pu4uuzbAf0TO8Xz3SGTucAQV2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/TZyuzs9daRi07q-oD0XFA_aILbk>
Subject: Re: [icnrg] [irsg] Final IRSG poll on draft-irtf-icnrg-terminology-05
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 00:59:22 -0000

Hiya,

On 23/09/2019 23:12, Colin Perkins wrote:
> IRSG members,
> 
> This is to initiate a final IRSG poll on
> draft-irtf-icnrg-terminology-05 with a deadline of 14 October 2019.

Given that I'm coming to the game very late, I am fine
with a ready to publish vote on this.

However, had I not been so late, I'd have said this was
not ready as I'm not sure that any of the cryptographic
mechanism terms are properly handled.

In particular I wonder if data packet signatures are
really checked or not (with existing s/w) and have to
consider the descriptions of confidentiality as being
mythical. I'd say fixing those parts could well be
considered an inherent part of due diligence.

Detailed comments/suggestions below.

Cheers,
S.

- abstract: is ICN still "novel"?

- intro: Is there really an intention to publish an equivalent for
  e.g.  NetInf? Be nice if there were, but it seems less likely now
than perhaps when this effort started.

- section 2: I refute the potential existence of an "irrefutable
  binding":-) Probably better to not use such odd language in a
terminology draft? (In case someone wants to discuss, consider a
DNSpionage type attack against a CA issuing certificates for use in
an ICN - doesn't matter if that'd be a hard or unlikely attack,
it's enough that irrefutable is wrong.) Suggest s/irrefutable
binding/strong cryptographic binding/

- s2: "Data authenticity and encryption" - hmm. Last time I asked a
  student implementing ICN, he couldn't find any code that actually
enforced signature verification. Is that still the case? If so,
then it seems wrong to perpetuate a myth like this. If not - great!
And where can I find sample logs for mismatching interest and data
packet caught via signature failure? Secondly, the idea that it's
fine and dandy that confidentiality doesn't exist within ICN seems
nicely 20th century. All in all that paragraph seems misleading.  I
think the best fix would be to make the description contingent,
e.g. to say something like "s/w could (but mostly doesn't) drop
data packets that don't match interests because of signature check
failure." And maybe say "there is no ICN confidentiality service
(sadly)" if we want to be clear.

- s2: "Trust" - meh. I don't trust text with such definitions.
  Also, a description of the concept of "Trust" that ends with
"trust model" seems circular. I'd just delete that para - it only
obfuscates and doesn't help.

- s2: "packet mule" - there is a "data mule" concept from DTN that
  may be what's meant here. I think using that term and referring
to something that defines it would be better than inventing the new
term "packet mule." Later I find you even define the term "data
mule" in 3.2 so just using that will be better.

- 3.1: "Data packet immutability" - I don't believe it myself:-) If
  you hand me a packet, I can change and forward it. I think what
you mean is that change can be detected (in principle).  I don't
get the last sentence.

- 3.3: I was puzzled by the ordering of terms here. Why be coy
  about that? IOW, be good to explain to the reader why terms are
in this order. (My guess: to avoid forward refs.)

- 3.3: If there exists a useful definition of stateful forwarding,
  then why is there not one for stateless forwarding? If there is
not then why is there not just forwarding? In which case, why do we
need an entry in 3.3?

- 3.3: "data packet" ... the "and is directly secured" phrase - is
  that true? (See earlier.)

- 3.5: "name" ... the assertion of being "semantically meaningful"
  seems unnecessary to me and also impossible to verify. Maybe just
delete the phrase as it's qualified with a "usually" anyway?

- 3.5: SHA256 probably calls for a reference.

- 3.5: "nonce" - this has a cryptographic definition that is
  perhaps not the same (see RFC4949). Saying that explicitly would
be good.

- 3.7: "data integrity" also protects against deliberate
  modification, as well as corruption.

- 3.7: "authenticity" - using HMAC? Really? That seems like a
  totally broken idea for an ICN. Surely any symmetric scheme
like that couldn't work with caching without allow forgery?

- 3.7: all the "... confidentiality" paragraphs - this seems like
  it'd be better omitted given the utter lack of ways in which such
a service can be provided as part of an ICN.