Re: [secdir] Secdir review of draft-ietf-intarea-broadcast-consider-05
Vincent Roca <vincent.roca@inria.fr> Tue, 16 January 2018 08:57 UTC
Return-Path: <vincent.roca@inria.fr>
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 2BFD212FAC4; Tue, 16 Jan 2018 00:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.186
X-Spam-Level:
X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 h3eY4ghN_OmD; Tue, 16 Jan 2018 00:57:09 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 679F0126D05; Tue, 16 Jan 2018 00:57:08 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.46,367,1511823600"; d="scan'208,217";a="309217945"
Received: from agrenoble-651-1-576-228.w92-129.abo.wanadoo.fr (HELO [192.168.10.46]) ([92.129.108.228]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 09:57:05 +0100
To: Rolf Winter <rolf.winter@hs-augsburg.de>
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Content-Type: text/html; charset="utf-8"
X-Apple-Base-Url: x-msg://13/
X-Apple-Mail-Remote-Attachments: YES
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <80beb32b-35fe-9a2d-e951-037a34d81a5f@hs-augsburg.de>
X-Should-Pgp-Sign: NO
Date: Tue, 16 Jan 2018 09:50:26 +0100
Cc: Vincent Roca <vincent.roca@inria.fr>, IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-intarea-broadcast-consider.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <50006956-2D5C-49F9-8CA8-ACBEC2B266F1@inria.fr>
References: <383EA7C8-CFF0-48AF-AD0C-840545483E94@inria.fr> <80beb32b-35fe-9a2d-e951-037a34d81a5f@hs-augsburg.de>
X-Should-Pgp-Encrypt: NO
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/DCPyJVWNSsoS56OmEF4b0IaqMY8>
Subject: Re: [secdir] Secdir review of draft-ietf-intarea-broadcast-consider-05
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: Tue, 16 Jan 2018 08:57:12 -0000
thanks for the detailed review and sorry for the belated reply. We have submitted a new version based on these comments and recommendations. Please see inline:
2) Another point: I'd like to see the item (b) of introduction
developed as this is the key issue with multicast/broadcast traffic.
Without encryption, application messages are vulnerable to
eavesdropping and all kinds of analyses. A group key could be
negociated and used for encrypting this traffic, but this requires a
more complex setup mechanism (typically a key management system,
probably with re-keying and all the stuff) and requires a preliminary
association of a terminal that is not necessarily compatible with the
application-layer protocol features.
The text could say that if possible, multicast/broadcast traffic
encryption should be used, otherwise risks should be minimised as
discussed in this document. And of course, it's always good to remind
the designers that unicast traffic should be always encrypted since
there's no good reason not to do that.
We talk about this in the security considerations section and come to the same conclusion as you do:
"It should be noted that certain applications could make use of
existing mechanisms to protect multicast traffic such as the ones
defined in [RFC5374]. Examples of such applications can be found in
Appendix A. of [RFC5374]. Given the required infrastructure and
assumptions about these applications and the security infrastructure,
many applications will not be able to make use of such mechanisms."
In which way would you expand on this?
3) I'd like to suggest another recommendation: when applicable, limit
or avoid user-originated broadcast/multicast messages, preferring
infrastructure originated messages.
An example: in a discovery mechanism, avoid terminal sollicitation as
much as possible and limit oneself to infrastructure announcement
broadcast messages, even if it can include some extra delay (controled
with the announcement frequency). This is exactly what happened in
Wifi AP discovery, where the passive discovery scheme, AP based, is
now prefered to the active scheme.
Said differently, multicast/broadcast is not per se the issue, when
originating from the infrastructure it is generaly safe.
I think I disagree somewhat (and it is not a generally applicable use case, e.g. if resources on a host are offered there is no general way to delegate announcements of these to the infrastructure). Saying that infrastructure announcements are generally safe requires that a receiver can validate that a message came from the infrastructure which is a problem (e.g. rogue DHCP servers). A lot of deployments solve some of this through infrastructure means (e.g. DHCP snooping), but we have documented that. Also, whatever comes from the infrastructure requires a standard so that devices/apps understand it. We have text around that, too.
4) A more general comment, related to item (a) of intro:
Broadcast/multicast can simplify user surveillance, I agree. However,
when I'm looking at all the practicies of companies working in the
advertising area (in particular A&A companies, sitting between
smartphone users and advertisers, domain that I know a little bit),
the techniques deployed are incredibly smart, some of them bypassing
technical protections set up by the OS manufacturers, others relying
on hidden technical features. It's impressive how inventive those
companies can be.
My point is that even if traffic is 100% unicast, as long as a
wireless medium is used, anyone wanting to monitor users in order to
profile them will set up the required hardware/software configuration.
This is trivial and extremely cheap nowadays (except perhaps for 4G
connections), and most of the time this is a purely passive
monitoring. The unicast/multicast/broadcast nature of traffic has no
importance as long as you are within wireless network range.
I think there is little that the IETF can do about that. Also "bypassing technical protection" and using "hidden technical features" is nothing you can protect against in general and I assume is often not by design.
*Various:*
** the authors use the term "host name" to refer to a higher layer
name of a device. To me this term refers to the DNS notion of
"hostname", i.e. something different, hence confusion. I'd recommend
to use "device name" in order to avoid it.
Well, RFC 7719 even admits the term is ill defined and does refer to various things. Also, for the protocols we looked at and OS configurations, sometimes there are different host namens being used for different purposes. We would like to stick with host names (also since RFC8117 useses the term which is highly relevant in this context).
- [secdir] Secdir review of draft-ietf-intarea-broa… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-intarea-… Rolf Winter
- Re: [secdir] Secdir review of draft-ietf-intarea-… Vincent Roca
- [secdir] Secdir review of draft-ietf-intarea-broa… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-intarea-… Rolf Winter
- Re: [secdir] Secdir review of draft-ietf-intarea-… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-intarea-… Rolf Winter
- Re: [secdir] Secdir review of draft-ietf-intarea-… Vincent Roca