Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE301B2C4C; Tue, 9 Jun 2015 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1IwZ0w0yk_jJ; Tue, 9 Jun 2015 06:51:41 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8045F1B2C5E; Tue, 9 Jun 2015 06:50:41 -0700 (PDT) X-SBRS: None Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jun 2015 15:50:41 +0200 Received: from MUCSE607.infineon.com (mucltm.muc.infineon.com [172.23.8.247]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Tue, 9 Jun 2015 15:50:39 +0200 (CEST) Received: from MUCSE613.infineon.com (172.23.7.84) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 9 Jun 2015 15:50:38 +0200 Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE613.infineon.com (172.23.7.84) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 9 Jun 2015 15:50:38 +0200 Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.0995.032; Tue, 9 Jun 2015 15:50:38 +0200 From: To: , , Thread-Topic: SecDir Review of draft-ietf-rtcweb-stun-consent-freshness-14 Thread-Index: AdCiuP9HBMF1kiH7Sn2XX8QyBIo+fw== Date: Tue, 9 Jun 2015 13:50:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0A98_01D0A299.B98CE8E0" MIME-Version: 1.0 Archived-At: Subject: [secdir] SecDir Review of draft-ietf-rtcweb-stun-consent-freshness-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 13:51:45 -0000 ------=_NextPart_000_0A98_01D0A299.B98CE8E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0A99_01D0A299.B98CE8E0" ------=_NextPart_001_0A99_01D0A299.B98CE8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. In my view, this document is Ready with Issues. The purpose of the document is to reduce flooding attacks by defining a standard method for WebRTC endpoints to obtain "consent to send" before sending traffic to another endpoint and continuously while sending. I have a few questions: 1) Will misbehaving or malicious endpoints obey this? If not, what's the point? If only a few polite endpoints go to the trouble of obtaining consent to send, I don't see how this will solve anything. 2) Section 5.1 says "An endpoint MUST NOT send data other than the messages used to establish consent unless the receiving endpoint has consented to receive data." This seems to be a long way from the present reality. How many applications implement this requirement? Or will this feature somehow be built into the OS? 3) The document says that "Consent expires after 30 seconds." And "Implementations SHOULD set a default interval of 5 seconds" for retransmitting STUN binding requests (requests for consent). If I understand this correctly, every pair of endpoints with an active connection will now exchange STUN binding request and response pairs in each direction every five seconds. That works out to about one packet per second transit for every connection. That seems like a lot of overhead. Is the benefit adequate? Other than these issues, the document seems ready. Thanks, Steve ------=_NextPart_001_0A99_01D0A299.B98CE8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

 

In my view, = this document is Ready with Issues.

 

The purpose = of the document is to reduce flooding attacks by defining a standard = method for WebRTC endpoints to obtain “consent to send” = before sending traffic to another endpoint and continuously while = sending. I have a few questions:

 

1)      = Will misbehaving or malicious endpoints obey = this? If not, what’s the point? If only a few polite endpoints go = to the trouble of obtaining consent to send, I don’t see how this = will solve anything.

 

2)      = Section 5.1 says “An endpoint MUST NOT = send data other than the messages used to establish consent unless the = receiving endpoint has consented to receive data.” This seems to = be a long way from the present reality. How many applications implement = this requirement? Or will this feature somehow be built into the = OS?

 

3)      = The document says that “Consent expires = after 30 seconds.” And “Implementations SHOULD set a default = interval of 5 seconds” for retransmitting STUN binding requests = (requests for consent). If I understand this correctly, every pair of = endpoints with an active connection will now exchange STUN binding = request and response pairs in each direction every five seconds. That = works out to about one packet per second transit for every connection. = That seems like a lot of overhead. Is the benefit = adequate?

 

Other than these issues, the document seems = ready.

 

Thanks,

 

Steve

 

------=_NextPart_001_0A99_01D0A299.B98CE8E0-- ------=_NextPart_000_0A98_01D0A299.B98CE8E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM7jCCA+4w ggLWoAMCAQICEGsk517Bqmu0TbjoYC/BbAIwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCZGUx ITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVj aG5vbG9naWVzIEFHIFJvb3QgQ0EgMjAeFw0xMTA3MjYxMzEyMjBaFw0zNjA3MjYxMzIyMjBaMF0x CzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMT IkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDMQpw2+wMM1Zu9gvlmBJSMi0GGkpvNL+RUfdNatlMGrliwyaCEB+HZzZP9CLys cLIglTKWeANzKozlAjE4ubdO/Y1IBmnuJMDW2lI73bZOwR2Y0shwmO1esRd2EyGCtVa9RgKa7HD3 pEHJAXlu9+IejoYv94lF80E/5jsNMeczlwUV7cF3NwXQKMoRd1BHGtFnwwOqIVELmDC/coQM6UXe MlUzYpfVJyqdCiNHU0wPzFNyeDObgDOLNIH222OuRR5wsDvmDiP/6j8QPTBJ71uGWlFE6B7cVvAO QXVDCZYLpfQLkNFnG8BElOH7gSzuAiBvQtoERRC1QyZZC2MEValdAgMBAAGjgakwgaYwDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFDhv1fR35slaIStRFWrWIKsC DacVMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9v dGNhMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEB BQUAA4IBAQCsiCetpToA0t9yFxPkiw1pekvEPPEeOqsMEGa/Xf6JyqZCC0lSAyu9Uo6l6YSCAb73 f0TjNH0JDNApW2q6556qloVM0almOTirDaM+R8bJzeRg7xHeZriif9QWfA9czBfK6MSDTDULatcH mJwNznVQWuRBefTg/txo0OuPvvmbuGVT8hhdEf1fu0rcX7fE1X7zP27opZ3DjMk+ocu9MRk3L+Cw ISxiCfo2af0hWLZBTuQPqODjx73waxOAK317QwRC4m84BwUEZ3IR3CfvK3ukk6UQ8Pgl6SmDdzNw KGVNo+tNELKtgW125xQ5znatvPJQjYJjhB0XikvWjdKJL48PMIIEIzCCAwugAwIBAgIKYR4k+gAA AAAAAjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJkZTEhMB8GA1UEChMYSW5maW5lb24gVGVj aG5vbG9naWVzIEFHMSswKQYDVQQDEyJJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgUm9vdCBDQSAy MB4XDTExMDcyNzEyMzIwNVoXDTI2MDcyNzEyNDIwNVowXTELMAkGA1UEBhMCZGUxITAfBgNVBAoT GEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVz IEFHIFVzZXIgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBHZyb03ScBt//g 4A4cOg5bRHXlpCBOyzJo/X4sMpuxu+47KFkVAIWhUlyhVk4f22+EDos6Ley7/10Pl7VNBuTj0i07 P5vjTbT/CgshA3mcRb4xqyXZx4Eh/rnMicAlXQ8OUhbg+uBMjBOuvQrhXg2epP6+etKdg6LlXDrD edZflpmIGvn8sgGyfbAiH0Wy/HGJngg6dncHacL6hPzGTrhR4bJwTnogxhN7NaDmuU1OxzKjsPc7 cidAmTtIlGpEfXj162C8GZ6vQjmBjH+ZqEdnz86IPGnUHb4Ifoa/GVzSlH0hPtMmybczi/BAcAQO obiKhfCbpNU8/nXhuiQ3kbcCAwEAAaOB5DCB4TALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFBoYmNi4 E/3bHsoMirMTA3B3wxeWMB8GA1UdIwQYMBaAFDhv1fR35slaIStRFWrWIKsCDacVMDwGA1UdHwQ1 MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9vdGNhMi5jcmwwEgYD VR0TAQH/BAgwBgEB/wIBADBABgNVHSAEOTA3MDUGCyqCFABEChQBAQEBMCYwJAYIKwYBBQUHAgEW GGh0dHBzOi8vY3BzLmluZmluZW9uLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAbOjg2haQMCPP0ZcS 1+hd0teYaBpi2LpwADGVyFAUO2UuPKGxAfYxWf3/v0FNW2IOhNKj8w3f076sKkeSlb6WiZZIe+ao kG2H6AimMIlhvv4GGAFHzQLVclXIz9jM7H4fH/wA/gHE4wDE1dvsGVjeM2fEjwTOtNrPzGF9SF1s NyJy8a2AZ83b6J6WIN72Jg2KXXQuVsa61/q2C5AAMfXLL4shuWN1JnYO03PBUjYWxqNdcETppKhc swaIZJ0MjKDttzuT9IntFeoOYMJx27KGowOqMDbmRoXRGWZahO4m4UkjIo9uzMX7U5EQymoMiVJc Ndp3qT5b48QXhmDe7Cmd4DCCBNEwggO5oAMCAQICAn7aMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNV BAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMTIkluZmlu ZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDIwHhcNMTQwNTA4MDYzMDI0WhcNMTkwNTA4MDYz MDI0WjCBgjELMAkGA1UEBhMCVVMxMjAwBgNVBAoTKUluZmluZW9uIFRlY2hub2xvZ2llcyBOb3J0 aCBBbWVyaWNhIENvcnAuMRYwFAYDVQQDEw1TdGVwaGVuIEhhbm5hMScwJQYJKoZIhvcNAQkBFhhT dGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCA FtObO7F+pUxS4qh2dVM0xI9zDZquunmkxtfb7TG3IXsd7NaqDYBXI67jA3WfxI/DHp3ub0ZuQ3qv JLzsdCr5FQgDDh7MBvesFRoYa6RHT/dUWE9SGjexFquQRHP75ZYxNBw3zOYpr87XFE1rsjXIQp7s 2ehfZLiIEr3NkyzjeAqBw6EfT65Dy598EWFon2Ky/QfJsDmBAfTc4+Ews2suhvS8x2pqSwHtOLNF PK2zD+zFsBdZJyv+ZawWaLO/B8aAwavVBDYBd3S5/4FJKEG8ednZpetkNQ2aMMg3Lnay8/t9UvcY jS810qTNVOEfiyZBzlJi53I4Nhw35UC6o1P5AgMBAAGjggFzMIIBbzA/BgNVHREEODA2gRhTdGV2 ZS5IYW5uYUBpbmZpbmVvbi5jb22BGlN0ZXBoZW4uSGFubmFAaW5maW5lb24uY29tMEAGA1UdIAQ5 MDcwNQYLKoIUAEQKFAEBAQEwJjAkBggrBgEFBQcCARYYaHR0cHM6Ly9jcHMuaW5maW5lb24uY29t MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3VzZXJjYTIvdXNlcmNh Mi5jcmwwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMEcGCCsGAQUFBwEBBDsw OTA3BggrBgEFBQcwAoYraHR0cDovL2NybC5pbmZpbmVvbi5jb20vdXNlcmNhMi91c2VyY2EyLmNy dDAfBgNVHSMEGDAWgBQaGJjYuBP92x7KDIqzEwNwd8MXljAdBgNVHQ4EFgQUhs576DHwRkp1mWLi fTZ7b4yVe+UwDQYJKoZIhvcNAQEFBQADggEBADKEDQXoKMcxN3zhhg3gfoVJII4Y8BWdjTzs5q2D bivs+8Ic8v/7KT3a61Gmz+BJx/8kWTe8LbJtk3GM0ui1MLUo8110r7qnvNtTtM8hYAuQGXYDGhkh H2PmZG7VSgB6G6DFNLA/017Uqvz6UiRLTUJcge7VJvk40cxJ1Mzs240+JVW9nLb/Fn+zI5KJj573 tXv7LTNVK2whVD7fJ3s07JGh75QYw5NusaHT9/4Zh/7idDdE/ailMY9pPvEtbVWcBnQxcXSoFEiM LKZFJ3o8nN7XFscSUqGRNNVYrAxpcktrnbz+assus7SbIYDpkOAOToBIWkdcxTXOWkv0Me9tVGcx ggODMIIDfwIBATBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMAkG BSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYwOTEzNTAzMlowIwYJKoZIhvcNAQkEMRYEFDYrYKEZhz2Ns1pvCuq22DIeMtl+MHIGCSsGAQQB gjcQBDFlMGMwXTELMAkGA1UEBhMCZGUxITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBB RzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVzIEFHIFVzZXIgQ0EgMgICftowdAYLKoZI hvcNAQkQAgsxZaBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMIGr BgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzAL BglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAEib1raCFNX6saSHwyTtdsWpqzyywn3n7x4esaNLEqmvg3zDAa+a rSWZt2c04RncV/vnejT/MYbNrGOswCXUeAlTVAzqF2KjORHCrVSR/b8SqSrf9BSy8TOMkPqwpVfw 5aBDafeLe2mmOFpCZFhMIoWo53OIoTKMylu+Ci5aCduDbn4LixXB0bM3RXicIfZo3aZNBG6KDBqy H+3GtH998yhSWRx+NYU7Yppa6vinsB0NjmLberosAtrR7p45cqa2Dbf30H0nQZCW8N/oEVxId5Ck tMNcnFqqsRUKVeHwJ8q+MVD5uoSau7PrfKXNAcLIIghYX4XVOCQ+aMHGus/Fg+YAAAAAAAA= ------=_NextPart_000_0A98_01D0A299.B98CE8E0--