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

Göran Selander <goran.selander@ericsson.com> Sun, 21 October 2018 12:45 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 8DF8F130FB4 for <core@ietfa.amsl.com>; Sun, 21 Oct 2018 05:45:35 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=YxpIzowb; dkim=pass (1024-bit key) header.d=ericsson.com header.b=cDn5ct5L
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 CQxcGuFdLJuW for <core@ietfa.amsl.com>; Sun, 21 Oct 2018 05:45:33 -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 111C6130FB2 for <core@ietf.org>; Sun, 21 Oct 2018 05:45:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540125926; x=1542717926; 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=WY/UZN8HfKCyGbxw79GMbLU4WIkqeRVISb7Nj+5E9nc=; b=YxpIzowbIRP8pvzbCs6QGEp6D1IRHSH9brrd3NrSYzs87uzUK7fsKMstOAkfxOZG HIplIOhKet1e3CuIowHoL/tGGzlP+MHl2inL6a4AMo+3efJn9VAXr4uYcqqNujMc 17EWJ5yj+O79wENNlau0KcXcOSZQf6YVK19FQ27BACM=;
X-AuditID: c1b4fb2d-fb3d09e000003a27-dc-5bcc74e614df
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E5.29.14887.6E47CCB5; Sun, 21 Oct 2018 14:45:26 +0200 (CEST)
Received: from ESESSMB505.ericsson.se (153.88.183.166) 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; Sun, 21 Oct 2018 14:45:13 +0200
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) 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; Sun, 21 Oct 2018 14:45:13 +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=WY/UZN8HfKCyGbxw79GMbLU4WIkqeRVISb7Nj+5E9nc=; b=cDn5ct5L/8F8Q9QDPOyAvfgNNcWhvt66vOxuCtElvrTWWi4zIgnMy4nQuH6qzrQir0KW5ZUJNqrj1yHMeCB17jh12swp9bukpnlAzQbHifE/Lzry1dxDZWg638jg/yroDqKYXjd98JDxQGYfm/TwGrB0oh9ERkOELhwBPfBR1nQ=
Received: from AM6PR07MB4822.eurprd07.prod.outlook.com (20.177.190.219) by AM6PR07MB3895.eurprd07.prod.outlook.com (52.134.115.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.5; Sun, 21 Oct 2018 12:45:12 +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.014; Sun, 21 Oct 2018 12:45:12 +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///7WwCAAvd+AA==
Date: Sun, 21 Oct 2018 12:45:12 +0000
Message-ID: <AA48491F-4185-408A-AEE3-074252891DE9@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> <049375ED-A806-4969-8403-8DB18317021F@ericsson.com> <00d901d467d0$eef06f20$ccd14d60$@augustcellars.com>
In-Reply-To: <00d901d467d0$eef06f20$ccd14d60$@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; AM6PR07MB3895; 6:N1jfGoMKerxcYwKS7uxX5oGBFbpZahdNLCjADmv9Cs3TZnfjFbFAgSVut+sUYcXZ+0a0OdilyngviE7xi0OpbFZ4llWKBszp7CcTGK143YowvDWPXQthqzwDjvWvxSzl46m1VuWhADfRKXRx9MH4PdoV/wBgTrZbD3v3n1ydniRuNdG37fu8e77XZKuXiElTG4W2bllbRO6zHgZbx7kVpzn+DQSbWDE+tMj9iWG3OUD2gWQKsn08XySA3S2uvzf0XmcmJRBF6xRsv3B6UX9fbGeUkPxiTA6RoZJWO2Y/dgIzAJIk831c0QzpzkDahNbup+TNoue5f9Egrn84aCjBqnXyC33d3R3UukqHQxituMIHqXRvLvWLMoRkbnkqhghTW6fFQsdqg8Xh900Q7ylST42/cbWS9U7vWstN2J+qC0uN4U751u0plfE8+6OYgOcw2xlkr2oh0EVW+sL03quzFQ==; 5:T2hh/AW2uZDZE7u7v8F1Ld76rpuW16nml/lUf/ROVGOHq9BG3x2E1p5XmkNOk5Em1QgbSS3INspzgqZh0Pr4ESKtenxu78ZZkmEtKASbtJqeuFdJHzJlpCZnWYN+npTJR9ldRnJ3N4IbiRTsVeiio4U53tA2E39FToDV3wV9U+Y=; 7:5ppQT6dh7vNSyc7uI9VlkxOnX1TaYU8b853AIE3g4MJw2WxvbNYW4aob+rRdh+5TacaJjN8S5atElWsPFQusXJqhsOAXsmqQ31oJ2m/yx3wsg43YY1fAbeVatL5XdjfsUW8Tk4yRE/Ge1PXaUkws5w==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 4f5251b2-5c48-4d72-2834-08d637530b32
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM6PR07MB3895;
x-ms-traffictypediagnostic: AM6PR07MB3895:
x-microsoft-antispam-prvs: <AM6PR07MB3895997907EF5627ECBDF8DBF4FB0@AM6PR07MB3895.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(158342451672863)(17755550239193)(192374486261705)(248295561703944)(37575265505322);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM6PR07MB3895; BCL:0; PCL:0; RULEID:; SRVR:AM6PR07MB3895;
x-forefront-prvs: 083289FD26
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(366004)(346002)(39860400002)(189003)(199004)(13464003)(36756003)(966005)(25786009)(478600001)(82746002)(14444005)(256004)(14454004)(66066001)(26005)(305945005)(5660300001)(7736002)(11346002)(476003)(93886005)(2616005)(102836004)(83716004)(486006)(561944003)(33656002)(186003)(446003)(71190400001)(71200400001)(2906002)(8676002)(81166006)(5250100002)(4326008)(81156014)(53546011)(6486002)(2501003)(6512007)(6306002)(316002)(58126008)(4001150100001)(86362001)(97736004)(6506007)(54906003)(8936002)(110136005)(105586002)(6436002)(85182001)(85202003)(2900100001)(229853002)(99286004)(6246003)(6116002)(3846002)(66574009)(76176011)(53936002)(68736007)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB3895; 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: 2RVQYzY18teas6rxqVjpOCE9Mlev3+qPfVY8LIGycekK1AU7hG/gO2m/CsAwr4ru5t8vUKL+kvlGfrQn8phvzRUit1zEdv077D1t5aaSbDMsQEnQO68FnrxMn/Odi80HowCGUkVWZ8hsUTyq2E57MF1ax1IYCkflhTKUMTJUlX4G1MYoY7GvgfkT7jYR74JVadln09kJkRSSPcd5CZAKvL0vlpODN6C7SpY8+sGvG09XQukR1kSrRAxayxRX90lYY18iN6ByIopbfje0iY03O7u5oS1pJqwAKbOwShP4Gal6nDGW11KPT4ke3ttbKn4Alb9S60alffWDNVm/ZZ2vTO57Di56X0GcQfM2T/8Nrtg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <B18166F937D31C47BC61C8CBD96497E5@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f5251b2-5c48-4d72-2834-08d637530b32
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2018 12:45:12.8372 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3895
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85OzuORq9T88GIcNCHFG9pMEhrUaIGUkiIaGhDj5fUKTvL UtCWYOASMW9LExTT8JZLES+bSYnivEASNKS8lA6dt7SwzEuW2zHo2+95/r/38ry8DCmpEbgx KUo1q1Iq0qS0iKqK6rnntaieiPE11TvKujsmadnAup6UzZmMtKxVt03LqdCOGh0d2tCwQ9wg okWBCWxaShar8rl4W5Q81KajMvdv3u9bLUcaZInQIgcGcABMmz5RWiRiJHgYwYutFQFf/ESw VzdN80UDATWzW8hWULiEhA+jq0dJOQGlxUNCvphHoDWPULadaXwVPmvmCRs74yjIn9q190mc B9+2ioQ2dsKB0G3VHjlBYGnto3mOhBn9Q2RjCp8BndFk74vxJXhpnLHvI8EmAprX4m3sgOWw XWYQ2BjhE7A91kbwZ7nCR0stwU+KoaH/HcmzCywvHNh9F+wDdeM6kl8bC/ntGpp3pGAsGD3y T8H72sf28QGbaSirXBHwgRdsVlQcSeHQPvyU5KURBJtbPRQfeIB1bumQmUNOBXOZK+8UI7BW rglLkH/1f5etPtRIfBb0Bh++HQrFy/0Ez+5Q/viLsNr+Fo4wWmWh6pCgBblwLMelJ53z92ZV KfEcl6H0VrLqTnT4Z9527Xn1otbVy4MIM0h6TKxRTsRIBIosLjt9EAFDSp3F1abxGIk4QZGd w6oy4lR301huEJ1kKKmr2LulP1qCkxRqNpVlM1nVv5RgHNw0yC+yURghtXY9jx4LkJet5HrG 7bbth+XKC61hpb6/6rnmnAXtla/ueTsPgoP0ofLjB49GX+U8e3P+j7rAsD/XKbT8HthYujM5 jpo0hYmv9YtGmTQkJOt6hTHHP/ZaU2xM763i+O9PnLQX0hvNs8rTXeFTiZ4Sw/pw9garDwwu +iGluGSFnwep4hR/AR48yOAvAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/lhpmBPgwaakhkMJWOv8nhqDrj7s>
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: Sun, 21 Oct 2018 12:45:36 -0000

Hi Jim,

Some replies inline. The .md file in core-wg/echo-request-tag is updated.

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

    > -----Original Message-----
    > From: Göran Selander <goran.selander@ericsson.com>;
    > Sent: Friday, October 19, 2018 8:43 AM
    > To: Jim Schaad <ietf@augustcellars.com>;; core-chairs@ietf.org
    > Cc: draft-ietf-core-echo-request-tag@ietf.org; core@ietf.org
    > Subject: Re: Comments on draft-ietf-core-echo-request-tag-02
    > 
    > 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?
    
    Not really.  What you are saying is that the proxy would reject a message w/ a request for an echo.  This would be satisfied by the client resending the request.  The server would then reject the message w/ a request for an echo and the client would then need to resend the request a second time.

GS: No, the order I had in mind is the one you sketch below.

    If the client had an encrypted message that it sent the first time which was rejected, then it needs to end that echo externally but the second echo would be sent inside of the encrypted message.  

GS: Echo may be Inner or Outer and are independent, I see no reason to mix them. If the server receives an OSCORE request that verifies but maybe isn't fresh, it can reject with an Inner Echo, and the OSCORE client needs to respond with an Inner Echo. If the server uses an outer Echo to verify the reachability of the client, then the client should respond with an outer Echo. In this case the message may be unprotected or only hop-by-hop with e.g. DTLS, which means that intermediary nodes may also need to take responsibility for ensuring reachability of requesting device.

    You are also assuming that the proxy would know it is going to be a large response before it sends the request to the server while it would not know that until it gets the response from the server so the order of events would be
    
    Client sends request
    Proxy passes on request
    Server says please echo
    Client sends request with echo
    Server replies
    Proxy caches result
    Proxy says please echo
    Client sends request with new echo
    Server replies
    
GS: This is the order I was thinking of. I didn't include this example it in the recent update, but perhaps we should?

    
    > 
    >     >
    >     > ---
    >     >
    >     >     * 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.
    
    My problem is that the text says something that I don't agree with.  It says:
    
    Servers SHOULD NOT use wall clock time
       for timestamps, as wall clock time is not monotonic, may reveal that
       the server will accept expired certificates, or reveal the server's
       location.
    
    If you are using encrypted wall clock time the only possible issue is that the wall clock may not be monotonic.  The second two items are not correct as the value of time cannot be seen.   In appendix A, you are suggesting an integrity protected time, but that is revealing information because the time is in the clear so the last two items might have some relevance (although I kind of doubt it unless you know that all of the devices are started up at 9 am every morning).
    
GS: Yes, there were too many statements combined here. I kept "not monotonic" in the security considerations and have "reveal location" and "accept expired certificates" in the privacy considerations.

    I would not recommend an integrity protected internal clock as a good method.  I would only recommend an encrypted wall clock value.
    
GS: I changed the recommendation to generally recommend the random value based method ("1. List of Cached Random Values and Timestamps.") as this is very simple to implement. 
The integrity protected time stamp is also recommended but only when Echo is encrypted. I also mention the encrypted timestamp but do not propose a mechanism. If you have a simple concrete proposal we could include that as well. 

Göran