Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
<mohamed.boucadair@orange.com> Mon, 21 January 2019 07:31 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECE7130F70; Sun, 20 Jan 2019 23:31:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xc9COsjfSrnq; Sun, 20 Jan 2019 23:31:32 -0800 (PST)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB9A130F55; Sun, 20 Jan 2019 23:31:32 -0800 (PST)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 43jjsZ0wB8z10kW; Mon, 21 Jan 2019 08:31:30 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 43jjsY6kZLz8sYn; Mon, 21 Jan 2019 08:31:29 +0100 (CET)
Received: from OPEXCAUBM5D.corporate.adroot.infra.ftgroup (10.114.13.60) by OPEXCLILMA2.corporate.adroot.infra.ftgroup (10.114.31.69) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 21 Jan 2019 08:31:29 +0100
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5D.corporate.adroot.infra.ftgroup ([fe80::8899:bbc3:9726:cd5e%22]) with mapi id 14.03.0415.000; Mon, 21 Jan 2019 08:31:29 +0100
From: mohamed.boucadair@orange.com
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, Benjamin Kaduk <kaduk@mit.edu>
CC: "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
Thread-Index: AQHUr3Ewz5rRJt5UT++zbKjLtGqWuKW2EcuAgAM4YMA=
Date: Mon, 21 Jan 2019 07:31:28 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0ABE9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B93302EA08D24@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190118210258.GO81907@kduck.mit.edu> <BYAPR16MB279063917ED17BF8D0331060EA9D0@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB279063917ED17BF8D0331060EA9D0@BYAPR16MB2790.namprd16.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/0uO1ezoqtiqgJIcyy5Nkr0tHspM>
Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jan 2019 07:31:35 -0000
Hi Ben, all, Please see inline. Cheers, Med > -----Message d'origine----- > De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] > Envoyé : samedi 19 janvier 2019 07:32 > À : Benjamin Kaduk; BOUCADAIR Mohamed TGI/OLN > Cc : draft-ietf-dots-signal-channel@ietf.org; dots@ietf.org > Objet : RE: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th Part) > > Hi Ben, > > Please see inline > > > -----Original Message----- > > From: Dots <dots-bounces@ietf.org> On Behalf Of Benjamin Kaduk > > Sent: Saturday, January 19, 2019 2:33 AM > > To: mohamed.boucadair@orange.com > > Cc: draft-ietf-dots-signal-channel@ietf.org; dots@ietf.org > > Subject: Re: [Dots] AD review of draft-ietf-dots-signal-channel-25 (5th > Part) > > > > This email originated from outside of the organization. Do not click links > or > > open attachments unless you recognize the sender and know the content is > safe. > > > > Hi all, > > > > Thanks for all the edits and the published -27. > > Assuming I'm actually caught up on all the review/response threads, I think > > we're pretty close to being able to go to IETF LC -- here's what I see as > still left: > > > > - We need to settle the risk of needing normative downrefs called out for > > the last call [Med] I updated the text to: * cite 7618/7624 as normative (+ indicate that a similar mechanism to false start may also be defined for DTLS). * tweak the TFO text to maintain it as informative. > > - I just noticed while reviewing the diff that we also need to say a > > little more about (D)TLS 1.3 0-RTT data (more below) > > - It looks like we lost the guidance to the Experts and text about the > > review mailing list from the IANA Considerations, during the reshuffling > > around having IANA manage more things > > [Med] That was on purpose. We would like to rely on RFC8126 rules for deigned expert reviews. > > Regarding the (D)TLS 1.3 0-RTT data, RFC 8446 notes that "Application > > protocols MUST NOT use 0-RTT data without a profile that defines its use. > > That profile needs to identify which messages or interactions are safe to > use > > with 0-RTT and how to handle the situation when the server rejects 0-RTT > and > > falls back to 1-RTT." So we either need to say which client requests are > 0-RTT > > safe (and why) or defer that profile to another document. draft-ietf- > dnsop- > > session-signal is perhaps an example of a document that specifies which > > messages are/aren't allowed in early data. > > (draft-ietf-acme-acme is another, but an uninteresting one, since they make > > every request include a single-use nonce, and all messages are 0-RTT safe.) > > Our use of increasing 'mid' values may help here, in terms of allowing > DELETEs > > to be safe, but I'd have to think a little more to be sure that requesting > > mitigation would be safe. (On first glance the session-managemnet bits > would > > not be safe, but I may be missing something.) > > The draft only uses idempotent requests (GET, PUT and DELETE), and CoAP is > capable of detecting message duplication (see > https://tools.ietf.org/html/rfc7252#section-4.5) for both confirmable and > non-confirmable messages. > [1] An attacker replaying DELETE will not have any adverse impact, 2.02 > (Deleted) Response Code is returned even if the mitigation request does not > exist. > [2] The techniques discussed in Section 8 of RFC8446 should suffice to handle > anti-replay (e.g. an attacker replaying a 0-RTT data carrying an old > mitigation request replaced by a new mitigation scope). > [Med] FWIW, we do already have this text in the draft: Section 8 of [RFC8446] discusses some mechanisms to implement to limit the impact of replay attacks on 0-RTT data. If the DOTS server accepts 0-RTT, it MUST implement one of these mechanisms. A DOTS server can reject 0-RTT by sending a TLS HelloRetryRequest. > > > > Further notes inline. > > > > On Thu, Jan 17, 2019 at 06:51:04AM +0000, mohamed.boucadair@orange.com > > wrote: > > > Hi Ben, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] Envoyé : mercredi 16 > > > > janvier 2019 01:14 À : draft-ietf-dots-signal-channel@ietf.org > > > > Cc : dots@ietf.org > > > > Objet : AD review of draft-ietf-dots-signal-channel-25 > > > > > > > > Section 7.2 > > > > > > > > The TLS 1.3 handshake with 0-RTT diagram needs to be > > > > revisited/refreshed, as RFC 8446 does not look like that. > > > > Additionally, the usage of PSK as well as a certificate is not > > > > defined until draft-housley-tls-tls13-cert-with-extern-psk is > published. > > > > I also note that in the diagram as presented, the client is not yet > > > > known to be authenticated when the server sends its initial > > > > (0.5-RTT) DOTS signal message. > > > > > > > > > > [Med] Noted. Thanks. > > > > > > > Section 7.3 > > > > > > > > This whole section seems to only be relevant for UDP usage, so > > > > probably the "If UDP is used" clause can be dropped and an > > > > introductory statement added earlier on. > > > > > > [Med] Will consider that. > > > > > > > > > > > Path MTU MUST be greater than or equal to > > > > [CoAP message size + DTLS overhead of 13 octets + authentication > > > > overhead of the negotiated DTLS cipher suite + block padding] > > > > (Section 4.1.1.1 of [RFC6347]). If the request size exceeds the > path > > > > MTU then the DOTS client MUST split the DOTS signal into separate > > > > messages, for example the list of addresses in the 'target-prefix' > > > > parameter could be split into multiple lists and each list conveyed > > > > in a new PUT request. > > > > > > > > (DTLS 1.3 will have a short header for some packets, that is less > > > > than > > > > 13 octets.) > > > > > > [Med] The text is more about 1.2. We can add a 1.3 note if you think it > is > > useful for the discussion. > > > > > > > > > > > Section 8 > > > > > > > > We've got some requirements in here about limiting behavior of > > > > clients/servers when talking to gateways; is knowing about the > > > > presence of a gateway something that's required to happen out of > > > > band or is there an in-band way to identify that the peer is a gateway? > > > > > > [Med] An agent does not necessary know that it peer is gateway. A gateway > is > > seen as a server for the client, and a client for a server. > > > > > > > > > > > messages from an authorized DOTS gateway, thereby creating a two- > link > > > > chain of transitive authentication between the DOTS client and the > > > > DOTS server. > > > > > > > > This seems to ignore the possibility of setups that include both > > > > client-domain and server-domain gateways. > > > > > > [Med] I updated the text to mention this is only an example. > > > > > > > > > > > DOTS client certificate validation MUST be performed > as > > > > per [RFC5280] and the DOTS client certificate MUST conform to the > > > > [RFC5280] certificate profile. [...] > > > > > > > > This seems to duplicate a requirement already stated in Section 7.1; > > > > it's probably best to only have normative language in one location, > > > > even if we need to mention the topic in multiple locations. > > > > Similarly for the mutual authentication requirement, which we > > > > duplicate in the second and fourth paragraphs of this section. > > > > > > [Med] Good point. Fixed. > > > > > > > > > > > If we don't want to use example.com vs. example.net as sample > > > > domains, we can also use whateverwewant.example, per RFC 6761. > > > > > > [Med] Will maintain the ones already in the draft. Thanks. > > > > > > > > > > > Section 9 > > > > > > > > We should mention the media-type allocation in the top-level section. > > > > > > [Med] Will fix that. > > > > > > > > > > > "mappings to CBOR" feels confusing to me, since it leaves empty what > > > > we are mapping from. Perhaps just talking about a registry of "CBOR > > > > map keys" would be better, both here and in the Section 9.3 intro. > > > > > > > > > > [Med] Unless there is an objection, I can use "CBOR Map Keys". > > > > > > > Section 9.3 > > > > > > > > I suggest being very explicit about whether new requests for > > > > registration should be directed to the mailing list or to IANA, as > > > > we've had some confusion about this elsewhere. > > > > > > > > The criteria used by the experts also just lists things they should > > > > consider, but does not provide full clarity on which answer to the > > > > question is more likely to be approved. (And yes, I know that this > > > > text is largely copied from already published RFCs, but we can still > > > > do > > > > better.) > > > > > > [Med] Will check this. > > > > > > > > > > > Section 9.3.1 > > > > > > > > If we want the value 0 to be reserved we need to say so. > > > > > > [Med] 0 is not part of the allocation range. > > > > > > > Do we want to say anything about the usage of negative integers as > > > > map keys? > > > > > > > > I suggest not mentioning the postal address, given the recent (e.g.) > > > > GDPR requirements. > > > > > > [Med] Good point. Done. > > > > > > > > > > > Section 9.3.2 > > > > > > > > It may be worth mentioning Table 4 here as well. > > > > > > [Med] OK. > > > > > > > > > > > Section 9.5.1 > > > > > > > > We need to specify which range of values we are asking for an > > > > allocation from. > > > > > > [Med] Added a mention to 0-255 range. > > > > > > > > > > > Section 9.6.1 > > > > > > > > As above, specify what range we're asking about. > > > > > > [Med] OK. > > > > > > > > > > > I expect the current text to get some IESG (or directorate) feedback > > > > that the Data Item and Semantics descriptions are repetitive and banal. > > > > > > > > Section 9.7 > > > > > > > > IIUC, IANA is going to ask if we want this module to be "maintained > > > > by IANA", so it would be good to have an answer ready even if we > > > > don't put it in the document text. > > > > > > [Med] This is discussed in -26. > > > > > > > > > > > Rate-limiting DOTS requests, including those with new 'cuid' values, > > > > from the same DOTS client defends against DoS attacks that would > > > > > > > > With respect to "new" 'cuid' values, is the server required to > > > > remember which ones it has seen in perpetuity, or can it time them > > > > out eventually? > > > > > > [Med] The attack vector is a DOTS client which changes frequently its > cuid. > > The DOTS server can set an interval in which the same client cannot present > a > > new cuid. > > > > > > > > > > > Section 10 > > > > > > > > The security considerations seem to be taking a narrow focus on the > > > > requirements for and consequences of specific bits on the wire in > > > > the signal channel protocol. I think it's appropriate to also > > > > include some high-level thoughts about the functional behavior of > > > > the protocol, allowing to signal that an attack is underway and > > > > trigger mitigation, increasing the availability of services, etc., > > > > and the risks that are posed by the protocol failing to work > > > > properly, whether that means letting attack traffic through or > > > > improperly blocking legitimate traffic. > > > > > > [Med] Would a pointer to the architecture/requirements I-Ds be sufficient > to > > cover to high-level aspects? > > > > Those documents' security considerations do seem to cover the relevant > points, > > yes. > > > > > > > > > > Section 13.1 > > > > > > > > I think the IANA registries should be listed as Informational and > > > > not Normative references. > > > > > > > > > > [Med] Done. > > > > > > > Section 13.2 > > > > > > > > Pending resolution of the question about using > > > > draft-ietf-core-yang-cbor rules or RFC7951+RFC7049, the > > > > draft-ietf-core-yang-cbor reference may need to be Normative. > > > > > > [Med] Please refer to my answer to that question. draft-ietf-core-yang- > cbor is > > informative. > > > > > > > > > > > Given that "URI" is a well-known abbreviation, we may be able to get > > > > away with not citing RFC 3986. On the other hand, it's not causing > > > > any harm to leave it in... > > > > > > [Med] Will leave it. > > > > > > > > > > > RFC 4632 needs to be Normative, since we need to know CIDR to > > > > encode/decode target-prefixes. > > > > > > [Med] Works for me. > > > > > > > > > > > Similarly, I think that RFCs 6234 > > > > > > [Med] This one is not listed as normative because other hash algos may be > > used. > > > > It's a lower-case "recommended", which can probably eke by as descriptive > and > > not a "protocol feature" (see below). > > > > > , 7413 > > > [Med] The support if TFO is not mandatory. > > > > It's a SHOULD ("SHOULD implement all of the following items"), though... > > > > > , 7589 > > > [Med] This is a MAY in the spec. It is just fine to leave it as > informative. > > > > ....per > > https://www.ietf.org/blog/iesg-statement-normative-and-informative- > > references/ > > note 1, "Even references that are relevant only for optional features must > be > > classified as normative if they meet the above conditions for normative > > references." > > > > This does seem to be something we actually need to care about before IETF > LC, > > though, as 7413 is Experimental and not listed in the downref registry > > (https://datatracker.ietf.org/doc/downref/), so if we leave it as > Informational > > and have to change it later, we'd need to also restart/re-run the IETF LC. > > > > > , 7918 > > > [Med] Idem as TFO. > > > > This is Informational (i.e., also susceptible to the downref issue). > > > > > , 7924 > > > [Med] Idem as TFO. > > > > (idem x2), though this is standards-track at least, so we have more leeway > to > > move things around later. > > > > > > > > I think the most expedient thing to do here would just be to relax the > > requirement for TLS Falst STart, TFO, and Cached Information, perhaps to > text > > like "The following items are additional mechanisms that can reduce the > delay > > required to deliver a DOTS signal channel message, which implementations > are > > encouraged to implement as possible.", but I am open to other suggestions > for > > what to do. > > TLS False Start and Cached Information can be made normative references (just > like we referenced these items in our spec > https://tools.ietf.org/html/rfc8310) > TFO is for TCP only and that too for exception scenarios where UDP is > blocked. TFO can removed from the list of items the DOTS agents SHOULD > implement. > > NEW: > Compared to UDP, DOTS signal channel over TCP requires an additional round- > trip time (RTT) of latency to establish a TCP connection. Implementations > are encouraged to implement TCP > Fast Open [RFC7413] to eliminate that RTT when information exists from prior > TCP connection. > > -Tiru > > > > > > > > , and 7951 > > > [Med] this one was not listed as normative because the document lists two > > ways to do the mapping. > > > > Agreed. > > > > -Ben > > > > > > should also be Normative. > > > > > > > > > > > > -Ben > > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… mohamed.boucadair
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Konda, Tirumaleswar Reddy
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… mohamed.boucadair
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Konda, Tirumaleswar Reddy
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Benjamin Kaduk
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Konda, Tirumaleswar Reddy
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… mohamed.boucadair
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Konda, Tirumaleswar Reddy
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… mohamed.boucadair
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Konda, Tirumaleswar Reddy
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Benjamin Kaduk
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Benjamin Kaduk
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… mohamed.boucadair
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Benjamin Kaduk
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… mohamed.boucadair
- Re: [Dots] AD review of draft-ietf-dots-signal-ch… Konda, Tirumaleswar Reddy