Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel)
"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 28 February 2019 10:50 UTC
Return-Path: <TirumaleswarReddy_Konda@mcafee.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 A4E60131231; Thu, 28 Feb 2019 02:50:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 FiqF_eNeXHh6; Thu, 28 Feb 2019 02:50:52 -0800 (PST)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 F2FA0130FD3; Thu, 28 Feb 2019 02:50:47 -0800 (PST)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1551350887; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-exchange-diagnostics: x-microsoft-antispam-prvs:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=/ WIr1RrL6mOMRE1Qkz0S4APXgcnDIEfzIwqaEm/Ff7 Q=; b=BPnhkUii3qzg1pAd06d0NlXSt7XJuHnueyd9H3LYalvm /jqqVnzGyUP6ZG0toL4Qg3qKgNAUPJC2g75W5c/z8A8yECgdMs Z9VN91xApAWObLMIAhLjy3v5d0H0LtokZhg9Cm/su5UNPpwaW9 Cv64aL+9A76FxA31BAQmvGSQ/0s=
Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 21a9_8292_7f94a86a_e958_4a25_b2e6_d9b059a159d0; Thu, 28 Feb 2019 03:48:07 -0700
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 03:49:53 -0700
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 28 Feb 2019 03:49:53 -0700
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 03:49:51 -0700
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2869.namprd16.prod.outlook.com (20.178.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Thu, 28 Feb 2019 10:49:49 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1665.015; Thu, 28 Feb 2019 10:49:49 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.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] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel)
Thread-Index: AQHUzz5BCXFDawydokCSl6Px8wMDQaX1B8jw
Date: Thu, 28 Feb 2019 10:49:48 +0000
Message-ID: <BYAPR16MB2790C6F98C259154C2AC200AEA750@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <787AE7BB302AE849A7480A190F8B93302EA0EC85@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA20112@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190215150458.GV56447@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA20406@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190218162322.GI24387@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA21AC0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190227155729.GL53396@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B93302EA2680B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA2680B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3e05268a-6b8a-43e6-8a2a-08d69d6a7601
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2869;
x-ms-traffictypediagnostic: BYAPR16MB2869:
x-ms-exchange-purlcount: 3
x-microsoft-exchange-diagnostics: 1;BYAPR16MB2869;23:YOzinYAgSP8/NhaaN+XVUCWLhMmOxF4Pvzqtq7yLG+NLZ2ymlmupI0/Wv6aiTwfb95k8EjhZka3M1uwbyKtIaqwrfjpSEP9RRJJGHMSDHdhUVWffj9HFIeLtmMaQaPTPEyfyBYRlORH/XGug+5MNMkvGSBf9llH4UGM4dgxpOq95VQYBCDdBsRnEMDDncyZovtLbKzyqY6Yfl3zT089PU6afbYssLi+dEH2tO4jecwULTr1iMEAvyl9PHGJkEB0Tld9u3Sd4rMaOtw4y9WpfqM49jgyA7LWAIa75LqKQfsa26mfX+wgiADZFhkK0zDisDox17Dfl9YSMkfaphgp761qzhu0r+SPcSqOFpXAESUI6ygXWhjE1ZDRxUHNGYJ0tiJai8J4KxkOJN8SlXa8HGfXlNqVpaS30mzm+NKT6gnU+rC+Z7q8bv64DiduraOJjmVDWN3IWwNPP1qT5Hi9v6s/M6jaJ6a83ODJVyYrxXhNiO8R3MSxZgJykuPU3VGSKCWpABxHs+m6HYyAoX4dgh8mZC0hAKsMJufR7A+zUtgzPZiLqAEESxOFUGX9ZOVAIoN7/yPLdQBD+vm9q6KwPb3mBb6+yDhSt4H/x9668Iw8g0BCszMSjyaW+fUDabWPo71btmOkFZvbnDPF+6Qhx32CyaLK4+gUra3PMtqbESb563gbYB9BsRZ/4v0zMuJ5FDG0n9IjmNOW9S0Nxn+XePbRW1o9vPl6nQrmSowVr6/amMVNPRqgoxTIevMoy/f/pXSDpyyxBUZ3RZ7EYOmktAMNki4dysLwg0V6u9P3pjj42mrV67bGU9vvPkNztMoknvr8gK3L7RjeJby1+WzJlgqLqs1JgE3hbQxUIiYa9kZDpDiYlLZXK9WgPX2Z76UHcuI6z+RxES0oxIbxV+6wqdYsh1IkBvkLhtQB1UE9+a4rcDM3Wa/Vt0skPnG3ZcpJ/tZqQBR5PXDCYAzfjflUY9BlMypmYKg4y9jaMGNddh3uVgkg3bw9Tm/106SX7NDv8ah/09Vu5AiUAQp1Fcnh9QrkTsFTVQiovYZxcrbI1el9KBOXKfuEvbGpKqP+ttKL6XYC3F6ff4QLe5ussrw5Cntrb6fCyBwwecV+f3qMMTTC4wL7uRB84N+PBvYPrzws5I8xj8nk4smoI8NYFi1WdaYwaNr4CUzxQr9xqSXkgBI4FbpKZ2vBi0UK8QyMBwb9gtHywXV2zde0cg7rnnGpas6zUnb4wmT0HEf8pkLMzeIhsu639TG9ht11l3d8xe4KGkbj6gRnCGRPwkyCKVA+90lWPvUpNekcgJw/3VYAnGN9ykgL2flIWURG1YILu3m4vA8hM8K2MEQ//u0hg1tyk6d1MFGlCgVgyvmIiCJi9rSj1l3ArtXQVIuY9dhsyEQPUg7q+N46TDJ2YSZ9Zp1QD2xPBgdOs1S60xD1laWtb1+CwSemlqN0VqRA01jFEzmqQlqlXdvh6LApmi37XCjuTIJp2VaNYuHNH3hT8mRAoAhIFY2sa0+s1ouXaTAF5saEoff0d9wxXd9VuprXzpyii8Pi2kj7IlS7z1ZRNkPd1ssU=
x-microsoft-antispam-prvs: <BYAPR16MB2869C1D6E90FEFA599180E3EEA750@BYAPR16MB2869.namprd16.prod.outlook.com>
x-forefront-prvs: 0962D394D2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(39860400002)(366004)(199004)(13464003)(189003)(51444003)(32952001)(8676002)(66574012)(81156014)(106356001)(30864003)(102836004)(93886005)(966005)(53946003)(4326008)(2501003)(81166006)(53546011)(6506007)(33656002)(53936002)(5024004)(2906002)(256004)(5660300002)(14444005)(105586002)(7736002)(6116002)(74316002)(186003)(305945005)(52536013)(68736007)(229853002)(3846002)(8936002)(6306002)(11346002)(446003)(486006)(316002)(86362001)(476003)(71200400001)(71190400001)(99286004)(55016002)(72206003)(478600001)(9686003)(14454004)(25786009)(76176011)(7696005)(54906003)(110136005)(97736004)(2171002)(80792005)(26005)(6246003)(66066001)(6436002)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2869; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: BjK4aI64UHnUIgD168v+YegkEyvy+84I8H7Lr96G33/ttnHkH7JwKcJyj5qbWBsJcWiCmnTeVHkkqBhG90OYbHjZbbKPSM4OUuHBK9jKPzLQ7DGm4QOGXpyrxx+We0XkL+iL+nWbGuyn382vxyyxN2NCVGj3NqKu2ynvcS9rN+t54TSL28ot7pPo85I3mXyhmkluAJeZLEwl73lnee8fikk3uvOFS479PeAEhHBVC8s2YeIqlh977J6WfS3AWNINkyMigNrYQCa9aotj9tAF36xGWGmc+W8cMk9thYeJ6lll/TjUmDRILpZXBkKBNtcs1Y2woftBwneWFKWLSQGz0VzPg4PFJP+7VaoCyrz1pgHflfD9X27lUBiDjlSZ/SxvJEOUOXruTWd5CWnXdGGbUeG16G/ydUrTcR3ghDsjEho=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e05268a-6b8a-43e6-8a2a-08d69d6a7601
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 10:49:49.0189 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2869
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6492> : inlines <7025> : streams <1814339> : uri <2803632>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/FSIrwgGe2MVu0ZsItXH1SmPAmWM>
Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots-signal-channel)
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: Thu, 28 Feb 2019 10:51:09 -0000
> -----Original Message----- > From: Dots <dots-bounces@ietf.org> On Behalf Of > mohamed.boucadair@orange.com > Sent: Thursday, February 28, 2019 1:48 PM > To: Benjamin Kaduk <kaduk@mit.edu> > Cc: draft-ietf-dots-signal-channel@ietf.org; Konda, Tirumaleswar Reddy > <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org > Subject: Re: [Dots] Using Early Data in DOTS (RE: AD review of draft-ietf-dots- > signal-channel) > > 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 Ben, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] Envoyé : mercredi 27 > > février 2019 16:58 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda, > > Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf.org; > > dots@ietf.org > > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of > > draft-ietf- > > dots-signal-channel) > > > > On Tue, Feb 19, 2019 at 07:59:29AM +0000, > mohamed.boucadair@orange.com wrote: > > > Hi Ben, > > > > > > Please see inline. > > > > Okay. BTW, it is looking like this is the last topic to resolve > > before starting IETF LC. It's probably worth s/the exponent is 2/the > > base of the exponent is 2/ in the next rev, though, just as a minor nit-fix. > > > > [Med] Fixed. > > > > > > > > -----Message d'origine----- > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] Envoyé : lundi 18 > > > > février 2019 17:23 À : BOUCADAIR Mohamed TGI/OLN Cc : Konda, > > > > Tirumaleswar Reddy; draft-ietf-dots-signal-channel@ietf..org; > > > > dots@ietf.org > > > > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of > > > > draft-ietf- > > > > dots-signal-channel) > > > > > > > > On Fri, Feb 15, 2019 at 03:36:05PM +0000, > > > > mohamed.boucadair@orange.com > > wrote: > > > > > Re-, > > > > > > > > > > Looking forward to discuss this further. > > > > > > > > > > I wonder whether you can consider putting the document in the > > > > > IETF LC > > for > > > > now. If it happen that we need to modify the 0-RTT text, we will > > > > handle > > it as > > > > other IETF LC comments. > > > > > > > > I would normally be pretty amenable to starting IETF LC and > > > > continuing discussion; it's just for this issue in particular that > > > > I seem to be the main person on the IESG that enforces the > > > > "application profile for 0-RTT data" requirement, so it would feel > > > > rather odd to go forward in this > > case. > > > > > > [Med] Fair enough. > > > > > > > Luckily, I spent some time this weekend reading RFC 7252 and have > > > > some substantive comments. > > > > > > > > The key oberservation here seems to be that the Message ID is > > > > scoped per endpoint, and replays can come from arbitrary addresses. > > > > > > > > Specifically, we recall that: > > > > > > > > The DOTS signal channel is layered on existing standards (Figure 3). > > > > > > > > +---------------------+ > > > > | DOTS Signal Channel | > > > > +---------------------+ > > > > | CoAP | > > > > +----------+----------+ > > > > | TLS | DTLS | > > > > +----------+----------+ > > > > | TCP | UDP | > > > > +----------+----------+ > > > > | IP | > > > > +---------------------+ > > > > > > > > We note that CoAP is using the IP address or "DTLS session" > > > > (arguably a poorly chosen term) to identify a CoAP association and > > > > that Message IDs > > are > > > > only used within the scope of such an association, it seems pretty > > > > clear that an attacker able to replay TLS 1.3 0-RTT data will > > > > slice off the top three lines of this figure and swap out the > > > > TCP/UDP/IP layers. In the absence of DTLS connection IDs, my > > > > understanding is that the "DTLS > > session" > > > > is identified solely by the transport connection, just as for > > > > coap-not-s, so by spoofing the source address, the attacker causes > > > > the replayed 0-RTT data (and thus, CoAP request) to be interpreted > > > > as a new incoming coaps connection. > > > > > > > > Given that Message ID is only 16 bits and the servers accepting > > > > 0-RTT > > data > > > > have potential to be quite busy, it does not seem workable to > > > > attempt to use the incoming Message IDs as globally unique replay > > > > defense, as the > > risk > > > > of collision would be pretty large. > > > > > > [Med] The replay detection relies on both Message ID and Token. > > > > In stock CoAP, the Message ID and Token are used only with the context > > of a specific transport association. > > [Med] Hmm...RFC7252 defines an endpoint as follows: > > The specific definition of an endpoint depends on the transport being > used for CoAP. For the transports defined in this specification, the > endpoint is identified depending on the security mode used (see > Section 9): With no security, the endpoint is solely identified by an > IP address and a UDP port number. With other security modes, the > endpoint is identified as defined by the security mode. > > DOTS adheres to that definition: it assumes that an endpoint is not identified by > its transport coordinates but with its identity. > > Furthermore, the correlation between sessions is clearly mentioned in the text: > > The DOTS server couples the DOTS signal channel sessions using the > DOTS client identity and optionally the 'cdid' parameter value, and > the DOTS server uses 'mid' and 'cuid' Uri-Path parameter values to > detect duplicate mitigation requests. > > > In order to use them for (D)TLS 1.3 replay > > defense, we need to expand that context to a broader scope, and direct > > the server to check the Message ID/Token globally (or at least within > > the scope of a given 'cuid'/'cdid'). Since this would reflect a > > divergence from normal CoAP, if we are going to rely on this sort of > > behavior, we must call it out very loudly as specific to DOTS. > > > > [Med] We can make this change if it helps: > > OLD: > The DOTS server(s) can use Message ID and > Token in the DOTS signal channel message to detect replay of early > data, and accept 0-RTT data at most once. > > NEW: > The DOTS server(s) can use Message ID and > Token in the DOTS signal channel message to detect replay of early > data, and accept 0-RTT data at most once from the same DOTS client. > DOTS servers do not rely on transport coordinates to > identify its peers. As a reminder, DOTS servers couples the DOTS signal > channel sessions > using the DOTS client identity and optionally the 'cdid' parameter value. I propose to update the text as follows: The DOTS server(s) can use the Message ID and Token in the DOTS signal channel message to detect replay of early data, and accept 0-RTT data at most once from the same DOTS client. This anti-replay defense requires sharing the Message ID and Token in the 0-RTT data between DOTS servers in the DOTS server domain. DOTS servers do not rely on transport coordinates to identify its peers. As a reminder, DOTS servers couples the DOTS signal channel sessions using the DOTS client identity and optionally the 'cdid' parameter value. -Tiru > > > > > > > > > So I think that the 'mid' monotonicity and the rejection of > > > > conflicting request scopes are the main mitigating factors against > > > > replay in the current design (alongside the RFC 8446 mechanisms, > > > > of course), and the > > text > > > > should be adjusted to reflect that. > > > > > > [Med] We do already have the following in the draft: > > > > > > The DOTS server(s) can use Message ID and > > > Token in the DOTS signal channel message to detect replay of early > > > data, and accept 0-RTT data at most once. Furthermore, 'mid' > > > ^^^^^^^^^^^^^^^^^^ > > > value is monotonically increased by the DOTS client for each > > > mitigation request, attackers replaying mitigation requests with > > > lower numeric 'mid' values and overlapping scopes with mitigation > > > requests having higher numeric 'mid' values will be rejected > > > systematically by the DOTS server. > > > > Sorry for being unclear in my comment. I was intending to emphasize > > that 'mid' and scope are the *only* measures that actually mitigate > > against 0-RTT replay, and that we are wrong to have text that > > indicates anything else is an effective anti-replay mechanism, at > > least given the present design. So I was trying to ask for the text > > about Message ID and Token to be removed. (Our subsequent discussion > > indicates that it would maybe also work to expand on it instead of > > remove it, noting that DOTS is requiring additional behavior not > > mandated by the CoAP spec.) > > > > > > > > > > It seems that the 'mid' ordering is probably enough to protect > > > > reordering/replay of mitigiation request and withdraw, even when > > reordered > > > > across other mitigation actions. But I am more concerned about > > > > reordering/replay of other messages, like efficacy updates and > > > > session configuration changes. > > > > > > [Med] For the configuration changes, I don't expect the exchange to > > > happen > > during an attack. The part of the text we are discussing is about > > mitigation requests. > > > > > > o 0-RTT mode in which the DOTS client can authenticate itself and > > > send DOTS mitigation request messages in the first message, thus > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > reducing handshake latency. > > > > If we don't expect to do anything other than mitigation requests in > > 0-RTT, then why don't we just limit the messages allowed in 0-RTT data > > to be such mitigation request messages (and explicitly exclude session > configuration)? > > I am not going to insist on it, but that does seem like the simplest > > way to resolve the question, at least from over here. > > > > > Putting that aside, we do have the following: > > > > > > The PUT request with a higher numeric 'sid' value overrides the DOTS > > > signal channel session configuration data installed by a PUT request > > > with a lower numeric 'sid' value. To avoid maintaining a long list > > > of 'sid' requests from a DOTS client, the lower numeric 'sid' MUST be > > > automatically deleted and no longer available at the DOTS server. > > > > > > Any replayed configuration change request will be discarded owing to > > > the > > 'sid' checks. > > > > That does help, yes. > > [Med] OK. > > (I'm not sure whether I had confused myself that the > > sid was for the abstract "DOTS session" that is roughly akin to the > > DTLS association, or this was added in response to some of my earlier > > comments and I failed to internalize it properly. It shows up as new > > in the diff from -25 to -29 that I'm looking at in preparation for > > starting IETF LC.) > > > > > > > > > > Consider > > > > > > > > client attacker server > > > > | > > > > |----efficacy: attack mitigated--------------------->| > > > > | | > > > > |----efficacy: under attack------------------------->| > > > > | | > > > > | |-replay: attack mitigated->| > > > > > > > > Is the server going to end up with the expected state? > > > > > > [Med] A general comment: The dots server uses the information > > > conveyed in > > the efficacy update as a hint; it may but it is not required to rely > > on those requests to adjust its mitigation actions. > > > > > > If the two first status messages are bound to distinct "mids" and > > > adjusted > > scopes, the replayed request will be discarded by the server thanks to > > the presence of If-Match option. The server does not maintain the > > request with the old mid. > > > > > > If, for some reason, the same mid is used and this flow is observed, > > > the > > server will detect that the same Message ID and Token are reused again > > and then reject. > > > > Not if the replay comes from a different transport endpoint! (But > > let's keep this topic at the discussion above, as it's the same > > topic.) > > > > -Ben > > > > > > > > > > -Ben > > > > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Benjamin Kaduk [mailto:kaduk@mit.edu] Envoyé : vendredi > > > > > > 15 février 2019 16:05 À : BOUCADAIR Mohamed TGI/OLN Cc : > > > > > > Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > > channel@ietf.org; > > > > > > dots@ietf.org > > > > > > Objet : Re: Using Early Data in DOTS (RE: [Dots] AD review of > > > > > > draft- > > ietf- > > > > > > dots-signal-channel) > > > > > > > > > > > > Hi Med, > > > > > > > > > > > > Short form: I need to think about it harder. There's some > > > > > > indication > > > > that > > > > > > the CoAp Message ID is at the wrong level to protect the 0-RTT > > > > > > data, > > but > > > > > > I'm not sure yet. > > > > > > > > > > > > Sorry for the delays; this has been a frenetic couple weeks :( > > > > > > > > > > > > -Ben > > > > > > > > > > > > On Fri, Feb 15, 2019 at 03:01:29PM +0000, > > mohamed.boucadair@orange.com > > > > wrote: > > > > > > > Hi Ben, > > > > > > > > > > > > > > What is the status for this one? Are we OK to move forward? > > > > > > > > > > > > > > Thank you. > > > > > > > > > > > > > > Cheers, > > > > > > > Med > > > > > > > > > > > > > > > -----Message d'origine----- De : > > > > > > > > mohamed.boucadair@orange.com > > > > [mailto:mohamed.boucadair@orange.com] > > > > > > > > Envoyé : mardi 29 janvier 2019 14:32 À : Benjamin Kaduk Cc > > > > > > > > : Konda, Tirumaleswar Reddy; draft-ietf-dots-signal- > > > > channel@ietf.org; > > > > > > > > dots@ietf.org > > > > > > > > Objet : Using Early Data in DOTS (RE: [Dots] AD review of > > > > > > > > draft- > > ietf- > > > > > > dots- > > > > > > > > signal-channel) > > > > > > > > > > > > > > > > Hi Ben, all, > > > > > > > > > > > > > > > > We edited a short draft > > > > > > > > (https://tools.ietf.org/html/draft- > > boucadair- > > > > > > dots- > > > > > > > > earlydata-00) to motivate the following text included in > > > > > > > > the > > signal > > > > > > channel > > > > > > > > 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. > > > > > > > > The DOTS signal channel messages sent as early data > > > > > > > > by the > > DOTS > > > > > > > > client are idempotent requests. As a reminder, Message ID > > > > > > > > (Section 3 of [RFC7252]) is changed each time a new > > > > > > > > CoAP > > > > request > > > > > > > > is sent, and the Token (Section 5.3.1 of [RFC7252]) > > > > > > > > is > > > > randomized > > > > > > > > in each CoAP request. The DOTS server(s) can use > > > > > > > > Message > > ID > > > > and > > > > > > > > Token in the DOTS signal channel message to detect > > > > > > > > replay > > of > > > > early > > > > > > > > data, and accept 0-RTT data at most once. > > > > > > > > Furthermore, > > 'mid' > > > > > > > > value is monotonically increased by the DOTS client > > > > > > > > for > > each > > > > > > > > mitigation request, attackers replaying mitigation > > > > > > > > requests > > > > with > > > > > > > > lower numeric 'mid' values and overlapping scopes > > > > > > > > with > > > > mitigation > > > > > > > > requests having higher numeric 'mid' values will be > > rejected > > > > > > > > systematically by the DOTS server. > > > > > > > > > > > > > > > > Owing to the aforementioned protections, especially > > > > > > > > those > > > > afforded > > > > > > > > by CoAP deduplication (Section 4.5 of [RFC7252]) and > > > > > > > > RFC > > 8446 > > > > > > > > anti-replay mechanisms, all DOTS signal channel > > > > > > > > requests > > are > > > > safe > > > > > > > > to transmit in TLS 1.3 as early data. Refer to > > > > > > > > [I-D.boucadair-dots-earlydata] for more details. > > > > > > > > > > > > > > > > This text and also the Designated Expert guidelines are > > implemented > > > > in - > > > > > > 28. > > > > > > > > These are the two pending issues from your AD review. > > > > > > > > > > > > > > > > Other edits were also made to record what was agreed on the list. > > > > > > > > > > > > > > > > We hope this version is now ready to move forward. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > Med > > > > > > > > > > > > > > > > > > > > > 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 > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots
- [Dots] Using Early Data in DOTS (RE: AD review of… mohamed.boucadair
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… mohamed.boucadair
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… Benjamin Kaduk
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… mohamed.boucadair
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… Konda, Tirumaleswar Reddy
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… Benjamin Kaduk
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… Konda, Tirumaleswar Reddy
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… mohamed.boucadair
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… mohamed.boucadair
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… Benjamin Kaduk
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… mohamed.boucadair
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… Konda, Tirumaleswar Reddy
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… Konda, Tirumaleswar Reddy
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… mohamed.boucadair
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… Konda, Tirumaleswar Reddy
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… Benjamin Kaduk
- Re: [Dots] Using Early Data in DOTS (RE: AD revie… mohamed.boucadair