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:32 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 C3DB1130E6E; Thu, 28 Feb 2019 02:32:32 -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 ZxJakCo1dNRd; Thu, 28 Feb 2019 02:32:29 -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 19FDA128B36; Thu, 28 Feb 2019 02:32:28 -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=1551349787; 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=p FVIi3qmRwHCpdan2cDiiXgX/obsaSUn0i/sQcmhY6 A=; b=XF7isXWb4iFk0roq6zC5N/9F/BaZo6iqI1gaxVzOrLbN 0yca3lWgRIlA27ak12T4tPuExGgvFxCpYsk6K76WUZEEyU5XA7 feXnlukWWCFl5pJwtPbkP3XqwdT9zze/iYv0el1PVa460e5Kcv etpq7o38GVPkNhZ2fiwDK5Sp2Oo=
Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 21ae_f807_ebaa70e7_f0b2_4909_9076_c19674750f64; Thu, 28 Feb 2019 03:29:47 -0700
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 03:31:53 -0700
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 28 Feb 2019 03:31:53 -0700
Received: from NAM01-BN3-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:31:52 -0700
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2903.namprd16.prod.outlook.com (20.178.235.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.15; Thu, 28 Feb 2019 10:31:51 +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:31:51 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
CC: "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Using Early Data in DOTS (RE: [Dots] AD review of draft-ietf-dots-signal-channel)
Thread-Index: AQHUx6Zad4wSPXSxIUiJUgMrwAb+nKXmwseAgA0YNQCAAAXmIA==
Date: Thu, 28 Feb 2019 10:31:50 +0000
Message-ID: <BYAPR16MB279082F0A79905D8CF9A79EFEA750@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>
In-Reply-To: <20190227155729.GL53396@kduck.mit.edu>
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: 6b899997-f09d-4e72-5259-08d69d67f388
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2903;
x-ms-traffictypediagnostic: BYAPR16MB2903:
x-ms-exchange-purlcount: 2
x-microsoft-exchange-diagnostics: 1;BYAPR16MB2903;23:C6+590RcCDDixpeyvQ5rUPcCfBnFOyYutCr/u+eXPkvo0ycHa7ejBWN+0u6MMRQxfK7gs1dU9UiIWupml9DXIVEgg+lGvMDkyp6wlhSoqC78WVwJuSIdN66qAzkpO52cRNmkJ0CXgZ+tC1SxkEhJdczdFRZYFNSv4oFW/YgKDjDYf1EAlBiiZ2LQIWMdrrjTubHPEf+S4RJCKCNix7juyk+iHqKxDziyzRLlXu2XZfCpaB/no1mtF6J01xHjqTIKNDY//N3/coebegWM94ZkI9CSsHBXNuYh2wV1CExMVGIJj3BO6TMl+MplWJU0mvyOetFz3Hj/R7POi1B6g55pyQr2s7TtIP5DEBgQYjhRr6c8tSsdbC+wFphaCCSf3qJ6VlbpLaWcLTR6qRA/wLrdxS03ZtbdldDKAq5r7t93Q+dH6Wxg/4YEyB+tZ5IDV7NTqdJx6NgTKa6yE4euvrv/Ipx24GTMnLHanfJ5hKXOvf7EH2lsq20UzGllSl7T4Ji+60usGtNWURcdOhl9syQHQsufKZWU1jvoaRuoIplxtOVLeU7SbL5AapNRIqHodiPRfDEVCFH6jXfYGAX/FxQ+TrWyk6GBpYdBrOkmSbAW9MwTtHUcosxD8LdBPA+8E/gAb2jQil7r+2+zXbem2tsJG9v0eBXg/g+xUST8pC5v+TtMQPUx8T2Ls+ufXEiVs1KxMIZ8zZfzOiCgIWVrsJJsDOhgKKA/H8IvzneC4m01JB/ln3sGjxSyN4MVxZG1tRwcqzmAw9ZGAXwIdJqRKWbMCiY9ncblO4uPDN2EbXRqWyndDSOsrNsAYI1bHyJNJwBmef2RuPBGWuQESkAEpvS6fkrINrELo/KHNJTEeYHhV5I7DFNhnq2Bnyjcrhr6bLdBOW2nCcldjbFn3Cl8pxRS/XdrzdmrqYD/2LSKpOcd4YLLzqrnr5jO/zB2UBCVF0Kd/6ha1qJVXgrtG4s+m3Fy/gXSDnKJGbWWia8L+wRYczLdtbWsk8C7rkJDboXIk8Udg/AS8xSBNkYgOC2F4Mjs2XHY+QVbDcoaMYIpRr9b4x7unWq6QN1ty0wl+LNqiGgd9VNzfcF53LNz9iGW642R7aZZIv+90GBPNbarbkmSJOaiOivH+VSpN44rFRLAlhm5cFimG1y3e15o4YNySQ3tI3l65YX7b8Ald+wbcSxanYh3Gre8GZHFJSYlcLmjacQ4LuJ+GgBuxkZEtxDbtqV3GmeoHLyEPGnALq+e7iI5tZCnh18UllqVortHHEqQaQFCoFVgfLeT2DPolBPTw9CarFm/5TnPVAjKUPLE8XJEc9aCYjxFe6VXzJxh/wb3l8K+ZTPOtRUR6qIseFbhCX8hqmiQfFvEanmIoC1DrLDmLCBk8dfvADsvezLR+joSRnJyqMcqzbxma88NfDpjMPnnqaK8AplkZh6AmuNKxyBpjjT0g5zt1jrlMZ/raA6DzEvnBpH0iCpQDEpVIYoaZfFOVZg4YV7jBOBzmAV5g6pGudwOwY+7jHwsOfI/smy6bhhhjjE+bmL2bXvcblkhM7ZXvX1rw9vzss3rmyhMLn/YyfM=
x-microsoft-antispam-prvs: <BYAPR16MB290313C2B42C0FCC1CB96874EA750@BYAPR16MB2903.namprd16.prod.outlook.com>
x-forefront-prvs: 0962D394D2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(346002)(376002)(39850400004)(51444003)(199004)(189003)(13464003)(32952001)(81156014)(81166006)(9686003)(6306002)(5660300002)(6436002)(102836004)(53546011)(6506007)(55016002)(72206003)(105586002)(8676002)(99286004)(66574012)(229853002)(7696005)(25786009)(6246003)(2171002)(4326008)(561944003)(7736002)(97736004)(33656002)(53946003)(53936002)(74316002)(76176011)(305945005)(26005)(966005)(80792005)(14454004)(2906002)(71190400001)(478600001)(71200400001)(93886005)(30864003)(68736007)(476003)(8936002)(66066001)(106356001)(54906003)(110136005)(3846002)(6116002)(316002)(86362001)(2501003)(14444005)(256004)(186003)(486006)(11346002)(52536013)(446003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2903; 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: mleEAolyRhjidiHbJv76O/m2NaKEzbn4TiXz4JyHT80eeejW2DtMGxVUtLFoC1kqtucCbiCPK8yfnnI3ww8ahU083AMqgaMVTQv+xJ1dQMgi03w+aInC+qo9NF2s3p5xreWUGoDJK6AFHjGMZ9pH2FUqVeQ1lfbtIu2CM50v9u8lWN1V3vqhraJ4WjcCdBHVpvKyJtPzvX1/g2wvp3ugC0UvvFYYJEpS2QlHB3TBvm2mGfQNWptJU/Ac+BMKmGswJ2tkwApwYVCMecbbmLEC5YLfdUdK4tY0UtTv9YnwXjLKTku7ngMxK+XlIzNW7wIpb8EdAD7MCYr4DarBjKRg5CdXIoHa12AHwt4ElTZZAVcznQmOmnotkx6mzk6aB8acUHXmITDAAPk30LJDsan6k/lITslbbxozuijL0BeRQBI=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6b899997-f09d-4e72-5259-08d69d67f388
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2019 10:31:51.1352 (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: BYAPR16MB2903
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 <1814337> : uri <2803626>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/wwjxRjldAbzjRc-SEfxnUEFJMbg>
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:32:33 -0000
> -----Original Message----- > From: Benjamin Kaduk <kaduk@mit.edu> > Sent: Wednesday, February 27, 2019 9:28 PM > To: mohamed.boucadair@orange.com > Cc: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; > draft-ietf-dots-signal-channel@ietf.org; dots@ietf.org > Subject: 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. > > > > > > -----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. 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. Agreed. > > > > > > > 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. I like the proposal, avoids the need to share Message ID and Token sent in 0-RTT data among all the DOTS servers in the domain. If the client uses a new 'mid' value (or a new mitigation request) every time a mitigation request is sent as 0-RTT data, sharing the 'mid' value sent in the 0-RTT data among the DOTS servers in the domain is sufficient to detect replay attacks. DOTS servers anyway have to co-ordinate and sync the mitigation requests, aliases and filtering rules. Cheers, -Tiru > > > 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. (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] 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