Re: [core] Comments on draft-ietf-core-echo-request-tag-02

Göran Selander <goran.selander@ericsson.com> Fri, 19 October 2018 15:43 UTC

Return-Path: <goran.selander@ericsson.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AE5130EF6 for <core@ietfa.amsl.com>; Fri, 19 Oct 2018 08:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.385
X-Spam-Level:
X-Spam-Status: No, score=-3.385 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, FROM_EXCESS_BASE64=0.979, 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=ericsson.com header.b=Xpw3YBEJ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZMjY4WS4
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 BYGeACv_ubl0 for <core@ietfa.amsl.com>; Fri, 19 Oct 2018 08:43:34 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B29B0130F73 for <core@ietf.org>; Fri, 19 Oct 2018 08:43:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1539963812; x=1542555812; 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=bZ73Mt9rnJhzpJ/0QMZtdB5uXrJpi1exGrub7GnE1xk=; b=Xpw3YBEJ0UKefEfyEG17mAHGNfXwz3n9qaP/9xp5Uw1P8sw9y7cmityxzfbd+TNQ hbEAcfXGLp2n25S9HdkJQYGT8CxYII07CsprLH5pH86YIfZU/T8/jbQMLHgbm2tw fxHPVOItm3Lvfv6e2bwKHLfGD2aYMFKjDIahigAL/B0=;
X-AuditID: c1b4fb2d-b4fff70000003a27-f4-5bc9fba3b30d
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.DA.14887.3ABF9CB5; Fri, 19 Oct 2018 17:43:31 +0200 (CEST)
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 19 Oct 2018 17:43:30 +0200
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) 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; Fri, 19 Oct 2018 17:43:30 +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=bZ73Mt9rnJhzpJ/0QMZtdB5uXrJpi1exGrub7GnE1xk=; b=ZMjY4WS4lPZR0olA63jsGKsZSZ1Dhq9blJ1tb1p+XoOtKR2uRCHaO9yS+rhzyQpeen+L7V5kAZ+NuwrVvjihY/o4l2miinPnQzoWA4GNO54JjB3QYgXhTIWdp1XY/MCV5Hz4j2VA+JnWrPaP6DpHnWtg3EXMwM7qDOKG/6ppsyo=
Received: from AM6PR07MB4822.eurprd07.prod.outlook.com (20.177.190.219) by AM6SPR01MB15.eurprd07.prod.outlook.com (52.134.121.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.10; Fri, 19 Oct 2018 15:43:29 +0000
Received: from AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::1061:1e88:206e:e289]) by AM6PR07MB4822.eurprd07.prod.outlook.com ([fe80::1061:1e88:206e:e289%4]) with mapi id 15.20.1273.012; Fri, 19 Oct 2018 15:43:29 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Jim Schaad <ietf@augustcellars.com>, "core-chairs@ietf.org" <core-chairs@ietf.org>
CC: "draft-ietf-core-echo-request-tag@ietf.org" <draft-ietf-core-echo-request-tag@ietf.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: Comments on draft-ietf-core-echo-request-tag-02
Thread-Index: AdRhDB0VTl1oEFpfS0G4KIUfFU0HbAFGCCUAAEWjJwD///dnAIABOYKA
Date: Fri, 19 Oct 2018 15:43:29 +0000
Message-ID: <049375ED-A806-4969-8403-8DB18317021F@ericsson.com>
References: <00fa01d461b0$2a314f40$7e93edc0$@augustcellars.com> <20181017141813.GA4084@hephaistos.amsuess.com> <E207969D-C945-4E7A-94E7-C3F08EC46882@ericsson.com> <005d01d46736$8025e8d0$8071ba70$@augustcellars.com>
In-Reply-To: <005d01d46736$8025e8d0$8071ba70$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.12.0.181014
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-originating-ip: [83.251.145.234]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM6SPR01MB15; 6:yCrr1cIbjeXWGneOPhX84XqipnwHUfqByay+1+eS8xLQYx62MPps9/Ax4F+8eXhTHtk7pz/ST7a99llIyt0/Ya4r3g2RuS2WpPF3aGVoJ4Dog6AlnZOwGwlPim+x8hAHxgWCouQv8KOhN0y5VOzwd0tSndApAw5ND+UiFcrJqUGXjKFjBl0AKJQNshe7JGTzPaSfqYsy4O1KQl+JQ899NbsdTIlCQajoqa4xg4wVtsRYuN6dD1YqMRgN8j5ButWVf2bmQf0R7EZcHHzTjd+Xc3uo62iV9aivwLOm8Ym+9VpJ8kzffyif4E9mfjB0FfFWo4hbkXOGD63l/oC6VGETK6of1gH3kmvheexcEtILHa6BYaRyyZ+hNyD8FTDbRq1czvjX7RbHR6FZMYTMynW/WGQboiphOCIXBsDjrEeIOKQV3NBk5G3BuB7XR5z1TZhYAdnDZQUCeMQVIMCYy7cP5A==; 5:CpRaK4mK65cXAX1yQIZNd26zFRy7LkCd0XQoq2hezKSPD4aTfpbg92lFeDrmk+shu21FgjcpPhzvRtq4MS0AN2V9DLK5XzP3BCmE2wVMsYYWqhFfuhIip3WH1nd7gg0QLHv16dF0+LCC2QV4D0jRn96B8t9YUAPKEqcdeHEcdUk=; 7:ypQscnxbEyq5Tb3Zy8IwmADPW8HXrCBr3c3zO220Xf0iZ0jPu7h4IV5zWQo6gz3JhCDZ+e32fJN6wiJsdXDZ3YkJXSE6ctS+Rhi3dO0BH660ofJQFItctH5EVMqgMjcXFIPArHpcyJcjKk1aalEIHQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 7bb4df95-28ee-4896-3d15-08d635d99e12
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM6SPR01MB15;
x-ms-traffictypediagnostic: AM6SPR01MB15:
x-microsoft-antispam-prvs: <AM6SPR01MB15BE2D36731521A0BA1297F4F90@AM6SPR01MB15.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231355)(944501410)(52105095)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:AM6SPR01MB15; BCL:0; PCL:0; RULEID:; SRVR:AM6SPR01MB15;
x-forefront-prvs: 0830866D19
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(136003)(396003)(39860400002)(189003)(199004)(478600001)(6116002)(11346002)(66066001)(14454004)(81166006)(54906003)(110136005)(256004)(14444005)(316002)(58126008)(68736007)(229853002)(81156014)(8936002)(99286004)(4326008)(102836004)(6306002)(33656002)(6506007)(6246003)(6436002)(6486002)(5660300001)(966005)(93886005)(25786009)(8676002)(6512007)(76176011)(85182001)(85202003)(36756003)(7736002)(486006)(66574009)(4001150100001)(106356001)(53936002)(82746002)(105586002)(86362001)(83716004)(71200400001)(71190400001)(2501003)(2906002)(5250100002)(2900100001)(186003)(3846002)(446003)(26005)(305945005)(2616005)(97736004)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6SPR01MB15; H:AM6PR07MB4822.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 5BX2BiZJHgMV4hBqiINt7OpimyDnciqsoVsf62SPlKedXaR+wfTSocKMYN9DIl0UP8m+y97ozXkxtTmbhgjjxM6Lm/vzkOM782XmhW8l4hLPtmRZUuc3YdzE1xEjqVjjJeiepl1I+r+F+UqYlgNziQyENMegHsVXa4WOVw+2S4O3HEuUMrIl/K/VwHjhtyePLI+EZ8WPsaiZkk4CG2B1Wp1I7mHzgntfTOjj6jSV7xKugh22S/JznVbiO2oD/3X0D2FLUuWWtXQBVEeh5XfLds4x0ttVXPmpwiuuI5JvMk6IpSUTcAG1Kn6qhV3dwYKp4uYIaG+RS7zNbeUR4XrZGvkd7JmZtr3FxUAlcTFHmIQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1ED0C327706D05408C241CEE12F0B736@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7bb4df95-28ee-4896-3d15-08d635d99e12
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2018 15:43:29.4424 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6SPR01MB15
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUyM2J7ue7i3yejDdqu21hs23iBzWLf2/XM FvdP7GazWD39O5sDi8fGOdPZPJYs+ckUwBTFZZOSmpNZllqkb5fAlTHx1WPmgh7diuOvdjA2 MP7Q7mLk4JAQMJG42OvexcjFISRwlFGiZesqJgjnG6NE/4NvbBDOEiaJ70cWATmcHCwCE5gl 5q5IhEhMZpI4cfkQO4TziFFiwda1rCBVbAIuEg8aHjGB2CICERJNN36xgNjMAnUSH7/0sIPY wgI2EttedEHV2Eo8Wb2TDcJ2k3h76jE7xDZViV0fbzCD3MorYC/x5EQRxK47QLe+fcoGEucU cJBYecIapJxRQEzi+6k1TBCrxCVuPZkPZksICEgs2XOeGcIWlXj5+B/YmaIC+hILTk9nhuiN k2ha18AGUaMksbv1JFS9rMSl+d2MIHslBK6ySfyYcZUVIqEr8WHqVKgiX4l3HZ+gmo8xSjQ9 E4ewNSUO3Z8OVZ8p8fT4QaiDfCS2bL/NOoHReBaSW2cBvcMM1LJ+lz5E2EPiyavFjBC2osSU 7ofsIDavgKDEyZlPWBYwsq5iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECEwvB7f81t3BuPq1 4yFGAQ5GJR7e/m8no4VYE8uKK3MPMUpwMCuJ8CqWAoV4UxIrq1KL8uOLSnNSiw8xSnOwKInz 6q3aEyUkkJ5YkpqdmlqQWgSTZeLglGpgjBC1DExdd/fOf/XIn0fmO7BeNVlXvPBr2vFXtyol PNTZdd4t1rb40/L85M1dB/VkSt9rBSYYafa8X9Wsq3GedeMEbefgeTYcZRNdosI5P8zZsM/z m67y9wmT1s3edj/bZYXAvwy1BY+nd3+6fe3q4jzuBk35c7oM1VHcvJMXKnYGxL5+fTbtnxJL cUaioRZzUXEiAB30IWsrAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/bWpYRQvMwcNcB4py6H2DAyUW33I>
Subject: Re: [core] Comments on draft-ietf-core-echo-request-tag-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Oct 2018 15:43:37 -0000

Hi Jim,

See below.

Please note that the "Editor's copy" does not build to the latest version (perhaps someone with admin rights could look at this __) so look at the .md file instead.
https://github.com/core-wg/echo-request-tag

                                                                                                                                                                                             
On 2018-10-19, 01:02, "Jim Schaad" <ietf@augustcellars.com>; wrote:

    
    >     * Section 2.3 - Item 5 - I am not sure that this is a reasonable answer for
    >     having a proxy sitting there.  I could easily be wrong and should probably
    >     spend some time thinking about how this does/does not work.
    > 
    > GS: This is now item 3. There is no intention to use a proxy here, so I don't
    > understand the question. Please elaborate.
    
  
    Consider the following setup
    
    C1 -----------|
                     Proxy  ----------- Server
    C2 -----------|
    
    C1 sends a request to server via the proxy
    Server responds w/ request w/ echo
    C1 responds w/ request + echo
    C2 sends request to server
    
    Since the server thinks the is just fine - it got a response w/ its echo.  Then the server will think that C2 is also ok so will not do any of the amplification mitigation work of asking for a repeat w/ echo value.


GS: Echo applies for the hop-by-hop setting as well. Reading item 3 of section 2.3 with the proxy in the role of server:

"3. A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks such as described in Section 11.3 of [RFC7252] (where an attacker would put a victim’s address in the source address of a CoAP request). For this purpose, the server MAY ask a client to Echo its request to verify its source address. This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server."

So in this case the server needs to mitigate amplification from the Proxy, and the Proxy, in turn, needs to mitigate amplification attacks from C1 and C2. 
Does that make sense?

    > 
    > ---
    > 
    >     * Section 5 - I have not seen a justification for this anyplace.
    > 
    > GS: Included reference to section 1.3. (Also reference to section 1.1 in section
    > 2, and to section 1.2 in section 3)
    > 
    >     * Section 7 - para 1 - What is the problem w/ using an encrypted wall clock
    >     time for a timestamp?  These text appears to say that this is a bad idea but
    >     the issues seem to be with using unencrypted items not with the wall clock.
    >     The next sentence makes more sense about why not to use one.
    > 
    > GS: With encrypted wall clock we typically need to store or transport the IV, in
    > which case the random value method is not worse in message size and server
    > state.
    
    Yes, but the same issue exist w/ a time since reboot clock.  If you use this value unencrypted you are heavily leaking information.
    
GS:  I didn't understand this last comment. I agree that unencrypted time would leak information - but that was the content of your comment following this one (below). The question you posed and I tried to answer was: why not encrypted timestamp? And a better answer is perhaps: encrypted time stamp is fine, but we considered it more difficult to specify and doesn't seem to have any advantage compared to the examples of Appendix A. In particular, the random value method does not have to leak any information at all. Is it more clear now? I will mention encrypted timestamp in Appendix A.
    
Göran


    > 
    >     * Appendix A - I would think that if you send a 32-bit timestamp in the
    >     clear w/ an integrity value that one can start making guesses about some of
    >     the same privacy problems as the use of a wall clock.  Knowing when a
    > server
    >     was last reset could tell you the same things.
    > 
    > GS: Added reference to the new privacy considerations section.
    >