Re: [secdir] [core] Secdir last call review of draft-ietf-core-too-many-reqs-04
Daniel Migault <daniel.migault@ericsson.com> Mon, 22 October 2018 07:01 UTC
Return-Path: <daniel.migault@ericsson.com>
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 E3576130DFB for <secdir@ietfa.amsl.com>; Mon, 22 Oct 2018 00:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.364
X-Spam-Level:
X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=RvgNX4AY; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=dhW7spK6
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 YweC_rhemL_d for <secdir@ietfa.amsl.com>; Mon, 22 Oct 2018 00:01:57 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 93DF2130E05 for <secdir@ietf.org>; Mon, 22 Oct 2018 00:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540191710; x=1542783710; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=p0PKHW/YlznyH3DFz2ckM+9eAnVJ0j4iuRzKskw4ajQ=; b=RvgNX4AYupzsPLyevZM30wIqYDEnsIVtyzxN/f8IRTCAfEMrHxaukpYi4PQJJEVx F/8bjOBbrl3M81OivvuCjmZQ81vmMGHHEGsULWbATK4Q9xW4ERwkVeaqQba/le4r GX+xfnc96wuwfnYtfHJQL2lZ3gxMguLLSmcwm8p7TR8=;
X-AuditID: c1b4fb30-2bbff700000047d2-3e-5bcd75de3644
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DA.5F.18386.ED57DCB5; Mon, 22 Oct 2018 09:01:50 +0200 (CEST)
Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESBMB503.ericsson.se (153.88.183.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 22 Oct 2018 09:01:49 +0200
Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 22 Oct 2018 09:01:49 +0200
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 22 Oct 2018 09:01:49 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FgdLw3gnFRIEFt3Is/KSi5Dxg1AuHykrEzNVEz2Yp5k=; b=dhW7spK6BCXSzr6aLGXFAsysmZ30laQ+/tQwOZL2AiXjgSJ91EKcfDuUjInKx2dVwIfP3lpM5YyX+3JfXTJlX7T22pRAFBcVSPz6KiweSRiX0IjEkRFUJfMTy0ufh3LMagQTmt1USCR7zRKMG7vPu3lvoZE5VPFoiJ8nVixcgMU=
Received: from DM3PR15MB1002.namprd15.prod.outlook.com (10.166.160.10) by DM3PR15MB0650.namprd15.prod.outlook.com (10.164.33.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.29; Mon, 22 Oct 2018 07:01:46 +0000
Received: from DM3PR15MB1002.namprd15.prod.outlook.com ([fe80::2501:1ff1:91d0:8b6e]) by DM3PR15MB1002.namprd15.prod.outlook.com ([fe80::2501:1ff1:91d0:8b6e%4]) with mapi id 15.20.1250.028; Mon, 22 Oct 2018 07:01:42 +0000
From: Daniel Migault <daniel.migault@ericsson.com>
To: Ari Keränen <ari.keranen@ericsson.com>, "core@ietf.org" <core@ietf.org>
CC: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-core-too-many-reqs.all@ietf.org" <draft-ietf-core-too-many-reqs.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Jim Schaad <ietf@augustcellars.com>
Thread-Topic: [core] Secdir last call review of draft-ietf-core-too-many-reqs-04
Thread-Index: AQHUXydxRR2UxETJ3ES1rGo1Lxy5eaUqFC0AgADWWyA=
Date: Mon, 22 Oct 2018 07:01:42 +0000
Message-ID: <DM3PR15MB1002D5ADF7C18CD21B34627AE3F40@DM3PR15MB1002.namprd15.prod.outlook.com>
References: <153895864367.4396.18138201518799857673@ietfa.amsl.com> <061801d45f27$602ef380$208cda80$@augustcellars.com> <031D5D2F-69BA-4315-BC89-1F40363EF586@ericsson.com>
In-Reply-To: <031D5D2F-69BA-4315-BC89-1F40363EF586@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com;
x-originating-ip: [199.91.196.135]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM3PR15MB0650; 6:/7gVOFmtTjAVTRF4D95K7SaGPpXlsROuiF4plyQk+Yavb9wLpVEadyaoVwYMNLs9X/WRyCd5qZkeZO+z3GhWdztM0AN/X4i4hVkOTK4Y+R4kyozYaTR6CgTiXngfyFKD1KXxsVEqCZzBNA5xoQWsemBgzkBAXbFNzUu2wBq/VN8E+/Fc5CGIApvRhkd9uluuDUgDSCOOnAwYmnlMgkNKswp/EBh0ozB6wDTYjT0Ip2/O0iaaht55PonWbNtlZqFO9Qi2hd7XSpruY3uxz7SgyZNRZ3WtnXs6ed7xvhOsPVtXrqJkiY2OhbTgwijF9UO2RI2kmsYE6A/6tkDmlsriVHQ4GotOLS6+R+SZptDjvKTKYrjvl4NXT2T+Kl5yhiN1vr0F7VofLhuN4wnPMEzYAZaJAC4CjrRByGveEJnaJqjECvfdtRlqM8s78PaX0BZg7pTx0lVzSlqEEfAoCsbpRA==; 5:vR78pSSSK088LZMGUp5FXyeGM606CWInRSv3gpHDid8093CD+5qcD2WVLGI/aRG+nI87MkkBCR2dZ13+PxhMSbtVCiEE/TjOdUnJtTPKkJFlzx6uGdkwpYZjCr1GJkJq/t++DPgMycIxNh04+uInYdkyX40CtKV6XhvJXS7w6Sg=; 7:eSD6wEpttHHLKi6nDkbz0LA0WL/3lMedC0m6/pwkrmPIgUMUOi6KDQa1ff2qG/Ta15Yd8894wCRo2FNaAIBnm8M/H5mAowLQUCsSstdnXsv9QFU/ZgyNYNWml6lOZHTrZjua6+QBFRM1mQoEjokFN8WB2XJuxCXFx7LTAv5Wmeq8XFD1pMMZcuubYpO8WyaxepoBGlPqmsg6Bp5zhbqKqZzozGBpRHRqxTW0PwEb0154dP86dZ0ul70YswPvJnFU
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(346002)(39850400004)(376002)(189003)(199004)(13464003)(99286004)(54906003)(110136005)(606006)(14454004)(966005)(478600001)(76176011)(7696005)(25786009)(2906002)(4326008)(790700001)(3846002)(6116002)(561944003)(7736002)(186003)(66574009)(446003)(486006)(44832011)(86362001)(476003)(33656002)(26005)(74316002)(2501003)(97736004)(5250100002)(2900100001)(66066001)(81166006)(256004)(8936002)(11346002)(99936001)(81156014)(106356001)(8676002)(105586002)(14444005)(229853002)(5660300001)(68736007)(53546011)(6506007)(54896002)(6306002)(6436002)(102836004)(55016002)(316002)(71200400001)(236005)(71190400001)(9686003)(345774005)(6246003)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM3PR15MB0650; H:DM3PR15MB1002.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-office365-filtering-correlation-id: 7ca5d903-d96d-4344-7db0-08d637ec38fe
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:DM3PR15MB0650;
x-ms-traffictypediagnostic: DM3PR15MB0650:
x-microsoft-antispam-prvs: <DM3PR15MB0650D9ED908A809F4BD2DB91E3F40@DM3PR15MB0650.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(248295561703944)(37575265505322)(166708455590820)(192374486261705)(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(4983020)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DM3PR15MB0650; BCL:0; PCL:0; RULEID:; SRVR:DM3PR15MB0650;
x-forefront-prvs: 08331F819E
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: SnNLBXTLhfArkAYkAcM3kSojQBH4dODSef+4Wqs02ot4q+luq5RrVA4QRFIeEda55NWftKMps3C3zW1SFuIliO9ElyC5oPvDNjkkv2/Ngg1pwVf3a/FsSXMrPWobZr2sbKIotlz/VNDhaL/67mrUCstAe/C/cNjGsNf+hyyA0TAbtCWi1yhfhM7XOAQMlmux8xpaANRAwsa3/p7HPWUqCY3MyUIhIcfr9NQTGBJ/6ymlqXh0UJ8nTdrWsATYL/0QBM4i7J6P+stU6z+pcSr06zVQv18DkXnZSXZk/jfrNLksvUQpE/zVMiwbaEfb5OjoEFD5WTeKJ48UQuLMEvcJsb40zVJ3jwHBShqMlfi3BAw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0019_01D469B3.8CECAB10"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ca5d903-d96d-4344-7db0-08d637ec38fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2018 07:01:42.5640 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR15MB0650
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSW0iTYRjHe7+Tn6vR25r5sChq1YVZ5qRoiJ3ACw0KC4JQsWZ95HGTba7j hVpKZJGVZK50mVZODTNjtoucrbRcTtJOOMxyljXMUqnZKKzt+xbU3e/5P//n9PKypMRLy9hM tZ7TqlU5ckZEVe5u068eynemRFf3SpXt482kssxUQysbK6YZ5WiLiVJO1AxTm+mElisVTEJd nY9IIpJFcfu5nEwDp12zca8ow/fqIplnqycOdb+YIAuQuZQ4hUJZwGvB97qYOYVErAR3Ihg0 zSAh8CKwjNrogIsP6rp2CYk6Aqyj96hAQOEyEqY+3yeEzHkCGicaSCFwI3hSXh8SqGdwDJTY z/IsxWnQcbWSN5G4F8F49bQ/wbLz8Q5wvcsSPDuhqNfDy1IcC7+HFQGZwivgue8yv7gYp0Jp yy9KmNWM4KG3mO8fijdDf5WTDDDCC2Da0cQXkDgcXO9NwaulMNz3lBE4DDwjM7TgTwPv5GlS 0OXw6csAEngR9JtKg9we4i+OFFgBj802/hbAbgbsN7/RgaUBb4Pi2ghB70Mw5rgUHLYSnCcK g55ssB6PL0MK4z/rGflnOYfg8vdBxsgfOg+6K99TgikFOizFIQJHwoeBD9RfvlEzRhr9bUn/ iFpj4v9ygDfAJ8fbYOlSKC8dDvI6GOucRFfR7AYUpuN06bkHYmKiOG3mPp1Oo45Sc/o7yP8D H9z9GX0PeT5usSPMIvkc8QjnTJHQKoPucK4dLff3cd9ufIZklFqj5uRScWK4Py3erzp8hNNq 9mjzczidHS1kKXm4WLm9NVmCD6j0XDbH5XHav1mCDZUVoKz4DFHPtmV6VWxmV9TPQ0Tr/er8 qq0y85BZM5665ai25PuiVbZNCUWmrmzXqinLifz0ptRjcet3mYvqr7UWNsw9n9X25qQh/pH7 hybiVljPy6POWdZN1uSTTPqFG51tSyzuhsSaisXHacMTeVKSwzoSH37H03HmYNWU2zPw9bqr XE7pMlSKlaRWp/oDrMLQeYkDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/hM1vghA-Twx1C3r4cq57KN8KFA8>
Subject: Re: [secdir] [core] Secdir last call review of draft-ietf-core-too-many-reqs-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 22 Oct 2018 07:02:01 -0000
Hi Ari! I checked the version on github. It addresses my concerns also considering Jim’s feed backs. Yours, Daniel From: Ari Keränen Sent: Sunday, October 21, 2018 2:10 PM To: Daniel Migault <daniel.migault@ericsson.com>; core@ietf.org Cc: secdir@ietf.org; draft-ietf-core-too-many-reqs.all@ietf.org; ietf@ietf.org; Jim Schaad <ietf@augustcellars.com> Subject: Re: [core] Secdir last call review of draft-ietf-core-too-many-reqs-04 Thank you for the review Daniel! I have now addressed your comments in the latest draft version in Github: https://github.com/core-wg/too-many-reqs/pull/4/files * Clarified the text in sections 4 and 5 roughly as proposed * Added a note in section 5 that dropping requests may result in retries * Added a note that responses without encryption can leak information (agree with Jim that it’s not a major risk so didn’t add normative language on this) I’m planning to submit a new version tomorrow before the DL. Cheers, Ari On 8 Oct 2018, at 19.53, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote: -----Original Message----- From: core <core-bounces@ietf.org <mailto:core-bounces@ietf.org> > On Behalf Of Daniel Migault Sent: Sunday, October 7, 2018 5:31 PM To: secdir@ietf.org <mailto:secdir@ietf.org> Cc: draft-ietf-core-too-many-reqs.all@ietf.org <mailto:draft-ietf-core-too-many-reqs.all@ietf.org> ; ietf@ietf.org <mailto:ietf@ietf.org> ; core@ietf.org <mailto:core@ietf.org> Subject: [core] Secdir last call review of draft-ietf-core-too-many-reqs-04 Reviewer: Daniel Migault Review result: Has Nits Hi, Reviewer: Daniel Migault Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is clear and almost ready. Most of my comments concerns the "Security Considerations". Yours, Daniel 4. CoAP Client Behavior A client MUST NOT rely on a server being able to send the 4.29 Response Code in an overload situation because an overloaded server may not be able to reply to all requests at all. <mglt> I believe the sentence may be rephrased. This is just a proposal. OLD may not be able to reply to all requests at all. NEW may not be able to reply (at all) to some requests. . </mglt> 5. Security Considerations Replying to CoAP requests with a Response Code consumes resources from a server. For a server under attack it may be more appropriate to simply drop requests without responding. <mglt> The gain from the response with Too Many Requests Response Code is almost the current response and all *similar* requests from that client during Max Age. I suspect that is likely a gain except when there is no responses from the server and client is not expect to send a request before Max Age. Simply dropping the requests may add the retry traffic, though it depends on the application. That said your text is correct. I am wondering if it would be good to illustrate your purpose. </mglt> If a CoAP reply with the Too Many Requests Response Code is not authenticated and integrity protected, an attacker can attempt to Keranen Expires January 25, 2019 [Page 3] Internet-Draft Too Many Requests Response Code for CoAP July 2018 spoof a reply and make the client wait for an extended period of time before trying again. <mglt> A similar attack may also consists in an attacker triggering multiple request or transactions with a spoofed IP so the server generates the reply to the legitimate IP. This could be used if an attacker cannot directly send the spoofed response to the legitimate client. The response code provides an information about the state (overloaded) of the server which can be used to infer additional information. This could potentially be used by an active attacker among other to confirm an attack is efficient, that a server is receiving multiple packet at a given time which may be used to identify some traffic patterns, identifying a bug a version... For a passive attacker, the response code may among other indicate an appropriated time to trigger a larger attack.... Because the code enable an attacker to gain some kind of control of the client, and reveals some information about the status of the server. I would suggest to mention that Too Many Response Code should not be considered outside unprotected channel. That is a server SHOULD NOT reply with a Too Many Requests Response Code unless the communication is encrypted. A client SHOULD ignore Too Many Response Code unless the communication is encrypted. The response seems to me small enough so reflection attacks may be out of scope. I do not believe that this is aimed to be any type of DOS prevention tool. I would disagree that this is a huge attack window. The client will filter the set of response that it is receiving to match only requests that it has made. Thus a general flood attack would not be useful unless it was targeting the same messages ids (and tokens) as requests from the client under attack. But then these would be seen by the server as duplicate messages and ignored w/o sending out a response. I am not sure that I would consider the fact that the server is currently "loaded" for some measure is a huge leak of information. I don't think I would care if that was leaked. Jim </mglt> _______________________________________________ core mailing list core@ietf.org <mailto:core@ietf.org> https://www.ietf.org/mailman/listinfo/core
- [secdir] Secdir last call review of draft-ietf-co… Daniel Migault
- Re: [secdir] [core] Secdir last call review of dr… Jim Schaad
- Re: [secdir] [core] Secdir last call review of dr… Ari Keränen
- Re: [secdir] [core] Secdir last call review of dr… Daniel Migault