From nobody Mon Nov 1 05:22:54 2021 Return-Path: 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 790AA3A12D4; Mon, 1 Nov 2021 05:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, 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=iki.fi 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 3TWF82_poCWM; Mon, 1 Nov 2021 05:22:47 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 4C32E3A12D1; Mon, 1 Nov 2021 05:22:46 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id EC9C520106; Mon, 1 Nov 2021 14:22:42 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1635769363; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T5l9B6D8Lf3vkKn18Ttc81boNYfaJtacE7jpyp//yk8=; b=cJH3AoAzjb1PxeObjjw2UiO9tngeOKtCe2+eIfK3gqfxXu9pr+sX/iATvD75kPi/2vfm1T NqeFQ94KjQuNpUXz15aeDzaeZc1nF/3xaH8jg4aCT7DVl7qmfUQgErEilSvnu8A/n6N7SH IQt52AxdYvTB/87EryageufJAOPGwxY= Received: by fireball.acr.fi (Postfix, from userid 15204) id 7F2FB25C12C4; Mon, 1 Nov 2021 14:22:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24959.56338.456532.711962@fireball.acr.fi> Date: Mon, 1 Nov 2021 14:22:42 +0200 From: Tero Kivinen To: tuexen@fh-muenster.de Cc: David Mandelberg , iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org In-Reply-To: <1BB0CA3B-8B01-4D7F-A332-3311DE53489E@fh-muenster.de> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <24941.43160.312498.778487@fireball.acr.fi> <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> <24955.17484.301497.733333@fireball.acr.fi> <1BB0CA3B-8B01-4D7F-A332-3311DE53489E@fh-muenster.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1635769363; a=rsa-sha256; cv=none; b=xv2hIH9w26Bj1sEQVfa2w1vaUl0yYKFvyS0LHC/XU3MCSteUvmK1GlReBlbKfKEPChFPLO CPnyxLAvih6zOZTwwn6GyBI+ZHm4PZSjfB36eJ8v+TWTzzMBa9lvds6hIXnDhM7E63OWsf /l+Yh5EViFYOtQTjEYxz5auZioR9NKQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1635769363; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T5l9B6D8Lf3vkKn18Ttc81boNYfaJtacE7jpyp//yk8=; b=nTUdM+X+c36lhb8fDVFEaotIutDdvIkh3aZDMwJEwC/zNzEq4Daie7gAhwqxW++vBWmIoD P9OFn8G+jdt5iGWgADyTCLyL254OKKgHwmgOB7Xjp2UY/dntYGhkXkoCDvkLCpn8OjStIV E9il8wv/j9z6IqvjRcEPvS7y3i6Z4VE= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 12:22:53 -0000 tuexen@fh-muenster.de writes: > > But the draft does not suggest the method used by FreeBSD, but instead > > suggest creating TCB and taking minimal subset of it. TCB might have > > some private data in it, so perhaps adding some comment about that > > too. > The text has changed. It doesn't mention the TCB anymore in this subsection. > > It reads: > > Inside this State Cookie, the sender SHOULD include a MAC (see [RFC2104] > for an example), a timestamp on when the State Cookie is created, and the > lifespan of the State Cookie, along with all the information necessary for > it to establish the association including the port numbers and the > verification tags. Looks good. > > I.e., say that as the cookie is not encrypted care must be taken when > > constructing cookie, so that the cookie does not leak out any > > information that should not be leaked. > Sure. What about adding the following sentence: > > Since the State Cookie is not encrypted, it MUST NOT contain information > which is not being envisioned to be shared. That sounds ok too. > > Anyways as this is internal matter to the implementation I do not > > think we need to recommend any specific algorithm, we could simply say > > any MAC with acceptable security properties is fine, and if we really > > want to suggest something suggesting HMAC-SHA256 or similar might be > > better. > OK. So I remove (the recently added) sentence: > > Using the HMAC-SHA1 might be an acceptable compromise. > > and replace it by > > A MAC with acceptable security properties SHOULD be used. Yep. > Then it makes sense to also remove (the recently added) sentence: > > When using HMAC-SHA1, secret keys of at least 160 bits are appropriate according > to . Yep. > Should I also change back "reasonably frequently (e.g., daily)" to > "reasonably frequently" when describing that the secret should be > changed? Daily does not sound very frequent to me... The attack that this protects is that someone slowly collects millions of cookies over some period of time, and then suddenly flood all those connection attempts to the server all at once, i.e., simulating monday morning problem. If I have understood correctly the cookie only needs to be valid for few seconds at most (i.e., few round trips over the network while the connection is being formed), and the cost of changing secret is just generating few random bits, changing it hourly or something is not too expensive. You do need to remember the previous secret for some time after secret was changed, but for that you can limit yourself to few tens of seconds. This of course depends what the failure model is when cookie is wrong. In IKEv2, if cookie is wrong the server just generates a new cookie, and sends that back to client, and client retries with that new cookie. I.e., even if the secret changed in the middle and the old cookie is no longer accepted as it was using old secret, this is not a fatal error, it just causes one extra round trip. The frequency how often you want to change the secret depends how many outstanding cookies you want to allow. Of course if you do have lifespan of the cookie inside the cookie, then you can limit the lifespan even without changing the secret, but changing secret will also limit the lifespan without a need of storing lifespands in the cookies. -- kivinen@iki.fi From nobody Mon Nov 1 08:11:16 2021 Return-Path: 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 97CB33A13CE; Mon, 1 Nov 2021 08:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 eD7K4Pdfjhul; Mon, 1 Nov 2021 08:11:05 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438AB3A09F7; Mon, 1 Nov 2021 08:11:03 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:2c02:2832:2395:dd95]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 8DBF0721E2807; Mon, 1 Nov 2021 16:10:58 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_AD98D8D4-B822-439D-8A65-B5C8F32B819F"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: tuexen@fh-muenster.de In-Reply-To: <24959.56338.456532.711962@fireball.acr.fi> Date: Mon, 1 Nov 2021 16:10:57 +0100 Cc: David Mandelberg , iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9E8B6E93-2781-41FE-9C8E-C1E8ABFD19C3@fh-muenster.de> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <24941.43160.312498.778487@fireball.acr.fi> <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> <24955.17484.301497.733333@fireball.acr.fi> <1BB0CA3B-8B01-4D7F-A332-3311DE53489E@fh-muenster.de> <24959.56338.456532.711962@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 15:11:10 -0000 --Apple-Mail=_AD98D8D4-B822-439D-8A65-B5C8F32B819F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 1. Nov 2021, at 13:22, Tero Kivinen wrote: >=20 > tuexen@fh-muenster.de writes: >>> But the draft does not suggest the method used by FreeBSD, but = instead >>> suggest creating TCB and taking minimal subset of it. TCB might have >>> some private data in it, so perhaps adding some comment about that >>> too. >> The text has changed. It doesn't mention the TCB anymore in this = subsection. >>=20 >> It reads: >>=20 >> Inside this State Cookie, the sender SHOULD include a MAC (see = [RFC2104] >> for an example), a timestamp on when the State Cookie is created, and = the >> lifespan of the State Cookie, along with all the information = necessary for >> it to establish the association including the port numbers and the >> verification tags. >=20 > Looks good.=20 >=20 >>> I.e., say that as the cookie is not encrypted care must be taken = when >>> constructing cookie, so that the cookie does not leak out any >>> information that should not be leaked. >> Sure. What about adding the following sentence: >>=20 >> Since the State Cookie is not encrypted, it MUST NOT contain = information >> which is not being envisioned to be shared. >=20 > That sounds ok too.=20 >=20 >>> Anyways as this is internal matter to the implementation I do not >>> think we need to recommend any specific algorithm, we could simply = say >>> any MAC with acceptable security properties is fine, and if we = really >>> want to suggest something suggesting HMAC-SHA256 or similar might be >>> better. >> OK. So I remove (the recently added) sentence: >>=20 >> Using the HMAC-SHA1 might be an acceptable compromise. >>=20 >> and replace it by >>=20 >> A MAC with acceptable security properties SHOULD be used. >=20 > Yep. >=20 >> Then it makes sense to also remove (the recently added) sentence: >>=20 >> When using HMAC-SHA1, secret keys of at least 160 bits are = appropriate according >> to . >=20 > Yep. >=20 >> Should I also change back "reasonably frequently (e.g., daily)" to >> "reasonably frequently" when describing that the secret should be >> changed? >=20 > Daily does not sound very frequent to me... The attack that this > protects is that someone slowly collects millions of cookies over some > period of time, and then suddenly flood all those connection attempts > to the server all at once, i.e., simulating monday morning problem. >=20 > If I have understood correctly the cookie only needs to be valid for > few seconds at most (i.e., few round trips over the network while the > connection is being formed), and the cost of changing secret is just > generating few random bits, changing it hourly or something is not too > expensive. You do need to remember the previous secret for some time > after secret was changed, but for that you can limit yourself to few > tens of seconds. >=20 > This of course depends what the failure model is when cookie is wrong. > In IKEv2, if cookie is wrong the server just generates a new cookie, > and sends that back to client, and client retries with that new > cookie. I.e., even if the secret changed in the middle and the old > cookie is no longer accepted as it was using old secret, this is not a > fatal error, it just causes one extra round trip. >=20 > The frequency how often you want to change the secret depends how many > outstanding cookies you want to allow. Of course if you do have > lifespan of the cookie inside the cookie, then you can limit the > lifespan even without changing the secret, but changing secret will > also limit the lifespan without a need of storing lifespands in the > cookies. We have a cookie lifetime in the cookie. The default value is 1 minute. If this is too short, the peer can request a longer lifetime, up to (2^32 - 1) usec, which is about 70 Minutes (there is no requirement to follow such an request). In FreeBSD you can change the time after which the secret is changed. We use 1 hour as the default and keep the current and the last secret. So if you prefer, I can (a) remove (e.g., daily) (b) change (e.g., daily) to (e.g., hourly) (c) anything else you would prefer. Just let me know... Best regards Michael > --=20 > kivinen@iki.fi --Apple-Mail=_AD98D8D4-B822-439D-8A65-B5C8F32B819F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEx MDExNTEwNTdaMC8GCSqGSIb3DQEJBDEiBCCnY+vgY59pGmwHnhGXcKkSbLBnbIpoGhMNPibbs/pR WTCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAVwiZTZFQhMCmO/0WE/N4FVjD1fDG VreKn2liyXiPlDu/MLu+PWW9+rnlWgk1cfGydH4FLDAcquo0phhdyQ2tFZGkk04PCgzQ4KHzjPKC FfHap2ACSzs9Too+wLeB9/4Pp6mFMcGsDB9l+8Z4kLVLw2pl/U1OaS247ZTFTnUy7P58DNYPvAxC r2IZ96v/tGhPv7Au2CKzgeIpeoX2W5U3Guiv4KMacWmRPl2VMn96grdvfiI1zW9Fay+2vZ/BZw5T GkijoBc5McaInzXlaR2eyybJ/vOZY8GOsQayT3XYdWzXch7Sc9yEnf8ljZuk5GF9cYgZYammrRZS pAYEX1/8IgAAAAAAAA== --Apple-Mail=_AD98D8D4-B822-439D-8A65-B5C8F32B819F-- From nobody Mon Nov 1 09:00:46 2021 Return-Path: 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 9896E3A0A46 for ; Mon, 1 Nov 2021 09:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=mandelberg.org header.b=ZWOJXkF8; dkim=pass (2048-bit key) header.d=mandelberg.org header.b=rOqTasf5 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 QqI_D-cgv0vV for ; Mon, 1 Nov 2021 09:00:40 -0700 (PDT) Received: from mail-ot1-x364.google.com (mail-ot1-x364.google.com [IPv6:2607:f8b0:4864:20::364]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1473A16AC for ; Mon, 1 Nov 2021 09:00:39 -0700 (PDT) Received: by mail-ot1-x364.google.com with SMTP id l16-20020a9d6a90000000b0054e7ab56f27so25891080otq.12 for ; Mon, 01 Nov 2021 09:00:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:dkim-signature:dkim-signature:subject:to:cc :references:from:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1qvHXMD67OoBktAAvnIV8aNtNoBWUP7BQPxuWEJthQU=; b=CiW20s+gABMom+5QKUlPEDmZ2qdeDC7ZIMwaZ+LEOsvRa1bBNELa7A5/RILsH+l+D4 23f/e0zTl0Oo1aYYCQ2dYEygHdCc3lrUB+mcIamAbM4XCeqtG8hQ70Xs5kpvPDaSSh6U CXcgeurujqsx+Ddgd+/obvT2BN3QuD6vIpYHJ1laCAY0sH4LeT/TQQshaetnzKIeO40G v0EJ32dzblQz4ufuB7w0wfxVqHpZI4gMAWZmYnSLCK8++bFUCJ+8ur+91VmBV9J1btni P9xXAHgHPqnZ3vWk/FG9UNS+qM7Hl9z8mVTByh72lKYFNuNRorop+QIRL//QKIkV51uH YCfA== X-Gm-Message-State: AOAM532hPHJ5cZLt0uaUawZxnL/UiWeyU7oy0dNlOIi/V/DWeyVRWxWt y/uLckgiohVNbE6Ijq7iWCkh7lJKp7Fee8JLA6EFwu9ZKaJBqA== X-Google-Smtp-Source: ABdhPJzpU7fnN0IyyEFQtWskvH87Iuf0MYd4ESGVAKTG6l1SnQnOX4FB/yVXMr6ho+hCIp9s8Wn4Gyv2QY5+ X-Received: by 2002:a9d:6c93:: with SMTP id c19mr21219735otr.117.1635782438379; Mon, 01 Nov 2021 09:00:38 -0700 (PDT) Received: from mail-outbound-e14cf917.virgo.mandelberg.org (pool-74-104-157-60.bstnma.fios.verizon.net. [74.104.157.60]) by smtp-relay.gmail.com with ESMTPS id n5sm901366ooj.10.2021.11.01.09.00.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Nov 2021 09:00:38 -0700 (PDT) X-Relaying-Domain: mandelberg.org DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-07914516; t=1635782437; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=C5A4Ap4eSx4R0cyyM3nyMrmLznXy+QOvDMN28LzFHfQ=; b=ZWOJXkF8UZZYfUKS+ghSYVCL4XO6yI0QCdEN2iOgvNUNVbcX3ixQOWfZZYPjaaJncyBR8 x6o/IHaVFBFN/3lAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; i=@mandelberg.org; q=dns/txt; s=mail-outbound-e14cf917-b7c648a2; t=1635782437; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding : from; bh=C5A4Ap4eSx4R0cyyM3nyMrmLznXy+QOvDMN28LzFHfQ=; b=rOqTasf5s8eLC9jLZebIUAIqi9wBFlheajnt4l/BGHZHdFdBdXvX3rtXh6bU4045/rlRQ IAj5frmH6u9IM4spBLojzT4FLej+P7f8Ru+ABDSMeHjZC1j6MBgNKATiYL+YIs6s0fC2fvm m3RXcJ0pzti6VBBpKw66B1VG27vluuR06eH9ylNjN74KYtWcQBLjSSVK+yZQk18k1vjSD38 T6X/eyVKBL6K8IN1b2cYZCeXSlBVvBHAERTunfXndnJlHqWQsjA0fwaQ2i3M7C54REv+vJd 8UXbQtkiwhvEVE935Y+PirywWcpS3XmXcV4a8r9/n3XFOCSUwf6jn0U6RREA== Received: from [IPv6:fde5:2b79:35f0:2::14e] (solaria.virgo.mandelberg.org [IPv6:fde5:2b79:35f0:2::14e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail-outbound-e14cf917.virgo.mandelberg.org (Postfix) with ESMTPSA id 4Hjd6Y61JJzySJ; Mon, 1 Nov 2021 16:00:37 +0000 (UTC) To: tuexen@fh-muenster.de, Tero Kivinen Cc: iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <24941.43160.312498.778487@fireball.acr.fi> <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> <24955.17484.301497.733333@fireball.acr.fi> <1BB0CA3B-8B01-4D7F-A332-3311DE53489E@fh-muenster.de> <24959.56338.456532.711962@fireball.acr.fi> <9E8B6E93-2781-41FE-9C8E-C1E8ABFD19C3@fh-muenster.de> From: David Mandelberg Message-ID: <489a76f2-40e3-4c50-ffa0-88deff9fcc85@mandelberg.org> Date: Mon, 1 Nov 2021 12:00:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <9E8B6E93-2781-41FE-9C8E-C1E8ABFD19C3@fh-muenster.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 16:00:45 -0000 Op 01-11-2021 om 11:10 schreef tuexen@fh-muenster.de: > We have a cookie lifetime in the cookie. The default value is 1 minute. > If this is too short, the peer can request a longer lifetime, up to > (2^32 - 1) usec, which is about 70 Minutes (there is no requirement > to follow such an request). > In FreeBSD you can change the time after which the secret is changed. > We use 1 hour as the default and keep the current and the last secret. > > So if you prefer, I can > (a) remove (e.g., daily) > (b) change (e.g., daily) to (e.g., hourly) > (c) anything else you would prefer. I prefer (b) or explaining the criteria for picking how often to change the secret. I think (a) is likely to result in misunderstandings about what "reasonably frequently" means. E.g., people who are thinking in terms of root CA certificates might think it means more than once per decade. From nobody Mon Nov 1 09:56:11 2021 Return-Path: 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 9F71B3A2C55; Mon, 1 Nov 2021 09:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 Dv2RV-oasZls; Mon, 1 Nov 2021 09:56:05 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B763A2C53; Mon, 1 Nov 2021 09:56:04 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id A62BC1B0004B; Mon, 1 Nov 2021 18:55:53 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1635785753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tg6nh2wpGB6y6RwlZfRxpUOOq2sYoloYYtk3pCObLvs=; b=aIcpotFvZkdtoommtfNFnO9ZrYFKLZCYJxSx/vqFQIuJnvuqUigrAsaowVS8WTrqMEJ0U1 YMCAavqMtoJIfzNTP3VcVlqo9ObDzZSDbt77yZ/Ydy2dObzLindvz+frFSGcjX5eB6b/l6 pHLAijL7ryZmQW5NcZncifRUlVgVjyTskKbP8MdtId0dsrVxNuJsjod9hfwmUmDA11IRHq V8lsUK5H+rMAPuByzkcdxxPqSLg1EyKl3+3zjJjlcdZbhCcBZ9zdimAGu9n5gDXW7q8c+P UIUZQECZkMXTV3XrbTsEywcqps5QsWG7N+S1O7oSBRjJi252GFaX++NjOP+FLw== Received: by fireball.acr.fi (Postfix, from userid 15204) id 3354225C12C4; Mon, 1 Nov 2021 18:55:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24960.7193.164205.178529@fireball.acr.fi> Date: Mon, 1 Nov 2021 18:55:53 +0200 From: Tero Kivinen To: tuexen@fh-muenster.de Cc: David Mandelberg , iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org In-Reply-To: <9E8B6E93-2781-41FE-9C8E-C1E8ABFD19C3@fh-muenster.de> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <24941.43160.312498.778487@fireball.acr.fi> <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> <24955.17484.301497.733333@fireball.acr.fi> <1BB0CA3B-8B01-4D7F-A332-3311DE53489E@fh-muenster.de> <24959.56338.456532.711962@fireball.acr.fi> <9E8B6E93-2781-41FE-9C8E-C1E8ABFD19C3@fh-muenster.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1635785753; a=rsa-sha256; cv=none; b=ayZuc9ddkgd2szq2Z95m5bzqBNQxXXANOip1KN0gq/bXA7lo9svvCxUEsPavpeXkxuqRNO a2jieeZN7acKbAIjMMwznqGhZkF/4OqjUVu55B2NhYgtLPs/C7LR2ndBAk6haCrx/buQVt Q1mEz0KOSuk4jxyjhQj9dcSnTdd1AS6tjTnUu1Ch7bs90Xz6pkjzxVdhX49e28atFmUekT 6GPOYTD8vKGg6SzGIAkz43Sjx3CIlAQMuqY47yjDel73utHz241K7drm5L0gY0IxvgWy6j PimXVAQ277mbqm0gGj2BbqazDpZw57sKDUU7/dn/YxXZSJ4mlqYRJej9J6Z6SA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1635785753; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tg6nh2wpGB6y6RwlZfRxpUOOq2sYoloYYtk3pCObLvs=; b=rdYJaYQHUoU5lCT/+tl+Q77kW7T8DMDzdLwhh75Xme2U12ykjMBqNqsTDTZCjtXzH0Etur Szc+T2Sz7fgrdU4IzRb4K6dUB758VQAGoG2VmFFeiq3V4bPPfMsSkf7tpE6hUHhXIb4Q6R FO4q7D8Uy8nKBnrOqVKo2DIzq0sFRnUHFejlyRVijmlN3tui6oLqHQ9Y4W4+PXlqVXW5pO ZKWMljzi4vDyjV3iyj8X0uaOwnrWZq/Ssxi2cekCm+TPmb3OsMoZBRafwTo34GoVKWcWZj NdhFgp3cyfemiCKq+rg79eWyAMYcY+sJvgrRvm3y4dt6IX/F/K0oG4HPFwMBng== Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 16:56:10 -0000 tuexen@fh-muenster.de writes: > We have a cookie lifetime in the cookie. The default value is 1 minute. > If this is too short, the peer can request a longer lifetime, up to > (2^32 - 1) usec, which is about 70 Minutes (there is no requirement > to follow such an request). > In FreeBSD you can change the time after which the secret is changed. > We use 1 hour as the default and keep the current and the last secret. > > So if you prefer, I can > (a) remove (e.g., daily) > (b) change (e.g., daily) to (e.g., hourly) > (c) anything else you would prefer. > > Just let me know... I think you know much better what kind of default to use than me, so pick something that makes sense to you. Having some kind of indication what frequently means it good idea, so having something like (e.g., xxx) is good thing. -- kivinen@iki.fi From nobody Mon Nov 1 10:11:06 2021 Return-Path: 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 353603A1FF6; Mon, 1 Nov 2021 10:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 tn60v_g8ug_s; Mon, 1 Nov 2021 10:10:52 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429F93A1E7E; Mon, 1 Nov 2021 10:10:47 -0700 (PDT) Received: from smtpclient.apple (ip1f100ed2.dynamic.kabel-deutschland.de [31.16.14.210]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id E8AA6721E2806; Mon, 1 Nov 2021 18:10:39 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_91ADECE9-3BD8-43F2-8795-5299F0A381C6"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Michael Tuexen In-Reply-To: <24960.7193.164205.178529@fireball.acr.fi> Date: Mon, 1 Nov 2021 18:10:39 +0100 Cc: David Mandelberg , iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <85674C4B-7900-4AD8-B8AD-79E21E2D8CFA@fh-muenster.de> References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <24941.43160.312498.778487@fireball.acr.fi> <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> <24955.17484.301497.733333@fireball.acr.fi> <1BB0CA3B-8B01-4D7F-A332-3311DE53489E@fh-muenster.de> <24959.56338.456532.711962@fireball.acr.fi> <9E8B6E93-2781-41FE-9C8E-C1E8ABFD19C3@fh-muenster.de> <24960.7193.164205.178529@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 17:11:01 -0000 --Apple-Mail=_91ADECE9-3BD8-43F2-8795-5299F0A381C6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 1. Nov 2021, at 17:55, Tero Kivinen wrote: > > tuexen@fh-muenster.de writes: >> We have a cookie lifetime in the cookie. The default value is 1 minute. >> If this is too short, the peer can request a longer lifetime, up to >> (2^32 - 1) usec, which is about 70 Minutes (there is no requirement >> to follow such an request). >> In FreeBSD you can change the time after which the secret is changed. >> We use 1 hour as the default and keep the current and the last secret. >> >> So if you prefer, I can >> (a) remove (e.g., daily) >> (b) change (e.g., daily) to (e.g., hourly) >> (c) anything else you would prefer. >> >> Just let me know... > > I think you know much better what kind of default to use than me, so > pick something that makes sense to you. Having some kind of indication OK, will take hourly. Best regards Michael > what frequently means it good idea, so having something like (e.g., > xxx) is good thing. > -- > kivinen@iki.fi --Apple-Mail=_91ADECE9-3BD8-43F2-8795-5299F0A381C6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEx MDExNzEwMzlaMC8GCSqGSIb3DQEJBDEiBCBevHqkxviT0u0GAQkEzEqHYs82Az5Zu2Rznvd66zos 2TCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAODtxMrXVtRQHDQ/C2Cugof3BMOxV xtREylAfuJdRsqadwlaD/43zkWLmbELCCQRfAk4PaVi0ODIZaCgJKSuFNG17A1ScSAd+YfS5Y3B5 WVCem/FgAZN3CoaRWW7gTAJFz5OVPTD82rTC+h7//vE5walnvEtdtjmxx75J2mpkRfcQoLedG0R6 oxOKlPGIpuoDWwWmRYUTvVn916aBwUMi0/fw2gl06C+4TyCQPbFBnqvPY1sYrwAFx1d4HfOHeSVL V5KTejkb1dpOrA8YvZBreriF8/0q9P0ABegMq6WmEVhPEsQeCYcE/hVakFb+xjHBB56Gsw24nAvk IPkU0FnuXAAAAAAAAA== --Apple-Mail=_91ADECE9-3BD8-43F2-8795-5299F0A381C6-- From nobody Mon Nov 1 10:11:38 2021 Return-Path: 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 641BF3A195B; Mon, 1 Nov 2021 10:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 iBONKu_pmbWe; Mon, 1 Nov 2021 10:11:27 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFE93A1D6B; Mon, 1 Nov 2021 10:11:25 -0700 (PDT) Received: from smtpclient.apple (ip1f100ed2.dynamic.kabel-deutschland.de [31.16.14.210]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 58FF1721E2806; Mon, 1 Nov 2021 18:11:17 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_E6DE2533-1053-4D68-98A1-D6E1F1DB6D42"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Michael Tuexen In-Reply-To: <489a76f2-40e3-4c50-ffa0-88deff9fcc85@mandelberg.org> Date: Mon, 1 Nov 2021 18:11:17 +0100 Cc: Tero Kivinen , iesg@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6bad085d-aea3-c827-5788-2d377ec0fac3@mandelberg.org> <2bac74f5-e134-d50c-a640-4a87fdbc5790@mandelberg.org> <24941.43160.312498.778487@fireball.acr.fi> <87B43E4B-F93B-4ED7-9BFD-C501B093F9DB@fh-muenster.de> <24955.17484.301497.733333@fireball.acr.fi> <1BB0CA3B-8B01-4D7F-A332-3311DE53489E@fh-muenster.de> <24959.56338.456532.711962@fireball.acr.fi> <9E8B6E93-2781-41FE-9C8E-C1E8ABFD19C3@fh-muenster.de> <489a76f2-40e3-4c50-ffa0-88deff9fcc85@mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-rfc4960-bis-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 17:11:32 -0000 --Apple-Mail=_E6DE2533-1053-4D68-98A1-D6E1F1DB6D42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 1. Nov 2021, at 17:00, David Mandelberg = wrote: >=20 > Op 01-11-2021 om 11:10 schreef tuexen@fh-muenster.de: >> We have a cookie lifetime in the cookie. The default value is 1 = minute. >> If this is too short, the peer can request a longer lifetime, up to >> (2^32 - 1) usec, which is about 70 Minutes (there is no requirement >> to follow such an request). >> In FreeBSD you can change the time after which the secret is changed. >> We use 1 hour as the default and keep the current and the last = secret. >> So if you prefer, I can >> (a) remove (e.g., daily) >> (b) change (e.g., daily) to (e.g., hourly) >> (c) anything else you would prefer. >=20 > I prefer (b) or explaining the criteria for picking how often to = change the secret. I think (a) is likely to result=20 Will use (b). Best regards Michael > in misunderstandings about what "reasonably frequently" means. E.g., = people who are thinking in terms of root CA certificates might think it = means more than once per decade. --Apple-Mail=_E6DE2533-1053-4D68-98A1-D6E1F1DB6D42 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTEx MDExNzExMTdaMC8GCSqGSIb3DQEJBDEiBCDrmAN7mokbd0iT2UaoCtsiOK9wA30GsqubHrlYyqxW OTCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQELBQAEggEAe9Si+UVf+2aJI7rMqjvtXpR/PiRZ VeefQG2+c4BYaFyEszn03UhQOzRmjwUnexHpFHRQrSevRSuxjTc16ywQwmM0BundnfIz2QynU3vF NBdp7frny91Q+U5uDcDct0s92jPTzvcXFu3QjgCFhKE2nycovn2YTN9D+hYJ2cykqh5fo7Sbv/Qh TTpLWb1FBZTVnaZ18pc4czcLpYxn4GsjmG5SZtzEJCVgTn1b5weTH4fsl8JXRX90EEWeREM4tX11 iEXnS2X3Di50uZkKGGDItvY8hjY36x5fLwuoLQg+Nb+0NcX1fmSdMRRI+tuwLKpzKRko0t14DaEc 466kwgiidwAAAAAAAA== --Apple-Mail=_E6DE2533-1053-4D68-98A1-D6E1F1DB6D42-- From nobody Tue Nov 2 18:04:40 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 077713A0824; Tue, 2 Nov 2021 13:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1635885308; bh=59Lu9sDwRpAR1X/JnyZxtwtvX9jITM8Rd67iZVtkHpU=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=pW5PyfDV6Azn6XyqOTtNS4vfUl/e5vqcsbJY3psyjZle3BnJt1S0f7R+xXl7c0p04 dMuw5vr3DtNGBETWD7qBezylEWT0xQ2HjeQNZYhzTlcisMH8qqFpkkyn/sXM9DlGz7 I4wrJLExWg74MVrZKoR1+WkqGdWkbzNpNZxEsqWM= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Nov 2 13:35:00 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C76983A09E5; Tue, 2 Nov 2021 13:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1635885292; bh=59Lu9sDwRpAR1X/JnyZxtwtvX9jITM8Rd67iZVtkHpU=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=CqWYNCobhezixhWPPnxr8HZ3DQeoiZ9xijjA7XwD6F2Oub7UznQ+BH8j7PG/qGoM+ eyCYSn2aZKYP4ny07CZlDMj88LB5WqBAO+gZ0sU/i+Y98ZD6BJHuB+Kq0DtqiuAIMq wm6RvkOzpDst+4mJtBRTVSU9+zg/dO6EwqtrGajA= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E953A083D for ; Tue, 2 Nov 2021 13:34:45 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <163588528585.22035.2385896583972982402@ietfa.amsl.com> Date: Tue, 02 Nov 2021 13:34:45 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 02 Nov 2021 18:04:40 -0700 Subject: [secdir] [new-work] WG Review: Network Time Protocol (ntp) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 20:35:16 -0000 VGhlIE5ldHdvcmsgVGltZSBQcm90b2NvbCAobnRwKSBXRyBpbiB0aGUgSW50ZXJuZXQgQXJlYSBv ZiB0aGUgSUVURiBpcwp1bmRlcmdvaW5nIHJlY2hhcnRlcmluZy4gVGhlIElFU0cgaGFzIG5vdCBt YWRlIGFueSBkZXRlcm1pbmF0aW9uIHlldC4gVGhlCmZvbGxvd2luZyBkcmFmdCBjaGFydGVyIHdh cyBzdWJtaXR0ZWQsIGFuZCBpcyBwcm92aWRlZCBmb3IgaW5mb3JtYXRpb25hbApwdXJwb3NlcyBv bmx5LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBJRVNHIG1haWxpbmcgbGlzdAoo aWVzZ0BpZXRmLm9yZykgYnkgMjAyMS0xMS0xMi4KCk5ldHdvcmsgVGltZSBQcm90b2NvbCAobnRw KQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQpDdXJyZW50IHN0YXR1czogQWN0aXZlIFdHCgpDaGFpcnM6CiAgS2Fy ZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlzb2Mub3JnPgogIERpZXRlciBTaWJvbGQgPGRzaWJv bGQuaWV0ZkBnbWFpbC5jb20+CgpBc3NpZ25lZCBBcmVhIERpcmVjdG9yOgogIEVyaWsgS2xpbmUg PGVrLmlldGZAZ21haWwuY29tPgoKSW50ZXJuZXQgQXJlYSBEaXJlY3RvcnM6CiAgRXJpayBLbGlu ZSA8ZWsuaWV0ZkBnbWFpbC5jb20+CiAgw4lyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4K Ck1haWxpbmcgbGlzdDoKICBBZGRyZXNzOiBudHBAaWV0Zi5vcmcKICBUbyBzdWJzY3JpYmU6IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnRwCiAgQXJjaGl2ZTogaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9udHAvCgpHcm91cCBwYWdlOiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2dyb3VwL250cC8KCkNoYXJ0ZXI6IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1udHAvCgpOZXR3b3JrIFRpbWUgUHJv dG9jb2xzIHdvcmtpbmcgZ3JvdXAKCkFjY3VyYXRlLCBwcmVjaXNlLCBhbmQgcmVsaWFibGUgdGlt ZSBpcyBhIGtleSBjb21wb25lbnQgb2YgYWxsIG1vZGVybgpzeXN0ZW1zLCBkZXZpY2VzLCBhbmQg YXBwbGljYXRpb25zLiBUaGlzIHJlcXVpcmVzIHJlbGlhYmxlIGFuZCBhY2N1cmF0ZQpuZXR3b3Jr IHRpbWUgc3luY2hyb25pemF0aW9uIG92ZXIgbW9kZXJuIElQLWJhc2VkIG5ldHdvcmtzLiBBZGRp dGlvbmFsbHksCmFjY3VyYXRlIHRpbWUgaXMgZnVuZGFtZW50YWwgdG8gaW1wbGVtZW50aW5nIG1h bnkgaW1wb3J0YW50IHNlY3VyaXR5CnByb3BlcnRpZXMsIGFuZCB0aGVyZWZvcmUgb2Z0ZW4gbXVz dCBiZSAoY3J5cHRvZ3JhcGhpY2FsbHksIG9yIG90aGVyd2lzZSkKc2VjdXJlZC4gVGhlIE5ldHdv cmsgVGltZSBQcm90b2NvbHMgd29ya2luZyBncm91cCBpcyBmb2N1c2VkIG9uIGVuaGFuY2luZwpl eGlzdGluZyBuZXR3b3JrIHRpbWUgc3luY2hyb25pemF0aW9uIHByb3RvY29scywgc3VjaCBhcyB0 aGUgTmV0d29yayBUaW1lClByb3RvY29sIChOVFApLCBhbmQgc3BlY2lmeWluZyBuZXcgbmV0d29y ay10aW1lLXJlbGF0ZWQgcHJvdG9jb2xzIG9yCmV4dGVuc2lvbnMgZm9yIHB1cnBvc2VzIHRoYXQg dGhlIGV4aXN0aW5nIHByb3RvY29scyBhcmUgbm90IHdlbGwgc3VpdGVkIHRvCmFkZHJlc3MuCgpO VFAgd2FzIGZpcnN0IGRlZmluZWQgaW4gdGhlIElFVEYgaW4gUkZDIDk1OCBpbiAxOTg1LiBJdCBo YXMgYmVlbiB0aHJvdWdoCnNldmVyYWwgaXRlcmF0aW9ucyBpbiB0aGUgSUVURi4gVGhlIGxhdGVz dCwgTlRQdjQgKFJGQyA1OTA1KSB3YXMgcHVibGlzaGVkCmluIDIwMTAuIFRvZGF5LCBpdCBpcyBh IHdpZGVseSB1c2VkIHRpbWUgc3luY2hyb25pemF0aW9uIHByb3RvY29sCmZvciB0aGUgc3luY2hy b25pemF0aW9uIG9mIGNsb2NrcyBvZiB2YXJpb3VzIGRpZ2l0YWwgc3lzdGVtcyBpbmNsdWRpbmcK Y29tcHV0ZXJzLCBuZXR3b3JrcywgYW5kIGEgbXlyaWFkIG9mIGRldmljZXMuIERlc3BpdGUgTlRQ J3Mgd2lkZS1zcHJlYWQKc3VjY2VzcywgaXQgaGFzIGJlY29tZSBhcHBhcmVudCB0aGF0IGl0IG5l ZWRzIGZ1cnRoZXIgZGV2ZWxvcG1lbnQgaW4gb3JkZXIKdG8gYWRlcXVhdGVseSBtZWV0IHRoZSBt b2Rlcm4gcmVxdWlyZW1lbnRzIG9mIHRpbWUgc3luY2hyb25pemF0aW9uCnByb3RvY29scyBhbmQg dG8gbWVldCB0aGUgaW5jcmVhc2luZyBzZWN1cml0eSB0aHJlYXRzIG9uIHRoZSBJbnRlcm5ldC4K ClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29udGludWUgdG8gYWRkcmVzcyB0aGUgbWFpbnRlbmFu Y2Ugb2YgTlRQdjQsCmluY2x1ZGluZyBleHRlbnNpb25zIGFuZCBjb3JyZWN0aW9ucy4gVGhpcyBp bmNsdWRlcyB0aGUgaW50cm9kdWN0aW9uIG9mIGFuCmludGVybGVhdmUgbW9kZSBpbiBvcmRlciB0 byBlbmhhbmNlIHRoZSBhY2N1cmFjeSBvZiB0aGUgbmV0d29yayB0aW1lCnN5bmNocm9uaXphdGlv biBhbmQgdGhlIGludHJvZHVjdGlvbiBvZiBhbHRlcm5hdGl2ZSBjbG9jayBzZWxlY3Rpb24KYWxn b3JpdGhtcyBpbiBvcmRlciB0byBlbmhhbmNlIHJvYnVzdG5lc3MgYWdhaW5zdCBkZWxheSBhdHRh Y2tzLgoKTlRQIHJlbWFpbnMgdnVsbmVyYWJsZSB0byBtYW55IHR5cGVzIG9mIGF0dGFja3MuIFRo ZXJlZm9yZSwgaW4gMjAyMCwgdGhlCndvcmtpbmcgZ3JvdXAgcHVibGlzaGVkIE5ldHdvcmsgVGlt ZSBTZWN1cml0eSAoTlRTKSBhcyBSRkMgODkxNS4gTlRTIGV4dGVuZHMKTlRQIHdpdGggYW4gYXV0 aGVudGljYXRpb24gYXBwcm9hY2ggdG8gZW5zdXJlIGF1dGhlbnRpY2l0eSBvZiBOVFAgdGltZQpz ZXJ2ZXJzIGFuZCBwcm90ZWN0cyB0aGUgaW50ZWdyaXR5IG9mIGV4Y2hhbmdlZCBOVFAgcGFja2V0 cy4gVGhlIHdvcmtpbmcKZ3JvdXAgd2lsbCB3b3JrIG9uIGV4dGVuZGluZyBOVFMgdG8gY292ZXIg dGhlIHJlbWFpbmluZyBtb2RlcyBvZiBzZXJ2aWNlIGZvcgpOVFAgbm90IGNvdmVyZWQgYnkgdGhl IGluaXRpYWwgc3BlY2lmaWNhdGlvbi4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhbHNvCndvcmsg b24gZXh0ZW5kaW5nIE5UUyBmb3IgUFRQIFsxXSBpbiBjb2xsYWJvcmF0aW9uIHdpdGggdGhlIElF RUUgMTU4OAp3b3JraW5nIGdyb3VwLgoKVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhbHNvIGRldmVs b3AgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIE5UUAoocHJlbGltaW5hcmlseSBrbm93biBhcyBOVFB2 NSksIGFkZHJlc3NpbmcgYSBudW1iZXIgb2YgaWRlbnRpZmllZAp3ZWFrbmVzc2VzLiBUaGUgbmV3 IHNwZWNpZmljYXRpb24gd2lsbCBjb25zaXN0IG9mIGEgc2V0IG9mIGRvY3VtZW50cywKc2VwYXJh dGluZyB0aGUgb24td2lyZSBwcm90b2NvbCBlbmdpbmUgYW5kIHRoZSB0aW1pbmcgZW5naW5lIG9m IE5UUApjbGllbnRzIGFuZCBzZXJ2ZXJzLiBUaGUgdXBkYXRlZCB2ZXJzaW9uIG9mIE5UUCB3aWxs IGFkZHJlc3MgdGhlIHNlY3VyaXR5CnJlcXVpcmVtZW50cyBzcGVjaWZpZWQgaW4gUkZDIDczODQg YW5kIGxldmVyYWdlIHRoZSB3b3JrIGNvbXBsZXRlZCBpbgpSRkMgODkxNS4KCkZpbmFsbHksIHRo ZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyBvdGhlciBuZXR3b3JrLXRpbWUtcmVsYXRlZApw cm90b2NvbHMgaW4gdGhlIElFVEYgKGUuZy4sIHJvdWdodGltZSkgYXMgd2VsbCBhcyB3b3JrIG9u IGl0ZW1zIGJyb3VnaHQgdG8KdGhlIGdyb3VwIGZyb20gb3RoZXIgc3RhbmRhcmRzIGJvZGllcyAo ZS5nLiBJRUVFIDE1ODgpLCB3aXRoIHRoZQphY2tub3dsZWRnZWQgcmVxdWVzdCB0byBkbyBzbyBm cm9tIHRoYXQgYm9keS4KCldvcmtpbmcgZ3JvdXAgaXRlbXM6CgogICogWUFORyBtb2RlbCBmb3Ig TlRQdjQKICAqIGludGVybGVhdmVkIG1vZGUgZm9yIE5UUHY0CiAgKiBhbHRlcm5hdGl2ZSBjbG9j ayBzZWxlY3Rpb24gYWxnb3JpdGhtcwogICogTlRTIGZvciBQVFAKICAqIE5UUHY1IHJlcXVpcmVt ZW50cwogICogTlRQdjUgc3BlY2lmaWNhdGlvbihzKQogICogcm91Z2h0aW1lIHNwZWNpZmljYXRp b24KClsxXSAiSUVFRSBTdGFuZGFyZCBmb3IgYSBQcmVjaXNpb24gQ2xvY2sgU3luY2hyb25pemF0 aW9uIFByb3RvY29sIGZvcgogICAgTmV0d29ya2VkIE1lYXN1cmVtZW50IGFuZCBDb250cm9sIFN5 c3RlbXMsIiBpbiBJRUVFIFN0ZCAxNTg4LTIwMTkKICAgIChSZXZpc2lvbiBvZiBJRUVFIFN0ZCAx NTg4LTIwMDgpICwgcHAuMS00OTksIDE2IEp1bmUgMjAyMCwKICAgIGRvaTogMTAuMTEwOS9JRUVF U1RELjIwMjAuOTEyMDM3Ni4KCk1pbGVzdG9uZXM6CgpUQkQKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29y a0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3Jr Cg== From nobody Fri Nov 5 13:39:02 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC633A0DE9 for ; Fri, 5 Nov 2021 13:39:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163614474174.27687.6816073549037997487@ietfa.amsl.com> Date: Fri, 05 Nov 2021 13:39:01 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 20:39:02 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2021-12-02 Reviewer LC end Draft Samuel Weiler 2021-08-25 draft-ietf-alto-path-vector Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto For telechat 2021-12-16 Reviewer LC end Draft David Mandelberg R2021-10-14 draft-ietf-tsvwg-rfc4960-bis Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 David Mandelberg R2021-10-14 draft-ietf-tsvwg-rfc4960-bis Adam Montville 2021-11-23 draft-eggert-bcp45bis Russ Mundy 2021-10-26 draft-ietf-rum-rue Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Yoav Nir 2021-11-17 draft-ietf-oauth-iss-auth-resp Magnus Nystrom 2021-11-16 draft-ietf-acme-authority-token Hilarie Orman 2021-11-15 draft-ietf-lsr-yang-isis-reverse-metric Radia Perlman 2021-11-15 draft-ietf-dispatch-javascript-mjs Derrell Piper 2021-11-26 draft-ietf-lamps-samples Vincent Roca 2021-11-15 draft-ietf-dhc-dhcpv6-yang Kyle Rose 2021-11-23 draft-ietf-i2nsf-nsf-facing-interface-dm Rich Salz 2021-11-19 draft-ietf-tls-external-psk-guidance Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Samuel Weiler 2021-08-25 draft-ietf-alto-path-vector Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Liang Xia 2021-03-17 draft-ietf-core-sid Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Kathleen Moriarty 2021-10-25 draft-ietf-dots-multihoming Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Next in the reviewer rotation: Joseph Salowey Rich Salz Stefan Santesson Benjamin Schwartz Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Tina Tsou From nobody Fri Nov 5 14:23:17 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CF63A0FB6; Fri, 5 Nov 2021 14:23:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Mandelberg via Datatracker To: Cc: draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163614739072.15769.17894970681813473446@ietfa.amsl.com> Reply-To: David Mandelberg Date: Fri, 05 Nov 2021 14:23:10 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-tsvwg-rfc4960-bis-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 21:23:11 -0000 Reviewer: David Mandelberg 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 summary of the review is Ready with nits. (nit) I thought section 5.1.3 was going to have an example of what "reasonably frequently" means? From nobody Fri Nov 5 14:41:03 2021 Return-Path: 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 EC1D63A0F48; Fri, 5 Nov 2021 14:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 zc8RlxzTGrxr; Fri, 5 Nov 2021 14:40:57 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E033A1019; Fri, 5 Nov 2021 14:40:55 -0700 (PDT) Received: from smtpclient.apple (ip4d15f695.dynamic.kabel-deutschland.de [77.21.246.149]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 32908721BE008; Fri, 5 Nov 2021 22:40:49 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Michael Tuexen In-Reply-To: <163614739072.15769.17894970681813473446@ietfa.amsl.com> Date: Fri, 5 Nov 2021 22:40:48 +0100 Cc: secdir@ietf.org, draft-ietf-tsvwg-rfc4960-bis.all@ietf.org, last-call@ietf.org, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <163614739072.15769.17894970681813473446@ietfa.amsl.com> To: David Mandelberg X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-tsvwg-rfc4960-bis-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 21:41:02 -0000 > On 5. Nov 2021, at 22:23, David Mandelberg via Datatracker = wrote: >=20 > Reviewer: David Mandelberg > Review result: Has Nits >=20 > 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. >=20 > The summary of the review is Ready with nits. >=20 > (nit) I thought section 5.1.3 was going to have an example of what = "reasonably frequently" means? Revision 17 (to be submitted once possible again) will contain: The secret key SHOULD be changed reasonably frequently (e.g., hourly), I guess this will address this issue. Best regards Michael >=20 >=20 From nobody Sat Nov 6 12:11:01 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1503A0D2F; Sat, 6 Nov 2021 12:10:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Samuel Weiler via Datatracker To: Cc: alto@ietf.org, draft-ietf-alto-path-vector.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163622585572.5175.16258030882995270903@ietfa.amsl.com> Reply-To: Samuel Weiler Date: Sat, 06 Nov 2021 12:10:55 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-alto-path-vector-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2021 19:10:56 -0000 Reviewer: Samuel Weiler Review result: Ready This and the prerequisite doc, draft-ietf-alto-unified-props-new, seem to adequately call out differences v. base ALTO (rfc7285). I'm somewhat concerned about the building of what's looking like an overlay routing system protected only by pairwise relationships between the parties rather than by authenticating the data (as BGPsec aims to do), but that's a much broader architectural concern, which does not directly impact this extension. From nobody Sat Nov 6 15:06:56 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 662733A11A7; Sat, 6 Nov 2021 15:06:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: draft-ietf-oauth-iss-auth-resp.all@ietf.org, last-call@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163623641036.23265.3678140155645804989@ietfa.amsl.com> Reply-To: Yoav Nir Date: Sat, 06 Nov 2021 15:06:50 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-oauth-iss-auth-resp-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2021 22:06:51 -0000 Reviewer: Yoav Nir Review result: Ready 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 draft is clear and well-written. The Security Considerations section specifically is comprehensive and clear. My one suggestion would be to move the first paragraph in the Security Considerations section to the Introduction. It is about the attack and about the protocol in the document being effective against the attack. It's not really a consideration in the way that the rest of the section is. From nobody Mon Nov 8 08:55:12 2021 Return-Path: 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 313DF3A11FA; Mon, 8 Nov 2021 08:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 B5S8fTF0TMNF; Mon, 8 Nov 2021 08:55:08 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8425C3A11F8; Mon, 8 Nov 2021 08:55:08 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id 8so14244871qty.10; Mon, 08 Nov 2021 08:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=4o3ZQha1hI821XxvyFgwtI5TZZa0YvPd+9fPkv1ramw=; b=PPJGfR/Of/UvZZXrogczWv19EItuww0Q55j+kKH1IvJW9FLrczy0ymy5oQp6naDDFI KZgOo5tvqFzJFlYXvv1AQIDgcY2SQsicddRO6ZMkkcd9V3YyuCZLoH0hJmhNNt025K4/ uye9qKbKDBkH5p1IBnQ84155Wdu7yThoDjfW5g8SLd8r+1QkmlKRn6+dJLew4WNtCWRV /KqDfG+Q5zkKPVyBFJMr7ZVYZ8jlot3//0t/naF0TS935u1magPFAQ1mhvWAIqPCJtlm G5WaJ5w3Ngc0a76mBkuYAA++0boesVgkGFL7m4mO26CrM7QR14/Zv4wz2OjEMpMNwtdZ 9vwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=4o3ZQha1hI821XxvyFgwtI5TZZa0YvPd+9fPkv1ramw=; b=8K9xjO8LRIao2nSgtCCkXbi72WEvj5YnTZ1pQ9hyYwz4OMuidn5DqwCEVc0xphlJ6z B4ZqqhGJqqbSUuuO4GxSfFE6/bhx0no8v3N+opadH1nXng7/G12OTMh11r89AZ0bSz9+ nzwi7t1EdKHEA7FSUirkogX54nbhOFHKk4zq8Dakd56LfniEEFtJowkhtBfYsrBuT8nZ 7lZSXtE02QRIl83S4U8ne0GB8E8MKj6hA7w+rIzL7sBAwOdwXtqElfzm4EF8ES7CRjq+ vtj8rZ/nzbmMsC2w9hUkw4noTdoDjxB5OLBLPuAtx/3MWcf90yDL5Vcu4rNY409HrJdE IN2w== X-Gm-Message-State: AOAM533hX1du5dM1ukPrycDfBxMoNhj80EFkyAVCu43cPTNRlDFLvRrF PCLKqjZxqsA1cJG7i8JsrK0= X-Google-Smtp-Source: ABdhPJwrvs9wgSyVNdCdQdzaqobkhYMLoaXC6zlYQ1HwLKaEFEnnHhjtz+QgUsnuRLo9mnlwNs5GYw== X-Received: by 2002:ac8:59cb:: with SMTP id f11mr954541qtf.99.1636390506735; Mon, 08 Nov 2021 08:55:06 -0800 (PST) Received: from [192.168.1.149] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id b20sm11538649qtx.89.2021.11.08.08.55.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 08:55:06 -0800 (PST) Message-ID: <2f1455f9-f4a9-995d-3496-900d8f495cc8@gmail.com> Date: Mon, 8 Nov 2021 11:55:05 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Catherine Meadows , secdir@ietf.org Cc: draft-ietf-calext-ical-relations.all@ietf.org, last-call@ietf.org, calsify@ietf.org References: <163527417024.2618.2790897732112692791@ietfa.amsl.com> From: Michael Douglass In-Reply-To: <163527417024.2618.2790897732112692791@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-calext-ical-relations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 16:55:10 -0000 On 10/26/21 14:49, Catherine Meadows via Datatracker wrote: > Reviewer: Catherine Meadows > Review result: Has Issues > > This draft describes increases the expressive and scope of relationships that > can be defined in iCalendar. It updates the already existing RELATED-TO by > allowing UID and URI as values and introduces a GAP parameter to specify the > length of time between two events. It also introduces three new properties: > CONCEPT (roughly, category), LINK (typed reference to external meta-data or > related resources), and REFID(used to identify a key that identifies all > components that use that REFID). The syntax of the relationships is given and > intended use cases are described. > > The introduction of greater expressiveness does not by itself introduce > security considerations, but the introduction of references to external sources > does, specifically for URIs, which are allowed as arguments of the RELATED-TO, > CONCEPT, and LINK properties. The authors of this document are aware of this, > and refer the reader to [RFC3986] for more information. I agree that the > security considerations related to use of URIs proposed in this draft are > covered by this RFC. > > I wonder though, if the document shouldn’t concern a similar warning about the > data type REFERENCE. This refers to an XML document or a portion of an XML > document. Since XML can also be used as an attack vector, a mention in the > Security Considerations Section would seem appropriate. I agree with the sentiment. I thought it would be easy to find a document with such a section - however the XML spec itself doesn't have a security section. There is at least section 20.6 in RFC4918 (WebDAV) which talks about external entities. Perhaps something like this: When the value is a REFERENCE type the targeted data is an XML document or portion thereof. Consumers need to be aware of the security issues related to XML processing - in particular those related to XML entities. See RFC4918 - Section 20.6 > > > From nobody Wed Nov 10 13:25:30 2021 Return-Path: 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 4587D3A13D5; Wed, 10 Nov 2021 13:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1UbHmn5I0t6o; Wed, 10 Nov 2021 13:25:26 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6F83A1102; Wed, 10 Nov 2021 13:25:22 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3EF1228B003B; Wed, 10 Nov 2021 16:25:17 -0500 (EST) Received: from [127.0.0.1] (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id ECB981F8051; Wed, 10 Nov 2021 16:25:16 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Mundy Date: Wed, 10 Nov 2021 16:25:16 -0500 Cc: Russ Mundy , iesg@ietf.org, draft-ietf-rum-rue.all@ietf.org X-Mao-Original-Outgoing-Id: 658272316.264374-c4606b5b81424d05f388cf68e8959203 Content-Transfer-Encoding: quoted-printable Message-Id: <91F48DF5-102D-48C5-B1EB-018A25D2DE2B@tislabs.com> To: secdir@ietf.org X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: [secdir] Secdir Last Call assignment: draft-ietf-rum-rue X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 21:25:28 -0000 Reviewer: Russ Mundy Review result: Almost Ready 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 Interoperability Profile for Relay User Equipment = (draft-ietf-rum-rue-09) document is well structured and written as well = as providing very understandable information about the Video Relay = Service (VRS) and the Relay User Equipment (RUE). Although I have very = limited exposure to this technology area, the functional aspects of this = profile seem well thought out and described in the draft.=20 As an Interoperability Profile, I don't find it surprising that there is = absence of specific (or even general) security requirements in the = current draft. However, this may result in interoperability challenges = because RUE and VRS make different choices with respect to the (50+) = normative references particularly with respect to security = implementations. For example, RFC 7575 defines an "opportunistic = security" scenario that might (or might not) be appropriate for some of = the RUE activities perhaps anonymous calls as described in 5.2.1. Also, = it might (or might not) be acceptable for implementations to negotiate = the use of earlier versions of TLS or cryptographic algorithms for some = (or none) of the capabilities defined in sections 5 through 10 of the = draft. These sections (5 - 10) describe a sufficiently different set of = functions that it seems as though some of them might have different = security requirements but no specifics security requirements (besides = the use of TLS and HTTPS), it would be useful to state the security = requirements for each of the sub sections. Although I think that it would be useful to include other security = details, identifying at least the basic security requirements that must = be provided for each of the defined sub-sections in sections 5 -10 of = the draft seems essential. I.e., does each one of the functions require = Authentication, Confidentiality and Integrity as defined in section 1 of = RFC 8446 (or another RFC) or do some of the defined capabilities only = require a subset of these security services? Or do some of the defined = functions need something different? Identifying the specific security services required for each of the = defined sub-sections would provide more useful information for = implementors and deployers who will depend on this specification as well = as more consistent security properties in the deployments. Regards, Russ From nobody Thu Nov 11 07:02:18 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1223A0788 for ; Thu, 11 Nov 2021 07:02:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163664293174.23228.8810029688299970617@ietfa.amsl.com> Date: Thu, 11 Nov 2021 07:02:12 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2021 15:02:13 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2021-12-02 Reviewer LC end Draft Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Magnus Nystrom 2021-11-16 draft-ietf-acme-authority-token Hilarie Orman 2021-11-15 draft-ietf-lsr-yang-isis-reverse-metric Radia Perlman 2021-11-15 draft-ietf-dispatch-javascript-mjs Derrell Piper 2021-11-26 draft-ietf-lamps-samples Vincent Roca 2021-11-15 draft-ietf-dhc-dhcpv6-yang Kyle Rose 2021-11-23 draft-ietf-i2nsf-nsf-facing-interface-dm Joseph Salowey 2021-11-24 draft-ietf-bess-srv6-services Rich Salz 2021-11-19 draft-ietf-tls-external-psk-guidance Stefan Santesson 2021-11-23 draft-eggert-bcp45bis Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Benjamin Schwartz 2021-11-24 draft-ietf-spring-segment-routing-policy Yaron Sheffer 2021-11-23 draft-ietf-netconf-sztp-csr Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Liang Xia 2021-03-17 draft-ietf-core-sid Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Kathleen Moriarty 2021-10-25 draft-ietf-dots-multihoming Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Next in the reviewer rotation: Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Tina Tsou Sean Turner Loganaden Velvindron Mališa Vučinić Carl Wallace Samuel Weiler From nobody Thu Nov 11 12:09:02 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF563A0CBB; Thu, 11 Nov 2021 07:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1636646114; bh=kwt6dp6vvxPFmldsJMwB8PUd2QzxkIAtitnYk4ApqHU=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=Fyngs0PbOF0lZJthNDf00JgK6+e0R0dc1pvxUIX+SSni4k5Rht75w0HJkHaR7ei+e Xb3sZR9P2Rs5yNex56cBv9K7rc7QT5W+44tt+24WkJzOq80A5ihkA0/nLa5o5nxEJ+ 3DlTVoMqxzfKBEMkyJlEl8y51rvMz2ZJXw0rh8Jg= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Nov 11 07:55:09 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E069B3A0C9F; Thu, 11 Nov 2021 07:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1636646108; bh=kwt6dp6vvxPFmldsJMwB8PUd2QzxkIAtitnYk4ApqHU=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=fhD7T3D5CeJGu3SSSFWANt94/by4aJnUin8NIZCYJRuBJ/qPfi29zQYFd3o9yUIYJ xUQkP25u766BsXw44sdJJRQ2k8l8H7aT7rTvRWrR8DNOPWtmNAvje4QyFqGHF4K/me MFdd7gBl84X3qgp3Sy4gV+eoDsDLZ+a3rs5LDJOI= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A82D3A0A5E for ; Thu, 11 Nov 2021 07:55:02 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <163664610208.13531.5818872413978168145@ietfa.amsl.com> Date: Thu, 11 Nov 2021 07:55:02 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 11 Nov 2021 12:09:01 -0800 Subject: [secdir] [new-work] WG Review: Delay/Disruption Tolerant Networking (dtn) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2021 15:55:22 -0000 The Delay/Disruption Tolerant Networking (dtn) WG in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-11-21. Delay/Disruption Tolerant Networking (dtn) ----------------------------------------------------------------------- Current status: Active WG Chairs: Edward Birrane Rick Taylor Secretaries: Adam Wiethuechter Assigned Area Director: Zaheduzzaman Sarker Transport Area Directors: Martin Duke Zaheduzzaman Sarker Mailing list: Address: dtn@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/dtn Archive: https://mailarchive.ietf.org/arch/browse/dtn/ Group page: https://datatracker.ietf.org/group/dtn/ Charter: https://datatracker.ietf.org/doc/charter-ietf-dtn/ The Delay/Disruption Tolerant Networking (DTN) Working Group specifies mechanisms for data communications in the presence of long delays and/or intermittent connectivity. The Working Group has published the Bundle Protocol v7 (BPv7), corresponding Bundle Protocol Security protocol (BPSec) and an interoperable Security Context, and the TCP Convergence Layer specifications as standards track RFCs. Multiple independent implementations exist for these technologies in both space and terrestrial environments, and the technology is now used in production by government and commercial organizations world-wide. This Working Group now focuses on the further work relevant to the area of Delay/Disruption Tolerant Networking, dividing work items into 3 broad categories: * An architecture for Naming, Addressing and Forwarding The Bundle Protocol v7 defines an encoding of Names for use in DTN, but the detailed semantics have not been specified. The Working Group will define a common architecture for the delay/disruption tolerant assignment of names, and the late-binding of such names during bundle forwarding to end-points within a DTN. This architecture will define a standard model for the forwarding process of a Bundle Process Agent, providing an informational reference point for further specifications. The Working Group charter intentionally excludes topics related to Routing in DTNs. This does not preclude discussion of the subject, in coordination with the Routing Area, but no Working Group documents will be adopted under this charter. * The definition of architecture and protocols in the areas of Operations, Administration and Management (OAM), and Key Management Current DTN deployments rely on the use of pre-placed keys and configuration or bespoke tooling, and there is a growing demand for standards to improve the automation and reliability of DTN management. Existing IETF protocols for OAM and Key Management generally rely on a bi-directional end-to-end path between devices, and in Delay/Disruption Tolerant Networks (DTNs) such paths rarely exist. To enable OAM and Key Management in such cases, there may be a need to standardize an architecture supporting alternative methods and their supporting protocols and data models. The Working Group will liaise with relevant experts in the OPS Area to discover if there are existing standards that meet, or may be extended to meet, the DTN use-cases before standardizing new protocols. There is also believed to be cross-over between the use-cases for OAM and Key Management in DTNs and the use-cases in Mobile Ad-hoc Networks (MANETs); to this end the Working Group will coordinate with the MANET Working Group to explore potential synergies and avoid duplication of effort. * Extensions to and best practices for existing protocols Extensions to the Bundle Protocol to enable reliability signalling, tunnelling and Quality of Service indication are needed for the operational deployment of Delay/Disruption Tolerant Networks, and these capabilities will be standardized by the Working Group. Additional extensions to the Bundle Protocol, additional Security Context definitions for BPSec, and new Convergence Layer adaptors will be considered on a case-by-case basis by the working group. The Working Group will also document best practices learned from existing deployment. The Working Group will coordinate with other IETF Working Groups, especially in the Security, Routing, Operation and Management Areas, to ensure the quality of peer review, the avoidance of duplication of effort, and alignment with specifications produced in other Working Groups. ============================================= Proposed milestones: * Naming and Addressing Architecture document * Neighbor/Peer Discovery protocol specification * Delay-Tolerant Management Architecture and Protocols * Key Management protocol specification * Bundle progress signalling extension to Bundle Protocol specification * Bundle-in-Bundle Encapsulation extension to Bundle Protocol specification * Quality of Service/Flow indication extension to Bundle Protocol specification Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Nov 11 21:39:08 2021 Return-Path: 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 96AD13A1250; Thu, 11 Nov 2021 21:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 32aI0_3hv9jz; Thu, 11 Nov 2021 21:39:00 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E8D3A124F; Thu, 11 Nov 2021 21:38:57 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id v65so9815963ioe.5; Thu, 11 Nov 2021 21:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Bx9kmC/lsTO7WyVsXkjIiCqwmTqup2xPe2+OJqeqS6Q=; b=emln1Kkq9HRLIt0GTYbkt+Wz7aaiufyoC+HvD10PHW5yrVlbMsXjDX7slaZTQOzBcQ ow+odWVEjtGh2Z3Nnkr4MsdFi3y4vK74S0O3quNTEqwRSMKBU51D/tS7LYbrGcug6z9Y h0j+YmfmDBIUI/qYWNtjUVn+84m4X0AJXC1UsDDISmoS++41SylPebW5jGVu3ZPwNnWr eS3uSSOeXWzWl7nzUc6ov0nEeFdBf+SaV3XMrtssYcaHaZNJDLNOhCyaIbQz6Uum7Xsq zuftsfj8gkAwikypA8eGo16FBMHXcRRjcrMIsCM9S012i4QZF7Y1Qxx2FRlP019Y47f5 l4/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Bx9kmC/lsTO7WyVsXkjIiCqwmTqup2xPe2+OJqeqS6Q=; b=sPogtMcSACxGc1yBSf3g+O7WAoORXCmUUFeeo1MWvyFFdebFNqd0xBYo2b1X7uw/Ut K2oGPnrm9ixIUDgu7OWqN0wAYY9LFkxs632K/laKgM/HzN3k7x3SOAHhFke9nAFC0KUZ 1gpQhnxzp5LX+z17/KxCpUOyqYr2LjewRMh+U3KyardXlrwfzghcIe/nq1cO6edGbaZ/ ylJDBFRc5AlOJwfkym4sPg6uNe4oRyifUCE5SxsJIsm1LUQ3xm/CIM3i4PyGqg6JRFDO VITgK6R7gKQoChWn0hjdYUbEWheSznCzVuHlfLV7+1Yx6gdwEfVf3BxdXutEAb6kSssM HjRQ== X-Gm-Message-State: AOAM530nZfMCuqQIRyNkDEk1hjtxxnTXT+Q/QV/f0Qaqwmou2eWI+a4g Fhl9RqsqJp/Dc6Kr5LWHC/8yy/DLzAjyv8vAIVcNGtT75XM= X-Google-Smtp-Source: ABdhPJy7mbbXm/fFrKSF6OvT02F1T1kYQBYXGWdKRaLbj8H66FvX9yTdgGTSb7dgRTBKWiU2QqBjm1GRY2O8/WyDMa8= X-Received: by 2002:a05:6638:11cb:: with SMTP id g11mr9248266jas.139.1636695535559; Thu, 11 Nov 2021 21:38:55 -0800 (PST) MIME-Version: 1.0 From: Radia Perlman Date: Thu, 11 Nov 2021 21:38:44 -0800 Message-ID: To: secdir@ietf.org, The IESG , draft-ietf-dispatch-javascript-mjs.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000000a87905d090e0aa" Archived-At: Subject: [secdir] Secdir review of draft-ietf-dispatch-javascript-mjs-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2021 05:39:02 -0000 --00000000000000a87905d090e0aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Review result: Ready 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. This INFORMATIONAL document is intended to replace RFC 4329 (also INFORMATIONAL), updated to reflect current practice. The biggest change appears to be recommending that javascript, when embedded in html, should use the tag =E2=80=9Ctext/javascript=E2=80=9D rather than =E2=80=9Capplicat= ion/javascript=E2=80=9D while acknowledging that the two should be considered to be synonyms (along with text/ecmascript, text/javascript1.0, text/javascript1.1, text/javascript1.2, text/javascript1.3, text/javascript1.4, text/javascript1.5, text/jscript, text/livescript, text/x-javascript, text/x-ecmascript, application/x-javascript, application/x-ecmascript, and application/ecmascript). Security considerations notes that embedding javascript in html is dangerous and implementers should take care to see nothing bad happens. --00000000000000a87905d090e0aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Review result: Ready

=C2=A0

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being process= ed by the IESG.=C2=A0 These comments were written primarily for the benefit of th= e security area directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments.

=C2=A0

This INFORMATIONAL document is intended to replace RFC 4329 (also INFORMATIONAL), updated to reflect current practice. The biggest chan= ge appears to be recommending that javascript, when embedded in html, should u= se the tag =E2=80=9Ctext/javascript=E2=80=9D rather than =E2=80=9Capplication/= javascript=E2=80=9D while acknowledging that the two should be considered to be synonyms (along with =C2=A0text/ecmascript, text/javascript1.0, text/javascript1.1, text/javascript1.2, text/javascript1.3, text/javascript1.4, text/javascript= 1.5, text/jscript, text/livescript, text/x-javascript, text/x-ecmascript, application/x-javascript, application/x-ecmascript, and application/ecmascript).

=C2=A0

Security considerations notes that embedding javascript in html is dangerous and implementers should take care to see nothing bad happ= ens.

=C2=A0

--00000000000000a87905d090e0aa-- From nobody Fri Nov 12 09:23:47 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D73A0EC7; Fri, 12 Nov 2021 09:23:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derrell Piper via Datatracker To: Cc: draft-ietf-lamps-samples.all@ietf.org, last-call@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163673781866.8407.3431051894946455628@ietfa.amsl.com> Reply-To: Derrell Piper Date: Fri, 12 Nov 2021 09:23:38 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-samples-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2021 17:23:39 -0000 Reviewer: Derrell Piper Review result: Ready 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 summary of the review is Ready. As noted in the Document History, this switches SHA512 to SHA1 as the MAC checksum in PKCS#12 objects to interop. with Keychain Access on macOS. From nobody Mon Nov 15 07:00:43 2021 Return-Path: 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 709733A11A7 for ; Mon, 15 Nov 2021 07:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, 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=hackmanit.de 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 4rKyhvqWqi5x for ; Mon, 15 Nov 2021 07:00:30 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A24F3A0EC9 for ; Mon, 15 Nov 2021 07:00:07 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id m14so73504928edd.0 for ; Mon, 15 Nov 2021 07:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit.de; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=a5MNx1HQ3iIZwnVAD8+fk+au55T8VD8VFiN9WjVuud4=; b=nVTgCCZUP64/ezxc8onmdYpo7tTPhKHd/Kw9lzuHMyuVVUgoDZjaPZuo1rLIi8qzL6 Kv01ByN8tZaQVJLdFzoNQTYGn+03wEl44O2hfvDiRB+xzEKlMXqUUpHJO9+li/7M/dtm dH7IGroZhHE0Pr0i2cOtdJt/PmQa/ecFRATD0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=a5MNx1HQ3iIZwnVAD8+fk+au55T8VD8VFiN9WjVuud4=; b=mW5bSBJe1t8jIONHL7sPkgtVD6BaYh/UaJANGzQNS1trOzYsMLQBkyClWXf6HC+2j9 FFFWEvgvf8T4Pm1MXRTf2X3YTyX+2wgJCOuDAmBZyqqPritnie9W4vZ6VAR/AmGiKc7G ZFpYM3mqa403yiz0enEylsiz4X5WS4//d+5Qyd2c3CeWfwd95T+zjEtsitZvh+CuQrUg 0T2M/nDOytRCyDIAe6nAP60Sq31EYb+IIACHvGj7SSWw5NU7McPWA355qyJzRQT7D1kM XB/QxDm+Ts7fc79nfC9amdrY6NHarSU1KLklDNPFy156mmo3MXATsQY4pLb8YK3NK4lJ o7Ug== X-Gm-Message-State: AOAM533ytZHkvgDi1Riv56mk9QwrPGDddk5pEg5b070kQTEWCfO9EgyX D2/covJCiL5DyY27r/vPKJtJjA== X-Google-Smtp-Source: ABdhPJwXsFqsgHB5tIKNIYF1pZOfri8f5nyWPdomrrjuPTIKwxxodbtfWoAYfIACVGtmosGKKC1+ZA== X-Received: by 2002:a17:906:270e:: with SMTP id z14mr50425727ejc.414.1636988400552; Mon, 15 Nov 2021 07:00:00 -0800 (PST) Received: from [10.10.11.6] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id m25sm5756706edj.80.2021.11.15.06.59.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Nov 2021 06:59:59 -0800 (PST) Message-ID: <31c1d296-b53a-4480-9ea4-2293e8b31410@hackmanit.de> Date: Mon, 15 Nov 2021 15:59:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Yoav Nir , secdir@ietf.org Cc: draft-ietf-oauth-iss-auth-resp.all@ietf.org, last-call@ietf.org, oauth@ietf.org References: <163623641036.23265.3678140155645804989@ietfa.amsl.com> From: Karsten Meyer zu Selhausen In-Reply-To: <163623641036.23265.3678140155645804989@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------YKuBJaS0bhNCFV6aSZ3n7EBR" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-oauth-iss-auth-resp-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 15:00:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------YKuBJaS0bhNCFV6aSZ3n7EBR Content-Type: multipart/mixed; boundary="------------iQosQtsEaocx22M0QZTh0SpN"; protected-headers="v1" From: Karsten Meyer zu Selhausen To: Yoav Nir , secdir@ietf.org Cc: draft-ietf-oauth-iss-auth-resp.all@ietf.org, last-call@ietf.org, oauth@ietf.org Message-ID: <31c1d296-b53a-4480-9ea4-2293e8b31410@hackmanit.de> Subject: Re: Secdir last call review of draft-ietf-oauth-iss-auth-resp-02 References: <163623641036.23265.3678140155645804989@ietfa.amsl.com> In-Reply-To: <163623641036.23265.3678140155645804989@ietfa.amsl.com> --------------iQosQtsEaocx22M0QZTh0SpN Content-Type: multipart/alternative; boundary="------------70QUJxzyTDB3ydLnUsnSbUl8" --------------70QUJxzyTDB3ydLnUsnSbUl8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgWW9hdiwNCg0KdGhhbmsgeW91IGZvciB5b3VyIHN1Z2dlc3Rpb24uIFdlIHRoaW5rIGl0 cyBhIHZhbGlkIHBvaW50IGFuZCBmb2xsb3dlZCANCml0IGluIGEgbG9jYWwgYnJhbmNoLg0K DQpCZXN0IHJlZ2FyZHMsDQpLYXJzdGVuDQoNCk9uIDA2LjExLjIwMjEgMjM6MDYsIFlvYXYg TmlyIHZpYSBEYXRhdHJhY2tlciB3cm90ZToNCj4gUmV2aWV3ZXI6IFlvYXYgTmlyDQo+IFJl dmlldyByZXN1bHQ6IFJlYWR5DQo+DQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0KPiBlZmZv cnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhl IElFU0cuICBUaGVzZQ0KPiBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0 aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuDQo+ICAgRG9jdW1l bnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBq dXN0IGxpa2UgYW55IG90aGVyDQo+IGxhc3QgY2FsbCBjb21tZW50cy4NCj4NCj4gVGhlIGRy YWZ0IGlzIGNsZWFyIGFuZCB3ZWxsLXdyaXR0ZW4uIFRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uDQo+IHNwZWNpZmljYWxseSBpcyBjb21wcmVoZW5zaXZlIGFuZCBjbGVh ci4NCj4NCj4gTXkgb25lIHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gbW92ZSB0aGUgZmlyc3Qg cGFyYWdyYXBoIGluIHRoZSBTZWN1cml0eQ0KPiBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRv IHRoZSBJbnRyb2R1Y3Rpb24uIEl0IGlzIGFib3V0IHRoZSBhdHRhY2sgYW5kIGFib3V0DQo+ IHRoZSBwcm90b2NvbCBpbiB0aGUgZG9jdW1lbnQgYmVpbmcgZWZmZWN0aXZlIGFnYWluc3Qg dGhlIGF0dGFjay4gSXQncyBub3QNCj4gcmVhbGx5IGEgY29uc2lkZXJhdGlvbiBpbiB0aGUg d2F5IHRoYXQgdGhlIHJlc3Qgb2YgdGhlIHNlY3Rpb24gaXMuDQo+DQo+DQotLSANCkthcnN0 ZW4gTWV5ZXIgenUgU2VsaGF1c2VuDQpTZW5pb3IgSVQgU2VjdXJpdHkgQ29uc3VsdGFudA0K UGhvbmU6CSs0OSAoMCkyMzQgLyA1NDQ1NjQ5OQ0KV2ViOglodHRwczovL2hhY2ttYW5pdC5k ZSAgfCBJVCBTZWN1cml0eSBDb25zdWx0aW5nLCBQZW5ldHJhdGlvbiBUZXN0aW5nLCBTZWN1 cml0eSBUcmFpbmluZw0KDQpJcyB5b3VyIE9BdXRoIG9yIE9wZW5JRCBDb25uZWN0IGFwcGxp Y2F0aW9uIHZ1bG5lcmFibGUgdG8gbWl4LXVwIGF0dGFja3M/IEZpbmQgb3V0IG1vcmUgb24g b3VyIGJsb2c6DQpodHRwczovL3d3dy5oYWNrbWFuaXQuZGUvZW4vYmxvZy1lbi8xMzItaG93 LXRvLXByb3RlY3QteW91ci1vYXV0aC1jbGllbnQtYWdhaW5zdC1taXgtdXAtYXR0YWNrcw0K DQpIYWNrbWFuaXQgR21iSA0KVW5pdmVyc2l0w6R0c3N0cmHDn2UgNjAgKEV4emVudGVyaGF1 cykNCjQ0Nzg5IEJvY2h1bQ0KDQpSZWdpc3RlcmdlcmljaHQ6IEFtdHNnZXJpY2h0IEJvY2h1 bSwgSFJCIDE0ODk2DQpHZXNjaMOkZnRzZsO8aHJlcjogUHJvZi4gRHIuIErDtnJnIFNjaHdl bmssIFByb2YuIERyLiBKdXJhaiBTb21vcm92c2t5LCBEci4gQ2hyaXN0aWFuIE1haW5rYSwg UHJvZi4gRHIuIE1hcmN1cyBOaWVtaWV0eg0KDQo= --------------70QUJxzyTDB3ydLnUsnSbUl8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Yoav,=

thank you for your suggestion. We think its a valid point and followed it in a local branch.

Best regards,
Karsten

On 06.11.2021 23:06, Yoav Nir via Datatracker wrote:
= 
Reviewer: Yoav Nir
Review result: Ready

I have reviewed this document as part of the security directorate's ongoi=
ng
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area dire=
ctors.
 Document editors and WG chairs should treat these comments just like any=
 other
last call comments.

The draft is clear and well-written. The Security Considerations section
specifically is comprehensive and clear.

My one suggestion would be to move the first paragraph in the Security
Considerations section to the Introduction. It is about the attack and ab=
out
the protocol in the document being effective against the attack. It's not=

really a consideration in the way that the rest of the section is.



--=20
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	htt=
ps://hackmanit.de | IT Security Consulting, Penetration Testing, Secu=
rity Training

Is your OAuth or OpenID Connect application vulnerable to mix-up attacks?=
 Find out more on our blog:
https:=
//www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-agains=
t-mix-up-attacks

Hackmanit GmbH
Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
--------------70QUJxzyTDB3ydLnUsnSbUl8-- --------------iQosQtsEaocx22M0QZTh0SpN-- --------------YKuBJaS0bhNCFV6aSZ3n7EBR Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEDtqqxgHePX8hI3D4RTXA59sW8UgFAmGSde8FAwAAAAAACgkQRTXA59sW8Ug2 yA//R88i0GW3mlF+619vuZ8ab2EjWpplLtLgwfYbGuTBbDgIC6F2fQps0RXZT1B25Jojp/fdEFQ0 mSJrFP4ehnNLe2PMHjJkNX4Tuwq1KyApR6OOmchbrGO78fr9f8C7KYUclAfNigf/27G8tAYezEMV v0m/meKS8BsHWyfyxPkQNza1lgrwLj67oJERTYtr9NZheWf2HWg+JnsbfyWgsikfm81npbjuBxxH CU0sJg9oZHZ8tfVTANFeu8Lnm2KA84+PDlVbuvZ3Vn969InPbjbxOLm0jUPJsdq9nKumdAKXUxU2 8uugao2m3Hk4uQHDn5qoA9uEBd0nk2vP9sTmjrqly2svZ3QCMjFlVckePWWKtHSsD+ysyjb9dAwP F0M4Rgz8Y8xXp84OZ2yD6ewnGloAvIhFU31WFBeumh7gBCm1cJC0SGwDeAzZ6QcpgQYjsJrsfBTE 85in8KJwacpp7ldG13Z8I5yQLKASfom+x4wrbFxFn7WLkt+gJ5gZzq6tfwjJ9+NNC3Htrc5PxANz PpolQX6xLo92ojrSfulGjf1U/v0HE7x27AFGbQwtGXea0y+T0KOU9or45oz+Uy9GYKQPj75OiRVF Vh5ZUK2w4SChYhXXS8yMOm2ZY+hAuy13KyTYShH0+vKsqPrsvGN8L6ELhaZh5bMnatKxTk51CWQ2 JzY= =fmYc -----END PGP SIGNATURE----- --------------YKuBJaS0bhNCFV6aSZ3n7EBR-- From nobody Mon Nov 15 10:15:23 2021 Return-Path: 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 364E93A0FD1; Mon, 15 Nov 2021 10:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jSv3H4kMJJqH; Mon, 15 Nov 2021 10:15:15 -0800 (PST) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (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 E0CF33A0FCC; Mon, 15 Nov 2021 10:15:11 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]:55616) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mmgVY-004gql-IC; Mon, 15 Nov 2021 11:15:08 -0700 Received: from [166.70.232.207] (port=60182 helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mmgVX-000XQq-Ai; Mon, 15 Nov 2021 11:15:08 -0700 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 1AFIDQu5002873; Mon, 15 Nov 2021 11:13:26 -0700 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id 1AFIDQkh002872; Mon, 15 Nov 2021 11:13:26 -0700 Date: Mon, 15 Nov 2021 11:13:26 -0700 Message-Id: <202111151813.1AFIDQkh002872@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-lsr-yang-isis-reverse-metric.all@ietf.org X-XM-SPF: eid=1mmgVX-000XQq-Ai; ; ; mid=<202111151813.1AFIDQkh002872@rumpleteazer.rhmr.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=pass X-XM-AID: U2FsdGVkX1/bXkPXrM6ajkXTCA7U7XLE X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-Virus: No X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *******;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 259 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.7 (1.4%), b_tie_ro: 2.5 (1.0%), parse: 0.58 (0.2%), extract_message_metadata: 2.4 (0.9%), get_uri_detail_list: 0.56 (0.2%), tests_pri_-1000: 1.96 (0.8%), tests_pri_-950: 1.04 (0.4%), tests_pri_-900: 0.90 (0.3%), tests_pri_-90: 61 (23.7%), check_bayes: 60 (23.2%), b_tokenize: 3.3 (1.3%), b_tok_get_all: 4.0 (1.6%), b_comp_prob: 1.27 (0.5%), b_tok_touch_all: 49 (19.0%), b_finish: 0.63 (0.2%), tests_pri_0: 175 (67.7%), check_dkim_signature: 0.34 (0.1%), check_dkim_adsp: 14 (5.6%), poll_dns_idle: 10 (3.9%), tests_pri_10: 2.8 (1.1%), tests_pri_500: 7 (2.7%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Subject: [secdir] Security directorate review of draft-ietf-lsr-yang-isis-reverse-metric-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 18:15:17 -0000 Security review of YANG Module for IS-IS Reverse Metric draft-ietf-lsr-yang-isis-reverse-metric-04 Do not be alarmed. I generated this review of 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract (with typo noted): This document defines a YANG module for managing the reverse metric extension to the Intermediate System to Intermediate System intra- domain routeing information exchange protocol (IS-IS). ^ The spelling error seems to have been copied from ISO Standard 10589:2002. There's no need to continue propagating it. The draft has a decent discussion of security considerations regarding the privacy of the information expressed in the data. The document is READY. Hilarie From nobody Mon Nov 15 10:41:13 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA99B3A07CC; Mon, 15 Nov 2021 10:41:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: draft-ietf-tls-external-psk-guidance.all@ietf.org, last-call@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163700166290.13984.13464784184351879479@ietfa.amsl.com> Reply-To: Rich Salz Date: Mon, 15 Nov 2021 10:41:02 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tls-external-psk-guidance-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 18:41:03 -0000 Reviewer: Rich Salz Review result: Has Nits I'm the SECDIR reviewer for this document. This is a TLS WG draft, so everyone reading this should know what that means. If not, ask. :) As the opening sentence says, "This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446." PSKs are useful and important for those who do not wish to deploy a PKI or for whom symmetric trust is useful. I like section 4.1 which goes into detail about the problems with sharing keys among more than two parties. Section 6 is a good summary of use-cases with references. These sections should prove as valuable as section 7, which is presumably the heart of the document. Section 7.1 is not common for an IETF RFC, and shows evidence that the authors have some scars from experiments or deployments. It is nice to see. Section 8 says "The unique identifier can, for example, be one of its MAC addresses..." I thought we are moving away from that and I would prefer to see an explicit justification of why this is okay. I think this is a nit-level issue, and the only one I found. I also do suggest, however, that the draft be sent to the UTA working group and ask for comments from them as they're more application-focused like this document it. From nobody Mon Nov 15 12:41:24 2021 Return-Path: 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 C56623A0952 for ; Mon, 15 Nov 2021 12:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=sn3rd.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 PpA2hUX_M0iY for ; Mon, 15 Nov 2021 12:41:08 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8C43A0945 for ; Mon, 15 Nov 2021 12:41:08 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id j63so13925861qkd.2 for ; Mon, 15 Nov 2021 12:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dmca+GeJ+oD9/T+XardZURXZd5SQKzqEfkS4xLe9nsM=; b=YrwawxYeB6kuom79fh59m4a/PKlBpfWIF+P2djsbeaNVGE4aiwv6PB6qwKGPFEx8PI O5Hc9sJ7jzPHAkPxtl9T6ucvykGIy59hAarXqqBBc4PkhW3/pZAkHE3YwYJ9xnIhmIAc VXxCkZ7ZS25HqR/oHayAc6/KP2JHwq9mLnKgg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dmca+GeJ+oD9/T+XardZURXZd5SQKzqEfkS4xLe9nsM=; b=XFcVRFFAwIKRZsrEwoTnJRaqn+FIOZLpg+E6Veglx3flIs+rrvBXFEmHKeTxE2bo5t bWbvi/F3oYRs6rlGMqJ/flSJomcoxR9c7QlFDu0JRkIPNBR2jRo/LW6v10lWhJBVyt5F JvzaxHHWRzSL/uu1FpWCoBJRGAAcxVgq8KV+J+krlXhRh4zrFu0PDsA1/zQbdmtxkMka 5TvhCZl9vZS2vL4YnZrreVHr33+wysXIHIE87oWlLdZol0XgnWw29PtAgTvNEO/bJYUb iq+YmGPIsAQc920ka7uQxGkrz8O2AEowU/6XtgiTQY3I/DN/kUmfbB6ij0BB3TjS32IQ drew== X-Gm-Message-State: AOAM531j+Fh+dAjCa8U3nFvZxL1CYOeiq2/sd72o45WdDrgY+VSK8Qud CxYffYtDSFChqb3PtBoy1VNXsQ== X-Google-Smtp-Source: ABdhPJznRkXTmepOTON1UanC2/Id16vG7qB0dvjU+Y+3Da3o0B7Ee86IloUr5GanItImWEd9Ry20GQ== X-Received: by 2002:a05:620a:1a11:: with SMTP id bk17mr1674568qkb.394.1637008867024; Mon, 15 Nov 2021 12:41:07 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id s16sm7727478qko.82.2021.11.15.12.41.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Nov 2021 12:41:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: <163700166290.13984.13464784184351879479@ietfa.amsl.com> Date: Mon, 15 Nov 2021 15:41:05 -0500 Cc: secdir@ietf.org, draft-ietf-tls-external-psk-guidance.all@ietf.org, last-call@ietf.org, TLS List Content-Transfer-Encoding: quoted-printable Message-Id: <31F1F829-84EA-4CCE-8C21-F5C5AC799A40@sn3rd.com> References: <163700166290.13984.13464784184351879479@ietfa.amsl.com> To: Rich Salz X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-external-psk-guidance-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 20:41:14 -0000 Hi! I submitted an issue to track this review: https://github.com/tlswg/external-psk-design-team/issues/80 spt > On Nov 15, 2021, at 13:41, Rich Salz via Datatracker = wrote: >=20 > Reviewer: Rich Salz > Review result: Has Nits >=20 > I'm the SECDIR reviewer for this document. This is a TLS WG draft, so = everyone > reading this should know what that means. If not, ask. :) >=20 > As the opening sentence says, "This document provides usage guidance = for > external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 = as > defined in RFC 8446." >=20 > PSKs are useful and important for those who do not wish to deploy a = PKI or for > whom symmetric trust is useful. I like section 4.1 which goes into = detail about > the problems with sharing keys among more than two parties. Section 6 = is a good > summary of use-cases with references. These sections should prove as = valuable > as section 7, which is presumably the heart of the document. >=20 > Section 7.1 is not common for an IETF RFC, and shows evidence that the = authors > have some scars from experiments or deployments. It is nice to see. >=20 > Section 8 says "The unique identifier can, for example, be one of its = MAC > addresses..." I thought we are moving away from that and I would = prefer to > see an explicit justification of why this is okay. I think this is a = nit-level > issue, and the only one I found. >=20 > I also do suggest, however, that the draft be sent to the UTA working = group and > ask for comments from them as they're more application-focused like = this > document it. >=20 >=20 >=20 From nobody Mon Nov 15 14:21:35 2021 Return-Path: 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 489D33A0BCC; Mon, 15 Nov 2021 14:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CsF23V0I; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=p3bu0H/8 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 GWBTn94HVEZ2; Mon, 15 Nov 2021 14:21:19 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E753A0BC8; Mon, 15 Nov 2021 14:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1984; q=dns/txt; s=iport; t=1637014879; x=1638224479; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GGOjYLs7gt180L2ofvJUC6usvgYSwQZXroVOm2Jh2s8=; b=CsF23V0IncOxxhWaVdWhD0I0Yp304dmdHn8ZLRnBwWWedh0RU+UdGl8u lH/Jyyf5biDNlDSvLl+wedir75Y/wrpl/QUlL31el2wf4u66G16RcZF+r FtJpgzdsD29VNBCBsmPqV5yELMCWn/WFPeuiTbkXCO9mWaQzC8yy9NoE2 A=; IronPort-PHdr: =?us-ascii?q?A9a23=3AhIvZQRy2BSeu1l3XCzPZngc9DxPP8534PQ8Qv?= =?us-ascii?q?5wgjb8GMqGu5I/rM0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJX?= =?us-ascii?q?gUO3MMRmQFoCcWZCEr9efjtaSFyHMlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv?= IronPort-Data: =?us-ascii?q?A9a23=3AxViL26+UCBJ3tOumk+pwDrUDdnyTJUtcMsCJ2?= =?us-ascii?q?f8bNWPcYEJGY0x3zDEeXz3Qa/iDYDPyetolYIS+9x4GsZ/dndI2QQs9/39EQ?= =?us-ascii?q?iMRo6IpJzg2wmQcns+qw0aqoHtPt63yUfGdapBrJpPgjk31aOG49CAhjfvgq?= =?us-ascii?q?ofUUYYoBAggHWeIdw954f5Ts7ZRbr9A2bBVMSvU0T/Bi5W31Gue5tJBGjl8B?= =?us-ascii?q?5RvB/9YlK+aVDsw5jTSbB3Q1bPUvyF94Jk3fcldI5ZkK7S4ENJWR86bpF241?= =?us-ascii?q?mrd+xFoAdS/n/OrNEYLWbXVewOJjxK6WYD73UME/XJ0i/19baZFAatUo23hc?= =?us-ascii?q?9RZwd5AuLS7SBwiOevHn+F1vxxwQnwkYfMdoOSWSZS4mYnJp6HcSFPg2fxgE?= =?us-ascii?q?AQ3MJEWv+JsGyRf/PoXbTEWbwvGne+ozaigR6xpi9g5LcKtNYcbknBt0T+fC?= =?us-ascii?q?uwpKbjYTq7G5MVw3TosiIZJB/m2T8sUcjVHbRncbVtIIFh/IJI/mO6yh3TXa?= =?us-ascii?q?yBCsFaYvrYt7mHQigd21dDQ3HD9EjCRbcxRmkDdrWXc8iGpRBobL9eYjzGC9?= =?us-ascii?q?xqRaib0tXuTcOov+HeQr5aGWGGu+1E=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AnwVg/qxPuF/911e1fJtHKrPxfOgkLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBepTiBUJPwJk81bfZOkMks1MSZLX?= =?us-ascii?q?fbUQyTXcJfBOrZsnzd8kjFltK1up0QCJSWZOeAaGSSyPyKnDVQcOxQguVvkp?= =?us-ascii?q?rY/9s2pk0FJWoBBs0QjHYaNu/YKDwKeOAsP+teKHPo3Ls+m9PWQwVvUi3UPA?= =?us-ascii?q?hgY8Hz4/nw0L72ax8PABAqrCOUiymz1bL8Gx+Emj8DTjJm294ZgC34uj28wp?= =?us-ascii?q?/mn+Cwyxfa2WOWxY9RgsHdxtxKA9HJotQJKw/rlh2jaO1aKvm/VXEO0aaSAW?= =?us-ascii?q?QR4YDxSiQbTpxOArTqDzqISC7Wqk/dOfAVmiXfIBGj8CbeSIfCNUMH4oJ69P?= =?us-ascii?q?Jkm13imhYdVBUW6tMU44pf3KAnUi8o1R6NleQhHXtR5zmJiGtnnugJg3NFV4?= =?us-ascii?q?wCLLdXsIwE5UtQVIwNBSTg9ekcYaVT5eznlbxrmGmhHj3kV6hUsaqRd2V2Gg?= =?us-ascii?q?3DTlkJu8ST3TQTlHdlz1EAzMhamnsb7poyR5RN+uyBa81T5f9zZ95Tabg4CP?= =?us-ascii?q?YKQMOxBGCISRXQMHiKKVCiEK0cIXrCp5P+/b1w7uC3f54Dyoc0hf36IRxlnH?= =?us-ascii?q?93f1irBdyF3ZVN/ByISGKhXS71wsUb/JR9sq2UfsuhDcRCciFnryKNmYRqPi?= =?us-ascii?q?TrYYf7BHsNOY6XEYLHI/c/4zHD?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmCACB3JJh/40NJK1agQmBWYFSUQe?= =?us-ascii?q?BUTcxhEeDRwOFOYUOgwKbD4JTA1QLAQEBDQEBQQQBAYUEAheCSwIlNwYOAQI?= =?us-ascii?q?EAQEBEgEBBQEBAQIBBgSBEROFaA2GQwIBAxIREQwBATcBDwIBCBoCJgICAjA?= =?us-ascii?q?VEAIEAQ0FIoJPglYDLwFQn1cBgToCih96gTGBAYIIAQEGBASFChiCNQmBECq?= =?us-ascii?q?DDIQchwQnHIINgRQBJwwQgmc+h103gi6QQDYBAxSBIIEDLwIXlW+pIAqDOZ8?= =?us-ascii?q?CBS2nLJYUH6VkAgQCBAUCDgEBBoEwRyWBWXAVZQGCPlEZD44sFoNQil50OAI?= =?us-ascii?q?GAQoBAQMJkgwBAQ?= X-IronPort-AV: E=Sophos;i="5.87,237,1631577600"; d="scan'208";a="952463039" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Nov 2021 22:21:17 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 1AFMLHWe031886 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 15 Nov 2021 22:21:17 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 15 Nov 2021 16:21:17 -0600 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 15 Nov 2021 16:21:16 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 15 Nov 2021 16:21:16 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EaUH4YIGlkmGlD9Gic7OuG/j3DWzVKofdoJQARzbfiYweB4CpJa91m6Wt1MwdcycGuAt6Yh6ws14Ijk93mPkdNi8plXsQlyYFxee4GlXUsm43a9E1iWlP6Wov8UokkeHsgqveYdZ9hPlfrwOdO44DUyTpyLMH2ylxbAke69vY3hUxkGzQ/d7Mhuv5S24KSPZkPYoRhG9FjlAIApOTS03KLFzMwAhTFAFqVJqj7AHEUyfOyTw5L7YGOmMKDLzT7D3LGkb4RsbO7t3nSKX2T1hG05vWO6gcGyewAWcoL2rOK326ZJexIU+62ZFHwEWr0T+4sukGq5CYtUS70WnpqKFww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GGOjYLs7gt180L2ofvJUC6usvgYSwQZXroVOm2Jh2s8=; b=iXAwCDIjKcBxFDqKrnHtgSRkSWA62wbygy85e4Vp3joXG4WMWBdKUSdvGStyLGskz6JBtg11vktZH+ls4s+Kfa4eEBr/Nztyt6KlMwrERrxROmI4EnVzUtsRq+RxkO2yiTWDJY5GG1rQKbEAfSkM5QvD9on+k/QZGjgKThBAd4NyIQ9OrNoJjC0M5RGY9H9u1GBOepefnPi+/rFJ7vXnSZNlXCXRIbG4KtUMT5e64mave5wzeqDiUwltxyr11V7wSO8c8KGcpTdTYBniOUgDEECnUR1YHPLNuhHGks64SdJNsz4DC8hGO2ZhW9AhxVuxMREXtOENl67N8gWvzVIj/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GGOjYLs7gt180L2ofvJUC6usvgYSwQZXroVOm2Jh2s8=; b=p3bu0H/8W5Abmj7f7FMOzHOr+m3r7/Zh60njjpf+FhGXgcH3PTvzKaLlEpbTm4USpsv1YNb8oGG58ksztu5XijnburAJ6sBs1sOkt0P4Z6bSC1oFjCbK25Ae9KnSbVKvIPDKDZzI2cLi5K5Sr++SDDVlW38vcb3zeVWxxDyvvpo= Received: from BL0PR11MB2884.namprd11.prod.outlook.com (2603:10b6:208:72::25) by BL0PR11MB3123.namprd11.prod.outlook.com (2603:10b6:208:7b::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.15; Mon, 15 Nov 2021 22:21:13 +0000 Received: from BL0PR11MB2884.namprd11.prod.outlook.com ([fe80::a5ed:5b5b:79ad:9c67]) by BL0PR11MB2884.namprd11.prod.outlook.com ([fe80::a5ed:5b5b:79ad:9c67%7]) with mapi id 15.20.4690.027; Mon, 15 Nov 2021 22:21:11 +0000 From: "Acee Lindem (acee)" To: Hilarie Orman , "iesg@ietf.org" , "secdir@ietf.org" CC: "draft-ietf-lsr-yang-isis-reverse-metric.all@ietf.org" Thread-Topic: Security directorate review of draft-ietf-lsr-yang-isis-reverse-metric-04 Thread-Index: AQHX2kzCTzlE/Fo62k+xv/gbtNjlyKwE1cKA Date: Mon, 15 Nov 2021 22:21:11 +0000 Message-ID: <355CA216-A282-4391-BB46-DB27C637CA50@cisco.com> References: <202111151813.1AFIDQkh002872@rumpleteazer.rhmr.com> In-Reply-To: <202111151813.1AFIDQkh002872@rumpleteazer.rhmr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.54.21101001 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6ed92a00-1c53-41a7-9308-08d9a8863ade x-ms-traffictypediagnostic: BL0PR11MB3123: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RMICThvnHYO5u6PsWZKGKEhMQCkBvMUEJw1dhS9FCEMb/LHcOHINPSyNAwXYVKvVQTvGZraxBPV4l1JyCxMifoGK3kXN0yOQbla5SVPx6k/Cp0PE2Gx7FHFU/93C9pZ/SOCPFhj6hcaHB6Ytce5LYKv74hOaRHWprM9OWPMzXDSNhx1mX2RkrFQ1jTd5VAJc4w60rete/J49X7x6viNG//jxOdSyCIVD2jgPkpQVHZLv0ItjT572SVbME3k+Ptqpf47fM1m+B9Tyw3AYdYNDDL9RISYcquL9gjzKMumDNhMVncpvfUArBnaBkP+PpHa8ydRV7c7OR/evMI8HEMxUmp61DWZDYZI7Ty6lfpP9ZGefYs1jd+a9upGWh1V21AVMJPzVwOdAGF8OSD2vqoiJOkkAr0n/BsbjnGxYRD4w7kfT+3SaKeAafcwRtkBBlvLwy7nxGx9ZVQ0TFN5GUKCh/hzaIAhSzoC5KDlDxCjGafNIlWDIeZlUOrcvdtYlFjvkVL0gZQ9TEvIQSp2Ov4bZr1uaS5vy39WBJCSjdZlE7eXHiedmH6bwohHZBaEkF0t5pm8yLmz76ma2RA77iLYNbE6UfbSbwD0169F1wKpcO+R6T56nsqOyRsLUVOptPHNhV3J4hZ3q7WFjXa+q6nfwFWtlYxn0iUTvq4jg8vwyZI94ppSGFd11oaI+Jwm+SCiBfHM0DZrynq2ZBdeRhVfV80nW4oZp2MkqJaImPRd1yqYgwp9zWqInXUDNuCiOv36J x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB2884.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(110136005)(38070700005)(36756003)(66476007)(26005)(186003)(76116006)(71200400001)(316002)(508600001)(6486002)(15650500001)(91956017)(2906002)(6512007)(66946007)(8676002)(2616005)(38100700002)(64756008)(5660300002)(33656002)(66446008)(83380400001)(6506007)(4326008)(8936002)(66556008)(86362001)(122000001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZU1MdXVBWkdCNlQ2L0RSME45ZnNTa1RCcEM0M1Z3c1cveDVWaGpFQUVORk9t?= =?utf-8?B?aitEL1plNUZ4TU9IRnVmTWZJaEcxWHpkNkJ2ZTBBaHA3V2dCbnkrZy8reCsx?= =?utf-8?B?cU1lNVB4a2ExaTZURjlLYVlUQzhkR0tMdlo3d0hwRXl2bDZHVU15WlorVUs5?= =?utf-8?B?WUtNL2NYcmJSeDJPOFlNWjNqdVJHaWEramhreUhPUitwQVFKMjBNNEJsT2Jv?= =?utf-8?B?dkJxK0gvd2pxL0tvU3BkUUE5NEZRamFFWVRCYnp5RFhxaU82ZTNNcFNDa2JS?= =?utf-8?B?dHFCNjV4YW5Ddkk0YjdleUpkWThTczFMelFXR2hpaGZuSzArSDhVZDNZU3do?= =?utf-8?B?ZjFiR1QrS0dJdC9tcmtBd0xjQkM5d3pmbHlKQjE5MVJxeUZRVklvV242bUdE?= =?utf-8?B?enNUMU1hcytSakcvNnRTKzUrTjdJdk9PTmQ0a3Z3TnVVNHJiWHkyWVZja3dt?= =?utf-8?B?SDFOK2RlVW9BOVRPUThxbDQ5Kys4YVViVkFxQWNuQ3IrWDhGaC9EbThQU0xi?= =?utf-8?B?dzllVGxOTGNrZi83bkJjbDloTU9xcjgyNkVUQmF0QmdScDFDRHFZaFIwT1JL?= =?utf-8?B?WmRWZy9jcU5rZlNleExrRk1XRnpuZXo2a2ZuSk0vcFdEOEVWV2k0NTBqSTlv?= =?utf-8?B?TXl4TXJCNUxJM3dnejdBUmtnajZsY0FiRTArc1pJZDFHYm1PUUd3OHIrQUJy?= =?utf-8?B?Z3ZiWkZZQlJnRFJmZnhVOXpialBYV1dOaE4vcUxIQkRGMXBZWmJPbXkyZWRK?= =?utf-8?B?Z3BSU25NL05PNzZ3UmlRdS9Ia0VhcktBS1VsZHFCVmJSNEhDM2VVNW1lVmlW?= =?utf-8?B?VE1BVllEVklYUDRzQ2FuMlRvZUQ5NE1SZ3VjUHZKS1RJQ0tWamxUYTdXRlph?= =?utf-8?B?QTFKRTljSXcxekxPSWxmcHVwMkFRd3U3OFNGcUp1bmZHU0t1eHgrSjgzeWVj?= =?utf-8?B?QnZoR2ZPZUx1UXRyeEltcVNaUjQxRVFvNmRhZ1VlZy8xMm52cC9jVDRJZ2hk?= =?utf-8?B?eTEwU2VlV25naVRSb3lYWjEwTGJNbW1ScndhZ3RzRENOaENUMDBTU2JjK3Vt?= =?utf-8?B?SnQybkdKSGZxcVQxT3MwU2I5Yjh2OXM2MThTUzIwSmdSRGg5clhLMUxuTHVT?= =?utf-8?B?d2lRQ05YYWxUWlNDMHhjaEFLU256SjdBMVZScDhSL1kwcmUzRXJOSHlIbWU1?= =?utf-8?B?WkkreC8zekZmcDBEcG9NRXVXdE9vc1I4aDBENWMyUE1xMDUwTUtzU0tRQ0pB?= =?utf-8?B?ZDdMcFlvNk93d0dRMXRtMUYrVTZuOFBiODBIcGpQcTVVa0FpMkFRWCs3OFh1?= =?utf-8?B?TUR3SXc3YUdta2o5b1dUV2dyRnkvRGJpUkoxc00yMWRxRy96RUtDaWpYNUZr?= =?utf-8?B?ZUdVSU03bWRBT2NZWG1OYi84M21vSWk5bzdzQm9rTHdEZm85QUYvOGRDVTJB?= =?utf-8?B?MmdWTkU0aUhGQTZoMG9ENnZ3RUhZZW84TGVNRUtwY2xkRnZJaUZSOVFIL2Jy?= =?utf-8?B?YWhoQkdYeTRPeUhWR2t4USs4eS8rU1UyNU1NRDBMblNjZlFFWWpJb0Q1RGk0?= =?utf-8?B?Y1hmM0RSNUx4QWt0dWRIMk5Da2tPM3hqT2ZnQTAxNEZpWVJ3MXNKT2d2QzVh?= =?utf-8?B?TG9iM0JBbkdTMytWZHZWNXZZWk96MGJHaDZPZEpsMkdYR0pBMU5KU0pja2FX?= =?utf-8?B?SEtGci9qQnNsZDdVb0xPOWVORmo1OXpia0diL25DZjE4Rjc5bzdMWHFUNWFE?= =?utf-8?B?WElCQnBGMFBndDFNa1ZxR2UveE9YalNRc3ROYlBEZmthcW9SdHd3amJEYjdX?= =?utf-8?B?bUN4aDJKMEZjWWhzVCtTNXBXbHZuRjNTaDN6eDJwWEZRTUJjSjdWdFFkZWdy?= =?utf-8?B?c3FaQVQvcEVTNVBKRFlIbkV6bFl6eFlod01LNjcvS0F5TFQ4bGxHUmtVQVl4?= =?utf-8?B?OGw0emkzZ2UxSGdCM3B1dmw5dm4relhtVWE3b1htR205QjRwS1J2ODQwaVho?= =?utf-8?B?eXBVdkt2SGdZZGtOWHVYTXFkVm5XTFdzRWRCRXQ2TTRxSFlFUDZCbUo0aEJV?= =?utf-8?B?TjQ3YTNUYzBRV3pOcmxKMUdNR0lMeGxXNnRodjFLOHJzdXY4bDN1eEtHdytj?= =?utf-8?Q?TY3Q=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <4A47C6D74EC881469E5B631A85780F05@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB2884.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ed92a00-1c53-41a7-9308-08d9a8863ade X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2021 22:21:11.4925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2gvJiMzZPUp6CasNhlzOv1QxkEGITAVtMenyowFW+q5sY1QDq93cR5UQ43D1/xJl X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3123 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [secdir] Security directorate review of draft-ietf-lsr-yang-isis-reverse-metric-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 22:21:34 -0000 U3BlYWtpbmcgYXMgRG9jdW1lbnQgU2hlcGhlcmQ6DQoNCkhpIEhpbGFyaWUsIA0KDQrvu79PbiAx MS8xNS8yMSwgMToxNSBQTSwgIkhpbGFyaWUgT3JtYW4iIDxoaWxhcmllQHB1cnBsZXN0cmVhay5j b20+IHdyb3RlOg0KDQogICAgCSBTZWN1cml0eSByZXZpZXcgb2YgWUFORyBNb2R1bGUgZm9yIElT LUlTIFJldmVyc2UgTWV0cmljDQogICAgCSBkcmFmdC1pZXRmLWxzci15YW5nLWlzaXMtcmV2ZXJz ZS1tZXRyaWMtMDQNCg0KICAgIERvIG5vdCBiZSBhbGFybWVkLiAgSSBnZW5lcmF0ZWQgdGhpcyBy ZXZpZXcgb2YgdGhpcyBkb2N1bWVudCBhcyBwYXJ0DQogICAgb2YgdGhlIHNlY3VyaXR5IGRpcmVj dG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGDQogICAgZG9jdW1lbnRz IGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRl bg0KICAgIHdpdGggdGhlIGludGVudCBvZiBpbXByb3Zpbmcgc2VjdXJpdHkgcmVxdWlyZW1lbnRz IGFuZCBjb25zaWRlcmF0aW9ucw0KICAgIGluIElFVEYgZHJhZnRzLiAgQ29tbWVudHMgbm90IGFk ZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGluY2x1ZGVkDQogICAgaW4gQUQgcmV2aWV3cyBk dXJpbmcgdGhlIElFU0cgcmV2aWV3LiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzDQog ICAgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBj YWxsIGNvbW1lbnRzLg0KDQogICAgVGhlIGFic3RyYWN0ICh3aXRoIHR5cG8gbm90ZWQpOg0KDQog ICAgICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBtb2R1bGUgZm9yIG1hbmFnaW5nIHRo ZSByZXZlcnNlIG1ldHJpYw0KICAgICAgIGV4dGVuc2lvbiB0byB0aGUgSW50ZXJtZWRpYXRlIFN5 c3RlbSB0byBJbnRlcm1lZGlhdGUgU3lzdGVtIGludHJhLQ0KICAgICAgIGRvbWFpbiByb3V0ZWlu ZyBpbmZvcm1hdGlvbiBleGNoYW5nZSBwcm90b2NvbCAoSVMtSVMpLg0KICAgICAgICAgICAgICAg ICAgXg0KICAgIFRoZSBzcGVsbGluZyBlcnJvciBzZWVtcyB0byBoYXZlIGJlZW4gY29waWVkIGZy b20gSVNPIFN0YW5kYXJkIDEwNTg5OjIwMDIuDQogICAgVGhlcmUncyBubyBuZWVkIHRvIGNvbnRp bnVlIHByb3BhZ2F0aW5nIGl0Lg0KDQpUaGlzIGNvdWxkIGJlIHNhaWQgZm9yIG1hbnkgdGhpbmdz IGluIElTLUlTIGJ1dCB0aGF0IGhhcyBuZXZlciBkaXNzdWFkZWQgdXMuIF9fDQoNClRoYW5rcywN CkFjZWUNCg0KICAgIFRoZSBkcmFmdCBoYXMgYSBkZWNlbnQgZGlzY3Vzc2lvbiBvZiBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyByZWdhcmRpbmcNCiAgICB0aGUgcHJpdmFjeSBvZiB0aGUgaW5mb3Jt YXRpb24gZXhwcmVzc2VkIGluIHRoZSBkYXRhLg0KDQogICAgVGhlIGRvY3VtZW50IGlzIFJFQURZ LiAgDQoNCg0KICAgIEhpbGFyaWUNCg0K From nobody Mon Nov 15 21:02:13 2021 Return-Path: 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 9FBA33A0812; Mon, 15 Nov 2021 21:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FZn15hWkhXIa; Mon, 15 Nov 2021 21:02:07 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544823A080F; Mon, 15 Nov 2021 21:02:07 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id i9so19038122ilu.8; Mon, 15 Nov 2021 21:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=r1HqioDdwxXybZzUxDaAG4dmFYJIAIZfcK/hZI41MqI=; b=YyaGGwrlXGm8+A6dFwJnuA0nqfy8M7+zKuVTK6X9iLSkb6tbSN2oy926iwNO4Nw5nV yRufHN/V+cJIcpRuhbmkTxETGyubd/ZpbkJhmEwZjCEW5e5xUbIYIfvRALWm6Fza5WLA oGam+Tgo4Hdae9zxK6d0kZRJm6S2m7xz3oVGzDSJR1G7HF2rrPuz0xoerfOoHykUwuHp 2uL+lgw3/eczcfUcI/1YBVUx2lclljQ29wKbG6ZOZjN+FUshN8X4dTYfWovPhKnbH2WV 4TFn0i5jfmhCMqccPi9+C6grnp2e1w/kp/2dvULADYmcCqYiBfUR1RvguWr5kHz7/Pon gc4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=r1HqioDdwxXybZzUxDaAG4dmFYJIAIZfcK/hZI41MqI=; b=vYHfzBMKfZ7/kPf0FLbdCTsCV/+9nIzERwNZ0TlMk0aUuzMEUl81bbAIwkIT6VNpES jXoNPAQ4FKzoIchGCkfdBPC7ByoIsu8P5KJ3tOOG+cICugw6FxQni9EjG6jvTPe7C85M 0D+gbGySPJET7QHytUQXPvs9LVWEapZl3ut0Sih6i0iHI+sWiuliMQjuBuwSZgTPO/Wv qjTwUwAnsInV8nOKxCtAJA01Cq6jaOz/iFMBgTnQh+n8zzwMPssmgmY+jFCz7ZyBZMN9 v607onajb71TU7QRggD5YQpSWpihdCOxcpBOBCyD2Gb+NJ5jze1vcVnHuRc0RYh4Vann edNA== X-Gm-Message-State: AOAM532TpA1eN+qFYPH9YV19GMvm0rFT1ZUQVvwIed/sTQVE8JOlzAJG dNc+0IWBYyh5ZE20C95lr+gU+39Bba3Ui1RoQ01mI3Z1 X-Google-Smtp-Source: ABdhPJyErcZXeRNUtw4L9crZMFi1qpoQoCj5Azwn4A3XlGuIvIL5NYZ281k7+dvv2A8lkdF4iJsjxC21LHSfMdLNk5s= X-Received: by 2002:a05:6e02:1c8f:: with SMTP id w15mr2584617ill.147.1637038925478; Mon, 15 Nov 2021 21:02:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Mon, 15 Nov 2021 21:01:54 -0800 Message-ID: To: secdir@ietf.org, draft-ietf-acme-authority-token@ietf.org Content-Type: multipart/alternative; boundary="000000000000a2fdb105d0e0d3d6" Archived-At: Subject: [secdir] Secdir review of draft-ietf-acme-authority-token X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 05:02:12 -0000 --000000000000a2fdb105d0e0d3d6 Content-Type: text/plain; charset="UTF-8" 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 comments. This document describes use of "authority tokens" in the context of ACME, their purpose, use and format. The document is straightforward and the Security Considerations section seems adequate.Generally, iIt may help readers to include a summary of all the options and any recommended values. for the tokens, e.g. lifetime of issued tokens. For the Security Considerations section, shouldn't mandated supported algorithms and key sizes be specified? Editorial: The document is in need of a grammar / wording polish but I expect the rfc-editors to handle this.For example, "defines a the" in the Introduction section, and "in the way" in Section 5.1. Thanks, -- Magnus -- -- Magnus --000000000000a2fdb105d0e0d3d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div class=3D"gmail_quote">
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors.=C2=A0 Document editors and WG chairs should treat these comments just= like any other comments.

This document describes use of "authority tokens&q= uot; in the context of ACME, their purpose, use and format.

<= /div>
The document is straightforward and the Security Considerations s= ection seems adequate.Generally, iIt may help readers to include a summary = of all the options and any recommended values. for the tokens, e.g. lifetim= e of issued tokens. For the Security Considerations section, shouldn't = mandated supported algorithms and key sizes be specified?
Editorial: The document is in need of a grammar = / wording polish but I expect the rfc-editors to handle this.For example, &= quot;defines a the" in the Introduction section, and "in the way&= quot; in Section 5.1.

= Thanks,
-- Mag= nus




--
-- Magnus
--000000000000a2fdb105d0e0d3d6-- From nobody Tue Nov 16 17:54:06 2021 Return-Path: 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 F05A13A07B8; Tue, 16 Nov 2021 17:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 4gLmt9TgW7GI; Tue, 16 Nov 2021 17:53:56 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 21B493A07BC; Tue, 16 Nov 2021 17:53:54 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1AH1rlLe019003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Nov 2021 20:53:51 -0500 Date: Tue, 16 Nov 2021 17:53:46 -0800 From: Benjamin Kaduk To: Michael Douglass Cc: Catherine Meadows , secdir@ietf.org, draft-ietf-calext-ical-relations.all@ietf.org, last-call@ietf.org, calsify@ietf.org Message-ID: <20211117015346.GI93060@kduck.mit.edu> References: <163527417024.2618.2790897732112692791@ietfa.amsl.com> <2f1455f9-f4a9-995d-3496-900d8f495cc8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2f1455f9-f4a9-995d-3496-900d8f495cc8@gmail.com> Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-calext-ical-relations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 01:54:00 -0000 Hi Michael, Catherine, Catherine -- thanks for the review! Michael -- thanks for the proposed text. It's certainly better than nothing, and we could iterate further if needed. In particular, I wonder if we actually want to duplicate some of the considerations from RFC 3986 that also apply to XML references, such as the lack of a stability guarantee that fetching the referred-to resource will actually produce the same results over time and for all entities that might be performing the fetch operation. Thanks, Ben On Mon, Nov 08, 2021 at 11:55:05AM -0500, Michael Douglass wrote: > > On 10/26/21 14:49, Catherine Meadows via Datatracker wrote: > > Reviewer: Catherine Meadows > > Review result: Has Issues > > > > This draft describes increases the expressive and scope of relationships that > > can be defined in iCalendar. It updates the already existing RELATED-TO by > > allowing UID and URI as values and introduces a GAP parameter to specify the > > length of time between two events. It also introduces three new properties: > > CONCEPT (roughly, category), LINK (typed reference to external meta-data or > > related resources), and REFID(used to identify a key that identifies all > > components that use that REFID). The syntax of the relationships is given and > > intended use cases are described. > > > > The introduction of greater expressiveness does not by itself introduce > > security considerations, but the introduction of references to external sources > > does, specifically for URIs, which are allowed as arguments of the RELATED-TO, > > CONCEPT, and LINK properties. The authors of this document are aware of this, > > and refer the reader to [RFC3986] for more information. I agree that the > > security considerations related to use of URIs proposed in this draft are > > covered by this RFC. > > > > I wonder though, if the document shouldn’t concern a similar warning about the > > data type REFERENCE. This refers to an XML document or a portion of an XML > > document. Since XML can also be used as an attack vector, a mention in the > > Security Considerations Section would seem appropriate. > > I agree with the sentiment. I thought it would be easy to find a > document with such a section - however the XML spec itself doesn't have > a security section. There is at least section 20.6 in RFC4918 (WebDAV) > which talks about external entities. Perhaps something like this: > > When the value is a REFERENCE type the targeted data is an XML document > or portion thereof. Consumers need to be aware of the security issues > related to XML processing - in particular those related to XML entities. > See RFC4918 - Section 20.6 > > > > > > > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview From nobody Wed Nov 17 00:41:38 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 400D13A0AF3; Wed, 17 Nov 2021 00:41:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Roca via Datatracker To: Cc: dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-yang.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163713848820.18649.9224727643938761782@ietfa.amsl.com> Reply-To: Vincent Roca Date: Wed, 17 Nov 2021 00:41:28 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dhc-dhcpv6-yang-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 08:41:28 -0000 Reviewer: Vincent Roca Review result: Not Ready Hello, 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. Summary: Not Ready The Security Considerations section is globally well written, with links to appropriate documents. However, a few clarifications would be welcome IMHO. It is said: "An attacker who is able to access the DHCPv6 server" (resp. relay). It's not just a matter of accessing the server (resp. relay). As I understand it's more a matter of taking the control of the server (resp. relay), which is different. Please clarify. Then, the current text only mentions "denial of services" among the possible consequences. DoS are rapidly identified and fixed, and anyway, an attacker having full control on the DHCP server has other options to launch a DoS. I'd be more concerned by subtle attacks that could be used to exfiltrate sensitive information (maybe by redirecting to a rogue server?), or to create excessive traffic (maybe by changing the valid-lifetime?), or to create subtle dysfunctions (e.g., assigning the same IP to different clients), etc. Another example: an attacker may gather information about clients, network topology and network devices (e.g., by looking at the OUI part of the MAC address). Such information can be highly helpful when preparing an orchestrated attack towards a target company. If this is simplified by the YANG based configuration in some way (I think so but you have a better understanding than me), then it's worth mentioning. To summarize, I have the feeling the current text could better illustrate some of the consequences of attacks, beyond DoS attacks. Minor comments: - Section 5: remove "a" or "the" in: "changing the address of a the DNS server" - Section 5: "re-configuring messages" is ambiguous. I think "forwarding messages to a rogue server after modifying the 'server-address'" (I think this is what is meant) would be more appropriate. - intro: "...which is applicable device's interfaces." May be: "applicable to ..." - intro, 1st paragraph: You should choose to either expand both NETCONF and RESTCONF acronyms, or none of them. Cheers, Vincent From nobody Wed Nov 17 01:07:18 2021 Return-Path: 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 589AF3A0B30; Wed, 17 Nov 2021 01:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=nokia.onmicrosoft.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 Oy03z8EM-rux; Wed, 17 Nov 2021 01:07:08 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2107.outbound.protection.outlook.com [40.107.93.107]) (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 90E573A00C8; Wed, 17 Nov 2021 01:07:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kkTLTP0KkfjBRSA+anLAdqOBWF3GAk69Ejq1DEg26lIQzUv1x+Jikt78+BpnOejFdzAJ1U0CgpQOCRPg4VRphRskmpn+7o9vUZgxYiPHI8+j0RJoAbLncuC+DDPrXTpXAiWO8NH9Zz3D+lWPPvuF898MqJTXQYOJmiIS7VSTWubC/N8wKfR7ZFxC+DgZR2KssPt4IoKpJkDhTeGHjrwbpA5nU/F74xD33dEP+jNAx7iTJHHKf0Xy79XwnDvzRtr+2CHN+pL0ERUpus5j1Yw8Lw6ddo2TpClJdhi8wv7KBgHWrYrblPHeJ8CBflXu049Jtt1WanelRFDS5cQEDsr7Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=myzcfQSyjpw3DsBdDO7cxwX6MbphGVzWRUbipcmAFKs=; b=dwOIXfokAKDgxqMDwPhDqELyhC7gO1IST8F9oqFP9o1x2Jp8UrdBaLIQLN2bmsjQddsDFXcBFHkq81U2VS0zDhsI4631LZNcdmR5NTa/NMcgWGggKHBU/3KoApKbOB/1qorZCn1FRCGo2+aHOsHEKxpAiqq2IV+TzhbAxJ8Um7CRbOnqnGZY5xbZdb3MZoQnXfd6h2NHIL9gfbw/A4Ov5atgCvP0Lbo4h/1EK51X9OO91IaArulPtO2idDrxtvH6iNioWY2YywV5psrXjoeyxx6LEVOY1ZxH+Awe8BvNWRB/L4qYfR+9yzFSZd/IMgaPI2fxnfwTgKl5sA+a6lXqyg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=myzcfQSyjpw3DsBdDO7cxwX6MbphGVzWRUbipcmAFKs=; b=BzkEaIqBJM+9HJqr7IZkgPGItCGQLNwfgItmA4NnhphwZ+pjUm0CNlLZLMk4nJGr2G178WAcrvWu0aEAt7+wKbaYYqEn3rAlNjRKkwYLP4/w4DwYiT9uzYAFHifldq61e1ZygvnWlsDhRw/DR1gRQsFyqj77Qeiq6kLphpUMtHs= Received: from BY3PR08MB7060.namprd08.prod.outlook.com (2603:10b6:a03:36d::19) by BYAPR08MB3896.namprd08.prod.outlook.com (2603:10b6:a02:84::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.16; Wed, 17 Nov 2021 09:07:05 +0000 Received: from BY3PR08MB7060.namprd08.prod.outlook.com ([fe80::c481:f856:9121:e]) by BY3PR08MB7060.namprd08.prod.outlook.com ([fe80::c481:f856:9121:e%7]) with mapi id 15.20.4669.022; Wed, 17 Nov 2021 09:07:05 +0000 From: "Rabadan, Jorge (Nokia - US/Mountain View)" To: Derek Atkins , "secdir@ietf.org" CC: "bess@ietf.org" , "draft-ietf-bess-evpn-optimized-ir.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-bess-evpn-optimized-ir-09 Thread-Index: AQHXu3pZWBnJ1VT/ukeJa8VALCENH6wAL4hr Date: Wed, 17 Nov 2021 09:07:05 +0000 Message-ID: References: <163361121039.16337.12285140758441545338@ietfa.amsl.com> In-Reply-To: <163361121039.16337.12285140758441545338@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 28ae01f9-1cb7-4f08-edf1-08d9a9a9a04a x-ms-traffictypediagnostic: BYAPR08MB3896: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Bb4WTo0RjdSc3b21YpUl5TcLSQ1FPV5l393W0K3nMHxiiwUUNR5Odo3yzDD8oHG0rU+PzgHVSIiD9Dt+1ObGiKw+TCrf5HY0XtrztX6yeguNNsaiwHTztMerkGkBfm2QAb8iCZ+X/2LEm30/aU6K0LReT2Yrh4wkm6vfhxr8VsFeyDFXCPnZYPwNb/2DD38cvDvU1SO8MSEMf1MJg0KHE8p9vclinXv5nuej2HoDQUqtnehY0kMMP5HAck0aBd34PSWqt7pI47rIw0yR4MXhIeSAzA+8SaW6Qshfx1PQS4leTQC4B/mQogHeC1pOUOpWs3837LVPyUoIp49B4EdvzH2+7IAUleqzMuLjUktNLt8zDPV98TDDzdrSK8M+GKsyJFqOY3TEJwy3UtXRbobh4d79cwgsQpqeUv2E5p54xdikpcaOH4BlxdeNrvHU/2vXcyD2sYb0fVpcjBuzk/T891AYk1pkoUPQpL1iLs8aJUzk0ceTLgt4xKtdEkHwIogeFwv1ccp2R5vPRLsL42RhbjTTI7bvtes/tT6dIeIm4Rf7Xo3wZ3AFab5lveuq2KVUFjECH5rI6A2G5N7HLI+2O8Gbqm3b1AUrwOdx4cJ3ihV7ny13bmSEhDxmYNwTVWRBexEEIfShrBgBXI2oS6zmJD+3LgPWYG+MOpZ9rziZvjyPZLaWZpwqPWzHreFjx8r81BLym9Gu9J/grDtIHxEXWg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR08MB7060.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(26005)(66476007)(55016002)(86362001)(66946007)(91956017)(83380400001)(186003)(66446008)(8936002)(82960400001)(33656002)(71200400001)(66556008)(122000001)(38100700002)(7696005)(9326002)(64756008)(508600001)(52536014)(4326008)(2906002)(53546011)(5660300002)(110136005)(6506007)(316002)(38070700005)(54906003)(8676002)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?VAiEtsdJKqbEU9oZAaBeNxQN8wyHOrKU8vLxX9kn4PAPrvFMw1l1oA65ciDo?= =?us-ascii?Q?+zegeu3SHkSFfUM/iI5RcOv3ib9xhG62vvYDLg2x2DMPW75VbXz7HCOP8k3E?= =?us-ascii?Q?yNzEJ1gt32m/weZM2n7hIgPZtDPYIHgrTn90M7p8xW15gFZoCq69G0082Bgw?= =?us-ascii?Q?mU5DFPvvUEy+x0axvQvhHQ6lVJpADAOHOo/RVXByRDrnhdEHrUhF+tVAV3pD?= =?us-ascii?Q?u16jBCyhfPk5hltw840+11tMGB7WN5uDYQy5T2kdRYbxh8z4WRcSumIDHYod?= =?us-ascii?Q?wv+sOFHhYjzQv4rfDGS0CJG01UvPQpRrBMZaBRQ3K7LzpFw+8UUvCeIX67UA?= =?us-ascii?Q?Y9AYMmPED4p7d/7j8tTcCwYtNx9cK8/P6zBXz3BWlTrKXLsCSWDUCOg64uI5?= =?us-ascii?Q?Kk0a4zC8O/zs4oa28j/EG5sd9PPdp+JX2WpQZqRqcLJVdw4SNGwqveT18hyW?= =?us-ascii?Q?BU9YmuTx5pC9FHMPYGvq4YHyLBjXi+to9TN27xEKQn8oAxxR3Puqu6T1fmF6?= =?us-ascii?Q?SPSxcUlqfPmjZ6yUidEMmnIUSkXlCKHprkLfQWnsa5sMuycsFFqJvZJ8G+qT?= =?us-ascii?Q?ARTteufgMXY571i4L6CJBtBouA75/QsxNPzHvJvSXdXgdtQpjdlq8UCqKEyZ?= =?us-ascii?Q?3PDa7WuAcW6inEtCoTdhMlfraaxEDyj1ogxBrbd/njqkJVNlqXcU95PlpglS?= =?us-ascii?Q?fUfmczp0+OFSVz7RIF0ocDVZlpjRWAzzjCXkzu8r57FMNQ8nsvbZqscRZsf5?= =?us-ascii?Q?NZPFlYaux5oxABXkLYZJKh63ynIdSFttiEtMhKaE/PQo94uTjTCGg3hHYbz0?= =?us-ascii?Q?/QcP5gpTIGa5I6MNJkIYfxj8+COyvbLpWm349+YflYLTr9ORBFdupLhWBB3f?= =?us-ascii?Q?04FtIuSfW+wd8hRZ4QPa8FwY4v6tz154XQTOQZ2+G+MyGj45qt4Xcy/NitID?= =?us-ascii?Q?DKKD00pCyH8KYODFOh4Vlyd/y60ANsNVnA9ibG5rOdFhp5WkWowHzpzc1PC3?= =?us-ascii?Q?kpFEx/pD/PtkrUPfkLeEklgNtGYHFTaiNinSQmopISxSvsWnT8Sql11Km+X1?= =?us-ascii?Q?wtwaKCz1LkWIXunrmcd5+eTc7bD5/cYmO8TKTeX6QByM3H7zq0oVjjZFf4RQ?= =?us-ascii?Q?igLlVfZZ6ZCOVXdL1AeZCfjFgASCgyKraypdL626yzfNONScx9bxR3pNwy4A?= =?us-ascii?Q?DYOnfxTgQsfdajtGqlGxYA1cWkj2rEZ8n6Arirl+r+JW7OCyPY2U8xqKriD7?= =?us-ascii?Q?mo3d7tdlIQZV/RiLWvip/Vc70gUVEU/fO6cIxB+0CaNKgl7bRjQSksgDleiB?= =?us-ascii?Q?bYKOqLpdVOHxhWFPPlcqGr3Z4/xIAn8LuyWc0DGRJxK3OdH2TPjwgIhteGsw?= =?us-ascii?Q?0Nn/zF26qDUeuL07HcZujBymDGukmRDBkI5Q9Mn4u71fKAtcl2VtHorTLxqL?= =?us-ascii?Q?dde6cDAwG5N/jQv+iUlcPHM7Uh0e3KTKd1gPvJKOXX06ZtmdSVo2YsmJ9Spx?= =?us-ascii?Q?CQif38j7EkCdLxYmM2dq0r6qGKQv179iLMOGlT7P701iog/fNI9FLIeUYkss?= =?us-ascii?Q?Fa32CK++sYI8TgOVh24mjQ5dQG17jsnDpDRgRaBeTvQXxSPRrpGYk1LwjliW?= =?us-ascii?Q?j11vFKGL0kL73vuwT7Pnx6HML4A+6Ygmz5svlKNHqmS0?= Content-Type: multipart/alternative; boundary="_000_BY3PR08MB7060E2DD04FE114DEEE3F681F7959BY3PR08MB7060namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR08MB7060.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28ae01f9-1cb7-4f08-edf1-08d9a9a9a04a X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2021 09:07:05.1486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GcKyoAWSpW3/x7lzAtn19W7SWeTb0SXRuvg3cAZwzMEXWrG8KaeZO16gVGfaccKhunhpodJMTG7P+WEVLkq03Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB3896 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-evpn-optimized-ir-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 09:07:13 -0000 --_000_BY3PR08MB7060E2DD04FE114DEEE3F681F7959BY3PR08MB7060namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Derek, Thank you very much for reviewing. The Security section (along with the other sections) has been improved quit= e a bit in the latest revision compared to version 09. All in all, a forged BM packet sent into an EVPN PE will reach all the remo= te EVPN PEs of the same Broadcast Domain. The Assisted-Replication solution= makes that replication no worse than that, i.e. forged BM packets injected= into an EVPN PE acting as an AR-LEAF will be forwarded to all the remote E= VPN PE/NVEs of the same Broadcast Domain. Thanks. Jorge From: Derek Atkins via Datatracker Date: Thursday, October 7, 2021 at 2:53 PM To: secdir@ietf.org Cc: bess@ietf.org , draft-ietf-bess-evpn-optimized-ir.all@ie= tf.org , last-call@ietf.org= Subject: Secdir last call review of draft-ietf-bess-evpn-optimized-ir-09 Reviewer: Derek Atkins Review result: Ready Hi, 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to Publish Details: * It is unclear to me how one would protect from a (D)DoS attack with a forged BM packet sent into the replicator and prevent amplification attacks. -derek --_000_BY3PR08MB7060E2DD04FE114DEEE3F681F7959BY3PR08MB7060namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Derek,

 

Thank you very much for reviewing.

 

The Security section (along with the other sections) has been improved qu= ite a bit in the latest revision compared to version 09.<= /p>

 

All in all, a forged BM packet sent into an EVPN PE will reach all the re= mote EVPN PEs of the same Broadcast Domain. The Assisted-Replication soluti= on makes that replication no worse than that, i.e. forged BM packets injected into an EVPN PE acting as an AR-LEAF= will be forwarded to all the remote EVPN PE/NVEs of the same Broadcast Dom= ain.

 

Thanks.

Jorge

 

From: Derek Atkins via Datatracker <noreply= @ietf.org>
Date: Thursday, October 7, 2021 at 2:53 PM
To: secdir@ietf.org <secdir@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-evpn-optimi= zed-ir.all@ietf.org <draft-ietf-bess-evpn-optimized-ir.all@ietf.org>,= last-call@ietf.org <last-call@ietf.org>
Subject: Secdir last call review of draft-ietf-bess-evpn-optimized-i= r-09

Reviewer: Derek Atkins
Review result: Ready

Hi,

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 with the intent of improving
security requirements and considerations in IETF drafts.  Comments
not addressed in last call may be included in AD reviews during the
IESG review.  Document editors and WG chairs should treat these
comments just like any other last call comments.

Summary:

* Ready to Publish

Details:

* It is unclear to me how one would protect from a (D)DoS attack with
  a forged BM packet sent into the replicator and prevent
  amplification attacks.

-derek


--_000_BY3PR08MB7060E2DD04FE114DEEE3F681F7959BY3PR08MB7060namp_-- From nobody Wed Nov 17 02:28:22 2021 Return-Path: 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 6AC5B3A0B2A; Wed, 17 Nov 2021 02:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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=gmx.net 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 Sjgq6jHRzgtw; Wed, 17 Nov 2021 02:28:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 936013A05E2; Wed, 17 Nov 2021 02:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1637144880; bh=xdOkJ1pVF2PQT1qK6FfWPfm5tbAKu4Jg/+T65d+yAKg=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=jcT44ere/EQOC5dL25M7rc0CDdrPEAm6EAWFRGvp9kRV8tnquMWoyB9bxd/8oPkGF hVRd4kyn8VPt3p3Oi/kfaXBEuAwML6EcLG1t59+EKOwR4r869x8rifFIwPrEqhsaeA 4PT0mSZQiX6+v8nkXirDxeTP5U4dxScJXU0jJ6lg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([87.78.165.90]) by mail.gmx.net (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1Mqb1W-1mINFo1rWa-00mcV2; Wed, 17 Nov 2021 11:28:00 +0100 From: ianfarrer@gmx.com Message-Id: <83B0FF38-8180-4B5D-AE41-48E8AB7DA4A6@gmx.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6AE3DFC8-0371-4C4C-8D91-CCF8C786F9F4" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Wed, 17 Nov 2021 11:27:56 +0100 In-Reply-To: <163713848820.18649.9224727643938761782@ietfa.amsl.com> Cc: secdir@ietf.org, dhcwg , draft-ietf-dhc-dhcpv6-yang.all@ietf.org, last-call@ietf.org To: Vincent Roca References: <163713848820.18649.9224727643938761782@ietfa.amsl.com> X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Provags-ID: V03:K1:QOY1DUrITUfXVfWEaiGtXyWz+7lOaP8/GLIjhF8QUMIzm0RRM6t EMqgG+M2ukQ5y7qXcStbygTV+7YLeE+Qd4x25jXxj12hDmGenL6NM1gvoncRkyXXEYLebiz 9taGFT/AZtygt3BqPgW1EkD80il75NLgCsS86GN3O5+SgwvPD/qj5zfVUEkINmCaKdfGMZE pBsSavuwUQGRUdqRgwepw== X-UI-Out-Filterresults: notjunk:1;V03:K0:2FFhBuqrtn4=:HVx2Fs7PuTPOAz5yM4AMHg QjL4EjkEj+0LHgf8GjgEOvCXw+Hs1OQC+M1Mkxbt6RLIeopzLVkV4m4dIH8k4UUKPzb6yv8JB fbiHnqkZpWD5IK86e1m2PbwZRX7BQHxOtkTygBYn053h4ymhVF3nS4uuJbVA6mSbbE5nFAqLc k3/l/teNTYC04n+IZrE5xSiNBRR7xlK19jf4UEwRefVmn2cAafk3X8/HI4tL3N3PW0J5M65aK CwcRcpDtYL6bwtX3C817iwuzUCgGnmGSb7Y6/ps9UquLHKjskf6K70kwUyGiutx0kNnRf++Qo 2aIPodvWC9Q8d4Z3nuHmSLJ61utBDHUDeHIs95dlk1xd/crlNL5ce0Nrd0DFnU/hpgfK1vuUe hmxCUD3Ni7QI0h7D47w6IhXnXOWq5e+N6HxF4v+zXu8TN4FeE69JtOCDIYXRpAGLJG1FdXA2i D81TJ0nreHKQ4kt25JIQlqgWMqH/lyG/4sAI6Z+4pKB1cr08F58OmjBM/OEFYav1jkpSiknrc +yV2qB9Tx+0Ax/ZsT/dSZDiCgqeQiRv+UfeYif8d5mldV26J4IwODtSnn1fW4Fc9RMdF1vxrb orhLd4duDuD7UtCscOifomTKNda1rngdQgBjBEATkGjRICY58kwLbq1Jvph5Th2ErehiI4kj+ 8Bl/3A8YXsgE1BX0ByvoiGmQ+QGMTSrvaVuEgD7p8YM8k6bE7fQWZwpAXaKxk3J8/5jb6fL9j 09i1L8QOxeUr2fylsWtQm/mUM0Y75w3u+pMN86AsecJlkmRLbg2jZip/snD7aGMFViWW5/EfE VzFBtUyHgkAc/mHWyCZvrP3d2oMf2NgLerBUXAI38txjOEVZtlat6TD/VrH1/+5MQ+Y/6gMlH RvY1/aFjj4OX+Yuy1xvg68lBtq1pqA2v9FRBdAFNmdQGtlFkAu0fR/vBn9/kNhRWKRjJI+H8z j919PjAVPIkKUPHWMCQiOtTaLQFzZXm13nOvxDL2ifvtatvmO2Q0q3dnhriGVOIyyFG5T5Res WWsrDVCcwIEEEoQ8gvD0hBaeLgU0GfVJiRYf27JSExGDdB64mR7N5+Y6+Z7h7HLppozqa8A9K cBakuO+WHcA5To= Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dhc-dhcpv6-yang-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 10:28:13 -0000 --Apple-Mail=_6AE3DFC8-0371-4C4C-8D91-CCF8C786F9F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Vincent, Many thanks for your review. Please see inline below. Cheers, Ian > On 17. Nov 2021, at 09:41, Vincent Roca via Datatracker = wrote: >=20 > Reviewer: Vincent Roca > Review result: Not Ready >=20 > Hello, >=20 > I have reviewed this document as part of the security directorate=E2=80=99= 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. >=20 > Summary: Not Ready >=20 > The Security Considerations section is globally well written, with = links to > appropriate documents. However, a few clarifications would be welcome = IMHO. >=20 > It is said: "An attacker who is able to access the DHCPv6 server" = (resp. relay). > It's not just a matter of accessing the server (resp. relay). > As I understand it's more a matter of taking the control of the server = (resp. > relay), which is different. Please clarify. [if - I propose: Old: An attacker who is able to access the DHCPv6 server can undertake various attacks, such as: New: An attacker with read/write access the DHCPv6 server can undertake various attacks, such as: Same change for the relay text." ] >=20 > Then, the current text only mentions "denial of services" among the = possible > consequences. DoS are rapidly identified and fixed, and anyway, an = attacker > having full control on the DHCP server has other options to launch a = DoS. I'd > be more concerned by subtle attacks that could be used to exfiltrate = sensitive > information (maybe by redirecting to a rogue server?), or to create = excessive > traffic (maybe by changing the valid-lifetime?), or to create subtle > dysfunctions (e.g., assigning the same IP to different clients), etc. [if - The subtle attacks are properties of the DHCPv6 protocol and the = elements which provide it, rather than specifically associated with NETCONF/YANG or other methods = by which those elements are configured and managed. The text currently has: "Security considerations related to DHCPv6 are discussed in = [RFC8415].=E2=80=9D Do you think this covers it?] >=20 > Another example: an attacker may gather information about clients, = network > topology and network devices (e.g., by looking at the OUI part of the = MAC > address). Such information can be highly helpful when preparing an = orchestrated > attack towards a target company. If this is simplified by the YANG = based > configuration in some way (I think so but you have a better = understanding than > me), then it's worth mentioning. [if - The current Security Considerations text contains the following: " Some of the readable data nodes in this YANG module may be = considered sensitive or vulnerable in some network environments. Therefore, it is important to control read access (e.g., only permitting get, get- config, or notifications) to these data nodes. These subtrees and data nodes can be misused to track the activity of a host: * Information the server holds about clients with active leases: (dhc6-srv/allocation-ranges/allocation-range/address-pools/ address-pool/active-leases) * Information the relay holds about clients with active leases: (dhc6-rly/relay-if/prefix-delegation/) MAC address/Client DUIDs and other client state information is held as = part of these sub-trees. RFC7824 specfically covers DHCPv6 Privacy Considerations in some detail, = so I can add The following text: =E2=80=9C[RFC7824] covers privacy considerations for DHCPv6 and is = applicable here." ] >=20 > To summarize, I have the feeling the current text could better = illustrate some > of the consequences of attacks, beyond DoS attacks. >=20 > Minor comments: >=20 > - Section 5: remove "a" or "the" in: > "changing the address of a the DNS server" [if - done] >=20 > - Section 5: "re-configuring messages" is ambiguous. > I think "forwarding messages to a rogue server after modifying = the > 'server-address'" (I think this is what is meant) would be more > appropriate. [if - I=E2=80=99ve changed to the following: Modifying the relay's "destination-address" to send =20 messages to a rogue DHCPv6 server.=20 ] > - intro: > "...which is applicable device's interfaces." > May be: "applicable to ..." [if - done] >=20 > - intro, 1st paragraph: > You should choose to either expand both NETCONF and RESTCONF = acronyms, > or none of them. [if - AFAIK, RESTCONF does not have an expanded acronym (there isn=E2=80=99= t one given in RFC8040) The RFC Editor=E2=80=99s list of acronyms = (https://www.rfc-editor.org/materials/abbrev.expansion.txt = ) has the = following: NETCONF - Network Configuration Protocol (NETCONF)=20 RESTCONF - No Expansion=20 ] >=20 > Cheers, >=20 > Vincent >=20 >=20 --Apple-Mail=_6AE3DFC8-0371-4C4C-8D91-CCF8C786F9F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Vincent,

Many thanks = for your review. Please see inline below.

Cheers,
Ian

On 17. Nov 2021, at 09:41, Vincent Roca via Datatracker = <noreply@ietf.org> wrote:

Reviewer: Vincent Roca
Review result: Not = Ready

Hello,

I = have reviewed this document as part of the security directorate=E2=80=99s = 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.

Summary: Not Ready

The Security = Considerations section is globally well written, with links to
appropriate documents. However, a few clarifications would be = welcome IMHO.

It is said: "An attacker who = is able to access the DHCPv6 server" (resp. relay).
It's = not just a matter of accessing the server (resp. relay).
As = I understand it's more a matter of taking the control of the server = (resp.
relay), which is different. Please clarify.

[if - = I propose:

Old:
An attacker who is able to access the DHCPv6 server can = undertake
   various attacks, such = as:

New:
An attacker with = read/write access the DHCPv6 server can undertake
   various attacks, such as:

Same change for the = relay text."
]


Then, the current text only mentions "denial of services" = among the possible
consequences. DoS are rapidly = identified and fixed, and anyway, an attacker
having full = control on the DHCP server has other options to launch a DoS. I'd
be more concerned by subtle attacks that could be used to = exfiltrate sensitive
information (maybe by redirecting to = a rogue server?), or to create excessive
traffic (maybe by = changing the valid-lifetime?), or to create subtle
dysfunctions (e.g., assigning the same IP to different = clients), etc.

[if - The subtle attacks are properties of the = DHCPv6 protocol and the elements which provide it,
rather than = specifically associated with NETCONF/YANG or other methods by which = those elements are configured
and managed. The text currently = has:

"Security considerations = related to DHCPv6 are discussed in [RFC8415].=E2=80=9D

Do you think this covers it?]


Another example: an attacker may gather = information about clients, network
topology and network = devices (e.g., by looking at the OUI part of the MAC
address). Such information can be highly helpful when = preparing an orchestrated
attack towards a target company. = If this is simplified by the YANG based
configuration in = some way (I think so but you have a better understanding than
me), then it's worth mentioning.

[if - = The current Security Considerations text contains the = following:

"   Some of the = readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network = environments.  Therefore, it
   is = important to control read access (e.g., only permitting get, = get-
   config, or notifications) to = these data nodes.  These subtrees and
  =  data nodes can be misused to track the activity of a = host:

  =  *  Information the server holds about clients with active = leases:
      = (dhc6-srv/allocation-ranges/allocation-range/address-pools/
      address-pool/active-leases)

   * =  Information the relay holds about clients with active = leases:
      = (dhc6-rly/relay-if/prefix-delegation/)

MAC address/Client DUIDs and other = client state information is held as part of these sub-trees.

RFC7824 specfically = covers DHCPv6 Privacy Considerations in some detail, so I can = add
The following text:

=E2=80=9C[RFC7824] covers privacy = considerations for DHCPv6 and is applicable = here."
]


To= summarize, I have the feeling the current text could better illustrate = some
of the consequences of attacks, beyond DoS = attacks.

Minor comments:

- Section 5: remove "a" or "the" in:
=        "changing the address of a the = DNS server"

[if - done]


- = Section 5: "re-configuring messages" is ambiguous.
=        I think "forwarding messages = to a rogue server after modifying the
=        'server-address'" (I think = this is what is meant) would be more
=        appropriate.

[if - I=E2=80=99ve= changed to the following:

Modifying = the relay's "destination-address" to send         =       
          = messages to a rogue DHCPv6 server. 
]

- intro:
=        "...which is applicable = device's interfaces."
=        May be: "applicable to ..."

[if - = done]


- intro, 1st paragraph:
       You should choose = to either expand both NETCONF and RESTCONF acronyms,
=        or none of them.

[if - AFAIK, = RESTCONF does not have an expanded acronym (there isn=E2=80=99t one = given in RFC8040)
The RFC Editor=E2=80=99s list of acronyms = (https://www.rfc-editor.org/materials/abbrev.expansion.txt) = has the following:

NETCONF   =  - Network Configuration Protocol = (NETCONF) 
RESTCONF   - No = Expansion 
]


Cheers,

  Vincent



= --Apple-Mail=_6AE3DFC8-0371-4C4C-8D91-CCF8C786F9F4-- From nobody Wed Nov 17 05:38:40 2021 Return-Path: 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 AAF473A0CEB; Wed, 17 Nov 2021 05:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wD2OugLFP5vf; Wed, 17 Nov 2021 05:38:22 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 3CAAF3A0CE2; Wed, 17 Nov 2021 05:38:20 -0800 (PST) IronPort-Data: =?us-ascii?q?A9a23=3AQ/Lj/6gcKz7hUp/9/jbU/PcQX1619BIKZh0ujC4?= =?us-ascii?q?5NGQNrF6WrkUOy2ZLWD2COayNY2f8KY10Od+3pxwA7cCEyIJnSgs+/3w8FHgiR?= =?us-ascii?q?ejtVY3IdB+oV8+xBpSeFxw/t512huEtnanYd1eEzvuWGuWn/SYUOZ2gHOKmUbe?= =?us-ascii?q?dY38pHmeIdQ964f5ds79g6mJXqYjha++9kYuaT/z3YDdJ6RYsWo4nw/7rRCdUg?= =?us-ascii?q?RjHkGhwUmrSyhx8lAS2e3E9VPrzLEwqRpfyatE88uWSH44vwFwll1418SvBCvv?= =?us-ascii?q?9+lr6WlYPXqbZOQmDjGYQUrC6hhUqSi4ai/dncqNNOAEN23PVwbidy/0U3XC0Y?= =?us-ascii?q?RkoOKbBnvhbSR5TGgl/O7dH8fnJOxBTtOTPlhebLSu1qxlpJARsVWECwc52CGd?= =?us-ascii?q?A/OYCJSolYRWTwemxxdqTUO5nj+wxLczhJopZu3d6zDifA+xOaYvOSKnL//dZ0?= =?us-ascii?q?Ss+wMdUEp72a8oSdjVHbRncbVtIIFh/IJ4klem0w3jybzMdpFKe4KY36HDNkkl?= =?us-ascii?q?g2b7idtPRfvSLSNlb2EGCqQru+23iHlQRPdib4TuI7nzqgfXA9R4X8qp6+KaQ6?= =?us-ascii?q?ONumFCIgG0VEhwfUUO2ur+3kCaDtxtkAxR80kITQWIarSRHluXAYiA=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AXN2GM6Cg6tEGwtPlHel155DYdb4zR+YMi2TD?= =?us-ascii?q?tnoBNCC9F/byqynAppUmPGDP+VAssR0b9exoe5PwOE80jKQFmrX5ZI3SJjUO21?= =?us-ascii?q?HYUL2Kj7GD/9SIIUSXnNK1s50OT0EUMrDN5DZB4/oTnWGDYq4dKQ28gcKVbZu3?= =?us-ascii?q?9QYLcegTUdAC0+6PMHf+LqTefngiOaYE?= X-IronPort-AV: E=Sophos;i="5.87,241,1631570400"; d="scan'208,217";a="4125681" Received: from vulpes.inrialpes.fr (HELO smtpclient.apple) ([194.199.28.46]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Nov 2021 14:38:18 +0100 From: Vincent Roca Message-Id: <66A97B88-777B-43D5-A0B2-02ACB8297378@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_4EE8E56C-ED42-40E2-8ADE-2FC714D08993" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 17 Nov 2021 14:38:17 +0100 In-Reply-To: <83B0FF38-8180-4B5D-AE41-48E8AB7DA4A6@gmx.com> Cc: Vincent Roca , secdir@ietf.org, dhcwg , draft-ietf-dhc-dhcpv6-yang.all@ietf.org, last-call@ietf.org To: ianfarrer@gmx.com References: <163713848820.18649.9224727643938761782@ietfa.amsl.com> <83B0FF38-8180-4B5D-AE41-48E8AB7DA4A6@gmx.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dhc-dhcpv6-yang-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 13:38:28 -0000 --Apple-Mail=_4EE8E56C-ED42-40E2-8ADE-2FC714D08993 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for your quick answer Ian. > Hi Vincent, >=20 > Many thanks for your review. Please see inline below. >=20 > Cheers, > Ian >=20 >> On 17. Nov 2021, at 09:41, Vincent Roca via Datatracker = > wrote: >>=20 >> Reviewer: Vincent Roca >> Review result: Not Ready >>=20 >> Hello, >>=20 >> I have reviewed this document as part of the security directorate=E2=80= =99s 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. >>=20 >> Summary: Not Ready >>=20 >> The Security Considerations section is globally well written, with = links to >> appropriate documents. However, a few clarifications would be welcome = IMHO. >>=20 >> It is said: "An attacker who is able to access the DHCPv6 server" = (resp. relay). >> It's not just a matter of accessing the server (resp. relay). >> As I understand it's more a matter of taking the control of the = server (resp. >> relay), which is different. Please clarify. >=20 > [if - I propose: >=20 > Old: > An attacker who is able to access the DHCPv6 server can undertake > various attacks, such as: >=20 > New: > An attacker with read/write access the DHCPv6 server can undertake > various attacks, such as: >=20 > Same change for the relay text." > ] VR: yes, I now understand what you meant.=20 >> Then, the current text only mentions "denial of services" among the = possible >> consequences. DoS are rapidly identified and fixed, and anyway, an = attacker >> having full control on the DHCP server has other options to launch a = DoS. I'd >> be more concerned by subtle attacks that could be used to exfiltrate = sensitive >> information (maybe by redirecting to a rogue server?), or to create = excessive >> traffic (maybe by changing the valid-lifetime?), or to create subtle >> dysfunctions (e.g., assigning the same IP to different clients), etc. >=20 > [if - The subtle attacks are properties of the DHCPv6 protocol and the = elements which provide it, > rather than specifically associated with NETCONF/YANG or other methods = by which those elements are configured > and managed. The text currently has: >=20 > "Security considerations related to DHCPv6 are discussed in = [RFC8415].=E2=80=9D >=20 > Do you think this covers it?] VR: if I follow your logic and if I correctly understand, DoS attacks = are already discussed in RFC 8415 and could be removed from this document since there=E2=80=99s = nothing specific to YANG. My point is to highlight that risks are not limited to DoS, unlike what = is currently suggested.=20 Maybe: Old: * Various attacks based on re-configuring the contents of DHCPv6 options. For example, changing the address of a the DNS server supplied in a DHCP option to point to a rogue server. New: * Various attacks based on re-configuring the contents of DHCPv6 options, leading to several types of security or privacy threats. =20= For example, changing the address of a the DNS server supplied in a DHCP option to point to a rogue server. >> Another example: an attacker may gather information about clients, = network >> topology and network devices (e.g., by looking at the OUI part of the = MAC >> address). Such information can be highly helpful when preparing an = orchestrated >> attack towards a target company. If this is simplified by the YANG = based >> configuration in some way (I think so but you have a better = understanding than >> me), then it's worth mentioning. >=20 > [if - The current Security Considerations text contains the following: >=20 > " Some of the readable data nodes in this YANG module may be = considered > sensitive or vulnerable in some network environments. Therefore, = it > is important to control read access (e.g., only permitting get, = get- > config, or notifications) to these data nodes. These subtrees and > data nodes can be misused to track the activity of a host: >=20 > * Information the server holds about clients with active leases: > (dhc6-srv/allocation-ranges/allocation-range/address-pools/ > address-pool/active-leases) >=20 > * Information the relay holds about clients with active leases: > (dhc6-rly/relay-if/prefix-delegation/) >=20 > MAC address/Client DUIDs and other client state information is held as = part of these sub-trees. >=20 > RFC7824 specfically covers DHCPv6 Privacy Considerations in some = detail, so I can add > The following text: >=20 > =E2=80=9C[RFC7824] covers privacy considerations for DHCPv6 and is = applicable here." > ] VR: indeed, RFC 7824 is a key reference and must be referenced by your = document. Thanks for adding it. >> To summarize, I have the feeling the current text could better = illustrate some >> of the consequences of attacks, beyond DoS attacks. >>=20 >> Minor comments: >>=20 >> - Section 5: remove "a" or "the" in: >> "changing the address of a the DNS server" >=20 > [if - done] >=20 >>=20 >> - Section 5: "re-configuring messages" is ambiguous. >> I think "forwarding messages to a rogue server after modifying = the >> 'server-address'" (I think this is what is meant) would be = more >> appropriate. >=20 > [if - I=E2=80=99ve changed to the following: >=20 > Modifying the relay's "destination-address" to send =20 > messages to a rogue DHCPv6 server.=20 > ] VR: yes. >=20 >> - intro: >> "...which is applicable device's interfaces." >> May be: "applicable to ..." >=20 > [if - done] >=20 >>=20 >> - intro, 1st paragraph: >> You should choose to either expand both NETCONF and RESTCONF = acronyms, >> or none of them. >=20 > [if - AFAIK, RESTCONF does not have an expanded acronym (there isn=E2=80= =99t one given in RFC8040) > The RFC Editor=E2=80=99s list of acronyms = (https://www.rfc-editor.org/materials/abbrev.expansion.txt = ) has the = following: >=20 > NETCONF - Network Configuration Protocol (NETCONF)=20 > RESTCONF - No Expansion=20 > ] VR: okay, forget what I said, I was not aware. Cheers, Vincent= --Apple-Mail=_4EE8E56C-ED42-40E2-8ADE-2FC714D08993 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you for your quick answer Ian.


Hi = Vincent,

Many thanks = for your review. Please see inline below.

Cheers,
Ian

On 17. Nov 2021, at 09:41, Vincent Roca via = Datatracker <noreply@ietf.org> wrote:

Reviewer: Vincent Roca
Review result: Not = Ready

Hello,

I = have reviewed this document as part of the security directorate=E2=80=99s = 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.

Summary: Not Ready

The Security = Considerations section is globally well written, with links to
appropriate documents. However, a few clarifications would be = welcome IMHO.

It is said: "An attacker who = is able to access the DHCPv6 server" (resp. relay).
It's = not just a matter of accessing the server (resp. relay).
As = I understand it's more a matter of taking the control of the server = (resp.
relay), which is different. Please clarify.

[if - I propose:
Old:
An attacker who is able to access the DHCPv6 server can = undertake
   various attacks, such = as:

New:
An attacker with = read/write access the DHCPv6 server can undertake
   various attacks, such as:

Same change for the = relay text."
]

VR: yes, I now understand what you = meant. 


Then, the current text only = mentions "denial of services" among the possible
consequences. DoS are rapidly identified and fixed, and = anyway, an attacker
having full control on the DHCP server = has other options to launch a DoS. I'd
be more concerned = by subtle attacks that could be used to exfiltrate sensitive
information (maybe by redirecting to a rogue server?), or to = create excessive
traffic (maybe by changing the = valid-lifetime?), or to create subtle
dysfunctions (e.g., = assigning the same IP to different clients), etc.

[if - The subtle attacks are properties = of the DHCPv6 protocol and the elements which provide it,
rather than specifically associated with NETCONF/YANG or = other methods by which those elements are configured
and managed. The text currently has:

"Security considerations related to = DHCPv6 are discussed in [RFC8415].=E2=80=9D

Do you think this covers = it?]

VR: if I follow your logic and if I correctly = understand, DoS attacks are already discussed
in RFC 8415 and = could be removed from this document since there=E2=80=99s nothing = specific to YANG.
My point is to highlight that risks are not = limited to DoS, unlike what is currently suggested. 

Maybe:

Old:
   *  Various = attacks based on re-configuring the contents of DHCPv6
      options.  For example, = changing the address of a the DNS server
    =   supplied in a DHCP option to point to a rogue server.

New:
  =  *  Various attacks based on re-configuring the contents = of DHCPv6
      options, leading to = several types of security or privacy = threats.  
      For example, = changing the address of a the DNS server
    =   supplied in a DHCP option to point to a rogue server.


Another example: an attacker = may gather information about clients, network
topology and = network devices (e.g., by looking at the OUI part of the MAC
address). Such information can be highly helpful when = preparing an orchestrated
attack towards a target company. = If this is simplified by the YANG based
configuration in = some way (I think so but you have a better understanding than
me), then it's worth mentioning.

[if - The current Security = Considerations text contains the following:

"   Some of the readable data = nodes in this YANG module may be considered
  =  sensitive or vulnerable in some network environments. =  Therefore, it
   is important to = control read access (e.g., only permitting get, get-
   config, or notifications) to these data nodes. =  These subtrees and
   data nodes = can be misused to track the activity of a host:

   *  Information the = server holds about clients with active leases:
 =     = (dhc6-srv/allocation-ranges/allocation-range/address-pools/
      address-pool/active-leases)

   * =  Information the relay holds about clients with active = leases:
      = (dhc6-rly/relay-if/prefix-delegation/)

MAC address/Client DUIDs and other = client state information is held as part of these sub-trees.

RFC7824 specfically = covers DHCPv6 Privacy Considerations in some detail, so I can = add
The following text:

=E2=80=9C[RFC7824] covers privacy = considerations for DHCPv6 and is applicable here."
]

VR: indeed, RFC 7824 is a key reference and must = be referenced by your document.
Thanks for adding = it.


To summarize, I have the feeling the current = text could better illustrate some
of the consequences of = attacks, beyond DoS attacks.

Minor = comments:

- Section 5: remove "a" or "the" = in:
       "changing = the address of a the DNS server"

[if - done]


- Section 5: "re-configuring messages" is = ambiguous.
       I = think "forwarding messages to a rogue server after modifying the
       'server-address'" = (I think this is what is meant) would be more
=        appropriate.

[if - = I=E2=80=99ve changed to the following:

Modifying the relay's = "destination-address" to send             =   
          messages to a rogue = DHCPv6 server. 
]

VR: yes.


- intro:
=        "...which is applicable = device's interfaces."
=        May be: "applicable to ..."

[if - done]


- intro, 1st paragraph:
=        You should choose to either = expand both NETCONF and RESTCONF acronyms,
=        or none of them.

[if - = AFAIK, RESTCONF does not have an expanded acronym (there isn=E2=80=99t = one given in RFC8040)
The RFC Editor=E2=80=99s list = of acronyms (https://www.rfc-editor.org/materials/abbrev.expansion.txt) = has the following:

NETCONF    - Network Configuration Protocol = (NETCONF) 
RESTCONF   - No = Expansion 
]

VR: okay, forget what I said, I was not = aware.

Cheers,

  =  Vincent
= --Apple-Mail=_4EE8E56C-ED42-40E2-8ADE-2FC714D08993-- From nobody Wed Nov 17 08:01:35 2021 Return-Path: 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 7459C3A0794; Wed, 17 Nov 2021 08:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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=gmx.net 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 gMSVCNt6ecCI; Wed, 17 Nov 2021 08:01:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D87CC3A0799; Wed, 17 Nov 2021 08:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1637164884; bh=BtSxbisDo27os5NymNC7GcjNg9pdJ6THDQaTr4ss9mI=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=OvABiB53txgS8ZUW33lULxO4JSsps4jKHr/6oP0A9ERQqGAnMYJFhq/1Pkx+MN7tz NtDn5RqdCNi6ahYv7in0cSRI5TXJ+4CrrJM6vuB4cguVMu3FIK44JviuB8/bhqbA25 b+clsadPrSGJBvVBASb2ZgJujrMtnw0ac5Xrusgk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from smtpclient.apple ([87.78.165.90]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1N5GE1-1mdMuc3fkr-0118UQ; Wed, 17 Nov 2021 17:01:23 +0100 From: ianfarrer@gmx.com Message-Id: <2F867726-7AB5-4959-B9B1-124D05B8CBDC@gmx.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_582B3F25-47BB-43B8-B7D7-90DA573FF527" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Wed, 17 Nov 2021 17:01:22 +0100 In-Reply-To: <66A97B88-777B-43D5-A0B2-02ACB8297378@inria.fr> Cc: secdir@ietf.org, dhcwg , draft-ietf-dhc-dhcpv6-yang.all@ietf.org, last-call@ietf.org To: Vincent Roca References: <163713848820.18649.9224727643938761782@ietfa.amsl.com> <83B0FF38-8180-4B5D-AE41-48E8AB7DA4A6@gmx.com> <66A97B88-777B-43D5-A0B2-02ACB8297378@inria.fr> X-Mailer: Apple Mail (2.3693.20.0.1.32) X-Provags-ID: V03:K1:9MjSuzEidHD15qMoW2OKIFtrCoLB+w49t1R6P7TVkAn3N53H+yi yP8IMdM/dtG3JPCQiLt4xmCEa9FuQDcXl1KiIB/Xw+jxJkZfWVUw1vuXQOmdB5+Arv+USP7 SpTH7APtpoNPRh3lpWlMEKMKubsNA4eC/dCCqop4w0sJ6c1toLC170ewPgCjC9Jk9uaJBXc PSZIrsBt3zL7JJ3uYKt9w== X-UI-Out-Filterresults: notjunk:1;V03:K0:L8itNGKl9qc=:59cq76BSTnCyF5Lkk5sbrB T+XCS0lSPzaROv1KdJsP4x6g046B75c7dabAP1TkhsBVZ5R+S/wk8cey69Eglj+qekzr8KDLE TkIQmJCf5ZjS1jrIZ8EQmHfYPjHr6MTc9QPL9GE9fHyycs7IAgAba9jIYn3eCiK30nJiyfEXS fynJsUtoxTCOJECEcLJOzzmIoHYFoIl1iIah3DCn0mjmi1C1kfh5zpORQW/XW6Zs2amixmVMB 71RhpzW1nZ0AY5U9/DeMsDUqLXr7J0wT843GkrRHaPn5yleszHDlJWYuN336qIK02u6Yvo4hH nz7syXGohjs4mXQh64WXVyA42gi7VesEYMIuxxYsDjVjZxj4ZN8549YJDOBflJg25hx7lK6TH z8F1s7Z/oeKwZDTea3uPS7PRWml/7+ns1YoHC8C1ARFBvQII9eQOl0kr2DWAM+POCq0PuB26i iv/kjVhKhNXDQxmYS/AlUQLdxGLhrLqEF1tW10NiRvxKM/97+nPVvrtPn8iMkqGtR2FDVph/d /UU43l+GWiJB3cn0ptkpxzYBZGx8PM+XLNwrm1bRtyd/OR2JaBWHAbepQRdXFHETT8jpzSbY2 V6WPeIkHzo1luea0vQ23edcSrX3kpYaIgj/+I1gwbgZkjqtTwu5QgMWDgNIIMRVvIJXbggWuL ItXcoepDPhHr9XcgLabUHvEXZE4ULgV7ddttzu2Be9bzcwnxJIp97t7jIbflzjkdfZZ/TNbmo WUMTw2WckJZHu24EpIKaNHusnzYMk83ru0ZgV7NIVuNjzQHlqbhHHyIxgE1BI2MipAMoiWPYN yNGBSx46kJwSdxrhdoKKUkDEDEUp0aPIvbSS4G+5FOGK5OOoKQSwMZm3XRO30CTsDx3Nidiga tV+j9R2AG+BtIUvoA44aPQvmQfYT1szR3FRc7BwJXhHA5mgFXNY1kPLoVC/l5bEeR6/JwpZWi M+peMkDSCJdJ7vksEI55fciJwOrB2gEqVkrLlr62YegWee7oNhGTbtcwhNrs6nCM8brd6EY/j N2G75yNCTtuZS71LEdWbooYZp42wjb7t0PTjuH5117WWHP8LQJXFRupYlfbO84NvMzFHAwHtt T9VK9gZuSk24us= Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dhc-dhcpv6-yang-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 16:01:34 -0000 --Apple-Mail=_582B3F25-47BB-43B8-B7D7-90DA573FF527 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Vincent, Thanks for your reply. The agreed changes will be in the next version. Cheers, Ian > On 17. Nov 2021, at 14:38, Vincent Roca wrote: >=20 > Thank you for your quick answer Ian. >=20 >=20 >> Hi Vincent, >>=20 >> Many thanks for your review. Please see inline below. >>=20 >> Cheers, >> Ian >>=20 >>> On 17. Nov 2021, at 09:41, Vincent Roca via Datatracker = > wrote: >>>=20 >>> Reviewer: Vincent Roca >>> Review result: Not Ready >>>=20 >>> Hello, >>>=20 >>> I have reviewed this document as part of the security = directorate=E2=80=99s 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. >>>=20 >>> Summary: Not Ready >>>=20 >>> The Security Considerations section is globally well written, with = links to >>> appropriate documents. However, a few clarifications would be = welcome IMHO. >>>=20 >>> It is said: "An attacker who is able to access the DHCPv6 server" = (resp. relay). >>> It's not just a matter of accessing the server (resp. relay). >>> As I understand it's more a matter of taking the control of the = server (resp. >>> relay), which is different. Please clarify. >>=20 >> [if - I propose: >>=20 >> Old: >> An attacker who is able to access the DHCPv6 server can undertake >> various attacks, such as: >>=20 >> New: >> An attacker with read/write access the DHCPv6 server can undertake >> various attacks, such as: >>=20 >> Same change for the relay text." >> ] >=20 > VR: yes, I now understand what you meant.=20 >=20 >=20 >>> Then, the current text only mentions "denial of services" among the = possible >>> consequences. DoS are rapidly identified and fixed, and anyway, an = attacker >>> having full control on the DHCP server has other options to launch a = DoS. I'd >>> be more concerned by subtle attacks that could be used to exfiltrate = sensitive >>> information (maybe by redirecting to a rogue server?), or to create = excessive >>> traffic (maybe by changing the valid-lifetime?), or to create subtle >>> dysfunctions (e.g., assigning the same IP to different clients), = etc. >>=20 >> [if - The subtle attacks are properties of the DHCPv6 protocol and = the elements which provide it, >> rather than specifically associated with NETCONF/YANG or other = methods by which those elements are configured >> and managed. The text currently has: >>=20 >> "Security considerations related to DHCPv6 are discussed in = [RFC8415].=E2=80=9D >>=20 >> Do you think this covers it?] >=20 > VR: if I follow your logic and if I correctly understand, DoS attacks = are already discussed > in RFC 8415 and could be removed from this document since there=E2=80=99= s nothing specific to YANG. > My point is to highlight that risks are not limited to DoS, unlike = what is currently suggested.=20 >=20 > Maybe: >=20 > Old: > * Various attacks based on re-configuring the contents of DHCPv6 > options. For example, changing the address of a the DNS server > supplied in a DHCP option to point to a rogue server. >=20 > New: > * Various attacks based on re-configuring the contents of DHCPv6 > options, leading to several types of security or privacy = threats. =20 > For example, changing the address of a the DNS server > supplied in a DHCP option to point to a rogue server. [if - Done] >=20 >=20 >>> Another example: an attacker may gather information about clients, = network >>> topology and network devices (e.g., by looking at the OUI part of = the MAC >>> address). Such information can be highly helpful when preparing an = orchestrated >>> attack towards a target company. If this is simplified by the YANG = based >>> configuration in some way (I think so but you have a better = understanding than >>> me), then it's worth mentioning. >>=20 >> [if - The current Security Considerations text contains the = following: >>=20 >> " Some of the readable data nodes in this YANG module may be = considered >> sensitive or vulnerable in some network environments. Therefore, = it >> is important to control read access (e.g., only permitting get, = get- >> config, or notifications) to these data nodes. These subtrees and >> data nodes can be misused to track the activity of a host: >>=20 >> * Information the server holds about clients with active leases: >> (dhc6-srv/allocation-ranges/allocation-range/address-pools/ >> address-pool/active-leases) >>=20 >> * Information the relay holds about clients with active leases: >> (dhc6-rly/relay-if/prefix-delegation/) >>=20 >> MAC address/Client DUIDs and other client state information is held = as part of these sub-trees. >>=20 >> RFC7824 specfically covers DHCPv6 Privacy Considerations in some = detail, so I can add >> The following text: >>=20 >> =E2=80=9C[RFC7824] covers privacy considerations for DHCPv6 and is = applicable here." >> ] >=20 > VR: indeed, RFC 7824 is a key reference and must be referenced by your = document. > Thanks for adding it. >=20 >=20 >>> To summarize, I have the feeling the current text could better = illustrate some >>> of the consequences of attacks, beyond DoS attacks. >>>=20 >>> Minor comments: >>>=20 >>> - Section 5: remove "a" or "the" in: >>> "changing the address of a the DNS server" >>=20 >> [if - done] >>=20 >>>=20 >>> - Section 5: "re-configuring messages" is ambiguous. >>> I think "forwarding messages to a rogue server after = modifying the >>> 'server-address'" (I think this is what is meant) would be = more >>> appropriate. >>=20 >> [if - I=E2=80=99ve changed to the following: >>=20 >> Modifying the relay's "destination-address" to send =20 >> messages to a rogue DHCPv6 server.=20 >> ] >=20 > VR: yes. >=20 >>=20 >>> - intro: >>> "...which is applicable device's interfaces." >>> May be: "applicable to ..." >>=20 >> [if - done] >>=20 >>>=20 >>> - intro, 1st paragraph: >>> You should choose to either expand both NETCONF and RESTCONF = acronyms, >>> or none of them. >>=20 >> [if - AFAIK, RESTCONF does not have an expanded acronym (there = isn=E2=80=99t one given in RFC8040) >> The RFC Editor=E2=80=99s list of acronyms = (https://www.rfc-editor.org/materials/abbrev.expansion.txt = ) has the = following: >>=20 >> NETCONF - Network Configuration Protocol (NETCONF)=20 >> RESTCONF - No Expansion=20 >> ] >=20 > VR: okay, forget what I said, I was not aware. >=20 > Cheers, >=20 > Vincent --Apple-Mail=_582B3F25-47BB-43B8-B7D7-90DA573FF527 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Vincent,

Thanks for = your reply. The agreed changes will be in the next version.

Cheers,
Ian

On 17. Nov 2021, at 14:38, Vincent Roca = <vincent.roca@inria.fr> wrote:

Thank you for your quick answer Ian.


Hi Vincent,

Many thanks for your review. Please see inline = below.

Cheers,
Ian

On 17. Nov 2021, at 09:41, Vincent Roca via Datatracker = <noreply@ietf.org> wrote:

Reviewer: Vincent Roca
Review result: Not = Ready

Hello,

I = have reviewed this document as part of the security directorate=E2=80=99s = 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.

Summary: Not Ready

The Security = Considerations section is globally well written, with links to
appropriate documents. However, a few clarifications would be = welcome IMHO.

It is said: "An attacker who = is able to access the DHCPv6 server" (resp. relay).
It's = not just a matter of accessing the server (resp. relay).
As = I understand it's more a matter of taking the control of the server = (resp.
relay), which is different. Please clarify.

[if - I propose:
Old:
An attacker who is able to access the DHCPv6 server can = undertake
   various attacks, such = as:

New:
An attacker with = read/write access the DHCPv6 server can undertake
   various attacks, such as:

Same change for the = relay text."
]
VR: yes, I now understand what you = meant. 


Then, the current text only mentions "denial of services" = among the possible
consequences. DoS are rapidly = identified and fixed, and anyway, an attacker
having full = control on the DHCP server has other options to launch a DoS. I'd
be more concerned by subtle attacks that could be used to = exfiltrate sensitive
information (maybe by redirecting to = a rogue server?), or to create excessive
traffic (maybe by = changing the valid-lifetime?), or to create subtle
dysfunctions (e.g., assigning the same IP to different = clients), etc.

[if - The subtle attacks are properties = of the DHCPv6 protocol and the elements which provide it,
rather than specifically associated with NETCONF/YANG or = other methods by which those elements are configured
and managed. The text currently has:

"Security considerations related to = DHCPv6 are discussed in [RFC8415].=E2=80=9D

Do you think this covers = it?]

VR: if I follow your logic and if I = correctly understand, DoS attacks are already discussed
in RFC 8415 and could be removed from this document since = there=E2=80=99s nothing specific to YANG.
My point = is to highlight that risks are not limited to DoS, unlike what is = currently suggested. 

Maybe:

Old:
   *  Various = attacks based on re-configuring the contents of DHCPv6
      options.  For example, = changing the address of a the DNS server
    =   supplied in a DHCP option to point to a rogue server.

New:
   *  Various = attacks based on re-configuring the contents of DHCPv6
      options, leading to several types = of security or privacy threats.  
      For example, changing the address of a = the DNS server
      supplied in a = DHCP option to point to a rogue server.

[if - Done]



Another example: an attacker may gather information about = clients, network
topology and network devices (e.g., by = looking at the OUI part of the MAC
address). Such = information can be highly helpful when preparing an orchestrated
attack towards a target company. If this is simplified by the = YANG based
configuration in some way (I think so but you = have a better understanding than
me), then it's worth = mentioning.

[if - The current Security = Considerations text contains the following:

"   Some of the readable data = nodes in this YANG module may be considered
  =  sensitive or vulnerable in some network environments. =  Therefore, it
   is important to = control read access (e.g., only permitting get, get-
   config, or notifications) to these data nodes. =  These subtrees and
   data nodes = can be misused to track the activity of a host:

   *  Information the = server holds about clients with active leases:
 =     = (dhc6-srv/allocation-ranges/allocation-range/address-pools/
      address-pool/active-leases)

   * =  Information the relay holds about clients with active = leases:
      = (dhc6-rly/relay-if/prefix-delegation/)

MAC address/Client DUIDs and other = client state information is held as part of these sub-trees.

RFC7824 specfically = covers DHCPv6 Privacy Considerations in some detail, so I can = add
The following text:

=E2=80=9C[RFC7824] covers privacy = considerations for DHCPv6 and is applicable here."
]
VR: indeed, RFC 7824 is a key = reference and must be referenced by your document.
= Thanks for adding it.

To summarize, I = have the feeling the current text could better illustrate some
of the consequences of attacks, beyond DoS attacks.

Minor comments:

- = Section 5: remove "a" or "the" in:
       "changing the = address of a the DNS server"

[if - done]


- Section 5: "re-configuring messages" is = ambiguous.
       I = think "forwarding messages to a rogue server after modifying the
       'server-address'" = (I think this is what is meant) would be more
       appropriate.

[if - = I=E2=80=99ve changed to the following:

Modifying the relay's = "destination-address" to send             =   
          messages to a rogue = DHCPv6 server. 
]

VR: yes.


- intro:
       "...which is = applicable device's interfaces."
       May be: "applicable = to ..."

[if - done]


- intro, 1st paragraph:
       You should choose = to either expand both NETCONF and RESTCONF acronyms,
       or none of them.

[if - = AFAIK, RESTCONF does not have an expanded acronym (there isn=E2=80=99t = one given in RFC8040)
The RFC Editor=E2=80=99s list = of acronyms (https://www.rfc-editor.org/materials/abbrev.expansion.txt) = has the following:

NETCONF    - Network Configuration Protocol = (NETCONF) 
RESTCONF   - No = Expansion 
]

VR: okay, forget what I said, I was not = aware.

Cheers,

  =  Vincent

= --Apple-Mail=_582B3F25-47BB-43B8-B7D7-90DA573FF527-- From nobody Wed Nov 17 11:00:08 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 613953A0062; Wed, 17 Nov 2021 10:59:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: draft-ietf-netconf-sztp-csr.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163717559932.18384.2156774121641934785@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Wed, 17 Nov 2021 10:59:59 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 19:00:00 -0000 Reviewer: Yaron Sheffer Review result: Has Issues This draft defines a mechanism for a device, when it first starts, to generate a CSR to get itself provisioned with one or more certificates it needs to identify itself during its normal operation. * I was confused that the document starts out describing a generic cert request mechanism. Then deep into the YANG modules, it turns out that there is guidance (only?) for very specific types of certs, namely LDevID and IDevID. And the choice is non-orthogonal: it is unclear what is the guidance for other certs when using CMC and CMP, and conversely, whether these two certs can be generated with a PKCS#10 CSR. * I suggest adding a Security Considerations section about the need for strong randomness, which is often unavailable to small embedded devices at the early stages of provisioning. I wish we were more successful with: https://datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial-random-00 * Negotiation (?) of the CSR format and supported algorithms is unclear in Sec. 2.2: is it the client that provides the values it supports and the server picks one? Alternatively, is the list conveyed by the server in the error-info and so the client knows exactly what is supported? IOW, why include these values at all in error-info? * It is not clear from Sec. 2.2 how exactly the client is supposed to associate one of possibly multiple received certificates to the CSR it just sent out. Surely it is not expected to grep for the string "Newly-Generated"? * 2.3: the description of "error-info" still does not specify if the server should list all CSR format and algorithms it supports. * Is there really need to support 3 different CSR formats? * Where does the client indicate which cert is wants to receive based on this CSR, e.g. "this CSR is for a LDevID"? Is this information embedded in the CSR itself? * Is RFC 2986 (published Nov. 2000) the best reference for an AlgorithmIdentifier? Is there no IANA registry we could reference instead? * When talking about algorithm matching, I suggest changing "It is an error if..." into normative text, "The recipient MUST reject...". * "Details for how to generate a new private key and associate a new identity certificate are outside the scope of this document." - This is rather disappointing, since we just RECOMMENDED to regenerate certs periodically (and given that IOT devices often lack HSMs). From nobody Thu Nov 18 07:42:09 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5FF3A0062 for ; Thu, 18 Nov 2021 07:42:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163725012665.3128.16112097827703701034@ietfa.amsl.com> Date: Thu, 18 Nov 2021 07:42:07 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 15:42:08 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2021-12-02 Reviewer LC end Draft Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Kyle Rose 2021-11-23 draft-ietf-i2nsf-nsf-facing-interface-dm Joseph Salowey 2021-11-24 draft-ietf-bess-srv6-services Stefan Santesson 2021-11-23 draft-eggert-bcp45bis Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Benjamin Schwartz 2021-11-24 draft-ietf-spring-segment-routing-policy Rifaat Shekh-Yusef 2021-12-15 draft-eastlake-rfc6931bis-xmlsec-uris Melinda Shore 2021-12-01 draft-ietf-i2nsf-nsf-monitoring-data-model Valery Smyslov 2021-11-29 draft-ietf-acme-dtnnodeid Robert Sparks 2021-11-29 draft-ietf-httpbis-priority Sean Turner 2021-11-26 draft-ietf-httpbis-http2bis Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Klaas Wierenga 2021-08-30 draft-ietf-alto-cdni-request-routing-alto Paul Wouters R2021-11-29 draft-ietf-i2nsf-capability-data-model Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Liang Xia 2021-03-17 draft-ietf-core-sid Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Kathleen Moriarty 2021-10-25 draft-ietf-dots-multihoming Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Next in the reviewer rotation: Loganaden Velvindron Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Dacheng Zhang From nobody Sun Nov 21 23:42:56 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D65303A0CF7; Sun, 21 Nov 2021 23:42:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson via Datatracker To: Cc: draft-eggert-bcp45bis.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163756696977.16503.8399092079932602929@ietfa.amsl.com> Reply-To: Stefan Santesson Date: Sun, 21 Nov 2021 23:42:49 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-eggert-bcp45bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 07:42:50 -0000 Reviewer: Stefan Santesson Review result: Ready This draft does not have any security considerations text because there are no security issues to discuss relevant for this draft. I agree with this assessment. From nobody Mon Nov 22 09:56:06 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB80C3A0CCA; Mon, 22 Nov 2021 09:55:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: draft-ietf-i2nsf-nsf-facing-interface-dm.all@ietf.org, i2nsf@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163760375473.4258.2594227295562861974@ietfa.amsl.com> Reply-To: Kyle Rose Date: Mon, 22 Nov 2021 09:55:54 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 17:55:55 -0000 Reviewer: Kyle Rose Review result: Has Issues 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. This document Has Issues. I don't actually have a lot to say about this document from a security perspective: its purpose is to describe, using YANG, a data model intended as the basis for configuration schemas developed for implementations of the Interface to Network Security Functions (I2NSF) framework. Security considerations for the most part should be addressed in documents describing system architecture or normatively detailing how implementations are to make use of the data model described here. I'm not going to relitigate any such issues here. The main issues I found in this document are ones that I, as someone not terribly familiar with YANG, found troubling from a general engineering perspective. These are best illustrated by example: * Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) `-address` defined here? These concepts are generic enough that they should be in modules of their own to minimize variation among data models and the errors that will inevitably result from capturing the same concept in slightly different ways that are not obvious to the user. * Overall, I have to imagine that much of the `nsfintf` data model is generic enough that it should be captured externally. For instance, `tcp-flags`, `port-range`, `flow-label`, `dscp`, etc. are generally useful elements of an abstract transport data model that they shouldn't be defined here, but rather incorporated from an external data model that is maintained by those in (for example) the transport area. Am I just commenting on the YANG ecosystem in general? If these are standard practices, then the overall ecosystem has major latent problems. Ideally, a particular YANG module seems like it should describe only those elements defined at a particular layer, in this case rules and actions, and use reference external modules for elements that are defined at lower layers. Also some nits: * `ipvX-address` describes a subspace of the global IPvX address space, not a single address. The name is going to cause problems. * The descriptions given are often (usually?) just restatements of the entity name. Example is `identity priority-by-order` described as "Identity for priority by order". The description should provide some value for the user beyond simply restating the name. * The headings in section 5 should be clearly labeled with the word "example", such as "Example Security Requirement 1". * IPv6 addresses in text MUST be represented in lowercase, according to RFC 5952 section 4.3. From nobody Mon Nov 22 13:49:55 2021 Return-Path: <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@amazonses.watsen.net> 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 DDC673A0819; Mon, 22 Nov 2021 13:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 4pR1OGsNytdV; Mon, 22 Nov 2021 13:49:42 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F633A081C; Mon, 22 Nov 2021 13:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1637617780; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=xR2c0SAkwv5ugufBQMUOL/qm7vShhzAyYhkKaPvXi94=; b=Af54RFfDU/5o7dnG/djhyqJw4CfrLbDpLF7GtoQSxq8ElCAt1ZEgg2aeKk13EFnv Tp+Kl6StD1+tDtsuLn1sXD5W/3raLIKLOV8J3mbQceiJkf8yo2oLe2/4SKWmVrAvgYi rEjhB5JaYvpV3WuUviO1mtVWAE4pVg+a2/WNC/Yk= From: Kent Watsen Message-ID: <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_947C588E-6924-4A94-8069-A4B51A5B50A5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 22 Nov 2021 21:49:40 +0000 In-Reply-To: <163717559932.18384.2156774121641934785@ietfa.amsl.com> Cc: secdir@ietf.org, draft-ietf-netconf-sztp-csr.all@ietf.org, last-call@ietf.org, "netconf@ietf.org" To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.11.22-54.240.8.33 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 21:49:47 -0000 --Apple-Mail=_947C588E-6924-4A94-8069-A4B51A5B50A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yaron, Thank you for your valuable comments. My co-authors and I have the = following responses to your comments. > On Nov 17, 2021, at 1:59 PM, Yaron Sheffer via Datatracker = wrote: >=20 > Reviewer: Yaron Sheffer > Review result: Has Issues >=20 > This draft defines a mechanism for a device, when it first starts, to = generate > a CSR to get itself provisioned with one or more certificates it needs = to > identify itself during its normal operation. >=20 > * I was confused that the document starts out describing a generic = cert request > mechanism. Then deep into the YANG modules, it turns out that there is = guidance > (only?) for very specific types of certs, namely LDevID and IDevID. = And the > choice is non-orthogonal: it is unclear what is the guidance for other = certs > when using CMC and CMP, and conversely, whether these two certs can be > generated with a PKCS#10 CSR. We updated the YANG module to greatly remove references to = IDevID/LDevID. Specifically: 1) s/IDevID/initial device identity certificate/g 2) s/LDevID/local device identity certificate/g 3) manually rewrap lines to col 69 as required 4) removed the terminology-disclaimer block at top The diff is here: = https://github.com/netconf-wg/sztp-csr/commit/ac35f96eec96528dddf5798d528d= 9874a85c604b = Good? > * I suggest adding a Security Considerations section about the need = for strong > randomness, which is often unavailable to small embedded devices at = the early > stages of provisioning. I wish we were more successful with:=20 > = https://datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial-random-00 OLD: It is RECOMMENDED that a new private key is generated for each CSR described in this document. NEW: It is RECOMMENDED that a new private key is generated for each CSR described in this document. This private key MUST be generated using a quality random source. = The use of inadequate pseudo-random number generators (PRNGs) to generate private keys can result in little or no security. An = attacker may find it much easier to reproduce the PRNG environment that produced the private key, searching the resulting small set of possibilities, = rather than brute force searching the whole private key space. The = generation of quality random numbers is difficult. BCP 106 [RFC4086] offers important guidance in this area. and we added an Informational reference to RFC 4086. Good now? > * Negotiation (?) of the CSR format and supported algorithms is = unclear in Sec. > 2.2: is it the client that provides the values it supports and the = server picks > one? Alternatively, is the list conveyed by the server in the = error-info and so > the client knows exactly what is supported? IOW, why include these = values at > all in error-info? Section 2.1 states the sequence of exchanges, but we went ahead and = added more context to the examples for additional clarity. The diff is = here: = https://github.com/netconf-wg/sztp-csr/commit/7ed4f5b1daee539dc9071061e4d4= 27e843467d02 = Better? > * It is not clear from Sec. 2.2 how exactly the client is supposed to = associate > one of possibly multiple received certificates to the CSR it just sent = out. > Surely it is not expected to grep for the string "Newly-Generated"? There doesn=E2=80=99t have to be any logic on the client to detect the = signed certificate or, for that matter, to ensure that the server sent = one at all. The point of the bootstrap process is to *configure* the = SZTP-client, and the client's only post-update logic is to =E2=80=9Crun = as configured=E2=80=9D, whatever that might be. That said, it wouldn=E2=80=99t be hard for a client to, e.g., search a = =E2=80=9Ckeystore" mechanism for a key having the key used in the CSR = and then search certificates associated with that key for that cert = having the matching attributes (e.g., the =E2=80=9CSubject=E2=80=9D = attribute) as in the CSR. Makes sense? [No update to the draft was made to address this comment] > * 2.3: the description of "error-info" still does not specify if the = server > should list all CSR format and algorithms it supports. Section 2.1 indicates that the client=E2=80=99s message lists all of the = key-algorithms and csr-formats it supports and the server=E2=80=99s = message merely selects the specific algorithm/format it wishes the = client use. This comment is nearly identical to one of your earlier = comments, for which we added more context around the examples. Good = enough? =20 > * Is there really need to support 3 different CSR formats? Yes and, FWIW, the PKI world has even more formats; we actually = restricted them to just those that are most widely implemented. > * Where does the client indicate which cert is wants to receive based = on this > CSR, e.g. "this CSR is for a LDevID"? Is this information embedded in = the CSR > itself? The CSR is always for an LDevID. It can never be for an IDevID, which = can (effectively) only be generated/installed by the vendor during the = device=E2=80=99s manufacturing process.=20 Makes sense? [No update to the draft was made to address this comment] > * Is RFC 2986 (published Nov. 2000) the best reference for an > AlgorithmIdentifier? Is there no IANA registry we could reference = instead? There is not an IANA registry for AlgorithmIdentifiers. RFC 2986 is the = reference for the PKCS#10 CSR. [No update to the draft was made to address this comment] > * When talking about algorithm matching, I suggest changing "It is an = error > if..." into normative text, "The recipient MUST reject...". OLD: It is an error if the 'AlgorithmIdentifier' field contained inside the 'SubjectPublicKeyInfo' field does not match the algorithm identified by the 'selected-algorithm' node."; NEW: If the 'AlgorithmIdentifier' field contained inside the certificate 'SubjectPublicKeyInfo' field does not match the algorithm identified by the 'selected-algorithm' node, then the client MUST reject the certificate and raise an error."; Good? > * "Details for how to generate a new private key and associate a new = identity > certificate are outside the scope of this document." - This is rather > disappointing, since we just RECOMMENDED to regenerate certs = periodically (and > given that IOT devices often lack HSMs). Understood, but key-generation is indeed outside the scope of this = document. [No update to the draft was made to address this comment] Thanks again, Kent (and Sean and Russ) --Apple-Mail=_947C588E-6924-4A94-8069-A4B51A5B50A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Yaron,

Thank you for = your valuable comments.  My co-authors and I have the = following
responses to your comments.



On Nov = 17, 2021, at 1:59 PM, Yaron Sheffer via Datatracker <noreply@ietf.org> = wrote:

Reviewer: Yaron Sheffer
Review result: Has = Issues

This draft defines a mechanism for a = device, when it first starts, to generate
a CSR to get = itself provisioned with one or more certificates it needs to
identify itself during its normal operation.

* I was confused that the document starts out describing a = generic cert request
mechanism. Then deep into the YANG = modules, it turns out that there is guidance
(only?) for = very specific types of certs, namely LDevID and IDevID. And the
choice is non-orthogonal: it is unclear what is the guidance = for other certs
when using CMC and CMP, and conversely, = whether these two certs can be
generated with a PKCS#10 = CSR.

We = updated the YANG module to greatly remove references to = IDevID/LDevID.

Specifically:
1) = s/IDevID/initial device identity certificate/g
= 2) s/LDevID/local device identity = certificate/g
3) manually rewrap lines to col = 69 as required
4) removed the terminology-disclaimer block at = top


Good?


* I suggest adding a Security Considerations section about = the need for strong
randomness, which is often unavailable = to small embedded devices at the early
stages of = provisioning. I wish we were more successful with:
https://datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial= -random-00

OLD:

    It = is RECOMMENDED that a new private key is generated for each CSR
    described in this document.

NEW:

    It is = RECOMMENDED that a new private key is generated for each CSR
    described in this document.

    This private key MUST be generated using a = quality random source. The
    use of inadequate = pseudo-random number generators (PRNGs) to
    = generate private keys can result in little or no security.  An = attacker may
    find it much easier to = reproduce the PRNG environment that produced
    = the private key, searching the resulting small set of possibilities, = rather
    than brute force searching the whole = private key space.  The generation
    of = quality random numbers is difficult.  BCP 106 [RFC4086] offers
    important guidance in this area.

and we added an Informational = reference to RFC 4086.

Good = now?


* Negotiation = (?) of the CSR format and supported algorithms is unclear in Sec.
2.2: is it the client that provides the values it supports = and the server picks
one? Alternatively, is the list = conveyed by the server in the error-info and so
the client = knows exactly what is supported? IOW, why include these values at
all in error-info?

Section= 2.1 states the sequence of exchanges, but we went ahead and added more = context to the examples for additional clarity.  The diff is = here: https://github.com/netconf-wg/sztp-csr/commit/7ed4f5b1daee539dc= 9071061e4d427e843467d02

Better?


* It is not clear from Sec. 2.2 how exactly the client is = supposed to associate
one of possibly multiple received = certificates to the CSR it just sent out.
Surely it is not = expected to grep for the string "Newly-Generated"?

There = doesn=E2=80=99t have to be any logic on the client to detect = the signed certificate or, for that matter, to ensure that the = server sent one at all.  The point  of = the bootstrap process is to *configure* the = SZTP-client, and the client's only post-update logic is to =E2=80=9Crun = as configured=E2=80=9D, whatever that might be.

That said, it wouldn=E2=80=99t be hard for a = client to, e.g., search a =E2=80=9Ckeystore" mechanism for a key having = the key used in the CSR and then search certificates associated = with that key for that cert having the matching attributes = (e.g., the =E2=80=9CSubject=E2=80=9D attribute) as in the = CSR.

Makes sense?   [No update = to the draft was made to address this comment]


* 2.3: the description of "error-info" still = does not specify if the server
should list all CSR format = and algorithms it supports.


Section 2.1 indicates that the client=E2=80=99s = message lists all of the key-algorithms and csr-formats it supports = and the server=E2=80=99s message merely selects the specific = algorithm/format it wishes the client use.   This comment is nearly = identical to one of your earlier comments, for which we added more = context around the examples.  Good enough?  


* Is there really need to = support 3 different CSR formats?

Yes = and, FWIW, the PKI world has even more formats; we actually restricted = them to just those that are most widely implemented.


* Where does the client indicate which cert = is wants to receive based on this
CSR, e.g. "this CSR is = for a LDevID"? Is this information embedded in the CSR
itself?

The CSR is always for an LDevID.  It can = never be for an IDevID, which can (effectively) only be = generated/installed by the vendor during the device=E2=80=99s = manufacturing process. 

Makes sense? =   [No update to the draft was made to address this = comment]


* Is RFC 2986 (published Nov. 2000) the best reference for = an
AlgorithmIdentifier? Is there no IANA registry we could = reference instead?

There is not an IANA registry for AlgorithmIdentifiers. =  RFC 2986 is the reference for the PKCS#10 CSR.

[No update to the draft was made to address = this comment]



* When talking about = algorithm matching, I suggest changing "It is an error
if..." into normative text, "The recipient MUST = reject...".

OLD:

  =        It is an error if the 'AlgorithmIdentifier' = field
         contained inside = the 'SubjectPublicKeyInfo' field
      =    does not match the algorithm identified by the
         'selected-algorithm' = node.";

NEW:

         If the = 'AlgorithmIdentifier' field contained inside the
  =        certificate 'SubjectPublicKeyInfo' field does = not match
         the algorithm = identified by the 'selected-algorithm' node,
    =      then the client MUST reject the certificate and = raise an
        =  error.";

Good?



* "Details for how to generate a new private key and = associate a new identity
certificate are outside the scope = of this document." - This is rather
disappointing, since = we just RECOMMENDED to regenerate certs periodically (and
given that IOT devices often lack HSMs).

Understood, = but key-generation is indeed outside the scope of this = document.

[No = update to the draft was made to address this comment]



Thanks = again,
Kent (and Sean and = Russ)



= --Apple-Mail=_947C588E-6924-4A94-8069-A4B51A5B50A5-- From nobody Mon Nov 22 14:31:16 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E92E3A088A; Mon, 22 Nov 2021 14:31:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: draft-eastlake-rfc6931bis-xmlsec-uris.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163762027032.18344.2015966975858687973@ietfa.amsl.com> Reply-To: Rifaat Shekh-Yusef Date: Mon, 22 Nov 2021 14:31:10 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-eastlake-rfc6931bis-xmlsec-uris-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 22:31:11 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Ready This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document also updates, corrects three errata against, and obsoletes RFC 6931. Since the role of this document is to list the URIs used to indicate the usage of a specific algorithm, the security consideration section seems reasonable to me. From nobody Mon Nov 22 14:34:50 2021 Return-Path: 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 CEF723A0893; Mon, 22 Nov 2021 14:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ICmqJEeCalti; Mon, 22 Nov 2021 14:34:46 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920D83A0892; Mon, 22 Nov 2021 14:34:43 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id m9so25527558iop.0; Mon, 22 Nov 2021 14:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=usnjGTHNgZxdFRWhj1KzBgoH+UCNwykRB/iYhZMMH6Y=; b=d0KT+fo0+LEc7kfIBzw/CUxakPYGpQJOLsStBkpmoOm7z55CNpCw0zu7imYBaluTWY /g4QC/YYZlLa02BlNGvQzhCU1LCgADN5Ar+dwafJ1vntZVkCCg2CjANCN/9W7vZ1B8Jk zwivOZWCeKScAPPmtcWm02IY0KuCCqwRXUWoZXFy9RVcCl6pUAQMrDbDQdNlAfft6xh+ udh2HB1Q/94fo5z3kGwpBGThQ+7HjVCR85sa8wLLTqHX4Kp5DvwR9jTF3ZyZS4ckKOjd ibhXf9tiYuje1B65pPZ7KTQLcr+/0ZL2UcFGdXipCRe7C4q8j1ywaQtvf0iMRiazFblb 5Qbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=usnjGTHNgZxdFRWhj1KzBgoH+UCNwykRB/iYhZMMH6Y=; b=t9qr7+cQpyw9BtPgIDiTDRDTud2A9HJfYpzFzTzAnfGLZLM3d/1vowwWEO7ThMlwTn GGvraOw+OyycD2VQTDs2UCGXB6cry1Q6bDE7yaORWkEPR2rPyh/THgGBkKgdzt5bA5le PBtL0wyGQGw0PgH29yUlUZxkJ4EsgEOpOl8y2WeD4/en+6mRvnVgogxcYkToDNm0jcxJ OkZx+usRBWS1KSkS+CLxcfzmqktRUF84c9Oad6HkxH6O0FWbfDo9g1TKFp089F7hpESa /ShsAryqXauOe5gky7uPLTp8Il/HXXCRE4vAtzF4cM0yWB++JVgUFnvWQ5op/O7LBtI1 /7Hg== X-Gm-Message-State: AOAM530iT7v2qrvD0TX6X4nTkaqghwMOyWIVEyS+YtETaPXCMXmIK0Oa 7O26tdx746oGuXVQRHcRxZFmANRILldywD+PCw/JYdYm X-Google-Smtp-Source: ABdhPJwegMIur0DNXXHEn/Ea+hZwEgK34ZKwbXKcHWQfECPyEvK5rs2zF6O10EWlL8dTZnft4y5CJW7GSPwQudqr2Pc= X-Received: by 2002:a05:6602:2e8d:: with SMTP id m13mr393725iow.68.1637620482261; Mon, 22 Nov 2021 14:34:42 -0800 (PST) MIME-Version: 1.0 References: <163762027032.18344.2015966975858687973@ietfa.amsl.com> In-Reply-To: <163762027032.18344.2015966975858687973@ietfa.amsl.com> From: Donald Eastlake Date: Mon, 22 Nov 2021 17:34:31 -0500 Message-ID: To: Rifaat Shekh-Yusef Cc: secdir , draft-eastlake-rfc6931bis-xmlsec-uris.all@ietf.org, Last Call Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-eastlake-rfc6931bis-xmlsec-uris-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2021 22:34:49 -0000 Hi Rifaat, Thanks for your review. Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Nov 22, 2021 at 5:31 PM Rifaat Shekh-Yusef via Datatracker wrote: > > Reviewer: Rifaat Shekh-Yusef > Review result: Ready > > This document updates and corrects the IANA "XML Security URIs" > registry that lists URIs intended for use with XML digital > signatures, encryption, canonicalization, and key management. These > URIs identify algorithms and types of information. This document > also updates, corrects three errata against, and obsoletes RFC 6931. > > Since the role of this document is to list the URIs used to indicate the > usage of a specific algorithm, the security consideration section seems > reasonable to me. > > From nobody Mon Nov 22 17:05:30 2021 Return-Path: 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 D70913A0BE3; Mon, 22 Nov 2021 17:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GC_U7A6F_u7f; Mon, 22 Nov 2021 17:05:16 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499E83A0BE1; Mon, 22 Nov 2021 17:05:16 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id m27so86247966lfj.12; Mon, 22 Nov 2021 17:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Ii4lG9qQDX5jlQ6fxv2lw/+wta14SP5A/X6DdEwlcM=; b=lgWGAvGCoyKLO6psM150flGEeU+rtMslCx0QaXOsySDYIeKZOjh1A56kSBXYW3DFNm gIg3na1VqRBMC7o7juq4kCkyEXdJKRhYSnh41V7LpRsGj3ChUjK8WC6Slu62OSxzBYaU m5Jjrenskw9q5Hnv6nObUXM2U2UnmtecXtRb7PfyFmCuno9iAFGJUwoOfibMJjq8eHXN 6R0q3BgfMp8Cz8k8W+FltRyLrAUo4odKPYQZek6B7WXHKa9ec60mIDcoeF12jSaLkq+w VetOYTz4U2BC231sAUMSEt9g00cMy40Nn+6T9p340Na31Nr9Y11/JL+A+ahzIMnAgdCY 6z3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Ii4lG9qQDX5jlQ6fxv2lw/+wta14SP5A/X6DdEwlcM=; b=2VlsN9l8dpYPa7ZTgkcS2sLCcqa7riFzBPHbf37aOSHwSBFEDdBMqB2F686YHkCa3f BtRTy/AqRxSFV70AD4QiwaN0fJd7PxDxQLt9F3YZmgIMPR8w6UIDLxhogvfGNPAdwkzl KB4NKD6O4Oemo3vhfOLOqGE4jGXrbmuA9NtaRS7YXHz/M4tpzXRECd1SPWP2MC82aLvM uH76kgG2SD5fDLePUSmBtQXFvf8HbfpvO2gxrcVmqXwyDmfmDO1fPjrG3+XucP3cSs8a WrrCi0hfk4C7Zve0KWcOC9+nXScp4zIEFVON5ZG7HTi5sGs41b50iuw9bLxsEoikQjbE 0eYw== X-Gm-Message-State: AOAM533BygGw0zEg6wyQisv9rqHz7daItC3KuZ3FAfhLWDCcSxq5lc/x nhGGONJ/33TEHeycppGPqFyGnPgbG5lD5pRhXLw= X-Google-Smtp-Source: ABdhPJwDDnOtEbGiNRB1Rys7c3G1zJyL+MUhLcM1x3Gs4ddHzglE213FLeMmkyqBEQxF3DVwgvivq7S3heXwUfb4QSQ= X-Received: by 2002:a19:484b:: with SMTP id v72mr682615lfa.338.1637629513140; Mon, 22 Nov 2021 17:05:13 -0800 (PST) MIME-Version: 1.0 References: <163760375473.4258.2594227295562861974@ietfa.amsl.com> In-Reply-To: <163760375473.4258.2594227295562861974@ietfa.amsl.com> From: "Mr. Jaehoon Paul Jeong" Date: Tue, 23 Nov 2021 10:04:37 +0900 Message-ID: To: Kyle Rose Cc: secdir@ietf.org, "i2nsf@ietf.org" , Last Call , draft-ietf-i2nsf-nsf-facing-interface-dm.all@ietf.org, Patrick Lingga , "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000678fca05d16a552d" Archived-At: Subject: Re: [secdir] [I2nsf] Secdir last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 01:05:21 -0000 --000000000000678fca05d16a552d Content-Type: text/plain; charset="UTF-8" Hi Kyle, I will address your valuable comments on this draft. Thanks. Best Regards, Paul On Tue, Nov 23, 2021 at 2:57 AM Kyle Rose via Datatracker wrote: > Reviewer: Kyle Rose > Review result: Has Issues > > 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. > > This document Has Issues. > > I don't actually have a lot to say about this document from a security > perspective: its purpose is to describe, using YANG, a data model intended > as > the basis for configuration schemas developed for implementations of the > Interface to Network Security Functions (I2NSF) framework. Security > considerations for the most part should be addressed in documents > describing > system architecture or normatively detailing how implementations are to > make > use of the data model described here. I'm not going to relitigate any such > issues here. > > The main issues I found in this document are ones that I, as someone not > terribly familiar with YANG, found troubling from a general engineering > perspective. These are best illustrated by example: > > * Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) `-address` > defined here? These concepts are generic enough that they should be in > modules > of their own to minimize variation among data models and the errors that > will > inevitably result from capturing the same concept in slightly different > ways > that are not obvious to the user. * Overall, I have to imagine that much > of > the `nsfintf` data model is generic enough that it should be captured > externally. For instance, `tcp-flags`, `port-range`, `flow-label`, `dscp`, > etc. are generally useful elements of an abstract transport data model > that > they shouldn't be defined here, but rather incorporated from an external > data > model that is maintained by those in (for example) the transport area. > > Am I just commenting on the YANG ecosystem in general? If these are > standard > practices, then the overall ecosystem has major latent problems. Ideally, a > particular YANG module seems like it should describe only those elements > defined at a particular layer, in this case rules and actions, and use > reference external modules for elements that are defined at lower layers. > > Also some nits: > > * `ipvX-address` describes a subspace of the global IPvX address space, > not a > single address. The name is going to cause problems. * The descriptions > given > are often (usually?) just restatements of the entity name. Example is > `identity priority-by-order` described as "Identity for priority by > order". > The description should provide some value for the user beyond simply > restating > the name. * The headings in section 5 should be clearly labeled with the > word > "example", such as "Example Security Requirement 1". * IPv6 addresses in > text > MUST be represented in lowercase, according to RFC 5952 section 4.3. > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > --000000000000678fca05d16a552d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0 Kyle,
I will address your valuable comments on this draft.
Thanks.

Best Regards,
Paul<= /div>


On Tue, Nov 23, 2021 at 2:57 AM Kyle Rose via Datatrack= er <noreply@ietf.org> wrote:<= br>
Reviewer: Kyle R= ose
Review result: Has Issues

I have reviewed this document as part of the security directorate's ong= oing
effort to review all IETF documents being processed by the IESG.=C2=A0 Thes= e
comments were written primarily for the benefit of the security area direct= ors.
=C2=A0Document editors and WG chairs should treat these comments just like = any other
last call comments.

This document Has Issues.

I don't actually have a lot to say about this document from a security<= br> perspective: its purpose is to describe, using YANG, a data model intended = as
the basis for configuration schemas developed for implementations of the Interface to Network Security Functions (I2NSF) framework. Security
considerations for the most part should be addressed in documents describin= g
system architecture or normatively detailing how implementations are to mak= e
use of the data model described here. I'm not going to relitigate any s= uch
issues here.

The main issues I found in this document are ones that I, as someone not terribly familiar with YANG, found troubling from a general engineering
perspective. These are best illustrated by example:

=C2=A0* Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) `-add= ress`
=C2=A0defined here? These concepts are generic enough that they should be i= n modules
=C2=A0of their own to minimize variation among data models and the errors t= hat will
=C2=A0inevitably result from capturing the same concept in slightly differe= nt ways
=C2=A0that are not obvious to the user. * Overall, I have to imagine that m= uch of
=C2=A0the `nsfintf` data model is generic enough that it should be captured=
=C2=A0externally. For instance, `tcp-flags`, `port-range`, `flow-label`, `d= scp`,
=C2=A0etc. are generally useful elements of an abstract transport data mode= l that
=C2=A0they shouldn't be defined here, but rather incorporated from an e= xternal data
=C2=A0model that is maintained by those in (for example) the transport area= .

Am I just commenting on the YANG ecosystem in general? If these are standar= d
practices, then the overall ecosystem has major latent problems. Ideally, a=
particular YANG module seems like it should describe only those elements defined at a particular layer, in this case rules and actions, and use
reference external modules for elements that are defined at lower layers.
Also some nits:

=C2=A0* `ipvX-address` describes a subspace of the global IPvX address spac= e, not a
=C2=A0single address. The name is going to cause problems. * The descriptio= ns given
=C2=A0are often (usually?) just restatements of the entity name. Example is=
=C2=A0`identity priority-by-order` described as "Identity for priority= by order".
=C2=A0The description should provide some value for the user beyond simply = restating
=C2=A0the name. * The headings in section 5 should be clearly labeled with = the word
=C2=A0"example", such as "Example Security Requirement 1&quo= t;. * IPv6 addresses in text
=C2=A0MUST be represented in lowercase, according to RFC 5952 section 4.3.<= br>

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
--000000000000678fca05d16a552d-- From nobody Mon Nov 22 20:45:54 2021 Return-Path: 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 3982E3A03F7; Mon, 22 Nov 2021 20:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 a76uxk0Zq_n6; Mon, 22 Nov 2021 20:45:40 -0800 (PST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EA03A03ED; Mon, 22 Nov 2021 20:45:40 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id u16so14105005qvk.4; Mon, 22 Nov 2021 20:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=I6uTHhL+0+TPAuEj0X3WF6fbivKaNKJgey9OfsP26dQ=; b=mCC543wVSdDMfHBixuXYCqQdWe3Mlu857nzJ+JDPkMGEqcvteo3IsVMOwrwt3wV63I NNMPFGa457qdCp5A6vOxfz6j3fhBRYNtQ0eZdmC4G0qa9XK35vC92Mfwcm3EPUPosQ2K RjtXij9v5uuue77LlO6yihwWl5YtuwfI8biczVYTRK94LpyeHkDUHm4bhBX/Y0w00Sy7 L+t5ZBiq/Zn08aE3kK9YFPN7CHy67XcdlJkpYRtUKUF3VhwlKsO5CR7bdajXHqGVbMa0 JRgBh0NrI/6GYK/WLWje4pbefM6v2H/GYeG6uMDv+OB5/WkvtG0QSjcfUDnZzj5E8cfy cmPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=I6uTHhL+0+TPAuEj0X3WF6fbivKaNKJgey9OfsP26dQ=; b=DZkvbSlkAk0VI690pGm9BEbZYUCRi49OQopPCnv1RFtmzcTfh1pBV+50wvCC5mWPoP qsYwqJreHT+yocdNzXJxd/8c/mhrP14Fg8gaRMf09gTm573H8RgXgbuYmtEWASV08a5x sCKIe0RNxz44Aj4b3ZJglxe/pfjnC8VC6uRtpW/rr5M9EzVpFbC/MevxvkGwLfcGVAEM cGCWoBdIPbJQIg5jXKsChJ0m+5jgGZ0nC8B1Hj6jiZQv8KQ+ur+GxIzY3VKLfcxk94Mk JgjghX7fKdIHqUHkkc8syEaLNYy6+wQlNjChIuXgj8bUzH2nz+MpTmIbXNd5IW887xNv tc0g== X-Gm-Message-State: AOAM530Ze2z8t9BumKzH7KkNkIdIQPYEoPBW4hyCPNwz7v0n9+fTeKeE KHvjQiE0qB6RRsQFxdk4AXA= X-Google-Smtp-Source: ABdhPJxe2DkyoPxwSs1HulOOPwVvEdeyAhvxk7CYWBOWGk5nXh7XxxScLO2id4BI31G3gHp2apXziA== X-Received: by 2002:a05:6214:c81:: with SMTP id r1mr2492556qvr.10.1637642739011; Mon, 22 Nov 2021 20:45:39 -0800 (PST) Received: from [192.168.1.149] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id de40sm5692441qkb.99.2021.11.22.20.45.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Nov 2021 20:45:38 -0800 (PST) Content-Type: multipart/alternative; boundary="------------0q7JSwO5GYsVn0cQ0Ti5uP4u" Message-ID: Date: Mon, 22 Nov 2021 23:45:36 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: Benjamin Kaduk Cc: Catherine Meadows , secdir@ietf.org, draft-ietf-calext-ical-relations.all@ietf.org, last-call@ietf.org, calsify@ietf.org References: <163527417024.2618.2790897732112692791@ietfa.amsl.com> <2f1455f9-f4a9-995d-3496-900d8f495cc8@gmail.com> <20211117015346.GI93060@kduck.mit.edu> From: Michael Douglass In-Reply-To: <20211117015346.GI93060@kduck.mit.edu> Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-calext-ical-relations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 04:45:46 -0000 This is a multi-part message in MIME format. --------------0q7JSwO5GYsVn0cQ0Ti5uP4u Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/16/21 20:53, Benjamin Kaduk wrote: > Hi Michael, Catherine, > > Catherine -- thanks for the review! > > Michael -- thanks for the proposed text. It's certainly better than > nothing, and we could iterate further if needed. > In particular, I wonder if we actually want to duplicate some of the > considerations from RFC 3986 that also apply to XML references, such as the > lack of a stability guarantee that fetching the referred-to resource will > actually produce the same results over time and for all entities that might > be performing the fetch operation. Thanks Ben. I can do that. Clearly the security section in RFC3986 is applicable to any URI. For XML documents it may also be the case that  the reference is invalid or becomes so over time. === OLD === 10. Security Considerations Applications using the LINK property need to be aware of the risks entailed in using the URIs provided as values. See [RFC3986] for a discussion of the security considerations relating to URIs. The CONCEPT and redefined RELATED-TO property have the same issues in that values may be URIs. === END OLD === === NEW === 10. Security Considerations Applications using the LINK property need to be aware of the risks entailed in using the URIs provided as values. See section 7 of [RFC3986] for a discussion of the security considerations relating to URIs. In particular note section 7.1 "Reliability and Consistency" of [RFC3986] which points out the lack of a stability guarantee for referenced resources. When the value is a REFERENCE type the targeted data is an XML document or portion thereof. Consumers need to be aware of the security issues related to XML processing - in particular those related to XML entities. See [RFC4918] - Section 20.6. Additionally note that the reference may be invalid or become so over time. The CONCEPT and redefined RELATED-TO property have the same issues in that values may be URIs. === END NEW === > > Thanks, > > Ben > > On Mon, Nov 08, 2021 at 11:55:05AM -0500, Michael Douglass wrote: >> On 10/26/21 14:49, Catherine Meadows via Datatracker wrote: >>> Reviewer: Catherine Meadows >>> Review result: Has Issues >>> >>> This draft describes increases the expressive and scope of relationships that >>> can be defined in iCalendar. It updates the already existing RELATED-TO by >>> allowing UID and URI as values and introduces a GAP parameter to specify the >>> length of time between two events. It also introduces three new properties: >>> CONCEPT (roughly, category), LINK (typed reference to external meta-data or >>> related resources), and REFID(used to identify a key that identifies all >>> components that use that REFID). The syntax of the relationships is given and >>> intended use cases are described. >>> >>> The introduction of greater expressiveness does not by itself introduce >>> security considerations, but the introduction of references to external sources >>> does, specifically for URIs, which are allowed as arguments of the RELATED-TO, >>> CONCEPT, and LINK properties. The authors of this document are aware of this, >>> and refer the reader to [RFC3986] for more information. I agree that the >>> security considerations related to use of URIs proposed in this draft are >>> covered by this RFC. >>> >>> I wonder though, if the document shouldn’t concern a similar warning about the >>> data type REFERENCE. This refers to an XML document or a portion of an XML >>> document. Since XML can also be used as an attack vector, a mention in the >>> Security Considerations Section would seem appropriate. >> I agree with the sentiment. I thought it would be easy to find a >> document with such a section - however the XML spec itself doesn't have >> a security section. There is at least section 20.6 in RFC4918 (WebDAV) >> which talks about external entities. Perhaps something like this: >> >> When the value is a REFERENCE type the targeted data is an XML document >> or portion thereof. Consumers need to be aware of the security issues >> related to XML processing - in particular those related to XML entities. >> See RFC4918 - Section 20.6 >> >> >> >>> >>> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki:https://trac.ietf.org/trac/sec/wiki/SecDirReview --------------0q7JSwO5GYsVn0cQ0Ti5uP4u Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 11/16/21 20:53, Benjamin Kaduk wrote:
Hi Michael, Catherine,

Catherine -- thanks for the review!

Michael -- thanks for the proposed text.  It's certainly better than
nothing, and we could iterate further if needed.
In particular, I wonder if we actually want to duplicate some of the
considerations from RFC 3986 that also apply to XML references, such as the
lack of a stability guarantee that fetching the referred-to resource will
actually produce the same results over time and for all entities that might
be performing the fetch operation.

Thanks Ben.

I can do that. Clearly the security section in RFC3986 is applicable to any URI.

For XML documents it may also be the case that  the reference is invalid or becomes so over time. 

=== OLD ===

10.  Security Considerations

   Applications using the LINK property need to be aware of the risks
   entailed in using the URIs provided as values.  See [RFC3986] for a
   discussion of the security considerations relating to URIs.

   The CONCEPT and redefined RELATED-TO property have the same issues in
   that values may be URIs.

=== END OLD ===

=== NEW ===

10.  Security Considerations

   Applications using the LINK property need to be aware of the risks
   entailed in using the URIs provided as values.  See section 7 of
   [RFC3986] for a discussion of the security considerations relating to
   URIs.

   In particular note section 7.1 "Reliability and Consistency" of
   [RFC3986] which points out the lack of a stability guarantee for
   referenced resources.

   When the value is a REFERENCE type the targeted data is an XML
   document or portion thereof.  Consumers need to be aware of the
   security issues related to XML processing - in particular those
   related to XML entities.  See [RFC4918] - Section 20.6.  Additionally
   note that the reference may be invalid or become so over time.

   The CONCEPT and redefined RELATED-TO property have the same issues in
   that values may be URIs.

=== END NEW ===


Thanks,

Ben

On Mon, Nov 08, 2021 at 11:55:05AM -0500, Michael Douglass wrote:

On 10/26/21 14:49, Catherine Meadows via Datatracker wrote:

Reviewer: Catherine Meadows
Review result: Has Issues

This draft describes increases the expressive and scope of relationships that
can be defined in iCalendar.   It updates the already existing RELATED-TO by
allowing UID and URI as values and introduces a GAP parameter to specify the
length of time between two events.  It also introduces three new properties:
CONCEPT (roughly, category), LINK (typed reference to external meta-data or
related resources), and REFID(used to identify a key that identifies all
components that use that REFID).  The syntax of the relationships is given and
intended use cases are described.

The introduction of greater expressiveness does not by itself introduce
security considerations, but the introduction of references to external sources
does, specifically for URIs, which are allowed as arguments of  the RELATED-TO,
CONCEPT, and LINK properties. The authors of this document are aware of this,
and refer the reader to [RFC3986] for more information.  I agree that the
security considerations related to use of URIs proposed in this draft are
covered by this RFC.

I wonder though, if the document shouldn’t concern a similar warning about the
data type REFERENCE.  This refers to an XML document or a portion of an XML
document.  Since XML can also be used as an attack vector, a mention in the
Security Considerations Section would seem appropriate.

I agree with the sentiment. I thought it would be easy to find a 
document with such a section - however the XML spec itself doesn't have 
a security section. There is at least section 20.6 in RFC4918 (WebDAV) 
which talks about external entities. Perhaps something like this:

When the value is a REFERENCE type the targeted data is an XML document 
or portion thereof. Consumers need to be aware of the security issues 
related to XML processing - in particular those related to XML entities. 
See RFC4918 - Section 20.6







_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
--------------0q7JSwO5GYsVn0cQ0Ti5uP4u-- From nobody Mon Nov 22 22:19:49 2021 Return-Path: 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 A130F3A07CF; Mon, 22 Nov 2021 22:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 RRCRAl5DtdEV; Mon, 22 Nov 2021 22:19:17 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2B0873A0799; Mon, 22 Nov 2021 22:19:16 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1AN6J5Fp019408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Nov 2021 01:19:10 -0500 Date: Mon, 22 Nov 2021 22:19:04 -0800 From: Benjamin Kaduk To: Michael Douglass Cc: Catherine Meadows , secdir@ietf.org, draft-ietf-calext-ical-relations.all@ietf.org, last-call@ietf.org, calsify@ietf.org Message-ID: <20211123061904.GZ93060@kduck.mit.edu> References: <163527417024.2618.2790897732112692791@ietfa.amsl.com> <2f1455f9-f4a9-995d-3496-900d8f495cc8@gmail.com> <20211117015346.GI93060@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-calext-ical-relations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 06:19:22 -0000 Hi Michael, Looks great. Many thanks for putting it together! -Ben On Mon, Nov 22, 2021 at 11:45:36PM -0500, Michael Douglass wrote: > > On 11/16/21 20:53, Benjamin Kaduk wrote: > > Hi Michael, Catherine, > > > > Catherine -- thanks for the review! > > > > Michael -- thanks for the proposed text. It's certainly better than > > nothing, and we could iterate further if needed. > > In particular, I wonder if we actually want to duplicate some of the > > considerations from RFC 3986 that also apply to XML references, such as the > > lack of a stability guarantee that fetching the referred-to resource will > > actually produce the same results over time and for all entities that might > > be performing the fetch operation. > > Thanks Ben. > > I can do that. Clearly the security section in RFC3986 is applicable to > any URI. > > For XML documents it may also be the case that  the reference is invalid > or becomes so over time. > > === OLD === > > 10. Security Considerations > > Applications using the LINK property need to be aware of the risks > entailed in using the URIs provided as values. See [RFC3986] for a > discussion of the security considerations relating to URIs. > > The CONCEPT and redefined RELATED-TO property have the same issues in > that values may be URIs. > > === END OLD === > > === NEW === > > 10. Security Considerations > > Applications using the LINK property need to be aware of the risks > entailed in using the URIs provided as values. See section 7 of > [RFC3986] for a discussion of the security considerations relating to > URIs. > > In particular note section 7.1 "Reliability and Consistency" of > [RFC3986] which points out the lack of a stability guarantee for > referenced resources. > > When the value is a REFERENCE type the targeted data is an XML > document or portion thereof. Consumers need to be aware of the > security issues related to XML processing - in particular those > related to XML entities. See [RFC4918] - Section 20.6. Additionally > note that the reference may be invalid or become so over time. > > The CONCEPT and redefined RELATED-TO property have the same issues in > that values may be URIs. > > === END NEW === > > > > > Thanks, > > > > Ben > > > > On Mon, Nov 08, 2021 at 11:55:05AM -0500, Michael Douglass wrote: > >> On 10/26/21 14:49, Catherine Meadows via Datatracker wrote: > >>> Reviewer: Catherine Meadows > >>> Review result: Has Issues > >>> > >>> This draft describes increases the expressive and scope of relationships that > >>> can be defined in iCalendar. It updates the already existing RELATED-TO by > >>> allowing UID and URI as values and introduces a GAP parameter to specify the > >>> length of time between two events. It also introduces three new properties: > >>> CONCEPT (roughly, category), LINK (typed reference to external meta-data or > >>> related resources), and REFID(used to identify a key that identifies all > >>> components that use that REFID). The syntax of the relationships is given and > >>> intended use cases are described. > >>> > >>> The introduction of greater expressiveness does not by itself introduce > >>> security considerations, but the introduction of references to external sources > >>> does, specifically for URIs, which are allowed as arguments of the RELATED-TO, > >>> CONCEPT, and LINK properties. The authors of this document are aware of this, > >>> and refer the reader to [RFC3986] for more information. I agree that the > >>> security considerations related to use of URIs proposed in this draft are > >>> covered by this RFC. > >>> > >>> I wonder though, if the document shouldn’t concern a similar warning about the > >>> data type REFERENCE. This refers to an XML document or a portion of an XML > >>> document. Since XML can also be used as an attack vector, a mention in the > >>> Security Considerations Section would seem appropriate. > >> I agree with the sentiment. I thought it would be easy to find a > >> document with such a section - however the XML spec itself doesn't have > >> a security section. There is at least section 20.6 in RFC4918 (WebDAV) > >> which talks about external entities. Perhaps something like this: > >> > >> When the value is a REFERENCE type the targeted data is an XML document > >> or portion thereof. Consumers need to be aware of the security issues > >> related to XML processing - in particular those related to XML entities. > >> See RFC4918 - Section 20.6 > >> > >> > >> > >>> > >>> > >> _______________________________________________ > >> secdir mailing list > >> secdir@ietf.org > >> https://www.ietf.org/mailman/listinfo/secdir > >> wiki:https://trac.ietf.org/trac/sec/wiki/SecDirReview From nobody Tue Nov 23 09:53:01 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 438013A0781; Tue, 23 Nov 2021 09:52:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Schwartz via Datatracker To: Cc: draft-ietf-spring-segment-routing-policy.all@ietf.org, last-call@ietf.org, spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163768997021.9950.16814747984245499137@ietfa.amsl.com> Reply-To: Benjamin Schwartz Date: Tue, 23 Nov 2021 09:52:50 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-spring-segment-routing-policy-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 17:52:51 -0000 Reviewer: Benjamin Schwartz Review result: Ready This document is ready with a few minor clarifications. It does not seem to require detailed Security Area review. Section 2.1 "printable ASCII characters": Needs reference to what qualifies as "printable ASCII". "color is a 32-bit numerical value": specify unsigned? Section 2.4 "represented as a 4-byte number": In what byte order? Section 9 "Protection": It's not clear who this is protecting from what. Possible alternative title: "Recovering from segment failure". From nobody Tue Nov 23 18:59:59 2021 Return-Path: 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 88F283A088A; Tue, 23 Nov 2021 18:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lp9INrds-6dT; Tue, 23 Nov 2021 18:59:50 -0800 (PST) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC1D3A0889; Tue, 23 Nov 2021 18:59:49 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id o1so2078459uap.4; Tue, 23 Nov 2021 18:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bQNFYAPRlZLEOYheRKr/kKp1ozGvk+GIgJqB6UwIvyY=; b=Kzj7lrDcTPAq4skWWYRJLN2Ef2CNi6vvTK6UaQyCEicTpJBTySq6nJut0y6t1L5VnE xk37bFYl3CPk2xUi+BFgq7HFikZ/C/X9AfwzAWeoBz06n0NGeoAdLUnW3m4fvCToxuxz 1bwgA82RPSYw0M9IoCgPKZ/mB+fGRkbiiF8rRGcRPVrJ/2M3VCt1TlNIEkqPEdrB3mJT XeW5T7Qd2I3n0B2Vo3hIOS7SjgLe2v/yLgWFCUqsoeSmAH/z57pkpfqsQDHkeohBDaZ1 3voAdPpHnMd+KgeRx6FrWCQBUL1d3k9uX6ev3LP5v0YaehX7Xspv+tm3LaQc/HdTKIpP M7iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bQNFYAPRlZLEOYheRKr/kKp1ozGvk+GIgJqB6UwIvyY=; b=ooyPvHDfkYzpv5BPsQqGRWrC/TJXU5s2O36NzAWhQbL+kyDGErSqJvWs/1CfG7cspe yxJLzRYjOEq9i53Cg/XOyvyLTJQglz/9s1dcow5Suzj+J63k0wHqXHevPRALFRmL/8rH gNY+v57oYVSG4GFgHgzsYYuFfjNzueorbJvLMBU1NHPR9ibJv4cqba1ZzFMKJcfgd2pC yPSgfEi8NTMcQ5gTEaHxnHAXo9NTvcZB102WnITypsV/BkdsoS6q4RmnBYtchUL2XR/Z sz5sNHcizQrHnFNbMp6Y0duR1LgE1+gayOUBB1N1wRmWdrAOpR7PBGJ6UG6YPH0/fbQR w4WA== X-Gm-Message-State: AOAM530ZQTflyeV/O53TmfvipHu/pVQDV+yjMJ+OmOrXyao+0qXET3oD aUUBoQIoCpvq0QQcxoQSiqPnVv1xxbJ3yulmyxg= X-Google-Smtp-Source: ABdhPJxGD6iitBdG4XYfmZUJAwZiu0p48I6s155wxvovHeObegel6kgBH1R3Qjr+WVuRxykKJSI4zgyLCnFuJM5xXvY= X-Received: by 2002:ab0:4405:: with SMTP id m5mr4319635uam.11.1637722788030; Tue, 23 Nov 2021 18:59:48 -0800 (PST) MIME-Version: 1.0 References: <163768997021.9950.16814747984245499137@ietfa.amsl.com> In-Reply-To: <163768997021.9950.16814747984245499137@ietfa.amsl.com> From: Ketan Talaulikar Date: Wed, 24 Nov 2021 08:29:36 +0530 Message-ID: To: Benjamin Schwartz Cc: secdir@ietf.org, draft-ietf-spring-segment-routing-policy.all@ietf.org, last-call@ietf.org, SPRING WG Content-Type: multipart/alternative; boundary="000000000000056dae05d1800d4e" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-spring-segment-routing-policy-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2021 02:59:53 -0000 --000000000000056dae05d1800d4e Content-Type: text/plain; charset="UTF-8" Hi Benjamin, Thanks for your review and please check in-line below for responses. On Tue, 23 Nov 2021 at 23:22, Benjamin Schwartz via Datatracker < noreply@ietf.org> wrote: > Reviewer: Benjamin Schwartz > Review result: Ready > > This document is ready with a few minor clarifications. It does not seem > to > require detailed Security Area review. > > Section 2.1 > "printable ASCII characters": Needs reference to what qualifies as > "printable > ASCII". > KT> This made me search around a bit. I've found RFC20 (which doesn't explicitly define it) and then RFC1342 that uses that term. I thought this was a well-known thing and not something that needs additional qualifications or references and happy to put the right reference if one exists. > > "color is a 32-bit numerical value": specify unsigned? > KT> Yes. Will update in the next update. > > Section 2.4 > "represented as a 4-byte number": In what byte order? > KT> Since this document does not specify an "on the wire protocol" the byte order would be dictated by the system implementing it. > > Section 9 "Protection": It's not clear who this is protecting from what. > Possible alternative title: "Recovering from segment failure". > KT> Ack. Will change to "Recovering from Network Failures". Thanks, Ketan --000000000000056dae05d1800d4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,

Thanks fo= r your review and please check in-line below for responses.

<= /div>

On Tue, 23 Nov 2021 at 23:22, Benjamin Schwartz via Datatracker <noreply@ietf.org> wrote:
=
Reviewer: Benjamin Schwar= tz
Review result: Ready

This document is ready with a few minor clarifications.=C2=A0 It does not s= eem to
require detailed Security Area review.

Section 2.1
"printable ASCII characters": Needs reference to what qualifies a= s "printable
ASCII".

KT> This made me search= around a bit. I've found RFC20 (which doesn't explicitly define it= ) and then RFC1342 that uses that term. I thought this was a well-known thi= ng and not something that needs additional qualifications or references and= happy to put the right reference if one exists.
=C2=A0

"color is a 32-bit numerical value": specify unsigned?

KT> Yes. Will update in the next update.
=
=C2=A0

Section 2.4
"represented as a 4-byte number": In what byte order?

KT> Since this document does not specify an &qu= ot;on the wire protocol" the byte order would be dictated by the syste= m implementing it.
=C2=A0

Section 9 "Protection": It's not clear who this is protecting= from what.
Possible alternative title: "Recovering from segment failure".

KT> Ack. Will change to "Recoveri= ng from Network Failures".

Thanks,
= Ketan
=C2=A0
--000000000000056dae05d1800d4e-- From nobody Wed Nov 24 01:23:49 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5F23A0D1E; Wed, 24 Nov 2021 01:23:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Klaas Wierenga via Datatracker To: Cc: alto@ietf.org, draft-ietf-alto-cdni-request-routing-alto.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163774582007.27269.9699917272767893675@ietfa.amsl.com> Reply-To: Klaas Wierenga Date: Wed, 24 Nov 2021 01:23:40 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-alto-cdni-request-routing-alto-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2021 09:23:48 -0000 Reviewer: Klaas Wierenga Review result: Has Issues Hi, I found 1 nit and one more substantial issue - the abstract says: OLD RFC 8008 defines precisely the semantics of FCI and provides guidelines on the FCI protocol, but the exact protocol is specified. I think it should read NEW RFC 8008 defines precisely the semantics of FCI and provides guidelines on the FCI protocol, but the exact protocol is not specified. - A bigger problem I have is with the Security Considerations You state "In the context of CDNI Advertisement, additional security considerations should be included as follows:", you then list a set of concerns, and then write: "Although protection strategies as described in Section 15 of [RFC7285] should be applied to address aforementioned security and privacy considerations, one additional information leakage risk introduced by this document could not be addressed by these strategies. " So are they ADDITIONAL or were they ALREADY ADRESSED in RFC7285? Do you want to call the ones you list out as specifically relevant for this use-case? Please be clear why you list them here. And if they are NOT sufficiently addressed yet, you need to address them here. For the additional risk of leaking info from one uCDN to another uCDN it is unclear to me whether the intended mitigation is meant as normative (SHOULD instead of should) and I am curious why you don't make it a MUST. From nobody Wed Nov 24 02:54:04 2021 Return-Path: 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 BA85A3A0D68; Wed, 24 Nov 2021 02:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, 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=btconnect.onmicrosoft.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 k8aPWU-jTGAq; Wed, 24 Nov 2021 02:53:48 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2070c.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::70c]) (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 5A62B3A0D67; Wed, 24 Nov 2021 02:53:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JYmFsPxP4Mnrx7S6tPX4UNIUShu7I/R6mk5s6PMDHYOwfnk9gb2KlKU/TKE7LG8lvjc4LPRwvmmopfxNaSBJ5wwV5uhjBjO43NdtOeIKv6g46u8lHo1cVtxeqAXy2Wl+z0o0I9uysx8lCO69g1qgh0XFellc6JOXjy5dZIGcop6ksVOm3ivu48KiHOq+nmAKeOysXQJkLQ8V1K8KURT3Y6c7p79Me+OEgHSJzK+M9WmQ81gv184w3VTXDtXT8P/UUuXXbXBxbmvHr6K3+TY3whcIsJC+LCzH463qHxL0Vs61mZK4Cpkm1JCItfbUyIhpOxPi8g27CwDli7z3LM2D7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uuKnvyLioqodrkGWqs7oH/lE+x63htMxsTUryu6MwRQ=; b=eH1Uwm/WR8dZwWabuI3atn6Ue8hIvrWnVuf2iJi1UOa3cdgGo3JwHFpgGc4h/3RxV+ybB/8moDmZRSYpss91uhiwW25AmtSc7N5wTBznhysXPAGpECQYHCCO8Tnxf5CrZKy1YqRILAF1nKYsJzrgWyMC5sg0rUTQDdv5YPxr76p/RnMrsWiciDxfJWYkh76yJjzJSeDY5DjA4NhJjlegaU2sC40ywJpQcPZIe166tvDUATVoEarnuaMqkUIwi5PUsB33d/FYB1QLlVN9tPWvvPKbNSY/YsFTFn9wENKO376s/KlqE3dtopTX8WWgJXoexxCXlIRRFVKllKCaM9If/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uuKnvyLioqodrkGWqs7oH/lE+x63htMxsTUryu6MwRQ=; b=wBXuk2EMiYDEaDoxeke2Idv2IdPhhiGhdsAmgnvYaixmCAYYf5fiudV3l5H1xpFBOTHvRCoLI7p7hKmbpC0G5P4Ez5qp+Q8ObPGKUkNHRkErSzN2WZbvsSpzWf+Ts5+pU+zYd5uPCrcVYkGmxWKBnL03QDK7HzdRjWT9ilFwS24= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com; Received: from DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) by DB9PR07MB7243.eurprd07.prod.outlook.com (2603:10a6:10:219::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.13; Wed, 24 Nov 2021 10:53:35 +0000 Received: from DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::2090:eb3c:59e2:b4b2]) by DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::2090:eb3c:59e2:b4b2%6]) with mapi id 15.20.4734.020; Wed, 24 Nov 2021 10:53:35 +0000 To: Kyle Rose , secdir@ietf.org References: <163760375473.4258.2594227295562861974@ietfa.amsl.com> Cc: i2nsf@ietf.org, last-call@ietf.org, draft-ietf-i2nsf-nsf-facing-interface-dm.all@ietf.org From: t petch Message-ID: <619E19A8.1050103@btconnect.com> Date: Wed, 24 Nov 2021 10:53:28 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <163760375473.4258.2594227295562861974@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0251.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::23) To DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) MIME-Version: 1.0 Received: from [192.168.1.65] (86.141.47.219) by LO2P265CA0251.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4734.20 via Frontend Transport; Wed, 24 Nov 2021 10:53:34 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2a52223e-9b0d-4c40-3c2c-08d9af38a963 X-MS-TrafficTypeDiagnostic: DB9PR07MB7243: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DFln7Bx3tmvRY/6hyf6i38mIlo0WHf9/x3aM3J3Tr5zw2dtX0iZxPoJkyCN+Rh+Nlk0f1ECB/ZsTfmaMUQSiL4u0r90qFkJ1mNMnasABhHLHlGm6kH0NzYzWHYS9Syu+LDwMuAriZdYrabtWT/novhFvNsDBP4zFS0SUd8kV8ayDR2ir/yGBRB3nYknKqc//ifqbLaqq+eGQ4dDMDvDYSghDMPFzc8T9nmjATGcxH+ViDlqqKYGgKUj2/eApr1sjKWT00QVX1V9aUmu+i8tXI9YHvwLQKsrDUoL/TfK1mkphZxFVjjR02anag9yjkYJrF4qVUOT//fgrTXtuzulvT+kq2OHWvB9AuTVRVGqbJNndelPwWXcMG+3UiQ6poxHQVw/nIA38cjmYYImJP3eo7BsAe9b/Ud0tgqi1qvyT3xGXXuVeHUjZKhhQTkQb7FulmSmka8kQMAf9PiOsu7X5PFRhX/0sxtT0la/YKpUhXO5LnSRbEvtVhNN6Ix8b/BexwEVsHwPShBr0ILyGwMi66v/bqIhHb6QoXo/Bny+kFy40raC8zvlY8jCh2hLIdSiogFcXoi9W1cShgdQ+wtANYJbDxBEdmN624P2rKQbSRE9W5vEPVBLT4TtxludFOLlBKzICbYt3VKTXv1Iv48uZh2qO4F5SCZyZ4mtH1801Kl4TJPtGJvy2/vhHolgain9CxWujH7fGRqZqS1yi+OGTFtzlw/sR/S1B3FfO2mbWoXOrQqeEdvEi6QcyHa/i2DvIj3kurUBMkMCqN01sDPi3Mf8d8VatMuMbY/prux+SeRU8NXAejzkVhM78hHFxHFi2uu61z7loE05RtUohcTrWqQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5546.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66946007)(6486002)(66476007)(8676002)(6666004)(66556008)(2906002)(5660300002)(8936002)(36756003)(82960400001)(86362001)(186003)(966005)(87266011)(33656002)(4326008)(2616005)(508600001)(956004)(53546011)(16576012)(316002)(38100700002)(26005)(52116002)(38350700002)(83380400001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?Windows-1252?Q?oje6dG8JNcIaaTGt7QllxEZC9Y79WNwhyAblCsayfNkplmm+Cs4Fzl/N?= =?Windows-1252?Q?ev48XGpN7eMCIANJem77zI9fmvISmREFPVte1VEN/pWLBmEhx564TZtr?= =?Windows-1252?Q?wBzefF6L0zyLcEZXjvQDcUJcNpkiD2WltFAZp8UeGzNM+BHTbjEA/MJt?= =?Windows-1252?Q?0WohDz/jamN8Xf6K6epws1LLRPOVjJj/bbo3+/gW7UjJ8MAyZmmMf9N6?= =?Windows-1252?Q?yuUBPnQxKXVUEVrAwDdTaA1XzjGznw8qdagc5mr6dw/8RQFvg3M+oJEU?= =?Windows-1252?Q?uQ/DxpWgyf3NyZCCKm5VybPGVZo4yGty4xlfxMM4GuRa9c8aeFgUMddU?= =?Windows-1252?Q?biqDJ9vFjiIpzxT0p0gO8MsHSzzLdTK4ZCj7uQDY9kUbPQktlJhetVY1?= =?Windows-1252?Q?V8IjeD03QJXW8tBBrXwRxuNW0HFrl6kDy3qYSVIwbLC3C79QOH2Tz0Ns?= =?Windows-1252?Q?OOG+Ke74NCaiI3gfjlfKlmqKQUR9oKSGQVPK2Re0CM43cGRy238+xOMr?= =?Windows-1252?Q?hw3Bnf4mMJCFcvQ6U0eCel6YloHFdOffPLPs0PZDUyuIkLgYT3w9KyVo?= =?Windows-1252?Q?SnehDRNpX/VcFEqWWSpQrysV0kkP1MYQAtLng0sx5U2IGQfs6h+rpXtv?= =?Windows-1252?Q?lEF9DhEMr83NrKcKYdDO/SjQo6fDx6WRvjZXcq91xMFH8m8rSzP4oI+X?= =?Windows-1252?Q?Hhveu3kW20GmPeHlO6rYci8JHGI7CAFoaYClq99/X9nljlck6GwHLN5j?= =?Windows-1252?Q?uyUnYWhUuJHwRbhSf9ZOsX63gabDBwzF38e7UHjGfUGsi0HXuwSu6VLD?= =?Windows-1252?Q?V2eGFEitVj0BEjFAAy/31ZCPQT4Me2BZPW67yUe1eGkkUkjGaZjeHIS/?= =?Windows-1252?Q?HiA0uPndbdPg+RzlpPfm7ikXzdZIQZNWLNKuY0oYyYzJwrrypkfC3Btg?= =?Windows-1252?Q?XblqoHLLMNlTQHePQV7CYkUx12oVJQlfEHgJYKLkJrD+4mCLu8q+cR36?= =?Windows-1252?Q?TdYUyoW5eNshIBT1/plzP6IfW8GmJhhCcTT34ADfI6e3z73d05QCGh/v?= =?Windows-1252?Q?gZVFTfmLEyY7Fs0c52pX7KzDchfZIcl4wuTTUmhcbuNAylH2cIs0YyTe?= =?Windows-1252?Q?lZ5GSuleV2T25+oBfCD/EQ5DSmLhK7Qym6TSvTxm5OL2jfvQsZfBXe4B?= =?Windows-1252?Q?oJt/CokicB0HyuyrT+66U34hHVRJSp0+Y20asQMuXP3L3+yUc7/e5Vgv?= =?Windows-1252?Q?3IIDX080JRh45vFZeRgt0sETlIDCo0craweh9LHIDEyxzxxU3/daxoKk?= =?Windows-1252?Q?0z38G030x2bLJ/cIcsOeFdS+niPZvtrc67ayTEdXadlT8z98JrHFYTQR?= =?Windows-1252?Q?ufklA7WB9W/BiyBdQSWTxOWzkAaX+wS2n7P3qvNrIVfff0l80cJlzvxM?= =?Windows-1252?Q?76gKjoViohbODbBdjTqcnj3sReYhAum8c6ewuKuID5l7w2IjSdFwzMMV?= =?Windows-1252?Q?yvQZAXvGb2CgLraL3uLYhM2VWsx0vV752YspwTNDzXJ7CCYPZ5B76vha?= =?Windows-1252?Q?E7Ge+HQYA2LCmI3tHrIXi2o+XQM1allnVA31WIFcTowCcuNa3cwr1ydq?= =?Windows-1252?Q?sLZC8DpV0EiYBD5q9sVcIzmX+oToqSIiwBTloMg+8dxsZPteZ/jI4Mgq?= =?Windows-1252?Q?1u6NyBFULKS1VCeb93wi8vpDjVQlrJvzF72DGvyOI+xbL5GA+luhiQFj?= =?Windows-1252?Q?5cvmvIff1PiiNIMCxeI=3D?= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a52223e-9b0d-4c40-3c2c-08d9af38a963 X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5546.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2021 10:53:35.0065 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: hHFkUOiOiy7s5c2Mb2/8nPN2QxDKNTwgn4cHyNTd36M4D4ctjHdCOIcvhVcczfd7fNYSpgGAR4JJHoIwSOQWSA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR07MB7243 Archived-At: Subject: Re: [secdir] [I2nsf] Secdir last call review of draft-ietf-i2nsf-nsf-facing-interface-dm-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2021 10:53:53 -0000 On 22/11/2021 17:55, Kyle Rose via Datatracker wrote: > Reviewer: Kyle Rose > Review result: Has Issues > > 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. > > This document Has Issues. > > I don't actually have a lot to say about this document from a security > perspective: its purpose is to describe, using YANG, a data model intended as > the basis for configuration schemas developed for implementations of the > Interface to Network Security Functions (I2NSF) framework. Security > considerations for the most part should be addressed in documents describing > system architecture or normatively detailing how implementations are to make > use of the data model described here. I'm not going to relitigate any such > issues here. > > The main issues I found in this document are ones that I, as someone not > terribly familiar with YANG, found troubling from a general engineering > perspective. These are best illustrated by example: > > * Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) `-address` > defined here? These concepts are generic enough that they should be in modules > of their own to minimize variation among data models and the errors that will > inevitably result from capturing the same concept in slightly different ways > that are not obvious to the user. * Overall, I have to imagine that much of > the `nsfintf` data model is generic enough that it should be captured > externally. For instance, `tcp-flags`, `port-range`, `flow-label`, `dscp`, > etc. are generally useful elements of an abstract transport data model that > they shouldn't be defined here, but rather incorporated from an external data > model that is maintained by those in (for example) the transport area. > > Am I just commenting on the YANG ecosystem in general? If these are standard > practices, then the overall ecosystem has major latent problems. Ideally, a > particular YANG module seems like it should describe only those elements > defined at a particular layer, in this case rules and actions, and use > reference external modules for elements that are defined at lower layers. The overall ecosystem has major latent problems IMHO but it is the IETF ecosystem that has them. It is very hard to get one WG to collaborate with another (and sometimes they wilfully trample on another's toes:-( Yes, there a lots of e.g. transport-related items that could be in a transport module are imported by the other WG that need them. I tried to get the TCPM WG interested in draft-ietf-opsawg-l3sm-l3nm which e.g. redefined the flags in the TCP header, and mostly failed. Likewise I sought to get the LSR WG interesed in a redefinition of OSPF but failed. The IETF does not work that way. Even the NETMOD WG, which might have claim to primacy with YANG, has failed to progress a common module, 6991bis, which has several generally useful constructs over and above RFC6991; the author recently asked on the NETMOD list if it was time to give up - I have not seen a reply. Over the years, I have seen I-D import 6991bis and have suggested they duplicate the definitions as there is no guarantee the 6991bis will ever become an RFC. Equally the NETCONF WG has spent many years, performed many summersaults, and has yet to produce common modules for the netconf protocol, especially with security aspects thereof. Closer to home, I first reviewed the i2nsf sdn module which is now an RFC. I failed to realise that there were another five or more overlapping I2NSF modules which cried out for a common module but which instead did not agree on naming, strucure and so on. By then, these I-D had been long in the making and my sense was and is that the WG does not have the energy to undertake such a major rethink in the approach so I focussed instead on getting the I-D more in line, using the same identifiers and structure, as the WG list will show. So, when it comes to the common good, the IETF structure militates against it. I think that the early work on YANG succeeded because it was building on SMI, which had had decades to get it right (or not), and on the existing DDL of a major manufacturer. OPSAWG recently produced a common module for VPN, doing so after two of the four potential importers were RFC, and having it last called with the third. Now the fourth is in last call, suggestions have been made how the common should be improved - too late! Do it early, do it late, either way the IETF is not organised for it. Tom Petch > Also some nits: > > * `ipvX-address` describes a subspace of the global IPvX address space, not a > single address. The name is going to cause problems. * The descriptions given > are often (usually?) just restatements of the entity name. Example is > `identity priority-by-order` described as "Identity for priority by order". > The description should provide some value for the user beyond simply restating > the name. * The headings in section 5 should be clearly labeled with the word > "example", such as "Example Security Requirement 1". * IPv6 addresses in text > MUST be represented in lowercase, according to RFC 5952 section 4.3. > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > . > From nobody Wed Nov 24 05:07:15 2021 Return-Path: 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 6550E3A03F4; Wed, 24 Nov 2021 05:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 J39foT9WLkwb; Wed, 24 Nov 2021 05:07:04 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765F63A0129; Wed, 24 Nov 2021 05:07:04 -0800 (PST) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Hzh8P1C5vz67Mxp; Wed, 24 Nov 2021 21:05:57 +0800 (CST) Received: from dggeml754-chm.china.huawei.com (10.1.199.153) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Wed, 24 Nov 2021 14:06:59 +0100 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml754-chm.china.huawei.com (10.1.199.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Wed, 24 Nov 2021 21:06:58 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2308.020; Wed, 24 Nov 2021 21:06:58 +0800 From: Qin Wu To: Klaas Wierenga , "secdir@ietf.org" CC: "alto@ietf.org" , "draft-ietf-alto-cdni-request-routing-alto.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-alto-cdni-request-routing-alto-17 Thread-Index: AdfhMfclE9Wk/vimS0+SC6eRcZ20DA== Date: Wed, 24 Nov 2021 13:06:58 +0000 Message-ID: <4028e5fe5b7f4318a83185fd5ff07a40@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-alto-cdni-request-routing-alto-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2021 13:07:10 -0000 SGksIEtsYWFzOg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBLbGFhcyBXaWVy ZW5nYSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXSANCuWPkemAgeaX tumXtDogMjAyMeW5tDEx5pyIMjTml6UgMTc6MjQNCuaUtuS7tuS6ujogc2VjZGlyQGlldGYub3Jn DQrmioTpgIE6IGFsdG9AaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYWx0by1jZG5pLXJlcXVlc3Qtcm91 dGluZy1hbHRvLmFsbEBpZXRmLm9yZzsgbGFzdC1jYWxsQGlldGYub3JnDQrkuLvpopg6IFNlY2Rp ciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYWx0by1jZG5pLXJlcXVlc3Qtcm91dGlu Zy1hbHRvLTE3DQoNClJldmlld2VyOiBLbGFhcyBXaWVyZW5nYQ0KUmV2aWV3IHJlc3VsdDogSGFz IElzc3Vlcw0KDQpIaSwNCg0KSSBmb3VuZCAxIG5pdCBhbmQgb25lIG1vcmUgc3Vic3RhbnRpYWwg aXNzdWUNCg0KLSB0aGUgYWJzdHJhY3Qgc2F5czoNCg0KT0xEDQpSRkMgODAwOCBkZWZpbmVzIHBy ZWNpc2VseSB0aGUgc2VtYW50aWNzIG9mIEZDSSBhbmQgcHJvdmlkZXMgZ3VpZGVsaW5lcyBvbiB0 aGUgRkNJIHByb3RvY29sLCBidXQgdGhlIGV4YWN0IHByb3RvY29sIGlzIHNwZWNpZmllZC4NCg0K SSB0aGluayBpdCBzaG91bGQgcmVhZA0KDQpORVcNClJGQyA4MDA4IGRlZmluZXMgcHJlY2lzZWx5 IHRoZSBzZW1hbnRpY3Mgb2YgRkNJIGFuZCBwcm92aWRlcyBndWlkZWxpbmVzIG9uIHRoZSBGQ0kg cHJvdG9jb2wsIGJ1dCB0aGUgZXhhY3QgcHJvdG9jb2wgaXMgbm90IHNwZWNpZmllZC4NCg0KLSBB IGJpZ2dlciBwcm9ibGVtIEkgaGF2ZSBpcyB3aXRoIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cw0KDQpZb3Ugc3RhdGUgIkluIHRoZSBjb250ZXh0IG9mIENETkkgQWR2ZXJ0aXNlbWVudCwgYWRk aXRpb25hbCBzZWN1cml0eQ0KICAgY29uc2lkZXJhdGlvbnMgc2hvdWxkIGJlIGluY2x1ZGVkIGFz IGZvbGxvd3M6IiwgeW91IHRoZW4gbGlzdCBhIHNldCBvZg0KICAgY29uY2VybnMsIGFuZCB0aGVu IHdyaXRlOiAiQWx0aG91Z2ggcHJvdGVjdGlvbiBzdHJhdGVnaWVzIGFzIGRlc2NyaWJlZCBpbg0K ICAgU2VjdGlvbiAxNSBvZiBbUkZDNzI4NV0gc2hvdWxkIGJlIGFwcGxpZWQgdG8gYWRkcmVzcyBh Zm9yZW1lbnRpb25lZCBzZWN1cml0eQ0KICAgYW5kIHByaXZhY3kgY29uc2lkZXJhdGlvbnMsIG9u ZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGxlYWthZ2Ugcmlzaw0KICAgaW50cm9kdWNlZCBieSB0 aGlzIGRvY3VtZW50IGNvdWxkIG5vdCBiZSBhZGRyZXNzZWQgYnkgdGhlc2Ugc3RyYXRlZ2llcy4g Ig0KDQpTbyBhcmUgdGhleSBBRERJVElPTkFMIG9yIHdlcmUgdGhleSBBTFJFQURZIEFEUkVTU0VE IGluIFJGQzcyODU/IERvIHlvdSB3YW50IHRvIGNhbGwgdGhlIG9uZXMgeW91IGxpc3Qgb3V0IGFz IHNwZWNpZmljYWxseSByZWxldmFudCBmb3IgdGhpcyB1c2UtY2FzZT8gUGxlYXNlIGJlIGNsZWFy IHdoeSB5b3UgbGlzdCB0aGVtIGhlcmUuIEFuZCBpZiB0aGV5IGFyZSBOT1Qgc3VmZmljaWVudGx5 IGFkZHJlc3NlZCB5ZXQsIHlvdSBuZWVkIHRvIGFkZHJlc3MgdGhlbSBoZXJlLg0KW1FpbiBXdV0g OiBJIGJlbGlldmUgdGhlc2UgQURESVRJT05BTCBzZWN1cml0eSBoYXMgYWxyZWFkeSBiZWVuIEFE RFJFU1NFRCBieSBwcm90ZWN0aW9uIHN0cmF0ZWdpZXMgcHJvcG9zZWQgaW4gUkZDNzI4NSwgYnV0 IHRoZXJlIGlzIG9uZSBleGNlcHRpb24gY2FzZSwgaS5lLiwiIG9uZSBhZGRpdGlvbmFsIGluZm9y bWF0aW9uIGxlYWthZ2Ugcmlzaw0KICAgaW50cm9kdWNlZCBieSB0aGlzIGRvY3VtZW50IGNvdWxk IG5vdCBiZSBhZGRyZXNzZWQgYnkgdGhlc2Ugc3RyYXRlZ2llcy4iDQogICBNYXliZSB0aGUgZmly c3QgcGFyYWdyYXBoIGFuZCB0aGUgc2Vjb25kIHBhcmFncmFwaCBsYWNrIGEgZ29vZCBjb25uZWN0 aW9uIGxpbmssIEkgd291bGQgcHJvcG9zZSB0byBtYWtlIHRoZSBmb2xsb3dpbmcgY2hhbmdlOg0K ICAgT0xEIFRFWFQ6DQogICAiDQogICAgSW4gdGhlIGNvbnRleHQgb2YgQ0ROSSBBZHZlcnRpc2Vt ZW50LCBhZGRpdGlvbmFsIHNlY3VyaXR5DQogICBjb25zaWRlcmF0aW9ucyBzaG91bGQgYmUgaW5j bHVkZWQgYXMgZm9sbG93czoNCiAgICINCiAgIE5FVyBURVhUOg0KICAgIg0KICAgIEluIHRoZSBj b250ZXh0IG9mIENETkkgQWR2ZXJ0aXNlbWVudCwgdGhlIGZvbGxvd2luZyBzZWN1cml0eQ0KICAg IGlzc3VlcyBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgYXMgZm9sbG93czoNCiAgICINCkZvciB0aGUg YWRkaXRpb25hbCByaXNrIG9mIGxlYWtpbmcgaW5mbyBmcm9tIG9uZSB1Q0ROIHRvIGFub3RoZXIg dUNETiBpdCBpcyB1bmNsZWFyIHRvIG1lIHdoZXRoZXIgdGhlIGludGVuZGVkIG1pdGlnYXRpb24g aXMgbWVhbnQgYXMgbm9ybWF0aXZlIChTSE9VTEQgaW5zdGVhZCBvZiBzaG91bGQpIGFuZCBJIGFt IGN1cmlvdXMgd2h5IHlvdSBkb24ndCBtYWtlIGl0IGEgTVVTVC4NCltRaW4gV3VdIEkgaGF2ZSBu byBzdHJvbmcgb3BpbmlvbiBvbiB3aGF0IGxhbmd1YWdlIHNob3VsZCBiZSB1c2VkLCBidXQgSSBh Z3JlZSBTSE9VTEQgaXMgYmV0dGVyIHRoYW4gc2hvdWxkLg0KDQo= From nobody Wed Nov 24 15:01:22 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC513A0CC5; Wed, 24 Nov 2021 15:01:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-httpbis-priority.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163779487777.25643.17109907784762380095@ietfa.amsl.com> Reply-To: Robert Sparks Date: Wed, 24 Nov 2021 15:01:17 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-httpbis-priority-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2021 23:01:18 -0000 Reviewer: Robert Sparks Review result: Ready 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. Document reviewed: draft-ietf-httpbis-priority-10 This document is ready for publication as a Proposed Standard RFC This document is easy to read, and appears straightforward to implement (though there are complications for implementors that the document does a good job of exploring). The mechanism improves the overall robustness of the HTTP protocol family. From nobody Wed Nov 24 18:37:54 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DF53A0DF1; Wed, 24 Nov 2021 18:37:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Melinda Shore via Datatracker To: Cc: draft-ietf-i2nsf-nsf-monitoring-data-model.all@ietf.org, i2nsf@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163780786268.27164.7999459129717816374@ietfa.amsl.com> Reply-To: Melinda Shore Date: Wed, 24 Nov 2021 18:37:42 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-i2nsf-nsf-monitoring-data-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 02:37:43 -0000 Reviewer: Melinda Shore Review result: Not Ready I've marked this "not ready" only because of the quality of the writing, which is both unidiomatic and ungrammatical throughout the document. But, the draft has been through working group last call, and if the working group is good with it, I'm good with it - I'm here to do a security review, and it's basically fine in that regard. A couple of nits: In section 6, it seems to me that by having two different dampening messages you risk having both no-dampening and on-repetition active at the same time (implementers don’t always make good decisions). Setting on-repetition to an impossible value (say, -1) could serve the same purpose as no-dampening and avoid possible implementation errors. I'm curious why you’re monitoring system things (cpu, disk), since presumably those are also being monitored elsewhere. In the security considerations section you may want to discuss some of the limitations of relying not he transport protocol to protect the data, particularly around data authenticity, etc. From nobody Wed Nov 24 18:46:29 2021 Return-Path: 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 825063A0DFE; Wed, 24 Nov 2021 18:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 t4as19K8kIWV; Wed, 24 Nov 2021 18:46:13 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE5B3A0DF0; Wed, 24 Nov 2021 18:46:12 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id k37so12441174lfv.3; Wed, 24 Nov 2021 18:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IXXJfYYEH96WFbnUXbha7FBxAfyV4t06lEQcEovwO5k=; b=Mg4mwo/+11N/FUv7wAqPOOJRrDtctlHGO9l9zYSodbnNr1CTvuBC1Uwn1CxdTU5c3E RQqMRmQ3USa2RFgIrHdp16gkM1lKKfIScUoY5toi6pvc7A3STTihZmXjwnT3AmcKI0kT 4yKGEPAeyVekvG8UEwisSv09jiYKHfQyv9kGygV/UGO7pygF18F+DLeD5YTaY2IzzzfD UjDcZLhQJixlf7jX/ub109M24Gso8NmNh7Qsw/wrqcdG74zxYSxXHtT6xOSUX613ncgL 2Ywf0ZcqZifS1xRRMM3FlwIelxuXZUGXdOJz0lY1itDQSI3O3o3BZNEwC3qxt5Vl6y1D c6YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IXXJfYYEH96WFbnUXbha7FBxAfyV4t06lEQcEovwO5k=; b=iq9wxUSrdK9jpOv7gYHHKWdry2Qy6syYanHJmbC9Zt0axDnUzfnHNmeI6ohUNgvgnK 4dO6u6J0BRrqq4h1GSnPC+bMxr1gYPW2oqEKbKq40tLZUwuAP7QyzlxJHO/YUtek0lqS wW0v6LQbK1qmEQGwWMuQGTx/O/ti9rYEBlbDsYQVUQl16X5RmnAT+lRWo5INOtN48OyI 63weQUCWB9kYyanP4mOfvjN+y7dg1A2OLyzF4XoMoo0YUgtrSH1XNX90Y6HQQ01wp6Xi m81mitvHXD8ejD1AbWZNaV9KKDuz/mssxEqAvzBKyIhPKW3Odrvhm3ne7ipdkLQyfz8t Bjsg== X-Gm-Message-State: AOAM530intyqq8dxWtDelBBd8krmZiSJOUxqMa9IJV+OtePjoIZOIspi KK7Ahbrga2ZuHKDCp7cgtx3/1Mz2M3h4NoB7zV0= X-Google-Smtp-Source: ABdhPJwbBLktewfk1d8uH/Zc5RboeZ9BUkVJv4EfldGO3Gn+sqoSbdxT56BgGvEPw/vgI68IFK35uuwAAW6rxCBp8ic= X-Received: by 2002:a19:484b:: with SMTP id v72mr19462766lfa.338.1637808369322; Wed, 24 Nov 2021 18:46:09 -0800 (PST) MIME-Version: 1.0 References: <163780786268.27164.7999459129717816374@ietfa.amsl.com> In-Reply-To: <163780786268.27164.7999459129717816374@ietfa.amsl.com> From: "Mr. Jaehoon Paul Jeong" Date: Thu, 25 Nov 2021 11:45:34 +0900 Message-ID: To: Melinda Shore Cc: secdir@ietf.org, "i2nsf@ietf.org" , draft-ietf-i2nsf-nsf-monitoring-data-model.all@ietf.org, Last Call , Patrick Lingga , "Mr. Jaehoon Paul Jeong" Content-Type: multipart/alternative; boundary="000000000000104fe005d193fa99" Archived-At: Subject: Re: [secdir] [I2nsf] Secdir last call review of draft-ietf-i2nsf-nsf-monitoring-data-model-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 02:46:19 -0000 --000000000000104fe005d193fa99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Melinda, I will address your comments on the revision on this draft. Thanks. Best Regards, Paul On Thu, Nov 25, 2021 at 11:37 AM Melinda Shore via Datatracker < noreply@ietf.org> wrote: > Reviewer: Melinda Shore > Review result: Not Ready > > I've marked this "not ready" only because of the quality of the writing, > which > is both unidiomatic and ungrammatical throughout the document. But, the > draft > has been through working group last call, and if the working group is goo= d > with > it, I'm good with it - I'm here to do a security review, and it's basical= ly > fine in that regard. > > A couple of nits: > > In section 6, it seems to me that by having two different dampening > messages > you risk having both no-dampening and on-repetition active at the same ti= me > (implementers don=E2=80=99t always make good decisions). Setting on-repe= tition to > an > impossible value (say, -1) could serve the same purpose as no-dampening a= nd > avoid possible implementation errors. > > I'm curious why you=E2=80=99re monitoring system things (cpu, disk), sinc= e > presumably > those are also being monitored elsewhere. > > In the security considerations section you may want to discuss some of th= e > limitations of relying not he transport protocol to protect the data, > particularly around data authenticity, etc. > > > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > --000000000000104fe005d193fa99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Melinda,
I will address your comments on the revisi= on on this draft.

Thanks.

Best Regards,
Paul


On Thu, Nov 25, 2021 at 1= 1:37 AM Melinda Shore via Datatracker <noreply@ietf.org> wrote:
Reviewer: Melinda Shore
Review result: Not Ready

I've marked this "not ready" only because of the quality of t= he writing, which
is both unidiomatic and ungrammatical throughout the document.=C2=A0 But, t= he draft
has been through working group last call, and if the working group is good = with
it, I'm good with it - I'm here to do a security review, and it'= ;s basically
fine in that regard.

A couple of nits:

In section 6, it seems to me that by having two different dampening message= s
you risk having both no-dampening and on-repetition active at the same time=
(implementers don=E2=80=99t always make good decisions).=C2=A0 Setting on-r= epetition to an
impossible value (say, -1) could serve the same purpose as no-dampening and=
avoid possible implementation errors.

I'm curious why you=E2=80=99re monitoring system things (cpu, disk), si= nce presumably
those are also being monitored elsewhere.

In the security considerations section you may want to discuss some of the<= br> limitations of relying not he transport protocol to protect the data,
particularly around data authenticity, etc.



_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
--000000000000104fe005d193fa99-- From nobody Thu Nov 25 06:02:49 2021 Return-Path: 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 9B97F3A089E; Thu, 25 Nov 2021 06:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pL7TuIegQ2OC; Thu, 25 Nov 2021 06:02:42 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C8F3A089A; Thu, 25 Nov 2021 06:02:42 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id w22so7672519ioa.1; Thu, 25 Nov 2021 06:02:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=DOvITYLZYi4w4gH4c5/lY0QYRZbREdDso+ud1jh1Qb0=; b=TWg0hRj+g9WvibgPS3uHMfzp+lU9wXe/ZDuzTUNKv/reswsu9NNN7LT8uvvhUs99/F IwB2SGspWgiMed+0hxUxB9XS1RyGyC/omK5n+RlDWravrzqxWbSJ9xGxmQB8gMILyBMr VxLXocVSbmuGCfjtQYoO8AoVep7CY1gKRLDGxRnpufYWMDK5rp1GsopOpJ02IJ2M/zOG ksTmgqF4gRIQO6wFTViZHDoD9bxg8BoOEnWLAvsVP22gKS1TVZiAq0x0EiPgB4UcuIMz IOU3w15dom6ioMNouHBaqALko52/iLPjjIAopYZssMZ9vTS2UQeFB6FusapHw2QkiBL6 SsQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=DOvITYLZYi4w4gH4c5/lY0QYRZbREdDso+ud1jh1Qb0=; b=2l2XBpsID+R9cO9eimSe+WVAFNpq+PDAwghQHEtikQqJjDj+eveVvaZrsh3gowq/MG H3Yjm7LNXcx3QAC0RptIyvWSNURKeuxHC5x4uiUwih/Hek0qrQ3uDl3BBPB0Z6bK4jmt AGnrjRag9B1rAF+fKddeIhJk4izim3CtdgjxX+cLAzCOF8JFxbQW1ym1vG6qD44TqJ2g c5EPsAft2DLMdA+DgBg9XhcOLaLwGWvoQuJw2SV0JiDB/0LuSC1XNNOcMPY5la6EBS5Z kyT0kqfZ5i93VBu1WSJ6Drz1JsOwuEYci//XoOBsRhIN/a2iu4xicpZ6xd5G6iP0A8d4 8neQ== X-Gm-Message-State: AOAM533g8Ozs5Jf8uZnvWDKoQnwdgr1fLvzP3QoRL1Ch7YX4w5K729kv 19HT5Gd7Fc1KFLR66CIC7oQJa9dXm30= X-Google-Smtp-Source: ABdhPJyGgMf26d038o+mu29aH2nuAmTc7Mnbboo4IjWDDx3+E8Kes1dgD1SHGbQT4sF818xaitcQeg== X-Received: by 2002:a05:6638:2178:: with SMTP id p24mr29235348jak.142.1637848960508; Thu, 25 Nov 2021 06:02:40 -0800 (PST) Received: from MacBook-Pro.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id x5sm1515537iov.50.2021.11.25.06.02.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Nov 2021 06:02:39 -0800 (PST) MIME-Version: 1.0 Date: Thu, 25 Nov 2021 16:02:32 +0200 From: Yaron Sheffer Thread-Topic: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> Message-ID: References: <163717559932.18384.2156774121641934785@ietfa.amsl.com>, <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> To: Kent Watsen Cc: "secdir@ietf.org" , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 14:02:48 -0000

Hi Kent,

 

Thank you for addre= ssing my comments, I am happy with most of your responses but I do have a f= ew remaining questions:

 

  • The commit that removes t= he dependency on IDevID and LDevID does not fix the issue of non-orthogonal= ity. There is very detailed description for CMP and CMC, but nothing for PK= CS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it= =E2=80=99ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#= 10 for these certs is still TBD=E2=80=9D?
  • I suggest to a= dd the following reference to the paragraph on quality randomness, as a str= ong proof that this is a real world concern:

 

Heninger, N., Durume= ric, Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detect= ion of Widespread Weak Keys in Network Devices", Proceedings of the 21= st USENIX Security Symposium , August 2012, <https://factorable.net/>.

 

    =
  • I understand that key generation is out of scope and maybe this needs t= o be a separate work item, but recommending periodic replacement of the cer= ts without recommending a suitable mechanism leaves this solution with a bi= g hole.
  • It is really annoying that 21 years after PKCS #= 10, we still cannot provide a reference that would enable implementers to f= ind out all available, non-deprecated AlgorithmIdentifier values. (And I re= alize there=E2=80=99s little you can do about it.)

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

 

From: = Kent Watsen <kent+ietf@watsen.net>
Date: Monday, November 2= 2, 2021 at 23:49
To: Yaron Sheffer <yaronf.ietf@gmail.com><= br>Cc: secdir@ietf.org <secdir@ietf.org>, draft-ietf-netconf-s= ztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, last= -call@ietf.org <last-call@ietf.org>, netconf@ietf.org <netconf@iet= f.org>
Subject: Re: Secdir last call review of draft-ietf-netc= onf-sztp-csr-11

Hi Yaron,

 

Thank you for your valuable comments.  My co-au= thors and I have the following

responses to your comments.

 

 



On Nov 17, 2021, at 1:59 PM, Ya= ron Sheffer via Datatracker <noreply= @ietf.org> wrote:

 

Reviewer: Yaron Sheffer
Review result: Has Issues<= br>
This draft defines a mechanism for a device, when it first starts, t= o generate
a CSR to get itself provisioned with one or more certificates= it needs to
identify itself during its normal operation.

* I was= confused that the document starts out describing a generic cert requestmechanism. Then deep into the YANG modules, it turns out that there is gui= dance
(only?) for very specific types of certs, namely LDevID and IDevID= . And the
choice is non-orthogonal: it is unclear what is the guidance f= or other certs
when using CMC and CMP, and conversely, whether these two= certs can be
generated with a PKCS#10 CSR.

 =

We updated = the YANG module to greatly remove references to IDevID/LDevID.

 

Specifica= lly:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 1) s/IDevID/initial device= identity certificate/g

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 2)&nb= sp;s/LDevID/local device identity certificate/g

=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3) manually rewrap lines to col 69 as required

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4) removed the terminology-disclaimer = block at top

 

 <= /p>

Good?

 



=

* I suggest adding a S= ecurity Considerations section about the need for strong
randomness, whi= ch is often unavailable to small embedded devices at the early
stages of= provisioning. I wish we were more successful with:
https://= datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial-random-00<= /o:p>

 

OLD:

    It is RECOMMENDED that a new private key is ge= nerated for each CSR
    described in this document.

NE= W:

    It is RECOMMENDED that a new private key is generat= ed for each CSR
    described in this document.

  =   This private key MUST be generated using a quality random source. Th= e
    use of inadequate pseudo-random number generators (PRNGs= ) to
    generate private keys can result in little or no secu= rity.  An attacker may
    find it much easier to reprodu= ce the PRNG environment that produced
    the private key, sea= rching the resulting small set of possibilities, rather
    th= an brute force searching the whole private key space.  The generation<= br>    of quality random numbers is difficult.  BCP 106 [RFC= 4086] offers
    important guidance in this area.

and we added a= n Informational reference to RFC 4086.

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>Good now?

 



<= /p>

* Negotiation (?) of the CSR f= ormat and supported algorithms is unclear in Sec.
2.2: is it the client = that provides the values it supports and the server picks
one? Alternati= vely, is the list conveyed by the server in the error-info and so
the cl= ient knows exactly what is supported? IOW, why include these values at
a= ll in error-info?

 

Section 2.1 states the sequence of = exchanges, but we went ahead and added more context to the examples for add= itional clarity.  The diff is here: https= ://github.com/netconf-wg/sztp-csr/commit/7ed4f5b1daee539dc9071061e4d427e843= 467d02

 

Better?

 



* It is not clear from Sec. 2.2 how exactly the client is suppo= sed to associate
one of possibly multiple received certificates to the C= SR it just sent out.
Surely it is not expected to grep for the string &q= uot;Newly-Generated"?

 

There doesn=E2=80=99t have= to be any logic on the client to detect the signed certificate or, fo= r that matter, to ensure that the server sent one at all.  The point &= nbsp;of the bootstrap process is to *configure* the SZT= P-client, and the client's only post-update logic is to =E2=80=9Crun as con= figured=E2=80=9D, whatever that might be.

 

That said, it wouldn=E2=80=99t=  be hard for a client to, e.g., search a =E2=80=9Ckeystore" mecha= nism for a key having the key used in the CSR and then search certificates = associated with that key = for that cert having the matching attributes (e.g., the =E2=80=9CSubject=E2= =80=9D attribute) as in the CSR.

 

Makes sense?   [No update to the d= raft was made to address this comment]

 



* 2.3: the description of "error-info"= still does not specify if the server
should list all CSR format and alg= orithms it supports.

 

 

Section 2.1 indicates tha= t the client=E2=80=99s message lists all of the key-algorithms and csr= -formats it supports and the server=E2=80=99s message merely selects t= he specific algorithm/format it wishes the client use.   This comment = is nearly identical to one of your earlier comments, for which we added mor= e context around the examples.  Good enough?  

 

 

* Is there really nee= d to support 3 different CSR formats?

 

Yes and, FWIW, = the PKI world has even more formats; we actually restricted them to just th= ose that are most widely implemented.

 



* Where does the client indicate which cert is wa= nts to receive based on this
CSR, e.g. "this CSR is for a LDevID&qu= ot;? Is this information embedded in the CSR
itself?

 

The CSR is always for an LDevID.  It can never be for an IDevID, wh= ich can (effectively) only be generated/installed by the vendor during the = device=E2=80=99s manufacturing process. 

 

Makes sense?   [No update to the draft was made to address this= comment]

 

 

* Is RFC 2986 (published Nov. 2000) the best referenc= e for an
AlgorithmIdentifier? Is there no IANA registry we could referen= ce instead?

 

There is not an IANA registry for AlgorithmIde= ntifiers.  RFC 2986 is the reference for the PKCS#10 CSR.

 

[No update to the draft was made to address this comment= ]



 



* When talking about algorithm = matching, I suggest changing "It is an error
if..." into norma= tive text, "The recipient MUST reject...".

=  

= OLD:

         I= t is an error if the 'AlgorithmIdentifier' field
      &n= bsp;  contained inside the 'SubjectPublicKeyInfo' field
  &nbs= p;      does not match the algorithm identified by the
&n= bsp;        'selected-algorithm' node.";

NE= W:

         If the 'AlgorithmIdentifier' fi= eld contained inside the
         certificate '= SubjectPublicKeyInfo' field does not match
        &= nbsp;the algorithm identified by the 'selected-algorithm' node,
  &= nbsp;      then the client MUST reject the certificate and r= aise an
         error.";

 

Good?

&n= bsp;

 

 

* &= quot;Details for how to generate a new private key and associate a new iden= tity
certificate are outside the scope of this document." - This is= rather
disappointing, since we just RECOMMENDED to regenerate certs per= iodically (and
given that IOT devices often lack HSMs).

 

Understood, but key-generation is indeed outside the scope of this documen= t.

 

[No update to the draft was made to = address this comment]



=





Thanks again,

Kent (and Sean and Russ)

 

 

 

= From nobody Thu Nov 25 07:49:42 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A77E83A0A93 for ; Thu, 25 Nov 2021 07:49:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163785538002.11308.10788074707036377739@ietfa.amsl.com> Date: Thu, 25 Nov 2021 07:49:40 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 15:49:41 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2021-12-02 Reviewer LC end Draft Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Tero Kivinen R2021-06-21 draft-ietf-mpls-lsp-ping-ospfv3-codepoint Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Scott Kelly 2021-10-27 draft-ietf-regext-rfc7484bis Tero Kivinen R2021-06-21 draft-ietf-mpls-lsp-ping-ospfv3-codepoint Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Joseph Salowey 2021-11-24 draft-ietf-bess-srv6-services Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Valery Smyslov 2021-11-29 draft-ietf-acme-dtnnodeid Sean Turner 2021-11-26 draft-ietf-httpbis-http2bis Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Paul Wouters R2021-11-29 draft-ietf-i2nsf-capability-data-model Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Liang Xia 2021-03-17 draft-ietf-core-sid Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Kathleen Moriarty 2021-10-25 draft-ietf-dots-multihoming Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Next in the reviewer rotation: Loganaden Velvindron Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Dacheng Zhang From nobody Thu Nov 25 07:54:20 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E09E3A0ADE; Thu, 25 Nov 2021 07:54:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: draft-ietf-mpls-lsp-ping-ospfv3-codepoint.all@ietf.org, last-call@ietf.org, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163785565051.8247.13009734476789714657@ietfa.amsl.com> Reply-To: Tero Kivinen Date: Thu, 25 Nov 2021 07:54:10 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-mpls-lsp-ping-ospfv3-codepoint-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 15:54:11 -0000 Reviewer: Tero Kivinen Review result: Ready 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. This document allocates a code point for OSPFv3 for MPLS LSP Ping and updates previous allocation to only cover OSPFv2. It also defines behavior when using IPv6 with OSPv3. This is the rereview of the document, and all my comments in previous review were addressed. I think the document is ready. From nobody Fri Nov 26 08:01:04 2021 Return-Path: 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 52F6A3A07DC for ; Fri, 26 Nov 2021 08:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 vUf9GPUJrNBS for ; Fri, 26 Nov 2021 08:00:58 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A443A07DD for ; Fri, 26 Nov 2021 08:00:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 15B8B300BDE for ; Fri, 26 Nov 2021 10:53:12 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Gyhn51Wj24E4 for ; Fri, 26 Nov 2021 10:53:07 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6452A300B38; Fri, 26 Nov 2021 10:53:07 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_643D9F68-DCD6-4ACC-8D68-EF10BCB53217" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Fri, 26 Nov 2021 10:53:03 -0500 In-Reply-To: Cc: Kent Watsen , IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2021 16:01:02 -0000 --Apple-Mail=_643D9F68-DCD6-4ACC-8D68-EF10BCB53217 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron: > Thank you for addressing my comments, I am happy with most of your = responses but I do have a few remaining questions: > =20 > The commit that removes the dependency on IDevID and LDevID does not = fix the issue of non-orthogonality. There is very detailed description = for CMP and CMC, but nothing for PKCS #10 (p10-csr). Does it mean =E2=80=9C= use PKCS#10 out of the box and it=E2=80=99ll just work=E2=80=9D? Or does = it mean =E2=80=9Cthe usage of PKCS#10 for these certs is still TBD=E2=80=9D= ? PKCS#10 is pretty simple. Are you aware of anything more that ought to = be said? > I suggest to add the following reference to the paragraph on quality = randomness, as a strong proof that this is a real world concern: > =20 > Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining = Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", = Proceedings of the 21st USENIX Security Symposium , August 2012, = >. In another thread, something like this was suggested for another = document: Implementations must randomly generate nonces and private keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An = attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of = possibilities, rather than brute force searching the whole key space. As example for predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],= NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and others offers valuable guidance in this area. If this approach works for you, we'll dig up the appropriate references. > =20 > I understand that key generation is out of scope and maybe this needs = to be a separate work item, but recommending periodic replacement of the = certs without recommending a suitable mechanism leaves this solution = with a big hole. I do not agree. It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair. Getting more detailed would be algorithm = specific, which is not appropriate in this document. > It is really annoying that 21 years after PKCS #10, we still cannot = provide a reference that would enable implementers to find out all = available, non-deprecated AlgorithmIdentifier values. (And I realize = there=E2=80=99s little you can do about it.) So, we will leave this part alone. Russ --Apple-Mail=_643D9F68-DCD6-4ACC-8D68-EF10BCB53217 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron:

Thank you for addressing my = comments, I am happy with most of your responses but I do have a few = remaining questions:
 
  • The commit that removes the dependency on IDevID and LDevID = does not fix the issue of non-orthogonality. There is very detailed = description for CMP and CMC, but nothing for PKCS #10 (p10-csr). Does it = mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99ll just work=E2=80= =9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for these certs is = still TBD=E2=80=9D?

PKCS#10 is pretty simple.  Are you aware of = anything more that ought to be said?

  • I suggest to = add the following reference to the paragraph on quality randomness, as a = strong proof that this is a real world concern:
 
Heninger, N., Durumeric, = Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of = Widespread Weak Keys in Network Devices", Proceedings of the 21st USENIX Security Symposium , = August 2012, <https://factorable.net/>.
=

In another thread, something like this was = suggested for another document:

  =  Implementations must randomly generate nonces and = private keys.
   The use of inadequate pseudo-random number = generators (PRNGs) to
  =  generate cryptographic keys can result in little or no security. = An attacker
   may find it much easier to = reproduce the PRNG environment that
  =  produced the keys, searching the resulting small set of = possibilities,
   rather than brute force searching = the whole key space. As example for
  =  predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation
   of quality random numbers is = difficult. ISO/IEC = 20543:2019 [=E2=80=A6],
   NIST = SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 = [RFC4086], and
   others offers valuable = guidance in this area.

If this approach works for you, we'll dig up = the appropriate references.

 
  • I understand that key generation is out of scope and maybe = this needs to be a separate work item, but recommending periodic = replacement of the certs without recommending a suitable mechanism = leaves this solution with a big = hole.

I do = not agree.  It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair.  Getting more detailed would be algorithm = specific, which is not appropriate in this document.

  • It is really annoying that 21 years after PKCS #10, we = still cannot provide a reference that would enable implementers to find = out all available, non-deprecated AlgorithmIdentifier values. (And I = realize there=E2=80=99s little you can do about = it.)

So, we = will leave this part alone.

Russ

= --Apple-Mail=_643D9F68-DCD6-4ACC-8D68-EF10BCB53217-- From nobody Fri Nov 26 18:22:50 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CFB3A0780; Fri, 19 Nov 2021 07:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1637336543; bh=21KRAON83bfmdPcM9hB/wMPUM/Ogyq+mbFgxSbjbMAo=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=c3Pmm3RYkPCNgNk20GC9alrvJv2y79DS3c0SDJFbnUx2nNPS4H1n2pmTOkmqqb04t XrLjeGHq4SkgikdnqxY1/Jdtw+m+cVNRKng2elHCFOSTA0ZGJXA7JTebhDN7+3qbkO j8IT4op9/D3lv6SCf8c0zRm1YJBm4lwmDsc1dxqA= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Nov 19 07:42:22 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B693A0745; Fri, 19 Nov 2021 07:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1637336542; bh=21KRAON83bfmdPcM9hB/wMPUM/Ogyq+mbFgxSbjbMAo=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Z3C+cR0f/zKVTiwGEYj7yA23Qf8IqnlLWUY1vTWQUqM+1X7/kMMnxT1ZPGt5EnRqh UqM47VkRVvA7AZgGmqg3mneXXuOZLjfmX/8OXu6CgoDw10RprslB1fzEEZo5MEKhIW DOBQfCHa3xZ834nTcHmdY0x6tsZ3qMEND73AuX94= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26ECB3A0658 for ; Fri, 19 Nov 2021 07:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.559, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 j1y7FgrC72xK for ; Fri, 19 Nov 2021 07:42:17 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 C61DB3A0745 for ; Fri, 19 Nov 2021 07:42:17 -0800 (PST) Received: from [85.203.23.180] (helo=[10.148.0.38]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mo61m-0000vD-9r for new-work@ietf.org; Fri, 19 Nov 2021 15:42:15 +0000 Message-ID: Date: Fri, 19 Nov 2021 23:42:09 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: new-work@ietf.org From: xueyuan Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 26 Nov 2021 18:22:48 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Accessible Rich Internet Applications Working Group (until 2021-12-17/18) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2021 15:42:26 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBBY2Nlc3Np YmxlIFJpY2ggSW50ZXJuZXQgQXBwbGljYXRpb25zCldvcmtpbmcgR3JvdXA6CiDCoCBodHRwczov L3d3dy53My5vcmcvMjAyMS8xMS9kcmFmdC1hcmlhLWNoYXJ0ZXIKCkFzIHBhcnQgb2YgZW5zdXJp bmcgdGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0 aGlzIGRyYWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVl IHJldmlldyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAwNDo1 OSBVVEMgb24gMTggRGVjZW1iZXIgMjAyMQooMjM6NTksIEVhc3Rlcm4gdGltZSBvbiAxNyBEZWNl bWJlcikgb24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIuClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHB1 YmxpYy1uZXctd29ya0B3My5vcmcsCndoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0 cHM6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVy IHRoYW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpD b21taXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNl IHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNv b3JkaW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJl c2VudGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1l bnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVz ZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVu dHMuCgpUaGUgY3VycmVudCBjaGFydGVyIGlzIGhlcmVieSBleHRlbmRlZCB1bnRpbCAzMSBKYW51 YXJ5IDIwMjIgdG8KYWNjb21tb2RhdGUgdGhlIGNoYXJ0ZXIgcmV2aWV3IHBlcmlvZDoKaHR0cHM6 Ly93d3cudzMub3JnLzIwMTgvMTEvYXJpYS1jaGFydGVyCgpJZiB5b3Ugc2hvdWxkIGhhdmUgYW55 IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFzZQpjb250YWN0IE1p Y2hhZWwgQ29vcGVyLCBBUklBIFdvcmtpbmcgR3JvdXAgVGVhbSBDb250YWN0LCA8Y29vcGVyQHcz Lm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSzCoCBXM0MgTWFya2V0aW5nICYgQ29tbXVu aWNhdGlvbnMKClsxXSBodHRwczovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlzdAoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsg bWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Fri Nov 26 18:22:54 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7103A08A0; Fri, 19 Nov 2021 08:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1637340983; bh=8QGzTipGImxV5jG74c02i5VkG4De7qvwMXnl6cNXhAI=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=CQXqiaNYqe6Vo+B0UOPOfdeLLh4Li7u5qA/ryCHvqSNQRA9JJmfxi/Vm1DrJf+qPb FFN6+pMkaY92k9fL46F3rrnkWMZaboCw544i9c9bdYktEl9E2ITDi+qs494JBHspiI 4U7wTmktklVRkch+2qIEY4sVrzSy0AV30eByjXE4= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Nov 19 08:56:22 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9936B3A0823; Fri, 19 Nov 2021 08:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1637340982; bh=8QGzTipGImxV5jG74c02i5VkG4De7qvwMXnl6cNXhAI=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=HV7uHWRV9CtkgpbPqKawS+FXRRy6fAQfK7Rs4bjVXUFMy8Zot919fh652sJVQA47e /GSbrlKfVZWLWnFHMN9iaTCTtIvJP2AgHPpY73SdsRmy4Br4I7y+oS0DrNMbAdF7DC UFADlzvfz6EAjpd2pHIVFf9S+9tQ3ys+MFUwFTA8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B6C3A0888 for ; Fri, 19 Nov 2021 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.559, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 umaM1MoKF46C for ; Fri, 19 Nov 2021 08:56:18 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 CC6903A0823 for ; Fri, 19 Nov 2021 08:56:16 -0800 (PST) Received: from [85.203.23.180] (helo=[10.148.0.38]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mo7BO-0004zX-NB for new-work@ietf.org; Fri, 19 Nov 2021 16:56:15 +0000 Message-ID: Date: Sat, 20 Nov 2021 00:56:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: new-work@ietf.org From: xueyuan Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 26 Nov 2021 18:22:48 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Payments Working Group (until 2021-12-17/18) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2021 16:56:25 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBXZWIgUGF5 bWVudHMgV29ya2luZyBHcm91cDoKIMKgIGh0dHBzOi8vd3d3LnczLm9yZy9QYXltZW50cy9XRy9j aGFydGVyLTIwMjEuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBjb21tdW5pdHkg aXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQgY2hhcnRlciBpcyBw dWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBlcmlvZC4KClczQyBp bnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDA0OjU5IFVUQyBvbiAxOCBEZWNlbWJlcgoo MjM6NTksIEJvc3RvbiB0aW1lIG9uIDE3IERlY2VtYmVyLCAyMDIxKSBvbiB0aGUgcHJvcG9zZWQg Y2hhcnRlci4KUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gcHVibGljLW5ldy13b3JrQHczLm9yZywK d2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwczovL2xpc3RzLnczLm9yZy9BcmNo aXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBzZW50IGlu IGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElmIHlvdSB3 b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNvbW1lbnRz IHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpleGFtcGxl LCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlzdCBhbmQK aGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0byBpdCBm cm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KClRoZSBjdXJyZW50IGNoYXJ0 ZXIgaXMgaGVyZWJ5IGV4dGVuZGVkIHVudGlsIDMxIE1hcmNoIDIwMjIgdG8KYWNjb21tb2RhdGUg dGhlIGNoYXJ0ZXIgcmV2aWV3IHBlcmlvZDoKaHR0cHM6Ly93d3cudzMub3JnL1BheW1lbnRzL1dH L2NoYXJ0ZXItMjAxOTEyLmh0bWwKCklmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9y IG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlCmNvbnRhY3QgSWFuIEphY29icywgV2Vi IFBheW1lbnRzIFdHIFRlYW0gQ29udGFjdCwgPGlqQHczLm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5 dWFuIEppYSzCoCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRwczovL3d3 dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlzdAoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGll dGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Sun Nov 28 01:29:41 2021 Return-Path: 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 C1A533A05DF; Sun, 28 Nov 2021 01:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OhEYqqcbLZv1; Sun, 28 Nov 2021 01:29:26 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5107E3A05F0; Sun, 28 Nov 2021 01:29:26 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id a18so29548853wrn.6; Sun, 28 Nov 2021 01:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=bStiFcCprgsoL/pLNQHhwew18a81e84d/8a3jANDLvk=; b=R5yTh63B9Cw/KjTylwuDuzvDBBcyawWZIJ+5hTcl6bOEKExOJVVcnEIV7iNyyE1XmU hF+PDoZI1PskQKaveJl013MOcpHa++WrovfeDnx8DgzRwtH85Oi/J/Eew3VhyNUrDl87 R8GMwMnEOztE2gcbSyhWUybRq6qWGis88/czDFZhRXxqbecKgJWlBp7nmeKIAFw33lTe NwyQwmXiGbDM2gYHjWYBgqMgvRp/id5h6xkPFYHc1CtOyL3TXr3e5lE0LaR6gsCmd6tO PTiTcDng0gbl++C54EmQunqZcU1XopElY2cmybOthnM6PCg9vonMIMC/BLa+z90Ay+qy RG7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=bStiFcCprgsoL/pLNQHhwew18a81e84d/8a3jANDLvk=; b=WY2VZdU3yUTFvfcFeA/SEwZTw8Gqbv1F3uMmRGQlbXKTChGZ+inWbMFNzOqI38PgLO ijx+JVG5J0melaTusJOCgn33zKndr6X88kAcQw31p+VILGYOO4bcwgYYpNL9986LSm07 GLnA99Qr/OFGf8Ez3LcWdO8pvM4lMcWe01cwwssrWWA/T0BScavx0j0rE6r5IHcbgoTW WLg4dUm8JDXj+g+zPi0VskSmwCtDe3g+5wz+qHlK/d57QKKXX7FAp8j+fLF2O57fLEUt p1uyiFv6cFwyZTbBlPW7T01z6B2X1XqLkI71snleQIiozdBeoz4kUecClU//ssHZNewV GaYg== X-Gm-Message-State: AOAM533wlTxNBZIqpIMZ7QKJnIxOF86o/+6zA6YdXqE2U6FssEgkcyux Sm3fUbgP5nTF9lzWxsXL9LqJ1LAuHEU= X-Google-Smtp-Source: ABdhPJxOkTRniPDfp9uaJE0pu1OXbcn28Wy4Azv4ceB1NLIDuzG3vqk1xBBs523Xn5ZfWodmy2T3iQ== X-Received: by 2002:a5d:4e0b:: with SMTP id p11mr25585296wrt.88.1638091763332; Sun, 28 Nov 2021 01:29:23 -0800 (PST) Received: from MacBook-Pro.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id 9sm13355768wry.0.2021.11.28.01.29.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Nov 2021 01:29:22 -0800 (PST) MIME-Version: 1.0 Date: Sun, 28 Nov 2021 11:29:19 +0200 From: Yaron Sheffer Thread-Topic: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: Message-ID: <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> , To: Russ Housley Cc: Kent Watsen , IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2021 09:29:32 -0000

Hi Russ,

 

Please see my answe= rs in-line.

 

Thanks,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ya= ron

 

From: Russ Housley= <housley@vigilsec.com>
Date: Friday, November 26, 2021 at = 17:53
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: <= /b>Kent Watsen <kent+ietf@watsen.net>, IETF SecDir <secdir@ietf.or= g>, draft-ietf-netconf-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp= -csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>, netco= nf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir last cal= l review of draft-ietf-netconf-sztp-csr-11

Yaron:

 

Thank you for addressing my comments, I am happy w= ith most of your responses but I do have a few remaining questions:

 

=C2=B7       &nb= sp; The commit that r= emoves the dependency on IDevID and LDevID does not fix the issue of non-or= thogonality. There is very detailed description for CMP and CMC, but nothin= g for PKCS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box = and it=E2=80=99ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of= PKCS#10 for these certs is still TBD=E2=80=9D?

 

PKCS#10 is prett= y simple.  Are you aware of anything more that ought to be said?<= /o:p>

&n= bsp;

I think we should explicitly mention wha= t this method *cannot* provide. As far as I can tell, none of the or= igin authentication methods are available when using PKCS #10 directly with= out wrapping it further.

= =C2=B7    =       

=C2=B7      &= nbsp;  I suggest= to add the following reference to the paragraph on quality randomness, as = a strong proof that this is a real world concern:

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>Heninger, N., Durumeric, Z.,= Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of W= idespread Weak Keys in Network Devices", Proceedings of the 21st<= /sup> USENIX Security Sympo= sium , August 2012, <https://factora= ble.net/>.

 

In another thread, something like this w= as suggested for another document:

 

   Implementations mus= t randomly generate nonces and private keys.

=

   The use of ina= dequate pseudo-random number generators (PRNGs) to

   generate cryp= tographic keys can result in little or no security. An attacker<= /p>

   = may find it much easier to reproduce the PRNG environment that

   p= roduced the keys, searching the resulting small set of possibilities,<= /o:p>

  =  rather than brute force searching the whole key space. As example for=

&= nbsp;  predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The g= eneration

   of quality random numbers is difficult. ISO/IEC 2= 0543:2019 [=E2=80=A6],

   NIST SP 800-90A Rev.1 [=E2=80=A6], = BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and

   others offer= s valuable guidance in this area.

 

If this approach works for you, w= e'll dig up the appropriate references.

=  

Yes, but the Heninger et al. refe= rence is a better fit than the Debian CVE because (1) it discusses network = devices rather than servers and (2) it shows how even less broken RNGs can = be exploited by a network attacker that only sees the public keys.

 = ;

 

=C2=B7         I understand that key g= eneration is out of scope and maybe this needs to be a separate work item, = but recommending periodic replacement of the certs without recommending a s= uitable mechanism leaves this solution with a big hole.

&nb= sp;

I do not= agree.  It does offer the protocol for obtaining replacement certific= ates for devices that are able to generating a fresh public/private key pai= r.  Getting more detailed would be algorithm specific, which is not ap= propriate in this document.

 

Not rea= lly, because the =E2=80=9Cprotocol=E2=80=9D described here is: Client sends= a CSR, Server responds with a complete client configuration blob. This obv= iously doesn=E2=80=99t work for an already deployed client.

<= p class=3DMsoNormal style=3D'margin-left:.5in'>

=C2=B7&nb= sp;         

<= span style=3D'font-size:10.0pt;font-family:Symbol'>=C2=B7  &nbs= p;      It is really annoying that 21 years after PKCS #10, we still = cannot provide a reference that would enable implementers to find out all a= vailable, non-deprecated AlgorithmIdentifier values. (And I realize there= =E2=80=99s little you can do about it.)

 

So, we will leave this p= art alone.

 

Agreed. Sigh.

 

Russ

 

= From nobody Sun Nov 28 10:16:11 2021 Return-Path: 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 6A84D3A0863 for ; Sun, 28 Nov 2021 10:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 ElKzphlcXHcA for ; Sun, 28 Nov 2021 10:16:05 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DE13A07D0 for ; Sun, 28 Nov 2021 10:16:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EFC16300C1E for ; Sun, 28 Nov 2021 13:10:08 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r-hM_kazbKah for ; Sun, 28 Nov 2021 13:10:03 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 397C13002A6; Sun, 28 Nov 2021 13:10:03 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_794155BA-5AF1-4DEE-8C1A-04D478DAA00D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Sun, 28 Nov 2021 13:09:59 -0500 In-Reply-To: <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> Cc: Kent Watsen , IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2021 18:16:10 -0000 --Apple-Mail=_794155BA-5AF1-4DEE-8C1A-04D478DAA00D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron: > =20 > Thank you for addressing my comments, I am happy with most of your = responses but I do have a few remaining questions: > =20 > =C2=B7 The commit that removes the dependency on IDevID and = LDevID does not fix the issue of non-orthogonality. There is very = detailed description for CMP and CMC, but nothing for PKCS #10 = (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99= ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for = these certs is still TBD=E2=80=9D? > =20 > PKCS#10 is pretty simple. Are you aware of anything more that ought = to be said? > =20 > I think we should explicitly mention what this method *cannot* = provide. As far as I can tell, none of the origin authentication methods = are available when using PKCS #10 directly without wrapping it further. That is reasonable. I will talk with my co-authors and see if we can = come up with a brief summary. =20 > =C2=B7 I suggest to add the following reference to the = paragraph on quality randomness, as a strong proof that this is a real = world concern: > =20 > Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining = Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", = Proceedings of the 21st USENIX Security Symposium , August 2012, = >. > =20 > In another thread, something like this was suggested for another = document: > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As example = for > predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation > of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6= ], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. > =20 > If this approach works for you, we'll dig up the appropriate = references. > =20 > Yes, but the Heninger et al. reference is a better fit than the Debian = CVE because (1) it discusses network devices rather than servers and (2) = it shows how even less broken RNGs can be exploited by a network = attacker that only sees the public keys. I just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys. How about: =20 Implementations must randomly generate nonces and private keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An = attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of = possibilities, rather than brute force searching the whole key space. As an example = of predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some = consequences of low-entropy random numbers are discussed in Mining Your Ps and Qs = [...]. The generation of quality random numbers is difficult. ISO/IEC = 20543:2019 [=E2=80=A6], NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and others offers valuable guidance in this area. > =20 > =20 > =C2=B7 I understand that key generation is out of scope and = maybe this needs to be a separate work item, but recommending periodic = replacement of the certs without recommending a suitable mechanism = leaves this solution with a big hole. > =20 > I do not agree. It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair. Getting more detailed would be algorithm = specific, which is not appropriate in this document. > =20 > Not really, because the =E2=80=9Cprotocol=E2=80=9D described here is: = Client sends a CSR, Server responds with a complete client configuration = blob. This obviously doesn=E2=80=99t work for an already deployed = client. I am really confused. The document is an addition to the Secure Zero = Touch Provisioning (SZTP). As such, it is technique to securely = provision a networking device when it is booting in a factory-default = state. That should happen at the initial deployment or after the device = is reset to the factory configuration. This is not the protocol for use = with an already deployed client. Russ --Apple-Mail=_794155BA-5AF1-4DEE-8C1A-04D478DAA00D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron:

 
Thank you for addressing my comments, I = am happy with most of your responses but I do have a few remaining = questions:
 

=C2=B7         The commit that removes the dependency on = IDevID and LDevID does not fix the issue of non-orthogonality. There is = very detailed description for CMP and CMC, but nothing for PKCS #10 = (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99= ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for = these certs is still TBD=E2=80=9D?

 
PKCS#10 is pretty simple.  Are you aware of anything = more that ought to be said?
 
I think we should = explicitly mention what this method *cannot* provide. = As far as I can tell, none of the origin authentication methods are = available when using PKCS #10 directly without wrapping it further.

That is reasonable.  I will talk with my = co-authors and see if we can come up with a brief = summary.
 

=C2=B7         I suggest to add the following reference = to the paragraph on quality randomness, as a strong proof that this is a = real world concern:

 
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, = "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network = Devices", Proceedings of the 21st USENIX Security Symposium , = August 2012, <https://factorable.net/>.
 
In = another thread, something like this was suggested for another = document:
 
   Implementations must = randomly generate nonces and private keys.
   The use of inadequate pseudo-random number = generators (PRNGs) to
   generate = cryptographic keys can result in little or no security. An attacker
   may find it much easier to reproduce the PRNG = environment that
   produced the keys, = searching the resulting small set of possibilities,
   rather than brute force searching the whole key = space. As example for
   predictable = random numbers see CVE-2008-0166 [=E2=80=A6]. The generation
   of quality random numbers is = difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS = 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and
   others offers valuable guidance in this = area.
 
If this approach works for you, we'll dig up the appropriate = references.
 
Yes, but the Heninger et = al. reference is a better fit than the Debian CVE because (1) it = discusses network devices rather than servers and (2) it shows how even = less broken RNGs can be exploited by a network attacker that only sees = the public keys.

I just read the Abstract of the paper, and I see your = point about the attacker only observing the public keys.  How = about:

 
  =  Implementations must randomly generate nonces and private = keys.
   The use of = inadequate pseudo-random number generators (PRNGs) = to
   generate = cryptographic keys can result in little or no security. An = attacker
   may find it = much easier to reproduce the PRNG environment = that
   produced = the keys, searching the resulting small set of = possibilities,
  =  rather than brute force searching the whole key space. As an = example of
  =  predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some = consequences
  =  of low-entropy random numbers are discussed = in Mining Your Ps and Qs [...].
  =  The generation of quality random numbers is difficult. ISO/IEC = 20543:2019 [=E2=80=A6],
   NIST SP = 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 = [RFC4086], and
  =  others offers valuable guidance in this = area.

 
 

=C2=B7         I understand that key generation is out of = scope and maybe this needs to be a separate work item, but recommending = periodic replacement of the certs without recommending a suitable = mechanism leaves this solution with a big hole.

 
I do not agree.  It does offer the protocol = for obtaining replacement certificates for devices that are able to = generating a fresh public/private key pair.  Getting more detailed = would be algorithm specific, which is not appropriate in this = document.
 
Not really, because = the =E2=80=9Cprotocol=E2=80=9D described here is: Client sends a CSR, = Server responds with a complete client configuration blob. This = obviously doesn=E2=80=99t work for an already deployed = client.

I = am really confused.  The document  is an addition to = the Secure Zero Touch Provisioning (SZTP).  As such, it is = technique to securely provision a networking device when it is booting = in a factory-default state.  That should happen at the initial = deployment or after the device is reset to the factory configuration. =  This is not the protocol for use with an already deployed = client.

Russ

= --Apple-Mail=_794155BA-5AF1-4DEE-8C1A-04D478DAA00D-- From nobody Sun Nov 28 12:23:22 2021 Return-Path: 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 1AB183A096C; Sun, 28 Nov 2021 12:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VJ1MZPei1j1U; Sun, 28 Nov 2021 12:23:05 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3715C3A096B; Sun, 28 Nov 2021 12:23:05 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id t5so63300556edd.0; Sun, 28 Nov 2021 12:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=IQCuWtZe20FWcu7mYhHLJQ2psYQwDN4cDtGXphk6qWI=; b=L0mpGM7HAEx6cw0v21nv5RvMpxocDRUERfbT5KzBGVJ6yc3NPAXF+YNRfTFyE+HW5S 1nnM4PZsQeyAUW9JsDfs1hL+VSW+Ey01+xDzoscisBG/Guckd72MJE1SpyN7EvlUIe42 Bk8B7cAgHphdqnM06vHd92pBH7HV4IHJCJuB5RJIS63h9ld6XhRgXrdPlO3fPuXbVeNy yolsyhH/UyeoP16BRmKcL3Bx03mlZ7piN48ZKfEQavSYL8oi897yy54JfrxtWK0J4jHU TNXZwTpvENMb8oho03mHDxxENB9Mp9KDRCwdIfa55Q7eKPs3YlhW/FfNLZyxOwc4Y/Ge yopQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=IQCuWtZe20FWcu7mYhHLJQ2psYQwDN4cDtGXphk6qWI=; b=1Hd5C8gsNuzph6jXxRR5CbbncNVs1Rughv6Rd5cyeMiYyNRTMr3NjajhWM6vSbsP9m J66hZpbZTX4rtjOMhM2JGNUZWf1N6ZS78Ul7B8CF60avPhEf3WeMD1jO7dDClL5v184Z iwlAVaFGAUR0vANs8foKFxj/glmQKycB4tlAZBsyyOjsZilegaB9TRLFBFinVYydz6bS nkPNvXJjXjsaGhzYzzats4LMXaWWHK0IqrZQIkuzM/wJa++phpZyYalSGELrD8B3Lxs0 D5w5RH1o21qBuP7AYL+u2itd3Wtt5yI/lzOZ0Cbvtf/SwqNx9An0Z0f8zuYzpzUZPmBv snhg== X-Gm-Message-State: AOAM532nq6Kc+1evgw3scs9xe5EIw2n29RQWhABugNQHq2oDMlSLotWy 2ZTOu1u9ml7aG93n1sYgznFJGowv+iQ= X-Google-Smtp-Source: ABdhPJw64XQ0QC3U4qg8e8UEiaua1GkoS6zGR7cUbnkAgBB9v2A7n9FMaBO5MEKxh0ic3JXJmtH+oA== X-Received: by 2002:a05:6402:445:: with SMTP id p5mr68578548edw.110.1638130978683; Sun, 28 Nov 2021 12:22:58 -0800 (PST) Received: from MacBook-Pro.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id d18sm7931129edj.23.2021.11.28.12.22.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Nov 2021 12:22:58 -0800 (PST) MIME-Version: 1.0 Date: Sun, 28 Nov 2021 22:22:54 +0200 From: Yaron Sheffer Thread-Topic: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: Message-ID: <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol>, To: Russ Housley Cc: Kent Watsen , IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2021 20:23:11 -0000

Hi Russ,

 

Thank you for the q= uick response.

 

We are in agreement re: PKCS #10 and randomness.

 

In the = third point below (certificate rotation), I understand why the editors see = it as out of scope. But we are still leaving implementers with no guidance,= and we=E2=80=99ve all seen enough real world cases where this leads to peo= ple ignoring the vague =E2=80=9Cregenerate the private key=E2=80=9D. Let me= try to offer an alternative.

 = ;

Old:

 

In cases where the SZTP-client does = not possess an HSM, or otherwise is unable to use an HSM for the private ke= y, it is RECOMMENDED to regenerate the private key (and associated identity= certificates) periodically. Details for how to generate a new private key = and associate a new identity certificate are outside the scope of this docu= ment.

 

New:

 

In cases where the SZTP-client does not possess an HSM, or o= therwise is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) periodica= lly. If CMP or CMC was used for initial certificate provisioning, it is REC= OMMENDED to reuse the protocol (CMC or CMP) for periodic certificate regist= ration. Similarly, implementations SHOULD also reuse the initial origin aut= hentication method.

 

Thanks,

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Yaron

 

 

From: Russ Housley <housley@vigilsec.co= m>
Date: Sunday, November 28, 2021 at 20:10
To: Yaro= n Sheffer <yaronf.ietf@gmail.com>
Cc: Kent Watsen <kent+= ietf@watsen.net>, IETF SecDir <secdir@ietf.org>, draft-ietf-netcon= f-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, l= ast-call@ietf.org <last-call@ietf.org>, netconf@ietf.org <netconf@= ietf.org>
Subject: Re: Secdir last call review of draft-ietf-n= etconf-sztp-csr-11

Yaron:

 

 

Thank you for = addressing my comments, I am happy with most of your responses but I do hav= e a few remaining questions:

 =

=C2=B7 &nbs= p;      &= nbsp;The commit that removes the dependency on IDevID and LDe= vID does not fix the issue of non-orthogonality. There is very detailed des= cription for CMP and CMC, but nothing for PKCS #10 (p10-csr). Does it mean = =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99ll just work=E2=80=9D? O= r does it mean =E2=80=9Cthe usage of PKCS#10 for these certs is still TBD= =E2=80=9D?

 

=

PKCS#10 is pretty simple.  Are you aware of anything = more that ought to be said?

 =

I thin= k we should explicitly mention what this method *cannot* provide. As= far as I can tell, none of the origin authentication methods are available= when using PKCS #10 directly without wrapping it further.

 

That is reasonable.  I will talk with my co-authors and see if = we can come up with a brief summary.

 

=C2=B7         I suggest to add the following= reference to the paragraph on quality randomness, as a strong proof that t= his is a real world concern:

 

<= /div>

Heninger, N., Durumeric, Z., Wustrow, E., and J. Hald= erman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Ne= twork Devices", Proceedings of the 21st USENIX Security Symposium , August 2012, <<= a href=3D"https://factorable.net/">https://factorable.net/>.

=

 

=

In another thread, something like this was suggested for another= document:

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

<= /div>

   Implementations must randomly generate n= onces and private keys.

  &nb= sp;The use of inadequate pseudo-random number generators (PRNGs) to

   generate cryptographic keys can r= esult in little or no security. An attacker

=

   may find it much easier to reproduce the PRNG environment= that

   produced the keys, s= earching the resulting small set of possibilities,

   rather than brute force searching the whole key sp= ace. As example for

   predic= table random numbers see CVE-2008-0166 [=E2=80=A6]. The generation

   of quality random numbers is diffi= cult. ISO/IEC 20543:2019 [=E2=80=A6],

<= div style=3D'margin-left:.5in'>

   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [= =E2=80=A6], BCP 106 [RFC4086], and

&nbs= p;  others offers valuable guidance in this area.

<= /div>

 

If this ap= proach works for you, we'll dig up the appropriate references.

 

Yes, but = the Heninger et al. reference is a better fit than the Debian CVE because (= 1) it discusses network devices rather than servers and (2) it shows how ev= en less broken RNGs can be exploited by a network attacker that only sees t= he public keys.

 

I just read the Abstract of th= e paper, and I see your point about the attacker only observing the public = keys.  How about:

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>=  

   Implementations must r= andomly generate nonces and private keys.

<= p class=3DMsoNormal style=3D'margin-left:.5in'>=    The use of inadequate pseudo-random number generators (PRNGs) = to

   generate cryptographic key= s can result in little or no security. An attacker

   may find it much easier to reproduce the PRNG environ= ment that

   produced the keys, = searching the resulting small set of possibilities,

   rather than brute force searching the whole key spac= e. As an example of

   predictab= le random numbers see CVE-2008-0166 [=E2=80=A6], and some consequences

   of low-entropy random numbers are= discussed in Mining Your Ps and Qs [...].

=

   The gener= ation of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6= ],

   NIST SP 800-90A Rev.1 [=E2=80=A6]= , BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and

=

   others offers valuable guidance in this area.



 

 

=C2=B7     &nbs= p;   I und= erstand that key generation is out of scope and maybe this needs to be a se= parate work item, but recommending periodic replacement of the certs withou= t recommending a suitable mechanism leaves this solution with a big hole.

 

=

I do not agree.  It does offer the protocol f= or obtaining replacement certificates for devices that are able to generati= ng a fresh public/private key pair.  Getting more detailed would be al= gorithm specific, which is not appropriate in this document.

=

 

Not really, because the =E2=80=9Cprotocol=E2=80= =9D described here is: Client sends a CSR, Server responds with a complete = client configuration blob. This obviously doesn=E2=80=99t work for an alrea= dy deployed client.

 

I am really confused.  The = document  is an addition to the Secure Zero Touch Provisioning (S= ZTP).  As such, it is technique to securely provision a networking dev= ice when it is booting in a factory-default state.  That should happen= at the initial deployment or after the device is reset to the factory conf= iguration.  This is not the protocol for use with an already deployed = client.

 

Russ

 

= From nobody Mon Nov 29 06:35:15 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B12083A0A3A; Mon, 29 Nov 2021 06:35:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: acme@ietf.org, draft-ietf-acme-dtnnodeid.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163819650566.3161.13064510086098914819@ietfa.amsl.com> Reply-To: Valery Smyslov Date: Mon, 29 Nov 2021 06:35:05 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-acme-dtnnodeid-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2021 14:35:06 -0000 Reviewer: Valery Smyslov Review result: Has Issues 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 draft specifies an extension to the Automated Certificate Management Environment (ACME) protocol that allows to automatically issue and manage certificates for nodes in the Delay-Tolerant Networking (DTN) networks. Issues. I was hesitating whether it is a real issue or just the lack of my understanding of the protocol, but finally decided to mark it as an issue. Section 5.1 states that CSR MAY contain a mixed set of SAN claims, including combinations of "ip", "dns", and "bundleEID" claims. However, this document only defines how ACME server can validate "bundleEID" claim. I think that the document should at least mention how "dns" and "ip" claims should be validated (pointing to the appropriate specs). Nits. The document uses both MUST and SHALL keywords. Not a problem, but I think readability of the document would increase if only one of these forms were used. Section 7.6. I think that it should be mentioned more explicitly that these channels must provide mutual authentication of ACME client/server and corresponding BP agents, and that the channels must protect integrity and authenticity of the messages, and in some situations (when client account key thumbprint is transmitted) also their confidentiality. These are standard security services and I think it's better to use these terms. From nobody Mon Nov 29 08:46:12 2021 Return-Path: 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 314173A0796 for ; Mon, 29 Nov 2021 08:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 cOlU0iwjZ801 for ; Mon, 29 Nov 2021 08:46:06 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2F13A0C05 for ; Mon, 29 Nov 2021 08:46:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6964B300C1B for ; Mon, 29 Nov 2021 11:38:42 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kcgx_OJnXlee for ; Mon, 29 Nov 2021 11:38:35 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 09928300B30; Mon, 29 Nov 2021 11:38:35 -0500 (EST) From: Russ Housley Message-Id: <9BF6DBF5-9394-4CFE-A8E5-E064AFE3A76D@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F8B832BD-0538-4803-8053-23DD31DE5E6A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Mon, 29 Nov 2021 11:38:31 -0500 In-Reply-To: <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> Cc: "last-call@ietf.org" , Kent Watsen , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "netconf@ietf.org" , IETF SecDir To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2021 16:46:10 -0000 --Apple-Mail=_F8B832BD-0538-4803-8053-23DD31DE5E6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron: Perhaps the word "regenerate" is the thing that is causing confusion. Suggestion: In cases where the SZTP-client does not possess an HSM, or otherwise is = unable to use an HSM for the private key, it is RECOMMENDED that the = device periodically reset the configuration to the factory default and = repeat the SZTP protocol. Repeating the SZTP protocol may cause the = device to generate a fresh private key (and associated identity = certificates). Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document. Russ > On Nov 28, 2021, at 3:22 PM, Yaron Sheffer = wrote: >=20 > Hi Russ, > =20 > Thank you for the quick response. > =20 > We are in agreement re: PKCS #10 and randomness. > =20 > In the third point below (certificate rotation), I understand why the = editors see it as out of scope. But we are still leaving implementers = with no guidance, and we=E2=80=99ve all seen enough real world cases = where this leads to people ignoring the vague =E2=80=9Cregenerate the = private key=E2=80=9D. Let me try to offer an alternative. > =20 > Old: > =20 > In cases where the SZTP-client does not possess an HSM, or otherwise = is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) = periodically. Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document. > =20 > New: > =20 > In cases where the SZTP-client does not possess an HSM, or otherwise = is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) = periodically. If CMP or CMC was used for initial certificate = provisioning, it is RECOMMENDED to reuse the protocol (CMC or CMP) for = periodic certificate registration. Similarly, implementations SHOULD = also reuse the initial origin authentication method. > =20 > Thanks, > Yaron > =20 > =20 > From: Russ Housley > > Date: Sunday, November 28, 2021 at 20:10 > To: Yaron Sheffer > > Cc: Kent Watsen >, = IETF SecDir >, = draft-ietf-netconf-sztp-csr.all@ietf.org = = >, last-call@ietf.org = >, netconf@ietf.org = > > Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 >=20 > Yaron: > =20 > =20 > Thank you for addressing my comments, I am happy with most of your = responses but I do have a few remaining questions: > =20 > =C2=B7 The commit that removes the dependency on IDevID and = LDevID does not fix the issue of non-orthogonality. There is very = detailed description for CMP and CMC, but nothing for PKCS #10 = (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99= ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for = these certs is still TBD=E2=80=9D? > =20 > PKCS#10 is pretty simple. Are you aware of anything more that ought = to be said? > =20 > I think we should explicitly mention what this method *cannot* = provide. As far as I can tell, none of the origin authentication methods = are available when using PKCS #10 directly without wrapping it further. > =20 > That is reasonable. I will talk with my co-authors and see if we can = come up with a brief summary. > =20 >=20 > =C2=B7 I suggest to add the following reference to the = paragraph on quality randomness, as a strong proof that this is a real = world concern: > =20 > Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining = Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", = Proceedings of the 21st USENIX Security Symposium , August 2012, = >. > =20 > In another thread, something like this was suggested for another = document: > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As example = for > predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation > of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6= ], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. > =20 > If this approach works for you, we'll dig up the appropriate = references. > =20 > Yes, but the Heninger et al. reference is a better fit than the Debian = CVE because (1) it discusses network devices rather than servers and (2) = it shows how even less broken RNGs can be exploited by a network = attacker that only sees the public keys. > =20 > I just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys. How about: > =20 > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As an = example of > predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some = consequences > of low-entropy random numbers are discussed in Mining Your Ps and = Qs [...]. > The generation of quality random numbers is difficult. ISO/IEC = 20543:2019 [=E2=80=A6], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. >=20 >=20 > =20 > =20 > =C2=B7 I understand that key generation is out of scope and = maybe this needs to be a separate work item, but recommending periodic = replacement of the certs without recommending a suitable mechanism = leaves this solution with a big hole. > =20 > I do not agree. It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair. Getting more detailed would be algorithm = specific, which is not appropriate in this document. > =20 > Not really, because the =E2=80=9Cprotocol=E2=80=9D described here is: = Client sends a CSR, Server responds with a complete client configuration = blob. This obviously doesn=E2=80=99t work for an already deployed = client. > =20 > I am really confused. The document is an addition to the Secure Zero = Touch Provisioning (SZTP). As such, it is technique to securely = provision a networking device when it is booting in a factory-default = state. That should happen at the initial deployment or after the device = is reset to the factory configuration. This is not the protocol for use = with an already deployed client. > =20 > Russ > =20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call = --Apple-Mail=_F8B832BD-0538-4803-8053-23DD31DE5E6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron:

Perhaps the word "regenerate" is the thing that is = causing confusion.

Suggestion:

In = cases where the SZTP-client does not possess an HSM, or otherwise is = unable to use an HSM for the private key, it is RECOMMENDED that the = device periodically reset the configuration to the factory default and = repeat the SZTP protocol.  Repeating the SZTP protocol may cause = the device to generate a fresh private key (and associated identity = certificates). Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document.

Russ



On = Nov 28, 2021, at 3:22 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Russ,
 
Thank you for the quick = response.
 
We are in agreement re: = PKCS #10 and randomness.
 
In the third point below = (certificate rotation), I understand why the editors see it as out of = scope. But we are still leaving implementers with no guidance, and = we=E2=80=99ve all seen enough real world cases where this leads to = people ignoring the vague =E2=80=9Cregenerate the private key=E2=80=9D. = Let me try to offer an alternative.
 
Old:
 
In cases where the SZTP-client does not possess = an HSM, or otherwise is unable to use an HSM for the private key, it is = RECOMMENDED to regenerate the private key (and associated identity = certificates) periodically. Details for how to generate a new private = key and associate a new identity certificate are outside the scope of = this document.
 
New:
 
In cases where the = SZTP-client does not possess an HSM, or otherwise is unable to use an = HSM for the private key, it is RECOMMENDED to regenerate the private key = (and associated identity certificates) periodically. If CMP or CMC was = used for initial certificate provisioning, it is RECOMMENDED to reuse = the protocol (CMC or CMP) for periodic certificate registration. = Similarly, implementations SHOULD also reuse the initial origin = authentication method.
 
Thanks,
          &nb= sp;     Yaron
 
 
From: Russ Housley <housley@vigilsec.com>
Date: Sunday, November 28, = 2021 at 20:10
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Kent Watsen <kent+ietf@watsen.net>, = IETF SecDir <secdir@ietf.org>, draft-ietf-netconf-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>, netconf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir last call = review of draft-ietf-netconf-sztp-csr-11

Yaron:
 
 
Thank you for addressing my comments, I am happy with most of = your responses but I do have a few remaining questions:
 

=C2=B7         The commit that = removes the dependency on IDevID and LDevID does not fix the issue of = non-orthogonality. There is very detailed description for CMP and CMC, = but nothing for PKCS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 = out of the box and it=E2=80=99ll just work=E2=80=9D? Or does it mean = =E2=80=9Cthe usage of PKCS#10 for these certs is still TBD=E2=80=9D?

 
PKCS#10 is pretty simple.  Are you aware of anything = more that ought to be said?
 
I think we should explicitly mention what this method *cannot* provide. As far as I can tell, none of the origin = authentication methods are available when using PKCS #10 directly = without wrapping it further.
 
That= is reasonable.  I will talk with my co-authors and see if we can = come up with a brief summary.
 

=C2=B7         I suggest to add the = following reference to the paragraph on quality randomness, as a strong = proof that this is a real world concern:

 
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, = "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network = Devices", Proceedings of the 21st USENIX Security Symposium , = August 2012, <https://factorable.net/>.
 
In another thread, something like this was suggested for = another document:
 
   Implementations must randomly generate nonces = and private keys.
   The use of inadequate = pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little = or no security. An attacker
   may find it much easier to = reproduce the PRNG environment that
   produced the keys, searching the resulting small = set of possibilities,
   rather than brute force = searching the whole key space. As example for
   predictable random numbers see CVE-2008-0166 = [=E2=80=A6]. The generation
   of quality random numbers = is difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS = 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and
   others offers valuable guidance in this = area.
 
If this approach works for you, we'll = dig up the appropriate references.
 
Yes, but the Heninger et al. reference is a better fit than = the Debian CVE because (1) it discusses network devices rather than = servers and (2) it shows how even less broken RNGs can be exploited by a = network attacker that only sees the public keys.
 
I = just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys.  How about:
 
 
   Implementations must randomly generate nonces = and private keys.
   The use of inadequate pseudo-random number = generators (PRNGs) to
   generate cryptographic keys can result in little = or no security. An attacker
   may find it much easier to reproduce the PRNG = environment that
   produced the keys, searching the resulting small = set of possibilities,
   rather than brute force searching the whole key = space. As an example of
   predictable random numbers see CVE-2008-0166 = [=E2=80=A6], and some consequences
   of low-entropy = random numbers are discussed in Mining Your Ps and Qs = [...].
   The generation of quality = random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A = Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], = and
  =  others offers valuable guidance in this area.


 
 

=C2=B7         I understand that = key generation is out of scope and maybe this needs to be a separate = work item, but recommending periodic replacement of the certs without = recommending a suitable mechanism leaves this solution with a big = hole.

 
I do not agree. =  It does offer the protocol for obtaining replacement certificates = for devices that are able to generating a fresh public/private key pair. =  Getting more detailed would be algorithm specific, which is not = appropriate in this document.
 
Not really, because the =E2=80=9Cprotocol=E2=80=9D described = here is: Client sends a CSR, Server responds with a complete client = configuration blob. This obviously doesn=E2=80=99t work for an already = deployed client.
 
I = am really confused.  The document  is an addition to = the Secure Zero Touch Provisioning (SZTP).  As such, it is = technique to securely provision a networking device when it is booting = in a factory-default state.  That should happen at the initial = deployment or after the device is reset to the factory configuration. =  This is not the protocol for use with an already deployed = client.
 
Russ
 
-- last-call mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call
= --Apple-Mail=_F8B832BD-0538-4803-8053-23DD31DE5E6A-- From nobody Mon Nov 29 08:59:57 2021 Return-Path: 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 8C8B53A067B; Mon, 29 Nov 2021 08:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ZAi3p-Dk-KLd; Mon, 29 Nov 2021 08:59:42 -0800 (PST) Received: from out25-ams.mf.surf.net (out25-ams.mf.surf.net [145.0.1.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484C13A0C37; Mon, 29 Nov 2021 08:59:38 -0800 (PST) Received: from mail.het.net.je (mail.het.net.je [192.87.110.20]) by outgoing1-ams.mf.surf.net (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPS id 1ATGxRZu002111 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 29 Nov 2021 17:59:30 +0100 Received: from 80-112-47-125.cable.dynamic.v4.ziggo.nl ([80.112.47.125] helo=smtpclient.apple) by mail.het.net.je with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mrjwR-0001yM-2p; Mon, 29 Nov 2021 16:55:47 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Klaas Wierenga Mime-Version: 1.0 (1.0) Date: Mon, 29 Nov 2021 17:59:27 +0100 Message-Id: <8887C96D-B7D6-4F99-B471-E15CC49311CC@wierenga.net> References: <4028e5fe5b7f4318a83185fd5ff07a40@huawei.com> Cc: secdir@ietf.org, alto@ietf.org, draft-ietf-alto-cdni-request-routing-alto.all@ietf.org, last-call@ietf.org In-Reply-To: <4028e5fe5b7f4318a83185fd5ff07a40@huawei.com> To: Qin Wu X-Mailer: iPad Mail (19B74) X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.87.110.20; country=NL; latitude=52.3824; longitude=4.8995; http://maps.google.com/maps?q=52.3824,4.8995&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0u6ogXrmL - fb4b8f9bb042 - 20211129 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-alto-cdni-request-routing-alto-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2021 16:59:47 -0000 Hi Qin, > On 24 Nov 2021, at 14:07, Qin Wu wrote: >=20 > =EF=BB=BFHi, Klaas: > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Klaas Wierenga via Datatracker [mailto:norepl= y@ietf.org]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B411=E6=9C=8824=E6=97=A5 1= 7:24 > =E6=94=B6=E4=BB=B6=E4=BA=BA: secdir@ietf.org > =E6=8A=84=E9=80=81: alto@ietf.org; draft-ietf-alto-cdni-request-routing-al= to.all@ietf.org; last-call@ietf.org > =E4=B8=BB=E9=A2=98: Secdir last call review of draft-ietf-alto-cdni-reques= t-routing-alto-17 >=20 > Reviewer: Klaas Wierenga > Review result: Has Issues >=20 > Hi, >=20 > I found 1 nit and one more substantial issue >=20 > - the abstract says: >=20 > OLD > RFC 8008 defines precisely the semantics of FCI and provides guidelines on= the FCI protocol, but the exact protocol is specified. >=20 > I think it should read >=20 > NEW > RFC 8008 defines precisely the semantics of FCI and provides guidelines on= the FCI protocol, but the exact protocol is not specified. >=20 > - A bigger problem I have is with the Security Considerations >=20 > You state "In the context of CDNI Advertisement, additional security > considerations should be included as follows:", you then list a set of > concerns, and then write: "Although protection strategies as described i= n > Section 15 of [RFC7285] should be applied to address aforementioned secu= rity > and privacy considerations, one additional information leakage risk > introduced by this document could not be addressed by these strategies. "= >=20 > So are they ADDITIONAL or were they ALREADY ADRESSED in RFC7285? Do you wa= nt to call the ones you list out as specifically relevant for this use-case?= Please be clear why you list them here. And if they are NOT sufficiently ad= dressed yet, you need to address them here. > [Qin Wu] : I believe these ADDITIONAL security has already been ADDRESSED b= y protection strategies proposed in RFC7285, but there is one exception case= , i.e.," one additional information leakage risk > introduced by this document could not be addressed by these strategies."= > Maybe the first paragraph and the second paragraph lack a good connectio= n link, I would propose to make the following change: > OLD TEXT: > " > In the context of CDNI Advertisement, additional security > considerations should be included as follows: > " > NEW TEXT: > " > In the context of CDNI Advertisement, the following security > issues need to be considered as follows: > " Would it be clearer if you would write s/additional/specifically ? It seems y= ou want to call out the one as of particular importance? > For the additional risk of leaking info from one uCDN to another uCDN it i= s unclear to me whether the intended mitigation is meant as normative (SHOUL= D instead of should) and I am curious why you don't make it a MUST. > [Qin Wu] I have no strong opinion on what language should be used, but I a= gree SHOULD is better than should. Perfect. Klaas >=20 From nobody Mon Nov 29 09:55:27 2021 Return-Path: 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 576CB3A03EA; Mon, 29 Nov 2021 09:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1QB0D2zm6P4s; Mon, 29 Nov 2021 09:55:17 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5443A0332; Mon, 29 Nov 2021 09:55:16 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id x6so75116900edr.5; Mon, 29 Nov 2021 09:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=bvdX+9/FGFCS7rTpFCLU1nAZkzM210QJKAWVxrzx5NI=; b=aZDjCtKsdP/VvbIUaUAN3N2JikdkCNBFsUDCnAkbWG36quiDlmGnxEOouE/pryzJCH Bri2DFm2mAudte/1r7pHiBbcFIGa0tKsQjeEX2YbIV6A8SUsMPIVzBY4zZ4slaPBdVly xfSQzwWxeUDtLLJKl7IJhyvCuKAWNi0QeRwgvKtwuDG4HlB9I/KHFpmG38Q+jZ8zcMRY U2KW+a4Xxw9l//m7Eik7NDK0RsN1OhemV3ZAZON1ez7Rc0AG4j2W9x/cwZqYT7jYo7B3 OPE9F2oc8TOuFOUI+//Dlx42G70G2Ow3DLJSr6zBbKo5cDFpJrfvpDYOvFA1BgkpR22x oQDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=bvdX+9/FGFCS7rTpFCLU1nAZkzM210QJKAWVxrzx5NI=; b=ZJfB+qojULuC7HstDSV3b5nIpbuu02CC1pa7RujufWqHPg4tcQIETHFiMLeedK/T+J u2jZwuHjSKZAYNCtY7U4cMuyhFmXztZxB1PxVj9ESj2Cs5DC1OdbteKPSJ2o+Bn17FbL +vkbK/vN0EFpwYftkuvlGIErThYeqlRon0tGvT1Mbb32FolNMfv487gXpzCFt2Ny2oBR 7RmgRFFbcHygvS0MRZRoFretiPNnNQZtPVk5eY8eBOYej11D+5CtV+6n6el8W44pOKgc rrtL8Jtk7mQCZFXBcQl9UMdhNJX+N0UjfuMb0Qu9AnlL4ckr64we8gfmnMZ9/ER65T8+ qeoQ== X-Gm-Message-State: AOAM533WyXQV144xE4Lb6DEe99fNa16VwejMPfh6tyR020ELuwyXnrc5 /PMmNxfYhYwf0Pkor765L0DL7PusVvg= X-Google-Smtp-Source: ABdhPJxovu03zAE6yR/eJyDVEzwFveaanDu6nh8HCIrVB9KdTI0n8XwXlICQEvYHgTCzGZ28Is3zAA== X-Received: by 2002:a17:906:4fc7:: with SMTP id i7mr38202811ejw.514.1638208513156; Mon, 29 Nov 2021 09:55:13 -0800 (PST) Received: from MacBook-Pro.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id sa17sm8240200ejc.123.2021.11.29.09.55.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Nov 2021 09:55:12 -0800 (PST) MIME-Version: 1.0 Date: Mon, 29 Nov 2021 19:55:08 +0200 From: Yaron Sheffer Thread-Topic: Re: [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: <9BF6DBF5-9394-4CFE-A8E5-E064AFE3A76D@vigilsec.com> Message-ID: <94FD2B17-7F8A-6843-9799-EF0C20F3F435@hxcore.ol> References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol>, <9BF6DBF5-9394-4CFE-A8E5-E064AFE3A76D@vigilsec.com> To: Russ Housley Cc: "last-call@ietf.org" , Kent Watsen , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "netconf@ietf.org" , IETF SecDir Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2021 17:55:22 -0000

Hi Russ,

 

I=E2=80=99m really = surprised that a factory reset is the right thing to do in this use case. B= ut you are the expert.

 =

The new text works for me.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Russ Housley <housley@vigilsec.com>
= Date: Monday, November 29, 2021 at 18:38
To: Yaron Sheffer= <yaronf.ietf@gmail.com>
Cc: last-call@ietf.org <last-ca= ll@ietf.org>, Kent Watsen <kent+ietf@watsen.net>, draft-ietf-netco= nf-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, = netconf@ietf.org <netconf@ietf.org>, IETF SecDir <secdir@ietf.org&= gt;
Subject: Re: [Last-Call] Secdir last call review of draft-iet= f-netconf-sztp-csr-11

Yaron:

 

Perhaps the word "regenerate" is t= he thing that is causing confusion.

 

Suggestion:

 

In cases where the S= ZTP-client does not possess an HSM, or otherwise is unable to use an HSM fo= r the private key, it is RECOMMENDED that the device periodically reset the= configuration to the factory default and repeat the SZTP protocol.  R= epeating the SZTP protocol may cause the device to generate a fresh private= key (and associated identity certificates). Details for how to generate a = new private key and associate a new identity certificate are outside the sc= ope of this document.

 

Russ

 

 

 

On Nov 28, 2021, at 3:22 PM, Yaron Sheffer <= ;yaronf.ietf@gmail.com> wro= te:

 

Hi Russ,

 

Thank you for the quick response.

 

We are in agreement re: P= KCS #10 and randomness.

 

In the third point below (certificate rotation),= I understand why the editors see it as out of scope. But we are still leav= ing implementers with no guidance, and we=E2=80=99ve all seen enough real w= orld cases where this leads to people ignoring the vague =E2=80=9Cregenerat= e the private key=E2=80=9D. Let me try to offer an alternative.<= /p>

 

Old:

 = ;

= In cases where the SZTP-client does not possess an HSM, or otherwise is una= ble to use an HSM for the private key, it is RECOMMENDED to regenerate the = private key (and associated identity certificates) periodically. Details fo= r how to generate a new private key and associate a new identity certificat= e are outside the scope of this document.

 

New:

=

 

=

In cases where the SZT= P-client does not possess an HSM, or otherwise is unable to use an HSM for = the private key, it is RECOMMENDED to regenerate the private key (and assoc= iated identity certificates) periodically. If CMP or CMC was used for initi= al certificate provisioning, it is RECOMMENDED to reuse the protocol (CMC o= r CMP) for periodic certificate registration. Similarly, implementations SH= OULD also reuse the initial origin authentication method.

 

Thanks,

 &n= bsp;            = ;  Yaron

 

 

Yaron:

<= /div>

 

&n= bsp;

Thank you for addr= essing my comments, I am happy with most of your responses but I do have a = few remaining questions:

 

=C2=B7       &nb= sp; The commit that = removes the dependency on IDevID and LDevID does not fix the issue of non-o= rthogonality. There is very detailed description for CMP and CMC, but nothi= ng for PKCS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box= and it=E2=80=99ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage o= f PKCS#10 for these certs is still TBD=E2=80=9D?

 

PKCS#10 is pretty simple.=  Are you aware of anything more that ought to be said?

=

 

I think we should explicitly mention what this = method *cannot* provide. As far as I can tell, none of the origin au= thentication methods are available when using PKCS #10 directly without wra= pping it further.

<= div style=3D'margin-left:.5in'>

 

That is reasonable.  I will = talk with my co-authors and see if we can come up with a brief summary.

 

=C2=B7&nb= sp;        I suggest to add the following reference to the p= aragraph on quality randomness, as a strong proof that this is a real world= concern:

 

Hen= inger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining Your = Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Proc= eedings of the 21st USENIX Security Symposium , August 2012, <https://factorable.net/>.

=

 

In another th= read, something like this was suggested for another document:

 

&nb= sp;  Implementations must randomly generate nonces and private ke= ys.

   The use of inadequate pseudo-random number generators (PRNG= s) to

=

   generate cryptographic keys can result in little or no se= curity. An attacker

   may find it much easier to reproduce the PR= NG environment that

   produced the keys, searching the resulting = small set of possibilities,

   rather than brute force searching t= he whole key space. As example for

   predictable random numbers s= ee CVE-2008-0166 [=E2=80=A6]. The generation

   of quality random = numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],

   = ;NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [R= FC4086], and

   others offers valuable guidance in this area.=

=  

If this approach works for you, we'll dig up the appropriate referenc= es.

 

Yes, but the Heninger et al. reference is a better fit than the Deb= ian CVE because (1) it discusses network devices rather than servers and (2= ) it shows how even less broken RNGs can be exploited by a network attacker= that only sees the public keys.

 

I just read = the Abstract of the paper, and I see your point about the attacker only obs= erving the public keys.  How about:

 

 

   Implementations must randomly= generate nonces and private keys.

&nbs= p;  The use of inadequate pseudo-random number generators (PRNGs) to

   generate cryptographic keys= can result in little or no security. An attacker

   may find it much easier to reproduce the PRNG envir= onment that

=

   produced the k= eys, searching the resulting small set of possibilities,

   rather than brute force searching the whole = key space. As an example of

  &nbs= p;predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some conseq= uences

   of low-entropy rand= om numbers are discussed in Mining Your Ps and Qs [...].

   The generation of quality random number= s is difficult. ISO/IEC 20543:2019 [=E2=80=A6],

<= div>

   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [= =E2=80=A6], BCP 106 [RFC4086], and

&nbs= p;  others offers valuable guidance in this area.

=

 

 

 

=C2=B7    &nbs= p;    I understand that key generation is out of scope and maybe this needs to b= e a separate work item, but recommending periodic replacement of the certs = without recommending a suitable mechanism leaves this solution with a big h= ole.

=

 

I do not agree.  It does offer the protocol = for obtaining replacement certificates for devices that are able to generat= ing a fresh public/private key pair.  Getting more detailed would be a= lgorithm specific, which is not appropriate in this document.

 

Not really, because the =E2=80=9Cprotocol=E2= =80=9D described here is: Client sends a CSR, Server responds with a comple= te client configuration blob. This obviously doesn=E2=80=99t work for an al= ready deployed client.

<= div>

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>I am really confused.  = The document  is an addition to the Secure Zero Touch Provisionin= g (SZTP).  As such, it is technique to securely provision a networking= device when it is booting in a factory-default state.  That should ha= ppen at the initial deployment or after the device is reset to the factory = configuration.  This is not the protocol for use with an already deplo= yed client.

=

 

=

Russ

 <= /p>

-- 
last-call mailing list
last-call@ietf.org
https://www.ie= tf.org/mailman/listinfo/last-call

 <= /p>= From nobody Mon Nov 29 13:05:43 2021 Return-Path: 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 7BA4C3A09A4 for ; Mon, 29 Nov 2021 13:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 luy0YwEo91pu for ; Mon, 29 Nov 2021 13:05:36 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 DBB3E3A09A1 for ; Mon, 29 Nov 2021 13:05:35 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4J2yYS5gxpz1sy for ; Mon, 29 Nov 2021 22:05:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1638219932; bh=6o0oJVDBmqyWTiPwYsw3wF7QeyNTulmElKfZXSssn3E=; h=Date:From:To:Subject; b=dCejFXTCWRdmQGgBhsfdnWgq3ZWuAppr9n7MVhUzNvnu2j1KC8Y8nJSz/XaisgGWr Zlz9jphnfvWqjPGj+txkg2qVzQC1uK1C8Mtr8xNVUFK1Xlfl948+NLS4/oTkc87ZZE hjbly946005hWJHMLHPITbRqYM6fJWkV3+UxnbnM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id h54_-tgX-8nT for ; Mon, 29 Nov 2021 22:05:31 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Mon, 29 Nov 2021 22:05:31 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AB3E01819CE; Mon, 29 Nov 2021 16:05:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A70731819CD for ; Mon, 29 Nov 2021 16:05:30 -0500 (EST) Date: Mon, 29 Nov 2021 16:05:30 -0500 (EST) From: Paul Wouters To: secdir Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [secdir] (updated) review of draft-ietf-i2nsf-capability-data-model-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2021 21:05:42 -0000 Note to tools team: I was assigned draft-ietf-i2nsf-capability-data-model, although I had already reviewed the -16 version. I did a review now of the -21 version but did not see a way within datatracker to update the review. So I opted to use the secdir mailing list for now. Paul 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 summary of the review is Has Issues I have reviewed the document. I don't have any particular security concerns, and the Security Considerations section is fine. I do have some questions/issues from reading the document. I am a bit confused about this part: | | +--rw ipv4-capability* identityref | | +--rw ipv6-capability* identityref | | +--rw icmpv4-capability* identityref | | +--rw icmpv6-capability* identityref | | +--rw tcp-capability* identityref | | +--rw udp-capability* identityref There is an item for v4 and v6 support. Why is there a split of icmpv4 and icmpv6? Why isn't that done similarly to tcp and udp that don't have v4/v6 versions? This term seems to be rather generic: | | +--rw url-capability* identityref Perhaps what is meant is url-filtering-capability or url-protection-capability ? It also seems rw advanced-nsf-capabilities is really either "rw protection-nsf-capabilities" or "rw filtering-nsf-capabilities" ? It seems "advanced" is a very generic term? It could be useful to allow for further non-filter/non-protective options, but it does seem right now this "advanced" category really means some kind of "client protection" category. Similarly, "rw target-capabilities" might be better descriped as "rw destination-capabilities" to avoid confusing about this being a "targetting system" or the client being "targetted". I also find "rw action-capabilities" confusing. Isn't "anti-virus" and "anti-ddos" also an action capability ? Or should I read this as a condition of "anti-virus" kind activate an action capability (filter in, filter out, log). It also seems the selector (eg "anti-virus") is coupled to an action (eg "block") so I'm a bit confused on why there is no capability link between these. Eg having "filtering" as a capability seems related to some conditionals, but perhaps not all. So I am not sure if the current model could describe that. Eg lets say there is a packet filter, not but no filter based on anti-virus but it can detect anti-virus. How would one know from these capabilities that anti-virus has "filter" and not only "log" ? And "rw generic-nsf-capabilities" seems to be more like "rw transport-nsf-capabilities" There are many email contacts listed in Section 6. These will not stand the passing of time. Why are they needed? Should there be an IANA registry/contact instead ? the identity targets include base target-device which only has a description field. So all these identity targets _only_ have a description. Is the presense of an empty identity entry enough to indicate this support, or is some kind of boolean field needed? identity flags is only about TCP. Should it be called tcp-flags (like tcp-options) ? Similar issue with identity total-length, verification-tag, identity chunk-type and service-code. I see identity for pop3 and imap. Does that include pop3s and imaps (version of those protocols over TLS). If so, should it be clarified in the description text? If not, do we need seperate identity types for these? I see identities for pass, drop, mirror and rate-limit, but not for reject (eg send an ICMP back) Security Considerations Section: The lowest layer of RESTCONF protocol layers MUST use HTTP over Transport Layer Security (TLS), that is, HTTPS [RFC7230][RFC8446] as a secure transport layer. This excludes QUIC? Perhaps it is better to say use an encrypted and authenticated transport layer, such as TLS or QUIC using HTTPS. I am a little confused at Example 3. It shows: It's only capability is "user-defined". It's only actions are "ingress/egree options that do pass/drop/mirror. Where does it state this is a web filter capability ? And does it really mean the web URI and content can be passed/dropped/mirrored? It feels like these pass/drop/mirror targets are for packets, not web-uri streams ? And should these actions not be inside the capability ? What if you define an NSF that has url-capability and a packet filter capability, how would one know the pass/mirror/drop targets are for the url-capability ot the packet filter capability ? Maybe, one of the examples can include an NSF with multiple conditions and actions that don't fully overlap? NITS Every NSF SHOULD be described with the set of capabilities it offers This is a directive for humans at the manufacturor which we can't impose RFC2119 words on :) I would just lowercase the SHOULD. Similar: Capabilities MUST be defined in a vendor- and technology- independent manner I would say "Capabilities are defined ...." Humans can refer to categories of security controls and understand each other. I find the use of the word "humans" a little amusing here :) More seriously though, I think a lot of this is for automated processing by tools, not humans. As a further example, network security experts unequivocally refer to "packet filters" as stateless devices I am not sure this is true. Some "packet filters" are statefull firewalls. I find the long sentence using "one can do this, one can do that and one can do something else" very hard to read. Perhaps split this up and just repeat "an attack can " .... I struggled when reading: Some of the features that this document defines capability indicators for are (although it is perfectly fine. For some reason it took me a little while to figure out how to read it) From nobody Tue Nov 30 04:47:14 2021 Return-Path: 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 722083A091B; Tue, 30 Nov 2021 04:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CyYZRxMXRBmA; Tue, 30 Nov 2021 04:46:58 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF4C3A086F; Tue, 30 Nov 2021 04:46:57 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id i5so44167044wrb.2; Tue, 30 Nov 2021 04:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=abB5MXi0pAuPgWUma28LVNK7GidN8/0x9XbhXthm8cY=; b=oaCMgE6PDii8jPo7tYlt3w1bR+w7i2K4qUOb+39Qz0xTnZANT0aaUujlI2Y02iKNGA iW+6JkepFAkt8Qv3RaHCM0Xb86KfGfKjJ6XgfL+JXlBl5PwdSEzzkmTe3KNbb8j9OV8X A9XRXJJAmF8Si9GW03yvsA6kJNc4CuL1gKFO0Cmkzi4m3lpspiSpUG7exuc0YU/qrnWY c74WY7peRSyYScmN5vELIvI3BtFgfj1/iKs8sSoJl+K/FYZheTNz89zYhQGSQgRF6TFp 6byUYqmSHYaXfJJG+RnIedHRZ+qlgpMiaYp8Y9k5mLq6GDIfLzd79AM4tBqOVdOtnEbk 6V6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=abB5MXi0pAuPgWUma28LVNK7GidN8/0x9XbhXthm8cY=; b=ZZ4FPcdLuIX0smcArs9n0pNBpynq0SWNxpY8n3ZmmGWMseMmL/eJ/CIm7GNZyLWsVi zAPjlpdz5DiiuXfNm0+W/FcevxTfOWuR8XvGwqN/KEro7ZkzhzPluBxzfmKDZ6BuySyI Tdn4BJWb/CknjcW6obFCKQSzX9NObt8JQ5xuQnvhE19BuHEWTelegztFCEKYMFx8IxXm y6fouK23Lwko5QY/Bu0+Tv3qUjV+ADEHJf8t7LQy//UCxLAR88s2REDUzlkdmke5fhDY oF6hvZnrJ5RSgyzDvA82aoWge/+V3EPthY5as+YIc1w5Eoj9JzuR3NqJyRMK8PvAUaNf qk5Q== X-Gm-Message-State: AOAM5311SeUs4cRnLbfyXZbdgWpTw0qIMt+jLPm3ZQYyBtfDYrv28/iZ AtsRcMV/mVkf7L6/A3FulLN1ibKqplMcHntYX61pNCZJjt8= X-Google-Smtp-Source: ABdhPJxFx/h41SN480Hu/mqv651tQGz53kixTUh6TxXQlat9dyH4axuBtQ+w46yPea2kaar8I3/VQ1GT3Nclj9XTB8k= X-Received: by 2002:a5d:64ea:: with SMTP id g10mr41364551wri.242.1638276411226; Tue, 30 Nov 2021 04:46:51 -0800 (PST) MIME-Version: 1.0 References: <4028e5fe5b7f4318a83185fd5ff07a40@huawei.com> <8887C96D-B7D6-4F99-B471-E15CC49311CC@wierenga.net> In-Reply-To: <8887C96D-B7D6-4F99-B471-E15CC49311CC@wierenga.net> From: Jensen Zhang Date: Tue, 30 Nov 2021 20:46:40 +0800 Message-ID: To: Klaas Wierenga Cc: Qin Wu , last-call@ietf.org, draft-ietf-alto-cdni-request-routing-alto.all@ietf.org, IETF ALTO , secdir@ietf.org Content-Type: multipart/alternative; boundary="00000000000088fb2e05d200f352" Archived-At: Subject: Re: [secdir] [alto] Secdir last call review of draft-ietf-alto-cdni-request-routing-alto-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2021 12:47:03 -0000 --00000000000088fb2e05d200f352 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Klaas and Qin, Thanks for the review and suggestions. See my comments inline. Thanks, Jensen On Tue, Nov 30, 2021 at 12:59 AM Klaas Wierenga wrote: > Hi Qin, > > > On 24 Nov 2021, at 14:07, Qin Wu wrote: > > > > =EF=BB=BFHi, Klaas: > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Klaas Wierenga via Datatracker [mailto:nor= eply@ietf.org] > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B411=E6=9C=8824=E6=97= =A5 17:24 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: secdir@ietf.org > > =E6=8A=84=E9=80=81: alto@ietf.org; > draft-ietf-alto-cdni-request-routing-alto.all@ietf.org; last-call@ietf.or= g > > =E4=B8=BB=E9=A2=98: Secdir last call review of > draft-ietf-alto-cdni-request-routing-alto-17 > > > > Reviewer: Klaas Wierenga > > Review result: Has Issues > > > > Hi, > > > > I found 1 nit and one more substantial issue > > > > - the abstract says: > > > > OLD > > RFC 8008 defines precisely the semantics of FCI and provides guidelines > on the FCI protocol, but the exact protocol is specified. > > > > I think it should read > > > > NEW > > RFC 8008 defines precisely the semantics of FCI and provides guidelines > on the FCI protocol, but the exact protocol is not specified. > [Jensen] Thanks for pointing it out. The authors will fix it in the next revision. > > > > - A bigger problem I have is with the Security Considerations > > > > You state "In the context of CDNI Advertisement, additional security > > considerations should be included as follows:", you then list a set o= f > > concerns, and then write: "Although protection strategies as describe= d > in > > Section 15 of [RFC7285] should be applied to address aforementioned > security > > and privacy considerations, one additional information leakage risk > > introduced by this document could not be addressed by these > strategies. " > > > > So are they ADDITIONAL or were they ALREADY ADRESSED in RFC7285? Do you > want to call the ones you list out as specifically relevant for this > use-case? Please be clear why you list them here. And if they are NOT > sufficiently addressed yet, you need to address them here. > > [Qin Wu] : I believe these ADDITIONAL security has already been > ADDRESSED by protection strategies proposed in RFC7285, but there is one > exception case, i.e.," one additional information leakage risk > > introduced by this document could not be addressed by these > strategies." > > Maybe the first paragraph and the second paragraph lack a good > connection link, I would propose to make the following change: > > OLD TEXT: > > " > > In the context of CDNI Advertisement, additional security > > considerations should be included as follows: > > " > > NEW TEXT: > > " > > In the context of CDNI Advertisement, the following security > > issues need to be considered as follows: > > " > [Jensen] Qin's proposed text looks good to me. The four bullet items are risk scenarios that are not listed in RFC7285 but can be addressed by corresponding protection strategies proposed by RFC7285. Only the "one additional information leakage risk" in the next paragraph is the exception that cannot be addressed by RFC7285. > > Would it be clearer if you would write s/additional/specifically ? It > seems you want to call out the one as of particular importance? > [Jensen] Sounds good to me. > > > For the additional risk of leaking info from one uCDN to another uCDN i= t > is unclear to me whether the intended mitigation is meant as normative > (SHOULD instead of should) and I am curious why you don't make it a MUST. > > [Qin Wu] I have no strong opinion on what language should be used, but = I > agree SHOULD is better than should. > > Perfect. > [Jensen] For my understanding, the protection strategy is just an optional feature that is recommended to be implemented, but not a mandatory-to-implement feature. All the protection strategies described in RFC7285 also use "should" not "must". But I also agree "SHOULD" is better. > > Klaas > > > > > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto > --00000000000088fb2e05d200f352 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Klaas and Qin,

Than= ks for the review and suggestions. See my comments inline.

Thanks,
Jensen
<= /div>

On Tue, Nov 30, 2021 at 12:59 AM Klaas Wierenga <klaas@wierenga.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi Qin,

> On 24 Nov 2021, at 14:07, Qin Wu <bill.wu@huawei.com> wrote:
>
> =EF=BB=BFHi, Klaas:
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Klaas Wierenga via Datatracker [mailto:noreply@ietf.org] <= br> > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B411=E6=9C=8824=E6=97= =A5 17:24
> =E6=94=B6=E4=BB=B6=E4=BA=BA: secdir@ietf.org
> =E6=8A=84=E9=80=81: alto@ietf.org; draft-ietf-alto-cdni-request-routing-a= lto.all@ietf.org; last-call@ietf.org
> =E4=B8=BB=E9=A2=98: Secdir last call review of draft-ietf-alto-cdni-re= quest-routing-alto-17
>
> Reviewer: Klaas Wierenga
> Review result: Has Issues
>
> Hi,
>
> I found 1 nit and one more substantial issue
>
> - the abstract says:
>
> OLD
> RFC 8008 defines precisely the semantics of FCI and provides guideline= s on the FCI protocol, but the exact protocol is specified.
>
> I think it should read
>
> NEW
> RFC 8008 defines precisely the semantics of FCI and provides guideline= s on the FCI protocol, but the exact protocol is not specified.

[Jensen] Thanks for pointing it out. The authors w= ill fix it in the next revision.
=C2=A0
>
> - A bigger problem I have is with the Security Considerations
>
> You state "In the context of CDNI Advertisement, additional secur= ity
>=C2=A0 =C2=A0considerations should be included as follows:", you t= hen list a set of
>=C2=A0 =C2=A0concerns, and then write: "Although protection strate= gies as described in
>=C2=A0 =C2=A0Section 15 of [RFC7285] should be applied to address afore= mentioned security
>=C2=A0 =C2=A0and privacy considerations, one additional information lea= kage risk
>=C2=A0 =C2=A0introduced by this document could not be addressed by thes= e strategies. "
>
> So are they ADDITIONAL or were they ALREADY ADRESSED in RFC7285? Do yo= u want to call the ones you list out as specifically relevant for this use-= case? Please be clear why you list them here. And if they are NOT sufficien= tly addressed yet, you need to address them here.
> [Qin Wu] : I believe these ADDITIONAL security has already been ADDRES= SED by protection strategies proposed in RFC7285, but there is one exceptio= n case, i.e.," one additional information leakage risk
>=C2=A0 =C2=A0introduced by this document could not be addressed by thes= e strategies."
>=C2=A0 =C2=A0Maybe the first paragraph and the second paragraph lack a = good connection link, I would propose to make the following change:
>=C2=A0 =C2=A0OLD TEXT:
>=C2=A0 =C2=A0"
>=C2=A0 =C2=A0 In the context of CDNI Advertisement, additional security=
>=C2=A0 =C2=A0considerations should be included as follows:
>=C2=A0 =C2=A0"
>=C2=A0 =C2=A0NEW TEXT:
>=C2=A0 =C2=A0"
>=C2=A0 =C2=A0 In the context of CDNI Advertisement, the following secur= ity
>=C2=A0 =C2=A0 issues need to be considered as follows:
>=C2=A0 =C2=A0"

[Jensen] Qin= 9;s proposed text looks good to me. The four bullet items are risk scenario= s that are not listed in RFC7285 but can be addressed by corresponding prot= ection strategies proposed by RFC7285. Only the "one additional inform= ation leakage risk" in the next paragraph is the exception that cannot= be addressed by RFC7285.
=C2=A0

Would it be clearer if you would write s/additional/specifically ? It seems= you want to call out the one as of particular importance?
=

[Jensen] Sounds good to me.
=C2=A0

> For the additional risk of leaking info from one uCDN to another uCDN = it is unclear to me whether the intended mitigation is meant as normative (= SHOULD instead of should) and I am curious why you don't make it a MUST= .
> [Qin Wu] I have no strong opinion on what language should be used, but= I agree SHOULD is better than should.

Perfect.

[Jensen] For my understanding,= the protection strategy is just an optional feature that is recommended to= be implemented, but not a mandatory-to-implement feature. All the protecti= on strategies described in RFC7285 also use "should" not "mu= st". But I also agree "SHOULD" is better.
=C2=A0

Klaas

>

_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
--00000000000088fb2e05d200f352-- From nobody Tue Nov 30 09:31:00 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCEC3A12C3; Tue, 30 Nov 2021 05:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1638278789; bh=54+T3N5qd0G/sfTb4xTuOFPbEze2ajf41rnaPFxE4u8=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Kw23zmaMjMlqTcxGlDrv6CPslRdT9xDc2EBVzM26KRn25OlhggqcDCLWc6HkYHQMC pM9rQJKNLXzWX7jN9crue/ekzJ8m/OliNMPiHS45bKvZPkkoBh/yJddxFV3BkFv2J2 gP/87K4lQ4+vKjdUzocmmhZLIbARpPLflJ32QdlE= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Nov 30 05:26:28 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A623A129F; Tue, 30 Nov 2021 05:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1638278788; bh=54+T3N5qd0G/sfTb4xTuOFPbEze2ajf41rnaPFxE4u8=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rzxQkfoSNYt27H2gKcVnmxiGVrKl9l+gchvhZD130pHsqXaHK8FCxhXFBCbWrurGk yr7gPpMylhmtlK/vL1EjMP6S2GpzAXPl1yjJfrP8XCC5nm2lKuBACLh/bIKtnXEGQa cWDbfg81tIX3ta00xKUCrNiDvVgrtxwJVmdMnbiw= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9853A129F for ; Tue, 30 Nov 2021 05:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.559, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 eJ_x-fSWT8Wi for ; Tue, 30 Nov 2021 05:26:23 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 BBEFE3A0903 for ; Tue, 30 Nov 2021 05:26:23 -0800 (PST) Received: from [194.5.48.239] (helo=[10.85.0.62]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ms39J-0003xN-PT for new-work@ietf.org; Tue, 30 Nov 2021 13:26:22 +0000 Message-ID: <0d8de5e8-6888-8651-5682-6726107d9c09@w3.org> Date: Tue, 30 Nov 2021 21:26:17 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: new-work@ietf.org From: xueyuan Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 30 Nov 2021 09:31:00 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Scalable Vector Graphics (SVG) Working Group (until 2022-01-10/11) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2021 13:26:33 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBTY2FsYWJs ZSBWZWN0b3IgR3JhcGhpY3MgKFNWRykKV29ya2luZyBHcm91cDoKIMKgIGh0dHBzOi8vd3d3Lncz Lm9yZy8yMDIxLzExL3N2Zy1wcm9wb3NlZC1jaGFydGVyLTIwMjEuaHRtbAoKQXMgcGFydCBvZiBl bnN1cmluZyB0aGF0IHRoZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBX M0MsIHRoaXMgZHJhZnQgY2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21t aXR0ZWUgcmV2aWV3IHBlcmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdo IDA0OjU5IFVUQyBvbiAxMSBKYW51YXJ5CigyMzo1OSwgQm9zdG9uIHRpbWUgb24gMTAgSmFudWFy eSwgMjAyMikgb24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIuClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRv IHB1YmxpYy1uZXctd29ya0B3My5vcmcsCndoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAg aHR0cHM6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90 aGVyIHRoYW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29y eQpDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3Bv bnNlIHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNl IGNvb3JkaW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJl cHJlc2VudGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNv bW1lbnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVw cmVzZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29t bWVudHMuCgpUaGUgY3VycmVudCBjaGFydGVyIGlzIGhlcmVieSBleHRlbmRlZCB1bnRpbCAzMSBK YW51YXJ5IDIwMjIgdG8KYWNjb21tb2RhdGUgdGhlIGNoYXJ0ZXIgcmV2aWV3IHBlcmlvZC4KaHR0 cHM6Ly93d3cudzMub3JnL0dyYXBoaWNzL1NWRy9zdmctMjAxOS5odG1sCgpJZiB5b3Ugc2hvdWxk IGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFzZQpj b250YWN0IENhcmluZSBCb3VybmV6LCBTVkcgV0cgVGVhbSBDb250YWN0LCBhdCA8Y2FyaW5lQHcz Lm9yZz4uCgpUaGFuayB5b3UsClh1ZXl1YW4gSmlhLMKgIFczQyBNYXJrZXRpbmcgJiBDb21tdW5p Y2F0aW9ucwoKWzFdIGh0dHBzOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0Cgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBt YWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXctd29yawo= From nobody Tue Nov 30 09:42:45 2021 Return-Path: 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 43C983A07BC for ; Tue, 30 Nov 2021 09:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no 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 jM11fLHlBqdS for ; Tue, 30 Nov 2021 09:42:41 -0800 (PST) Received: from smtp100.iad3a.emailsrvr.com (smtp100.iad3a.emailsrvr.com [173.203.187.100]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6713A143B for ; Tue, 30 Nov 2021 09:42:40 -0800 (PST) Received: from app14.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0BD17251A1; Tue, 30 Nov 2021 12:42:40 -0500 (EST) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app14.wa-webapps.iad3a (Postfix) with ESMTP id F07B8600BA; Tue, 30 Nov 2021 12:42:39 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 30 Nov 2021 09:42:39 -0800 (PST) X-Auth-ID: scott@hyperthought.com Date: Tue, 30 Nov 2021 09:42:39 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-regext-rfc7484bis.all@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain X-Client-IP: 73.93.184.62 Message-ID: <1638294159.982316211@apps.rackspace.com> X-Mailer: webmail/19.0.13-RC X-Classification-ID: 2f904963-70a9-42d1-a429-cf35882d605c-1-1 Archived-At: Subject: [secdir] secdir review of draft-ietf-regext-rfc7484bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2021 17:42:44 -0000 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AThe summary of the review is almost ready= =0A=0AThis review is quite late, but still ahead of the telechat, so I hope= it is useful.=0A=0AFrom the abstract:=0A This document specifies a metho= d to find which Registration Data=0A Access Protocol (RDAP) server is aut= horitative to answer queries for=0A a requested scope, such as domain nam= es, IP addresses, or Autonomous=0A System numbers. This document obsolet= es RFC7484=0A=0AHere is the security considerations section:=0A=0A "By pr= oviding a bootstrap method to find RDAP servers, this document=0A helps t= o ensure that the end users will get the RDAP data from an=0A authoritati= ve source, instead of from rogue sources. The method has=0A the same sec= urity properties as the RDAP protocols themselves. The=0A transport used= to access the registries can be more secure by using=0A TLS [RFC8446], w= hich IANA supports.=0A=0A Additional considerations on using RDAP are des= cribed in [RFC7481]."=0A=0ABecause this document is updating RFC7484, and b= ecause these security considerations are copied verbatim from that doc, I h= esitate to raise my concern. Nonetheless, I think the assertion that this d= ocument "helps to ensure that the end users will get the RDAP data from an = authoritative source, instead of from rogue sources." is questionable. I th= ink the suggestion to use TLS helps, but I think it would be better to say = something like this:=0A=0A"This document specifies a method to find which R= DAP server is authoritative to answer queries for a requested scope, such a= s domain names, IP addresses, or Autonomous System numbers. If this data is= not authenticated, an adversary may inject data that redirects the user to= a rogue RDAP server. A robust authentication method such as may be provide= d by TLS [RFC8446] SHOULD be utilized to protect against this.=0A=0AAdditio= nal considerations on using RDAP are described in [RFC7481]."=0A=0AI'm not = attached to the precise wording, but I think implementers should be told wh= at the risks are, and how to mitigate them. I don't think the current secur= ity considerations quite hit that aspiration.=0A=0A--Scott=0A=0A=0A