From nobody Tue Nov 1 01:22:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0C2129411 for ; Tue, 1 Nov 2016 01:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.398 X-Spam-Level: X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 q-1o1j_51e09 for ; Tue, 1 Nov 2016 01:22:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 F27C01294BE for ; Tue, 1 Nov 2016 01:22:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1c1ULL-0008Px-95; Tue, 01 Nov 2016 08:22:51 +0000 Date: Tue, 01 Nov 2016 17:22:50 +0900 Message-ID: From: Randy Bush To: Ted Hardie In-Reply-To: References: <86bbe523-972b-772c-b002-dbdbbedc00c8@cs.tcd.ie> <8C32B083-A92C-4FB1-B7B0-7B4F1A3E8F52@gmail.com> <92f3868e-cdb8-f95c-efb4-71471f34c887@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] metadata insertion draft question X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 08:22:55 -0000 >> Randy's comment up thread was a substantive comment on the content, >> please take a look at that if you've not already. >> Okay, I will see about including example ameliorations wow! thanks. i think a "try something such as this instead" will greatly help folk get beyond a "don't do this." reasonable security practice is not always impossible. randy From nobody Thu Nov 3 12:21:17 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBA61293E4 for ; Thu, 3 Nov 2016 12:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.788 X-Spam-Level: X-Spam-Status: No, score=-5.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 obAkwVVeD70N for ; Thu, 3 Nov 2016 12:21:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D9E12956A for ; Thu, 3 Nov 2016 12:21:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0340ABE79 for ; Thu, 3 Nov 2016 19:21:11 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7XQDRlbcPis for ; Thu, 3 Nov 2016 19:21:09 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E6700BE5F for ; Thu, 3 Nov 2016 19:21:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478200869; bh=ISynxPK0G+pEAu2HdUNGQJocq9YGbUbhXRESuXFW0uU=; h=Subject:References:To:From:Date:In-Reply-To:From; b=bBvZ0S1WCMyM+iqQRJD/2VGC6eYSMgzjOAXBTTAMwy3yBNLM4ahCPY+VHUk1i14D3 GhKt+S7yxqPxOJzyyHa1Si8OkcsifxHFEIEaR9C4hjqaXi2nav1gmomKltfqiQRK1M GoUfkYzOsATCaRnt6pEirCLcGBq0/gqIKEjbPT3s= References: <95127E71-6D5B-44C2-B5C4-119FF966626A@netapp.com> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <95127E71-6D5B-44C2-B5C4-119FF966626A@netapp.com> Message-ID: <96f94fa9-b2ae-d6fa-1d60-b274a8029db1@cs.tcd.ie> Date: Thu, 3 Nov 2016 19:21:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <95127E71-6D5B-44C2-B5C4-119FF966626A@netapp.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060505070400070006000004" Archived-At: Subject: [saag] Call for Nominations: 2017 Applied Networking Research Prize (ANRP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:21:15 -0000 This is a cryptographically signed message in MIME format. --------------ms060505070400070006000004 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, If you've read any already-published academic papers you think would be good to see presented at an IETF in the next year, then please do nominate them for the ANRP prize - it pays for the winners to attend and present at an IETF. There's usually about 6 winners from 40-ish submissions to the chances are fairly good if you nominate a good paper. It takes about 5 minutes to nominate something. Self-nominations are fine. It's also fine if you don't ask the author(s) ahead of time - that'd happen later anyway. So please do nominate some good security work you've seen. If you don't, it'll be all routing, routing, routing again:-) And lastly - this is one to do now or never - there's only 3 days left for nominations for this round, so why not whack one in right now? Cheers, S. !!!!!!!!!!!!!!!!!!!!!!!!! !DEADLINE ON NOV 6, 2016! !!!!!!!!!!!!!!!!!!!!!!!!! CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2017 http://irtf.org/anrp ******************************************************************** *** Submit nominations for the 2017 award period of the *** *** Applied Networking Research Prize until November 6, 2016! *** *** *** *** (Please share this announcement with your colleagues.) *** ******************************************************************** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: =E2=80=A2 cash prize of $500 (USD) =E2=80=A2 invited talk at the IRTF Open Meeting =E2=80=A2 travel grant to attend a week-long IETF meeting (airfare, hotel= , registration, stipend) =E2=80=A2 recognition at the IETF plenary =E2=80=A2 invitation to related social activities =E2=80=A2 potential for additional travel grants to future IETF meetings,= based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self-nominations (nominating one=E2=80=99s own pape= r) and third-party nominations (nominating someone else=E2=80=99s paper) are= encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year=E2=80=99s IETF meetings in person and in its entirety. Nominations must include: =E2=80=A2 the name and email address of the nominee =E2=80=A2 a bibliographic reference to the published (or accepted) nominated paper =E2=80=A2 a PDF copy of the nominated paper =E2=80=A2 a statement that describes how the nominated paper fulfills the= goals of the award =E2=80=A2 a statement about which of the year=E2=80=99s IETF meetings the= nominee would be available to attend in person and in its entirety =E2=80=A2 a brief biography or CV of the nominee =E2=80=A2 optionally, any other supporting information (link to nominee=E2= =80=99s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2017/. In exceptional cases, nominations may also be submitted by email to anrp@irtf.org. IMPORTANT DATES Applications close: November 6, 2016 (hard) Notifications: December 8, 2016 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2017-flyer.pdf --------------ms060505070400070006000004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDMx OTIxMDlaMC8GCSqGSIb3DQEJBDEiBCDmhGjnLoy9l3RgbmtXqQZAFq1fUfKVkOl2KPHOB7NU fjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBsymiEWISrFYE6BoIjjhh4X+zWRNj84EUjgvObhFfx/9LvqQM7h2ql WexrGbg+ksS+WOxq/VK0da4MlvkLxliNzZNDMgteEaUt8YiSQHclbmEaETm7fCjGd7AGE1ZK 0FpRgzIlckDV2KqGHLsJ9bhAZcDGig0QdvykdzznC252cgnjtHMa4lpEeGxq55tb+R6HAgPC xTQT0/xR+4bIdC8WMOiHNUJiDcm6DEDHbpZK0Mf8cMZ1V+hAKmPFyNIK3BwwgUjwZKtW7oue V5WbVEG5iASY+EASFLvnrJ2RYXsh/wjcwtIGHtj5g3yJgFXWSAwmfe4mnDRHcqR7LfuC1VMA AAAAAAAA --------------ms060505070400070006000004-- From nobody Fri Nov 4 18:26:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCB5129459 for ; Fri, 4 Nov 2016 18:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.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 Yqf4hVAWCKEl for ; Fri, 4 Nov 2016 18:26:10 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6130128B37 for ; Fri, 4 Nov 2016 18:26:10 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 37E0B206E0; Fri, 4 Nov 2016 21:26:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 04 Nov 2016 21:26:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=J/0UtoSB9r8Tjv h7XOG3qZlc0ao=; b=BX+iHS60k9FrR4z57ikB7uWIwYCDixAZ/lqxTLlWFbEU17 cUuukTk0U/V+WcXe7ATiNJoBKG+NlhEvVu5lyyD/CrYoFjUvjN1vGG0p5/MRJzyG n7zVVNxOyNKyyL4JIVrRv+zscOGrHvUyiAAMYDgqR5T45DHY9uwgkacYiilhg= X-ME-Sender: X-Sasl-enc: 6qzK/o0ykYHC+OVivBHjALbv6rWOEdi3sfPhv56fdbTG 1478309168 Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 82ACCCC07B; Fri, 4 Nov 2016 21:26:08 -0400 (EDT) To: saag@ietf.org From: Keith Moore Message-ID: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> Date: Fri, 4 Nov 2016 21:25:59 -0400 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2016 01:26:12 -0000 Stephen Farrell suggested I bring this draft to your attention. This was a rush job as the authors just started talking about this last Friday, but it was written in response to recent DDoS attacks that utilized easily-compromised IoT devices. I'm sure there are missing pieces (I've identified a few since -00) and sections that could be stated better (like the title of section 2.3.2), but hopefully this is a useful start. https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ Keith From nobody Sun Nov 6 12:19:18 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670DA129444 for ; Sun, 6 Nov 2016 12:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 OlLWf5LhI6ig for ; Sun, 6 Nov 2016 12:19:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60733129459 for ; Sun, 6 Nov 2016 12:19:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B6B79BE39 for ; Sun, 6 Nov 2016 20:19:10 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3d05S0SyvdF for ; Sun, 6 Nov 2016 20:19:09 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F09CFBE38 for ; Sun, 6 Nov 2016 20:19:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478463549; bh=+HlZcK14HQMx073zqIzBNy8fAsY4wWNCBvDeEGdZrgM=; h=To:From:Subject:Date:From; b=YFl002TCaVVw60dQKKMp9MKZOMV8/cI9SnNRKA2QBIR5m2PaKLdJt6Olxv2D2xUv5 Q7gCf1CN/HbvrsO2hgIewDJasTlay/EQpKoFEDuZ3+rxLZpiju+KFU/NyBx5X4VpAf tJAVibUjMMx6sw2+FUG/QNf6aEv4CHv/PubVpTT4= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 6 Nov 2016 20:19:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000900060702010606070503" Archived-At: Subject: [saag] DRAFT saag agenda X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 20:19:16 -0000 This is a cryptographically signed message in MIME format. --------------ms000900060702010606070503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I've posted a draft agenda. [1] Still a few things that might change though. We do have a bit more presentation time so ask Kathleen and/or I if you have something to suggest. If I've mucked up or forgotten something, please just ping Kathleen and I offlist. Cheers, S. [1] https://www.ietf.org/proceedings/97/agenda/agenda-97-saag-00 --------------ms000900060702010606070503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDYy MDE5MDlaMC8GCSqGSIb3DQEJBDEiBCAfBNgb5bNupp5VK7FK8De6Idi3HjwiUTXUYAerPabj mDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAh+g6GA9VSVi5uCo+Gr2CgiDS2+oKkI24+SMP6GqLLTZ7p9dKPhOOy FaU9iMd6mud+qn+8JOs2Es5GNyh8fYWRmssUvTCN1AdjC6y72UqjJXaGH9NliKGiKnNz3c1L 19lH8apSQMUPlmyT6qJoW1txsfZETscjbVwlBSpLdsPVRDSfOwvjYIu8w7qET71yfJrWqSCR DkzUp8OuPKwimuyKLn3L/Ukc7/VMUqPg0G6mK/Bm7BkApxTcB1UMA5HAmzveFceRJhROM84/ 6oo59IOgQ7w+Fgz/N1axP+opPYMJc00fZYulxn0AHjN8K1rfezkMf5ilMZnHFramo6pTgwLF AAAAAAAA --------------ms000900060702010606070503-- From nobody Mon Nov 7 02:42:02 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B640A129B38 for ; Mon, 7 Nov 2016 02:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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=gsmasso.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 V-HOomZSYUYJ for ; Mon, 7 Nov 2016 02:41:57 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0041.outbound.protection.outlook.com [104.47.1.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C06129B3B for ; Mon, 7 Nov 2016 02:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QQRYdsqwwg5f7/wXW9jPH/wdIXd1po6H3WUAcjuqnbc=; b=o9KeXphaA6y+6FNIgQHIY4y6hbY/FlgbXxejyED9byfqOTCO0GnGeDkKML56gxh75YfAPZJIKJGrIbqbr8J/UNEjwVEFl4LbxQHEG+9qQ/7uxwpQnIloRjPdag0roB+B8DDmf16eZ10E2fHMgqh/J88TnpS59g5h20x4AL7sg/Q= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2061.eurprd04.prod.outlook.com (10.166.141.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 10:41:52 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 10:41:52 +0000 From: Natasha Rooney To: Keith Moore Thread-Topic: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) Thread-Index: AQHSNwOd418Z+/nxoUCvigY2dlEx6aDNWRAA Date: Mon, 7 Nov 2016 10:41:52 +0000 Message-ID: References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> In-Reply-To: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [51.6.68.18] x-ms-office365-filtering-correlation-id: 400aa862-6894-49c6-bf12-08d406faaf76 x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2061; 7:+BZobyZapUColuLkmd1O2o7vEWCh22vdvC/kcRYFjte0hPSOY/YChZi2vvlxKhh/zLTvWioK/ZCzL2IEHzin+g31gFs0jLdIKNQMwxUEAB/IPk3My5gNLNZF6iufT2xvofYlujXCNahB8zSMcMV0a5cmbNg0YsQFZI/mfxfvwyMVL2nmoqMf8EwukkeZw3ECZ3y/rAwdnKdHsPN2MOsoXIxMV35sOlSQS9flDtvlTOYs530/fdb2TNGzh1spAOsmiTI18QYjXk800xKxKArpMicxgGo5vSWJRpexUZIeuKfQ+kJmeIU/bQbk0iVJ9zf9rZRo2MJECT/QC8IEhFZ9hduGt6INT7zGdAIayWGCtUg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2061; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(192374486261705)(160794256991155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045074)(6060229)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061226)(6046074); SRVR:VI1PR0401MB2061; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2061; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(24454002)(199003)(50986999)(101416001)(83716003)(7846002)(81166006)(81156014)(8676002)(6916009)(122556002)(36756003)(76176999)(66066001)(92566002)(16236675004)(86362001)(33656002)(8936002)(10400500002)(5002640100001)(106356001)(106116001)(105586002)(110136003)(3280700002)(4326007)(11100500001)(2906002)(189998001)(230783001)(2900100001)(97736004)(50226002)(5660300001)(3660700001)(82746002)(19617315012)(5890100001)(57306001)(15975445007)(77096005)(586003)(2950100002)(6116002)(102836003)(3846002)(7906003)(87936001)(68736007)(19580405001)(7736002)(19580395003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2061; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_ED86D1E037C240C481E2381639CD0B8Dgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 10:41:52.0407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2061 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 51.6.68.18 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: VI1PR0401MB2061.eurprd04.prod.outlook.com Archived-At: Cc: saag Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 10:42:01 -0000 --_000_ED86D1E037C240C481E2381639CD0B8Dgsmacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Keith, The Connected Living team here at GSMA recently published the IOT Security = Guidelines (including a self-assessment scheme) for the same purpose as you= r draft but with a wider focus (mobile operator networks, service providers= and applications). The guidelines may provide some input to the draft. http://www.gsma.com/connectedliving/future-iot-networks/iot-security-guidel= ines/ Thanks! Natasha On 5 Nov 2016, at 01:25, Keith Moore > wrote: Stephen Farrell suggested I bring this draft to your attention. This was a = rush job as the authors just started talking about this last Friday, but it= was written in response to recent DDoS attacks that utilized easily-compro= mised IoT devices. I'm sure there are missing pieces (I've identified a f= ew since -00) and sections that could be stated better (like the title of s= ection 2.3.2), but hopefully this is a useful start. https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ Keith _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 356 0600 and highlight the error. --_000_ED86D1E037C240C481E2381639CD0B8Dgsmacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9404EB89B2B9154DA7955A93E429FEC6@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Keith,

The Connected Living team here at GSMA recently published t= he IOT Security Guidelines (including a self-assessment scheme) for the sam= e purpose as your draft but with a wider focus (mobile operator networks, s= ervice providers and applications). The guidelines may provide some input to the draft.

http://www.gsma.com/connectedl= iving/future-iot-networks/iot-security-guidelines/

Thanks!

Natasha


On 5 Nov 2016, at 01:25, Keith Moore <moore@network-heretics.com> w= rote:

Stephen Farrell suggested I bring this draft to your attent= ion. This was a rush job as the authors just started talking about this las= t Friday, but it was written in response to recent DDoS attacks that utiliz= ed easily-compromised IoT devices.   I'm sure there are missing pieces (I've identified a few since= -00) and sections that could be stated better (like the title of section 2= .3.2), but hopefully this is a useful start.

https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/

Keith


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

This email and its attachments are intended for the above named only and may be= confidential. If they have come to you in error you must take no action ba= sed on them, nor must you copy or show them to anyone; please reply to this= email or call +44 207 356 0600 and highlight the error.

--_000_ED86D1E037C240C481E2381639CD0B8Dgsmacom_-- From nobody Mon Nov 7 04:58:11 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508061294A0 for ; Mon, 7 Nov 2016 04:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, 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 8S6OH0b-x75q for ; Mon, 7 Nov 2016 04:58:09 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 362B812947C for ; Mon, 7 Nov 2016 04:58:06 -0800 (PST) Received: from [192.168.91.155] ([80.92.115.71]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MarAM-1cO0Am2vpS-00KM5E; Mon, 07 Nov 2016 13:57:58 +0100 To: Natasha Rooney , Keith Moore References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <9079214d-4a36-7883-122e-c36374cb9c72@gmx.net> Date: Mon, 7 Nov 2016 13:57:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ncKeqclJ3tqnt8bLvPvHMo8msxlFHICJU" X-Provags-ID: V03:K0:Y2BIuCezwTyRTc/fmhM2MZxEfxTA5HEmNdS7c/HXVPOW3RmWDa4 YCIKM1X2lN322AF77bawmO39WvODXM8O8hP+sCwm33U5eR2CdzEJZ0VOlJ7wBtQGRySxqfz WUQwXhRQz2trRZnUEb14CnW5bbAmy3MIxwU/glqPX7n5sURE62YW/XXC6/dBE9SbXx1LCCr p85htYRg6EwyBDs9FgvXg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3SHvjHz/45U=:E5t/fpNc0Sdti1DTEdjKs6 IKknM6juYQhPNcINzHLAXxOHbXROUtSXXArts2c7dmm5pbRoJGXYA3p5KHROxvjSTAJlxu8QD tMai50MvqZTldoXAV4xxkf2LGsJqBBOwjqm5vw2KufM4MxuQ3G8cjOtkI0norAH4nscmXIAAF WIKJHZfaF1zbefONQpfSimlgeeYVzx1F11B2NanEupHOqOc93eSfvtOI2Jih9gzJ63fDBe/Ly bxPKz1RRfoRHZOl9tJC2oT1+iL1Vi9Y/RLmN/4wLrvhXa5ALFjvWOgTchh8jo9UzojBDTspVX Flq5a62hLf2dZjXc/hka1qnLV77WUWSnRGTePcKI1Z2acSsxfAOSA6HQbv1R8ktltmh9uh4k1 m7OXS33nAQY085hMYoahEdOd6j09vtmb7Ic5WO91bRN68utmf14hdHOb/zOlPM6hk0Fj3IY9L a3Z+O/EN8v1U/JyVlHbNboh5rOSHo4Bvqo2kyl7F6R7a+GuDlY2gf45FtsyT/mql5pwtGDVth PEjP/ycnX9hj+jQBYXnLjrOV6D/iVvYqccTGfg9dVA/IfxaOLBIFY3QENKi2uFjLBRw6rLKk8 nC6orTVCEOrZzXG+/h+XhQEV3ZPlKkMXiljuuJ/A+uJ4N4ttu6FCSGTdJ6F6U9E5InnsddPlA hL+9T7Qoi/FwONc4BBupddQLz/oLc9fDfiG3ooy+ZOBGf+I94Xnu8ova9TM6PJCK6m/VyQmTU AhSeu5IlLO2csgLL2c0YsetE5dKdCBp/7OyVTKNgh67Kg5TbOAB0Dm/Q1tY= Archived-At: Cc: saag Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 12:58:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ncKeqclJ3tqnt8bLvPvHMo8msxlFHICJU Content-Type: multipart/mixed; boundary="okoqUCxkAvqpUvEiUpceGE4p7Fff50nDe"; protected-headers="v1" From: Hannes Tschofenig To: Natasha Rooney , Keith Moore Cc: saag Message-ID: <9079214d-4a36-7883-122e-c36374cb9c72@gmx.net> Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> In-Reply-To: --okoqUCxkAvqpUvEiUpceGE4p7Fff50nDe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Natasha, thanks for pointing us to this GSMA effort. Could you provide a little bit of feedback on who wrote these documents? Ciao Hannes On 11/07/2016 11:41 AM, Natasha Rooney wrote: > Hi Keith, >=20 > The Connected Living team here at GSMA recently published the IOT > Security Guidelines (including a self-assessment scheme) for the same > purpose as your draft but with a wider focus (mobile operator networks,= > service providers and applications). The guidelines may provide some > input to the draft. >=20 > http://www.gsma.com/connectedliving/future-iot-networks/iot-security-gu= idelines/ >=20 > Thanks! >=20 > Natasha >=20 >=20 >> On 5 Nov 2016, at 01:25, Keith Moore > > wrote: >> >> Stephen Farrell suggested I bring this draft to your attention. This >> was a rush job as the authors just started talking about this last >> Friday, but it was written in response to recent DDoS attacks that >> utilized easily-compromised IoT devices. I'm sure there are missing >> pieces (I've identified a few since -00) and sections that could be >> stated better (like the title of section 2.3.2), but hopefully this is= >> a useful start. >> >> https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ >> >> Keith >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 > This email and its attachments are intended for the above named only an= d > may be confidential. If they have come to you in error you must take no= > action based on them, nor must you copy or show them to anyone; please > reply to this email or call +44 207 356 0600 and highlight the error. >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --okoqUCxkAvqpUvEiUpceGE4p7Fff50nDe-- --ncKeqclJ3tqnt8bLvPvHMo8msxlFHICJU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYIHpVAAoJEGhJURNOOiAtPFMH/3/NYAfyT8dPj3x4HSkn/Wdw Eu+8FWXeslB9peVsXlc1JbEa5iNe/Tc2Omacdi2TfAP4x5w4frnKLDtUbm7jswec a7rob/BPqg/d8Bj/gJcviFMbWf8ykl7N1UDeSEUu24hc1+iCQhed7mF3JbGs3goe 47oG3GS6oKFobBrmCIKXi1c07UlgDaybx5ZaTXszoCKVRXxJEt38N6WZXVr794wy NACCYVjYzzV8QCUHZE5eiTQOjdTvdAAP3Muj46eB0XG/qQsdD54awQTPZv7pB+u2 cZl3iNJyGTU0F8V9d6JrSHtwwxXc82A8na9/wfA27nBZmh20UkPctdKMoYS0uK0= =Qo5T -----END PGP SIGNATURE----- --ncKeqclJ3tqnt8bLvPvHMo8msxlFHICJU-- From nobody Mon Nov 7 05:41:47 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81CF129619 for ; Mon, 7 Nov 2016 05:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=gsmasso.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 R7kTyi4aIKnG for ; Mon, 7 Nov 2016 05:41:43 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40055.outbound.protection.outlook.com [40.107.4.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BFD41295AF for ; Mon, 7 Nov 2016 05:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=GSMASSO.onmicrosoft.com; s=selector1-gsma-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Yq560ipY9UPnG9DgJ8qmNaLtIG6Od0ngxmiwY5Z0foo=; b=JVLRtx7Si/uCxlthwqx5ekr5QL+Zl09MgKfLpRcdN2eTchGUXIgSOgxwOeE4g20yBdrRhaLygGU/HBs29G7vRLLBE11fYeIPv+z/qzyQCM9DOTJ0x9ATiVx5l378IJWIUId7CqRC4tvfdfbNwBZbsj4BD0c67uTHfMbHBn5SQfs= Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com (10.166.141.138) by VI1PR0401MB2061.eurprd04.prod.outlook.com (10.166.141.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Mon, 7 Nov 2016 13:41:38 +0000 Received: from VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) by VI1PR0401MB2064.eurprd04.prod.outlook.com ([10.166.141.138]) with mapi id 15.01.0707.006; Mon, 7 Nov 2016 13:41:38 +0000 From: Natasha Rooney To: Hannes Tschofenig Thread-Topic: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) Thread-Index: AQHSNwOd418Z+/nxoUCvigY2dlEx6aDNWRAAgAAmBgCAAAw2AA== Date: Mon, 7 Nov 2016 13:41:38 +0000 Message-ID: References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <9079214d-4a36-7883-122e-c36374cb9c72@gmx.net> In-Reply-To: <9079214d-4a36-7883-122e-c36374cb9c72@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nrooney@gsma.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [51.6.68.18] x-ms-office365-filtering-correlation-id: 493153e6-392f-4038-9e0d-08d40713cccb x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2061; 7:e0wnYAAfUNsk3TcmJpE/AnoDovy/ts32EoB8I6IxciZfSFhNB1DpTRLYvbhmleLYPB/McPr1V/wZrhwqpa1qOOW2ZhkCzFB81iEfHcex79fWczbgRavMfR7be9X5IBQV6YyK8jdEgVZ6xUys7SXEWRSovJFz1Uafb4Y0eL9vFjuf5tkH79ZNbG6XhPFzeg6tVuv0CxTwaJyBVP89rup5jVg9bG0dYraOAiPU9u6ZTqkb7HmKPqG42BJpCaJ9BnEH/mdw+4E9D7QJaghxwhvqGAohnXfTJm7mCEklFyif7QCicQ+3e8225bL9djFBnyFaOkwS5xhdO4Ukbplqm7voHWLcsc3o9bImTssj0W2HPHI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2061; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(192374486261705)(248736688235697)(160794256991155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045074)(6060229)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061226)(6046074); SRVR:VI1PR0401MB2061; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0401MB2061; x-forefront-prvs: 0119DC3B5E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(377454003)(24454002)(199003)(7736002)(50986999)(101416001)(83716003)(7846002)(81166006)(81156014)(6916009)(122556002)(8676002)(36756003)(76176999)(66066001)(92566002)(16236675004)(86362001)(8936002)(10400500002)(5002640100001)(106356001)(106116001)(105586002)(110136003)(3280700002)(4326007)(11100500001)(2906002)(189998001)(2900100001)(230783001)(97736004)(33656002)(5660300001)(3660700001)(19617315012)(82746002)(5890100001)(57306001)(50226002)(15975445007)(77096005)(586003)(2950100002)(6116002)(102836003)(3846002)(7906003)(87936001)(68736007)(19580395003)(19580405001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2061; H:VI1PR0401MB2064.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: gsma.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A07E9CF1C23A410087033759665D02FEgsmacom_" MIME-Version: 1.0 X-OriginatorOrg: gsma.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2016 13:41:38.6340 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72a4ff82-fec3-469d-aafb-ac8276216699 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2061 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: VI1PR0401MB2064.eurprd04.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 51.6.68.18 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-disclaimer-hash: 78ca8040c6722e32c2f5b0a45bf37e74b9409d645a53be96aa19958e0cee0f00 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: VI1PR0401MB2061.eurprd04.prod.outlook.com Archived-At: Cc: Keith Moore , saag Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 13:41:46 -0000 --_000_A07E9CF1C23A410087033759665D02FEgsmacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IEhhbm5lcyENCg0KVGhlIENvbm5lY3RlZCBMaXZpbmcgdGVhbSBoZXJlIGF0IEdTTUEgd3Jv dGUgdGhlbS4gSWYgeW91IHdpc2ggdG8gc2VuZCBpbiBzdWdnZXN0aW9ucyBsZXQgbWUga25vdyBv ZmYtbGlzdCwgSeKAmWxsIGNvbm5lY3QgeW91IHdpdGggdGhlIHJpZ2h0IHBlcnNvbi4NCg0KTmF0 YXNoYQ0KDQpPbiA3IE5vdiAyMDE2LCBhdCAxMjo1NywgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5l cy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3 cm90ZToNCg0KSGkgTmF0YXNoYSwNCg0KdGhhbmtzIGZvciBwb2ludGluZyB1cyB0byB0aGlzIEdT TUEgZWZmb3J0Lg0KDQpDb3VsZCB5b3UgcHJvdmlkZSBhIGxpdHRsZSBiaXQgb2YgZmVlZGJhY2sg b24gd2hvIHdyb3RlIHRoZXNlIGRvY3VtZW50cz8NCg0KQ2lhbw0KSGFubmVzDQoNCg0KT24gMTEv MDcvMjAxNiAxMTo0MSBBTSwgTmF0YXNoYSBSb29uZXkgd3JvdGU6DQpIaSBLZWl0aCwNCg0KVGhl IENvbm5lY3RlZCBMaXZpbmcgdGVhbSBoZXJlIGF0IEdTTUEgcmVjZW50bHkgcHVibGlzaGVkIHRo ZSBJT1QNClNlY3VyaXR5IEd1aWRlbGluZXMgKGluY2x1ZGluZyBhIHNlbGYtYXNzZXNzbWVudCBz Y2hlbWUpIGZvciB0aGUgc2FtZQ0KcHVycG9zZSBhcyB5b3VyIGRyYWZ0IGJ1dCB3aXRoIGEgd2lk ZXIgZm9jdXMgKG1vYmlsZSBvcGVyYXRvciBuZXR3b3JrcywNCnNlcnZpY2UgcHJvdmlkZXJzIGFu ZCBhcHBsaWNhdGlvbnMpLiBUaGUgZ3VpZGVsaW5lcyBtYXkgcHJvdmlkZSBzb21lDQppbnB1dCB0 byB0aGUgZHJhZnQuDQoNCmh0dHA6Ly93d3cuZ3NtYS5jb20vY29ubmVjdGVkbGl2aW5nL2Z1dHVy ZS1pb3QtbmV0d29ya3MvaW90LXNlY3VyaXR5LWd1aWRlbGluZXMvDQoNClRoYW5rcyENCg0KTmF0 YXNoYQ0KDQoNCk9uIDUgTm92IDIwMTYsIGF0IDAxOjI1LCBLZWl0aCBNb29yZSA8bW9vcmVAbmV0 d29yay1oZXJldGljcy5jb20NCjxtYWlsdG86bW9vcmVAbmV0d29yay1oZXJldGljcy5jb20+PiB3 cm90ZToNCg0KU3RlcGhlbiBGYXJyZWxsIHN1Z2dlc3RlZCBJIGJyaW5nIHRoaXMgZHJhZnQgdG8g eW91ciBhdHRlbnRpb24uIFRoaXMNCndhcyBhIHJ1c2ggam9iIGFzIHRoZSBhdXRob3JzIGp1c3Qg c3RhcnRlZCB0YWxraW5nIGFib3V0IHRoaXMgbGFzdA0KRnJpZGF5LCBidXQgaXQgd2FzIHdyaXR0 ZW4gaW4gcmVzcG9uc2UgdG8gcmVjZW50IEREb1MgYXR0YWNrcyB0aGF0DQp1dGlsaXplZCBlYXNp bHktY29tcHJvbWlzZWQgSW9UIGRldmljZXMuICAgSSdtIHN1cmUgdGhlcmUgYXJlIG1pc3NpbmcN CnBpZWNlcyAoSSd2ZSBpZGVudGlmaWVkIGEgZmV3IHNpbmNlIC0wMCkgYW5kIHNlY3Rpb25zIHRo YXQgY291bGQgYmUNCnN0YXRlZCBiZXR0ZXIgKGxpa2UgdGhlIHRpdGxlIG9mIHNlY3Rpb24gMi4z LjIpLCBidXQgaG9wZWZ1bGx5IHRoaXMgaXMNCmEgdXNlZnVsIHN0YXJ0Lg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb29yZS1pb3Qtc2VjdXJpdHktYmNwLw0KDQpL ZWl0aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzYWFnIG1haWxpbmcgbGlzdA0Kc2FhZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zYWFnDQoNClRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBh cmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFuZA0KbWF5IGJlIGNvbmZpZGVu dGlhbC4gSWYgdGhleSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm8N CmFjdGlvbiBiYXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8g YW55b25lOyBwbGVhc2UNCnJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2FsbCArNDQgMjA3IDM1NiAw NjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhYWcgbWFpbGluZyBsaXN0DQpzYWFnQGlldGYu b3JnPG1haWx0bzpzYWFnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zYWFnDQoNCg0KVGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRl bmRlZCBmb3IgdGhlIGFib3ZlIG5hbWVkIG9ubHkgYW5kIG1heSBiZSBjb25maWRlbnRpYWwuIElm IHRoZXkgaGF2ZSBjb21lIHRvIHlvdSBpbiBlcnJvciB5b3UgbXVzdCB0YWtlIG5vIGFjdGlvbiBi YXNlZCBvbiB0aGVtLCBub3IgbXVzdCB5b3UgY29weSBvciBzaG93IHRoZW0gdG8gYW55b25lOyBw bGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxsICs0NCAyMDcgMzU2IDA2MDAgYW5kIGhp Z2hsaWdodCB0aGUgZXJyb3IuDQo= --_000_A07E9CF1C23A410087033759665D02FEgsmacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGV5IEhhbm5lcyENCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBDb25uZWN0ZWQg TGl2aW5nIHRlYW0gaGVyZSBhdCBHU01BIHdyb3RlIHRoZW0uIElmIHlvdSB3aXNoIHRvIHNlbmQg aW4gc3VnZ2VzdGlvbnMgbGV0IG1lIGtub3cgb2ZmLWxpc3QsIEnigJlsbCBjb25uZWN0IHlvdSB3 aXRoIHRoZSByaWdodCBwZXJzb24uPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyI+DQo8YnIgY2xhc3M9IiI+DQpOYXRhc2hhPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gNyBOb3YgMjAxNiwgYXQgMTI6NTcsIEhhbm5lcyBU c2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIg Y2xhc3M9IiI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+SGkNCiBOYXRhc2hhLDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnRoYW5r cw0KIGZvciBwb2ludGluZyB1cyB0byB0aGlzIEdTTUEgZWZmb3J0Ljwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPkNvdWxkDQogeW91IHByb3ZpZGUgYSBsaXR0bGUgYml0IG9mIGZlZWRiYWNrIG9u IHdobyB3cm90ZSB0aGVzZSBkb2N1bWVudHM/PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Q2lh bzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SGFu bmVzPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPk9uDQogMTEvMDcvMjAxNiAxMTo0MSBBTSwgTmF0YXNoYSBSb29uZXkgd3JvdGU6PC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CkhpIEtlaXRoLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBDb25uZWN0ZWQgTGl2 aW5nIHRlYW0gaGVyZSBhdCBHU01BIHJlY2VudGx5IHB1Ymxpc2hlZCB0aGUgSU9UPGJyIGNsYXNz PSIiPg0KU2VjdXJpdHkgR3VpZGVsaW5lcyAoaW5jbHVkaW5nIGEgc2VsZi1hc3Nlc3NtZW50IHNj aGVtZSkgZm9yIHRoZSBzYW1lPGJyIGNsYXNzPSIiPg0KcHVycG9zZSBhcyB5b3VyIGRyYWZ0IGJ1 dCB3aXRoIGEgd2lkZXIgZm9jdXMgKG1vYmlsZSBvcGVyYXRvciBuZXR3b3Jrcyw8YnIgY2xhc3M9 IiI+DQpzZXJ2aWNlIHByb3ZpZGVycyBhbmQgYXBwbGljYXRpb25zKS4gVGhlIGd1aWRlbGluZXMg bWF5IHByb3ZpZGUgc29tZTxiciBjbGFzcz0iIj4NCmlucHV0IHRvIHRoZSBkcmFmdC48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmdzbWEuY29tL2Nvbm5l Y3RlZGxpdmluZy9mdXR1cmUtaW90LW5ldHdvcmtzL2lvdC1zZWN1cml0eS1ndWlkZWxpbmVzLyIg Y2xhc3M9IiI+aHR0cDovL3d3dy5nc21hLmNvbS9jb25uZWN0ZWRsaXZpbmcvZnV0dXJlLWlvdC1u ZXR3b3Jrcy9pb3Qtc2VjdXJpdHktZ3VpZGVsaW5lcy88L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KVGhhbmtzITxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5hdGFzaGE8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj5PbiA1IE5vdiAyMDE2LCBhdCAwMToyNSwgS2VpdGggTW9vcmUgJmx0 O21vb3JlQG5ldHdvcmstaGVyZXRpY3MuY29tPGJyIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1h aWx0bzptb29yZUBuZXR3b3JrLWhlcmV0aWNzLmNvbSIgY2xhc3M9IiI+bWFpbHRvOm1vb3JlQG5l dHdvcmstaGVyZXRpY3MuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClN0ZXBoZW4gRmFycmVsbCBzdWdnZXN0ZWQgSSBicmluZyB0aGlzIGRyYWZ0IHRv IHlvdXIgYXR0ZW50aW9uLiBUaGlzPGJyIGNsYXNzPSIiPg0Kd2FzIGEgcnVzaCBqb2IgYXMgdGhl IGF1dGhvcnMganVzdCBzdGFydGVkIHRhbGtpbmcgYWJvdXQgdGhpcyBsYXN0PGJyIGNsYXNzPSIi Pg0KRnJpZGF5LCBidXQgaXQgd2FzIHdyaXR0ZW4gaW4gcmVzcG9uc2UgdG8gcmVjZW50IEREb1Mg YXR0YWNrcyB0aGF0PGJyIGNsYXNzPSIiPg0KdXRpbGl6ZWQgZWFzaWx5LWNvbXByb21pc2VkIElv VCBkZXZpY2VzLiAmbmJzcDsmbmJzcDtJJ20gc3VyZSB0aGVyZSBhcmUgbWlzc2luZzxiciBjbGFz cz0iIj4NCnBpZWNlcyAoSSd2ZSBpZGVudGlmaWVkIGEgZmV3IHNpbmNlIC0wMCkgYW5kIHNlY3Rp b25zIHRoYXQgY291bGQgYmU8YnIgY2xhc3M9IiI+DQpzdGF0ZWQgYmV0dGVyIChsaWtlIHRoZSB0 aXRsZSBvZiBzZWN0aW9uIDIuMy4yKSwgYnV0IGhvcGVmdWxseSB0aGlzIGlzPGJyIGNsYXNzPSIi Pg0KYSB1c2VmdWwgc3RhcnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbW9vcmUtaW90LXNlY3VyaXR5LWJjcC88YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpLZWl0aDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyIGNsYXNzPSIiPg0Kc2FhZyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQpz YWFnQGlldGYub3JnPGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zYWFnPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0K VGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGFyZSBpbnRlbmRlZCBmb3IgdGhlIGFib3Zl IG5hbWVkIG9ubHkgYW5kPGJyIGNsYXNzPSIiPg0KbWF5IGJlIGNvbmZpZGVudGlhbC4gSWYgdGhl eSBoYXZlIGNvbWUgdG8geW91IGluIGVycm9yIHlvdSBtdXN0IHRha2Ugbm88YnIgY2xhc3M9IiI+ DQphY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkgb3Igc2hvdyB0aGVtIHRv IGFueW9uZTsgcGxlYXNlPGJyIGNsYXNzPSIiPg0KcmVwbHkgdG8gdGhpcyBlbWFpbCBvciBjYWxs ICYjNDM7NDQgMjA3IDM1NiAwNjAwIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0Kc2Fh ZyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2FhZ0BpZXRmLm9y ZyIgY2xhc3M9IiI+c2FhZ0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWciIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZzwvYT48L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8cCBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjExcHg7Y29sb3I6Izk5 OTk5OTsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMt c2VyaWY7Y29sb3I6Izk5OTk5OTsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEFyaWFsOyBtc28t ZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1sYXRpbjsgbXNvLWJpZGktZm9udC1mYW1pbHk6ICZx dW90O0FyaWFsJnF1b3Q7OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBFTi1HQjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5UaGlzDQogZW1haWwgYW5k IGl0cyBhdHRhY2htZW50cyBhcmUgaW50ZW5kZWQgZm9yIHRoZSBhYm92ZSBuYW1lZCBvbmx5IGFu ZCBtYXkgYmUgY29uZmlkZW50aWFsLiBJZiB0aGV5IGhhdmUgY29tZSB0byB5b3UgaW4gZXJyb3Ig eW91IG11c3QgdGFrZSBubyBhY3Rpb24gYmFzZWQgb24gdGhlbSwgbm9yIG11c3QgeW91IGNvcHkg b3Igc2hvdyB0aGVtIHRvIGFueW9uZTsgcGxlYXNlIHJlcGx5IHRvIHRoaXMgZW1haWwgb3IgY2Fs bCAmIzQzOzQ0IDIwNyAzNTYgMDYwMA0KIGFuZCBoaWdobGlnaHQgdGhlIGVycm9yLiA8L3NwYW4+ PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A07E9CF1C23A410087033759665D02FEgsmacom_-- From nobody Mon Nov 7 07:05:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897CA129898 for ; Mon, 7 Nov 2016 07:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 YFVvsdnNEzZi for ; Mon, 7 Nov 2016 07:05:01 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 F1E421295CF for ; Mon, 7 Nov 2016 07:05:00 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id a197so188118155wmd.0 for ; Mon, 07 Nov 2016 07:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HNTR1zZ1M7huRYE4sf1TyZuFaAyekIWnLayrRga8D8M=; b=OYNhkSq/dE38WY/UkENCxC5rfUu70QmUxG+EgB8AER/8lihsdpzMFvbUdALEw6pS1N ikhWzC5Bi3Pr8P6mY8/1EvUbr4sW2tNQsAEHi7kri9oodx5HsQ6jCjDz/xkQdDpdZGE8 v923aquu4eagiQoDcGyGrEGVpYhcN6sTozDDFfdgE+9LLPMhZy5UXrfhL/8djDAkTduy BB1UNrq9MyREQtWR/DbngpJ68Gm4cDQxNjXFfCtdogR2+9QFBcugUmy+KkpsPwwDZQVw SmRkzmMokATL+nkLpZjpGMjWYkBQw18b534UOMfI79+vaaLez2+W34XsmLaVlOvXs1vp WvuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HNTR1zZ1M7huRYE4sf1TyZuFaAyekIWnLayrRga8D8M=; b=jk/RRHDrJPb3r5Lwdi+t992iD2LpxE5qshQ9yPivmwPqnlkIJwnfvITdmNGtW8y0/r MDprtJnIxxZXq4EGClu3F8krIwZG8DTA3Cmf34W5iscu3vcPW0BqP0usIk3FSEi/3Ahx AdHyDpGcc7wEE6dGf39CTyaZG0ZocJfS1+6mtM+1zqTtYIwgvQZxcXL5eIcCPEoBHfsY jkrmZ8xxC/HNhWLcY7o5Jz8vQcv9x/r6bxUpU5bg/0DFBTueCMAQGljDfl9ZUHHKH2N/ z27/2n4kK6W82HJ2rn3I1TW7BVFrKGm1hZ778scUsp0psrPomiaAcnrA0qSnnD5H8UxD KimA== X-Gm-Message-State: ABUngvcdZzwPh/e9++pvkUDI8YDvvrc2tKGPuv4PrKkXJaWeSEa4MzxkKgOw5R/d+Vy24UcgQOUKBzr0L+Mosg== X-Received: by 10.194.24.34 with SMTP id r2mr5733305wjf.111.1478531099439; Mon, 07 Nov 2016 07:04:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.70.193 with HTTP; Mon, 7 Nov 2016 07:04:38 -0800 (PST) In-Reply-To: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> From: Ira McDonald Date: Mon, 7 Nov 2016 10:04:38 -0500 Message-ID: To: Keith Moore , Ira McDonald Content-Type: multipart/alternative; boundary=047d7b5d3b56f8bffc0540b75853 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 15:05:03 -0000 --047d7b5d3b56f8bffc0540b75853 Content-Type: text/plain; charset=UTF-8 Hi Keith, FWIW - link to the recent Trusted Computing Group's "Guidance for Securing IoT using TCG Technology" http://www.trustedcomputinggroup.org/wp-content/uploads/TCG_Guidance_for_Securing_IoT_1_0r21.pdf The use cases are potentially of general interest. Disclaimer - I was a contributor to this document, but I don't endorse the narrow TCG-specific solutions focus. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Nov 4, 2016 at 9:25 PM, Keith Moore wrote: > Stephen Farrell suggested I bring this draft to your attention. This was a > rush job as the authors just started talking about this last Friday, but it > was written in response to recent DDoS attacks that utilized > easily-compromised IoT devices. I'm sure there are missing pieces (I've > identified a few since -00) and sections that could be stated better (like > the title of section 2.3.2), but hopefully this is a useful start. > > https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ > > Keith > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --047d7b5d3b56f8bffc0540b75853 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Keith,

FWIW - link to the recent= Trusted Computing Group's "Guidance for
The use cases are potentially of gen= eral interest.

Disclaimer - I was a contributor to this d= ocument, but I don't endorse
the narrow TCG-specific solu= tions focus.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Tru= sted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
= Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
ht= tp://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Jan= -April: 579 Park Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
M= ay-Dec: PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434

<= div style=3D"display:inline">

On Fri, Nov 4, 2016 at 9:25 PM, Keith Moore = <moore@network-heretics.com> wrote:
Stephen Farrell suggested I bring this draft to your at= tention. This was a rush job as the authors just started talking about this= last Friday, but it was written in response to recent DDoS attacks that ut= ilized easily-compromised IoT devices.=C2=A0 =C2=A0I'm sure there are m= issing pieces (I've identified a few since -00) and sections that could= be stated better (like the title of section 2.3.2), but hopefully this is = a useful start.

https://datatracker.ietf.org/doc/= draft-moore-iot-security-bcp/

Keith


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--047d7b5d3b56f8bffc0540b75853-- From nobody Mon Nov 7 09:31:36 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D1112959C for ; Mon, 7 Nov 2016 09:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 G06PC-zaR8KY for ; Mon, 7 Nov 2016 09:31:31 -0800 (PST) Received: from us-smtp-delivery-199.mimecast.com (us-smtp-delivery-199.mimecast.com [63.128.21.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88891129580 for ; Mon, 7 Nov 2016 09:31:31 -0800 (PST) Received: from mx02.five9.com (mx02.five9.com [198.105.204.3]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-8-LcidP3MlO0-8MyuGKrcRlw-1; Mon, 07 Nov 2016 12:31:27 -0500 Received: from MB03.five9.com (10.7.8.143) by mx02.five9.com (10.7.15.112) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 7 Nov 2016 09:31:16 -0800 Received: from MB02.five9.com ([fe80::ede6:8312:5207:4046]) by mb03.five9.com ([fe80::4d18:3a9c:2936:eea8%16]) with mapi id 14.03.0248.002; Mon, 7 Nov 2016 09:31:25 -0800 From: Ronald del Rosario To: Keith Moore , Ira McDonald Thread-Topic: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) Thread-Index: AQHSNwOeTbxCVXita0CcyfirQL3uYqDOKJkA//+i5QA= Date: Mon, 7 Nov 2016 17:31:25 +0000 Message-ID: References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-originating-ip: [10.7.8.130] MIME-Version: 1.0 X-MC-Unique: LcidP3MlO0-8MyuGKrcRlw-1 Content-Type: multipart/alternative; boundary="_000_B63793B6174A4117A33E14B1133EFE3Efive9com_" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 17:31:34 -0000 --_000_B63793B6174A4117A33E14B1133EFE3Efive9com_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgS2VpdGgsDQoNClRoZSBDbG91ZCBTZWN1cml0eSBBbGxpYW5jZSAoQ1NBKSDigJMgSW9UIFdv cmtpbmcgR3JvdXAgYWxzbyBwdWJsaXNoZWQgYSBzaW1pbGFyIGRvY3VtZW50IE9jdG9iZXIgMjAx NiB0aXRsZWQg4oCcRnV0dXJlIFByb29maW5nIHRoZSBDb25uZWN0ZWQgV29ybGQ6IDEzIFN0ZXBz IHRvIERldmVsb3BpbmcgU2VjdXJlIElvVCBQcm9kdWN0c+KAnQ0KDQpodHRwczovL2Nsb3Vkc2Vj dXJpdHlhbGxpYW5jZS5vcmcvZG93bmxvYWQvZnV0dXJlLXByb29maW5nLXRoZS1jb25uZWN0ZWQt d29ybGQvDQoNCkRpc2NsYWltZXI6IEkgYW0gYSBtZW1iZXIgb2YgdGhlIENTQSBJb1QgV29ya2lu ZyBHcm91cCBidXQgbm90IGEgY29udHJpYnV0b3Igb24gdGhpcyBkb2N1bWVudC4NCg0KVGhhbmtz LA0KUm9uDQoNCkZyb206IHNhYWcgPHNhYWctYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IElyYSBNY0RvbmFsZCA8Ymx1ZXJvb2ZtdXNpY0BnbWFpbC5jb20+DQpEYXRlOiBNb25kYXksIE5v dmVtYmVyIDcsIDIwMTYgYXQgNzowNCBBTQ0KVG86IEtlaXRoIE1vb3JlIDxtb29yZUBuZXR3b3Jr LWhlcmV0aWNzLmNvbT4sIElyYSBNY0RvbmFsZCA8Ymx1ZXJvb2ZtdXNpY0BnbWFpbC5jb20+DQpD YzogInNhYWdAaWV0Zi5vcmciIDxzYWFnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzYWFnXSBk cmFmdC1tb29yZS1pb3QtYmNwLTAwIChCZXN0IEN1cnJlbnQgUHJhY3RpY2VzIGZvciBTZWN1cmlu ZyBJbnRlcm5ldCBvZiBUaGluZ3MgKElvVCkgRGV2aWNlcykNCg0KSGkgS2VpdGgsDQpGV0lXIC0g bGluayB0byB0aGUgcmVjZW50IFRydXN0ZWQgQ29tcHV0aW5nIEdyb3VwJ3MgIkd1aWRhbmNlIGZv cg0KU2VjdXJpbmcgSW9UIHVzaW5nIFRDRyBUZWNobm9sb2d5Ig0KDQpodHRwOi8vd3d3LnRydXN0 ZWRjb21wdXRpbmdncm91cC5vcmcvd3AtY29udGVudC91cGxvYWRzL1RDR19HdWlkYW5jZV9mb3Jf U2VjdXJpbmdfSW9UXzFfMHIyMS5wZGYNClRoZSB1c2UgY2FzZXMgYXJlIHBvdGVudGlhbGx5IG9m IGdlbmVyYWwgaW50ZXJlc3QuDQpEaXNjbGFpbWVyIC0gSSB3YXMgYSBjb250cmlidXRvciB0byB0 aGlzIGRvY3VtZW50LCBidXQgSSBkb24ndCBlbmRvcnNlDQp0aGUgbmFycm93IFRDRy1zcGVjaWZp YyBzb2x1dGlvbnMgZm9jdXMuDQpDaGVlcnMsDQotIElyYQ0KDQpJcmEgTWNEb25hbGQgKE11c2lj aWFuIC8gU29mdHdhcmUgQXJjaGl0ZWN0KQ0KQ28tQ2hhaXIgLSBUQ0cgVHJ1c3RlZCBNb2JpbGl0 eSBTb2x1dGlvbnMgV0cNCkNoYWlyIC0gTGludXggRm91bmRhdGlvbiBPcGVuIFByaW50aW5nIFdH DQpTZWNyZXRhcnkgLSBJRUVFLUlTVE8gUHJpbnRlciBXb3JraW5nIEdyb3VwDQpDby1DaGFpciAt IElFRUUtSVNUTyBQV0cgSW50ZXJuZXQgUHJpbnRpbmcgUHJvdG9jb2wgV0cNCklFVEYgRGVzaWdu YXRlZCBFeHBlcnQgLSBJUFAgJiBQcmludGVyIE1JQg0KQmx1ZSBSb29mIE11c2ljIC8gSGlnaCBO b3J0aCBJbmMNCmh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvYmx1ZXJvb2ZtdXNpYw0KaHR0 cDovL3NpdGVzLmdvb2dsZS5jb20vc2l0ZS9oaWdobm9ydGhpbmMNCm1haWx0bzogYmx1ZXJvb2Zt dXNpY0BnbWFpbC5jb208bWFpbHRvOmJsdWVyb29mbXVzaWNAZ21haWwuY29tPg0KSmFuLUFwcmls OiA1NzkgUGFyayBQbGFjZSAgU2FsaW5lLCBNSSAgNDgxNzYgIDczNC05NDQtMDA5NA0KTWF5LURl YzogUE8gQm94IDIyMSAgR3JhbmQgTWFyYWlzLCBNSSA0OTgzOSAgOTA2LTQ5NC0yNDM0DQoNCk9u IEZyaSwgTm92IDQsIDIwMTYgYXQgOToyNSBQTSwgS2VpdGggTW9vcmUgPG1vb3JlQG5ldHdvcmst aGVyZXRpY3MuY29tPG1haWx0bzptb29yZUBuZXR3b3JrLWhlcmV0aWNzLmNvbT4+IHdyb3RlOg0K U3RlcGhlbiBGYXJyZWxsIHN1Z2dlc3RlZCBJIGJyaW5nIHRoaXMgZHJhZnQgdG8geW91ciBhdHRl bnRpb24uIFRoaXMgd2FzIGEgcnVzaCBqb2IgYXMgdGhlIGF1dGhvcnMganVzdCBzdGFydGVkIHRh bGtpbmcgYWJvdXQgdGhpcyBsYXN0IEZyaWRheSwgYnV0IGl0IHdhcyB3cml0dGVuIGluIHJlc3Bv bnNlIHRvIHJlY2VudCBERG9TIGF0dGFja3MgdGhhdCB1dGlsaXplZCBlYXNpbHktY29tcHJvbWlz ZWQgSW9UIGRldmljZXMuICAgSSdtIHN1cmUgdGhlcmUgYXJlIG1pc3NpbmcgcGllY2VzIChJJ3Zl IGlkZW50aWZpZWQgYSBmZXcgc2luY2UgLTAwKSBhbmQgc2VjdGlvbnMgdGhhdCBjb3VsZCBiZSBz dGF0ZWQgYmV0dGVyIChsaWtlIHRoZSB0aXRsZSBvZiBzZWN0aW9uIDIuMy4yKSwgYnV0IGhvcGVm dWxseSB0aGlzIGlzIGEgdXNlZnVsIHN0YXJ0Lg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1tb29yZS1pb3Qtc2VjdXJpdHktYmNwLw0KDQpLZWl0aA0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzYWFnIG1haWxpbmcg bGlzdA0Kc2FhZ0BpZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZS1tYWlsIGFuZCBhbnkg ZmlsZXMgYXR0YWNoZWQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG9mIEZp dmU5IGFuZC9vciBpdHMgYWZmaWxpYXRlZCBlbnRpdGllcy4gQWNjZXNzIGJ5IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgb25seSBpcyBhdXRob3JpemVkLiBBbnkgbGlhYmlsaXR5IGFyaXNpbmcgZnJv bSBhbnkgcGFydHkgYWN0aW5nLCBvciByZWZyYWluaW5nIGZyb20gYWN0aW5nLCBvbiBhbnkgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIGlzIGhlcmVieSBleGNsdWRlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5LCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5kIGl0 cyBhdHRhY2htZW50cyBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBp bmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBDb3B5cmlnaHQgaW4gdGhpcyBlLW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBiZWxvbmdzIHRvIEZpdmU5IGFuZC9vciBpdHMgYWZmaWxpYXRlZCBlbnRp dGllcy4NCg0KRGlzY2xhaW1lcg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg Y29tbXVuaWNhdGlvbiBmcm9tIHRoZSBzZW5kZXIgaXMgY29uZmlkZW50aWFsLiBJdCBpcyBpbnRl bmRlZCBzb2xlbHkgZm9yIHVzZSBieSB0aGUgcmVjaXBpZW50IGFuZCBvdGhlcnMgYXV0aG9yaXpl ZCB0byByZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCB0aGUgcmVjaXBpZW50LCB5b3UgYXJlIGhl cmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24g b3IgdGFraW5nIGFjdGlvbiBpbiByZWxhdGlvbiBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZv cm1hdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQoNClRo aXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgbWFsd2FyZSwgYW5kIG1h eSBoYXZlIGJlZW4gYXV0b21hdGljYWxseSBhcmNoaXZlZCBieSBNaW1lY2FzdCBMdGQsIGFuIGlu bm92YXRvciBpbiBTb2Z0d2FyZSBhcyBhIFNlcnZpY2UgKFNhYVMpIGZvciBidXNpbmVzcy4gUHJv dmlkaW5nIGEgc2FmZXIgYW5kIG1vcmUgdXNlZnVsIHBsYWNlIGZvciB5b3VyIGh1bWFuIGdlbmVy YXRlZCBkYXRhLiBTcGVjaWFsaXppbmcgaW47IFNlY3VyaXR5LCBhcmNoaXZpbmcgYW5kIGNvbXBs aWFuY2UuIFRvIGZpbmQgb3V0IG1vcmUgdmlzaXQgdGhlIE1pbWVjYXN0IHdlYnNpdGUuDQo= --_000_B63793B6174A4117A33E14B1133EFE3Efive9com_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4N CjxtZXRhIG5hbWU9IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9y IiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+ PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi Q2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9y OnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2Nz cyI+LnN0eWxlMSB7Zm9udC1mYW1pbHk6ICJUaW1lcyBOZXcgUm9tYW4iO308L3N0eWxlPjwvaGVh ZD48Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIEtl aXRoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoZSBDbG91ZCBTZWN1cml0eSBBbGxpYW5j ZSAoQ1NBKSDigJMgSW9UIFdvcmtpbmcgR3JvdXAgYWxzbyBwdWJsaXNoZWQgYSBzaW1pbGFyIGRv Y3VtZW50IE9jdG9iZXIgMjAxNiB0aXRsZWQg4oCcRnV0dXJlIFByb29maW5nIHRoZSBDb25uZWN0 ZWQgV29ybGQ6IDEzIFN0ZXBzIHRvIERldmVsb3BpbmcgU2VjdXJlIElvVCBQcm9kdWN0c+KAnTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxhIGhyZWY9Imh0dHBzOi8vY2xvdWRzZWN1cml0eWFs bGlhbmNlLm9yZy9kb3dubG9hZC9mdXR1cmUtcHJvb2ZpbmctdGhlLWNvbm5lY3RlZC13b3JsZC8i Pmh0dHBzOi8vY2xvdWRzZWN1cml0eWFsbGlhbmNlLm9yZy9kb3dubG9hZC9mdXR1cmUtcHJvb2Zp bmctdGhlLWNvbm5lY3RlZC13b3JsZC88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RGlz Y2xhaW1lcjogSSBhbSBhIG1lbWJlciBvZiB0aGUgQ1NBIElvVCBXb3JraW5nIEdyb3VwIGJ1dCBu b3QgYSBjb250cmlidXRvciBvbiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Sb248bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5z YWFnICZsdDtzYWFnLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBJcmEgTWNEb25h bGQgJmx0O2JsdWVyb29mbXVzaWNAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25k YXksIE5vdmVtYmVyIDcsIDIwMTYgYXQgNzowNCBBTTxicj4NCjxiPlRvOiA8L2I+S2VpdGggTW9v cmUgJmx0O21vb3JlQG5ldHdvcmstaGVyZXRpY3MuY29tJmd0OywgSXJhIE1jRG9uYWxkICZsdDti bHVlcm9vZm11c2ljQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NhYWdAaWV0 Zi5vcmcmcXVvdDsgJmx0O3NhYWdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbc2FhZ10gZHJhZnQtbW9vcmUtaW90LWJjcC0wMCAoQmVzdCBDdXJyZW50IFByYWN0aWNlcyBm b3IgU2VjdXJpbmcgSW50ZXJuZXQgb2YgVGhpbmdzIChJb1QpIERldmljZXMpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgS2VpdGgsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZXSVcgLSBsaW5rIHRvIHRoZSByZWNl bnQgVHJ1c3RlZCBDb21wdXRpbmcgR3JvdXAncyAmcXVvdDtHdWlkYW5jZSBmb3I8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+U2VjdXJpbmcgSW9UIHVzaW5nIFRDRyBUZWNobm9sb2d5JnF1b3Q7PGJy Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy50cnVzdGVkY29tcHV0aW5nZ3JvdXAub3JnL3dwLWNvbnRl bnQvdXBsb2Fkcy9UQ0dfR3VpZGFuY2VfZm9yX1NlY3VyaW5nX0lvVF8xXzByMjEucGRmIj48YnI+ DQpodHRwOi8vd3d3LnRydXN0ZWRjb21wdXRpbmdncm91cC5vcmcvd3AtY29udGVudC91cGxvYWRz L1RDR19HdWlkYW5jZV9mb3JfU2VjdXJpbmdfSW9UXzFfMHIyMS5wZGY8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPlRoZSB1c2UgY2FzZXMgYXJlIHBvdGVudGlhbGx5IG9mIGdlbmVyYWwgaW50 ZXJlc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EaXNjbGFpbWVyIC0gSSB3YXMgYSBjb250cmlidXRvciB0byB0aGlzIGRvY3VtZW50LCBidXQg SSBkb24ndCBlbmRvcnNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPnRoZSBuYXJyb3cgVENHLXNw ZWNpZmljIHNvbHV0aW9ucyBmb2N1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+LSBJcmE8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+SXJhIE1jRG9uYWxkIChNdXNpY2lhbiAvIFNvZnR3YXJlIEFyY2hpdGVjdCk8YnI+ DQpDby1DaGFpciAtIFRDRyBUcnVzdGVkIE1vYmlsaXR5IFNvbHV0aW9ucyBXRzxicj4NCkNoYWly IC0gTGludXggRm91bmRhdGlvbiBPcGVuIFByaW50aW5nIFdHPGJyPg0KU2VjcmV0YXJ5IC0gSUVF RS1JU1RPIFByaW50ZXIgV29ya2luZyBHcm91cDxicj4NCkNvLUNoYWlyIC0gSUVFRS1JU1RPIFBX RyBJbnRlcm5ldCBQcmludGluZyBQcm90b2NvbCBXRzxicj4NCklFVEYgRGVzaWduYXRlZCBFeHBl cnQgLSBJUFAgJmFtcDsgUHJpbnRlciBNSUI8YnI+DQpCbHVlIFJvb2YgTXVzaWMgLyBIaWdoIE5v cnRoIEluYzxicj4NCjxhIGhyZWY9Imh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvYmx1ZXJv b2ZtdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzMzM0ZGIj5odHRw Oi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRlL2JsdWVyb29mbXVzaWM8L3NwYW4+PC9hPjxicj4NCjxh IGhyZWY9Imh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaGlnaG5vcnRoaW5jIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjAwQ0MiPmh0dHA6Ly9zaXRlcy5nb29nbGUu Y29tL3NpdGUvaGlnaG5vcnRoaW5jPC9zcGFuPjwvYT48YnI+DQptYWlsdG86IDxhIGhyZWY9Im1h aWx0bzpibHVlcm9vZm11c2ljQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJsdWVyb29mbXVz aWNAZ21haWwuY29tPC9hPjxicj4NCkphbi1BcHJpbDogNTc5IFBhcmsgUGxhY2UmbmJzcDsgU2Fs aW5lLCBNSSZuYnNwOyA0ODE3NiZuYnNwOyA3MzQtOTQ0LTAwOTQ8YnI+DQpNYXktRGVjOiBQTyBC b3ggMjIxJm5ic3A7IEdyYW5kIE1hcmFpcywgTUkgNDk4MzkmbmJzcDsgOTA2LTQ5NC0yNDM0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gRnJpLCBOb3YgNCwgMjAxNiBhdCA5OjI1IFBNLCBLZWl0aCBNb29yZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1vb3JlQG5ldHdvcmstaGVyZXRpY3MuY29tIiB0YXJnZXQ9Il9i bGFuayI+bW9vcmVAbmV0d29yay1oZXJldGljcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdGVwaGVuIEZhcnJlbGwg c3VnZ2VzdGVkIEkgYnJpbmcgdGhpcyBkcmFmdCB0byB5b3VyIGF0dGVudGlvbi4gVGhpcyB3YXMg YSBydXNoIGpvYiBhcyB0aGUgYXV0aG9ycyBqdXN0IHN0YXJ0ZWQgdGFsa2luZyBhYm91dCB0aGlz IGxhc3QgRnJpZGF5LCBidXQgaXQgd2FzIHdyaXR0ZW4gaW4gcmVzcG9uc2UgdG8gcmVjZW50IERE b1MgYXR0YWNrcyB0aGF0IHV0aWxpemVkIGVhc2lseS1jb21wcm9taXNlZCBJb1QgZGV2aWNlcy4m bmJzcDsNCiAmbmJzcDtJJ20gc3VyZSB0aGVyZSBhcmUgbWlzc2luZyBwaWVjZXMgKEkndmUgaWRl bnRpZmllZCBhIGZldyBzaW5jZSAtMDApIGFuZCBzZWN0aW9ucyB0aGF0IGNvdWxkIGJlIHN0YXRl ZCBiZXR0ZXIgKGxpa2UgdGhlIHRpdGxlIG9mIHNlY3Rpb24gMi4zLjIpLCBidXQgaG9wZWZ1bGx5 IHRoaXMgaXMgYSB1c2VmdWwgc3RhcnQuPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbW9vcmUtaW90LXNlY3VyaXR5LWJjcC8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb29yZS1p b3Qtc2VjdXJpdHktYmNwLzwvYT48YnI+DQo8YnI+DQpLZWl0aDxicj4NCjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2FhZyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2FhZ0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnNhYWdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zYWFnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9Ikdy YXkiIHNpemU9IjEiPjxicj4NCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZS1tYWlsIGFu ZCBhbnkgZmlsZXMgYXR0YWNoZWQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9u IG9mIEZpdmU5IGFuZC9vciBpdHMgYWZmaWxpYXRlZCBlbnRpdGllcy4gQWNjZXNzIGJ5IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb25seSBpcyBhdXRob3JpemVkLiBBbnkgbGlhYmlsaXR5IGFyaXNp bmcgZnJvbSBhbnkgcGFydHkgYWN0aW5nLCBvciByZWZyYWluaW5nIGZyb20gYWN0aW5nLA0KIG9u IGFueSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgaXMgaGVyZWJ5IGV4Y2x1 ZGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlc3Ryb3kgdGhlIG9yaWdpbmFsIHRyYW5zbWlzc2lv biBhbmQgaXRzIGF0dGFjaG1lbnRzIGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24sIHVzZSBpdA0KIGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gQ29weXJpZ2h0IGluIHRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYmVsb25ncyB0byBGaXZlOSBhbmQvb3IgaXRzIGFmZmls aWF0ZWQgZW50aXRpZXMuPGJyPg0KPC9mb250Pg0KPGRpdj48L2Rpdj4NCjxkaXY+PC9kaXY+DQoN CjxiciAvPjxiciAvPjxwIHN0eWxlPSJmb250LWZhbWlseTogVmVyZGFuYTsgZm9udC1zaXplOjEw cHQ7IGNvbG9yOiM2NjY2NjY7Ij48Yj5EaXNjbGFpbWVyPC9iPjwvcD48cCBzdHlsZT0iZm9udC1m YW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTo4cHQ7IGNvbG9yOiM2NjY2NjY7Ij5UaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgY29tbXVuaWNhdGlvbiBmcm9tIHRoZSBzZW5kZXIgaXMg Y29uZmlkZW50aWFsLiBJdCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHVzZSBieSB0aGUgcmVjaXBp ZW50IGFuZCBvdGhlcnMgYXV0aG9yaXplZCB0byByZWNlaXZlIGl0LiBJZiB5b3UgYXJlIG5vdCB0 aGUgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJl LCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdGFraW5nIGFjdGlvbiBpbiByZWxhdGlvbiBvZiB0 aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuPGJyIC8+PGJyIC8+VGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBtYWx3YXJlLCBhbmQgbWF5IGhhdmUgYmVlbiBhdXRvbWF0aWNhbGx5 IGFyY2hpdmVkIGJ5IDxiPk1pbWVjYXN0IEx0ZDwvYj4sIGFuIGlubm92YXRvciBpbiBTb2Z0d2Fy ZSBhcyBhIFNlcnZpY2UgKFNhYVMpIGZvciBidXNpbmVzcy4gIFByb3ZpZGluZyBhIDxiPnNhZmVy PC9iPiBhbmQgPGI+bW9yZSB1c2VmdWw8L2I+IHBsYWNlIGZvciB5b3VyIGh1bWFuIGdlbmVyYXRl ZCBkYXRhLiAgU3BlY2lhbGl6aW5nIGluOyBTZWN1cml0eSwgYXJjaGl2aW5nIGFuZCBjb21wbGlh bmNlLiBUbyBmaW5kIG91dCBtb3JlIDxhIGhyZWY9Imh0dHA6Ly93d3cubWltZWNhc3QuY29tL3By b2R1Y3RzLyIgdGFyZ2V0PSJfYmxhbmsiPkNsaWNrIEhlcmU8L2E+LjwvcD48L2JvZHk+PC9odG1s Pg0K --_000_B63793B6174A4117A33E14B1133EFE3Efive9com_-- From nobody Mon Nov 7 12:43:30 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6AB1294C5 for ; Mon, 7 Nov 2016 12:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, 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 yjvCFV5mm5YD for ; Mon, 7 Nov 2016 12:43:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73DA12948A for ; Mon, 7 Nov 2016 12:43:25 -0800 (PST) Received: from [192.168.91.155] ([80.92.115.71]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LlVZv-1cepPJ3iat-00bIa5 for ; Mon, 07 Nov 2016 21:43:23 +0100 To: saag From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <8b58793d-fdd0-42e6-ded5-be0ccbbecc44@gmx.net> Date: Mon, 7 Nov 2016 21:43:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xQBT7kgtGptKvbXW2cNRNGSWT9afviEVU" X-Provags-ID: V03:K0:0Qu4RRZCettPZpYZwLSNmrhz7A0ge8F+97fah/HDAc9pJ6t0s3m HkVm6oqhRxT2+tC5Urd9mMWJln6i9vjVbrj5kB6V5LPPxywdM9hwfWyfEdQS9JW5/9mwy2i C7+yLMVXnTxgd8vSTTbND3epz14xb3dNsPaceGpFklJeOpEYCWbl93jMPYK6eXwKTjdooOH f1Beiyy2sHJiJVXl7RRWA== X-UI-Out-Filterresults: notjunk:1;V01:K0:tVU3PzpcNrw=:iTTrthNoBVzWhq7+SFkhXd NPJERSagKWlAT6I4vhw0U7O8cDLjzl7gm+dClHrswrHmPlbwpcLZwd5B5Ld9Sfcqv6sY9zNZL uarAUvj+naM4mSrezUQtqn2GqN4mJTj5wuG2tdkVwwGKCZ3pQRObmQqwTVOo9pU7uzOpNVeNg CbUfS/GjnoTvUqgLI31n8IpuoMeedAfZbIXdrpLIJfb8ASkBXPFT1m/OM+Ry2Hv2UxoHk43dk zd6oNw2d7hPkUMRlwNh/Hsahn3otAuyMcDmh+I/w6WPohGEsT3tvzU2wlOSXx/x3+pr27Fxr3 3HIqqa/0XoXXdokJr92eaBHgMLYUVRYFLUMek7iU1kIO/n9sspCX5qA3Z0O6vWYPnJCp2KNQ+ PCkvYfkj65GMFuJtTxwB3EOCd2/tKKaHn0pJu7CiWaFR0qBidwW2cnZQ15pst2xux6LBrP5ic SKP+C+5uJk22MeuSGGAMMQADUYAf2hAoiRmvdHRpw4hUFKobNmBNPZx+81Jm9rBODGQF5GOUE m42joBPSGJmTJ9SWyz1Be/PTpGvZUAOByu2zC7oc90PzcGThu60MfbTp8u2CnOH5aktHefDSY +duPh4a/iyCt0u+11ME50MTViM8EL/4je0YceLPROIbnLTVAMnk/DSBkPvSy/03So3CPIUGDJ S6WQ/h61nZ/oBFJpj4fcKIPspbEwab1wB1g2s3FPXuwDz0FglpoJ5tr8taLGhK8DgB72d8eE9 +Q/1QqgBhh5YNxpYG2+O2QxlyIWWWtgIvlZuKGhhp8AuqtL4F+5HvN2AcbE= Archived-At: Subject: [saag] draft-moore-iot-bcp-00 -- Best Current Practices for Securing IoT Devices X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 20:43:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xQBT7kgtGptKvbXW2cNRNGSWT9afviEVU Content-Type: multipart/mixed; boundary="2PIWfdQScSi9NrGBPvHR0Amo06xHEgL2U"; protected-headers="v1" From: Hannes Tschofenig To: saag Message-ID: <8b58793d-fdd0-42e6-ded5-be0ccbbecc44@gmx.net> Subject: draft-moore-iot-bcp-00 -- Best Current Practices for Securing IoT Devices --2PIWfdQScSi9NrGBPvHR0Amo06xHEgL2U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would like to provide a little bit of background why Keith & Richard have put this document together so short notice. Keith and I had a discussion about what could be done regarding these DDoS attacks conducted with the help of IoT devices. I was skeptical about the value of writing a document that offers guidelines since one of the core problem with many IoT related security vulnerabilities is that those who develop IoT products simply do not read any security recommendations nor do they re-use any existing security techniques either (at least it seems so). Hence, my initial reaction was that they are probably not going to read this newly written document either. It is, however, clear that various SDOs will come up with the idea to write some guidelines since these security problems in the IoT space have gone on for a while now*. At ARM our approach is to give developers an operating system (mbed OS in our case) that comes with an embedded TLS stack and even with a device management solution (based on LWM2M). Developers do not need to worry about the details of networking protocols or security mechanisms. Other companies and even universities have a very similar strategy (just replace the name of the OS). Of course, there will still be developers and companies who strongly believe that they should roll out their own security design. For those folks, someone has to write some best current practice guidelines. To write such guidelines I believe there are various preconditions: * First, the group writing such guidelines should actually know something about the best current practices. They need to understand this part of the industry. Ideally, we want something that is still practical.= * Second, it needs to be a group with a lot of experience in the Internet security space since we are talking about **Internet** of Things= =2E * Third, enough folks need to review the work since otherwise the outcome is of limited value. As you can imagine that our thinking was that the IETF could be such a venue where lots of the security experts are already and where the barrier for participation is low. There is still room for improvement since we do not have many of the silicon vendors in the IETF. Will it make a difference in terms of practical IoT security? I don't know since there are still these nasty incentive problems (see a recent article written by Bruce Schneier on this topic: https://www.schneier.com/blog/archives/2016/10/security_econom_1.html). Ciao Hannes *: Various people have pointed to other guideline documents (on this mailing list and elsewhere). I was aware of some but certainly not all of them. Checking for the overlap is certainly helpful. If they all offer the same recommendations we can almost speak about industry-wide consensus (at least on paper). --2PIWfdQScSi9NrGBPvHR0Amo06xHEgL2U-- --xQBT7kgtGptKvbXW2cNRNGSWT9afviEVU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYIOdpAAoJEGhJURNOOiAtLFMH/jZl2LNLpjCyyOIFIp72NcnB bj7lW9tKwHGszldo2Zyk6q/3PF4OZ40OXzymml1hPB6GKdNYyZ9IwaPt2VqXvO/s AkhToNczHL3Lrr0l/lg/zyjQzdJc5zUCBA14InWe4QofGh6OyI5DtwRZxlTNStUw YQzsEU4ao53PUJfyCWH+7D1wCE1eSypzZ+WWuHXjPKsoAF+31FEhjn5GMP+ZCR41 6LVB23BWrMSJUf1CvygPWZmj2iqKpmdV3z5LVNMJzY/fSsr0O+HS8bc7aJYJM0dX QwN9b1cweUzkcE7E2a4kzEAn79juz4oSyjAmqstwwXC/HorBTNDNDttNUihWt+g= =sPVK -----END PGP SIGNATURE----- --xQBT7kgtGptKvbXW2cNRNGSWT9afviEVU-- From nobody Mon Nov 7 12:50:09 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9BB12948E for ; Mon, 7 Nov 2016 12:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 b5BPOPQwJV7H for ; Mon, 7 Nov 2016 12:50:06 -0800 (PST) Received: from us-smtp-delivery-199.mimecast.com (us-smtp-delivery-199.mimecast.com [216.205.24.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E08129593 for ; Mon, 7 Nov 2016 12:50:06 -0800 (PST) Received: from mx02.five9.com (mx02.five9.com [198.105.204.3]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-5-SJkxH6Q3MueDb2HA7jy4JQ-1; Mon, 07 Nov 2016 15:50:03 -0500 Received: from MB03.five9.com (10.7.8.143) by mx02.five9.com (10.7.15.112) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 7 Nov 2016 12:49:51 -0800 Received: from MB02.five9.com ([fe80::ede6:8312:5207:4046]) by mb03.five9.com ([fe80::4d18:3a9c:2936:eea8%16]) with mapi id 14.03.0248.002; Mon, 7 Nov 2016 12:50:01 -0800 From: Ronald del Rosario To: Hannes Tschofenig Thread-Topic: [saag] draft-moore-iot-bcp-00 -- Best Current Practices for Securing IoT Devices Thread-Index: AQHSOTee+TZKmIAmwkSsZu0OfsB+SaDN/pQn Date: Mon, 7 Nov 2016 20:50:01 +0000 Message-ID: <476F8348-BB6E-466B-AB44-B9C7AB37F1F9@five9.com> References: <8b58793d-fdd0-42e6-ded5-be0ccbbecc44@gmx.net> In-Reply-To: <8b58793d-fdd0-42e6-ded5-be0ccbbecc44@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-MC-Unique: SJkxH6Q3MueDb2HA7jy4JQ-1 Content-Type: multipart/alternative; boundary="MCBoundary=_11611071550042651" Archived-At: Cc: saag Subject: Re: [saag] draft-moore-iot-bcp-00 -- Best Current Practices for Securing IoT Devices X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 20:50:08 -0000 --MCBoundary=_11611071550042651 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Checking for the overlap is certainly helpful. If they all offer the same = recommendations we can almost speak about industry-wide consensus (at least= on paper)." Agree. Ron > On Nov 7, 2016, at 12:43 PM, Hannes Tschofenig wrote: > > of them. Checking for the overlap is certainly helpful. If they all > offer the same recommendations we can almost speak about industry-wide > consensus (at least on paper). ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= . Disclaimer The information contained in this communication from the sender is confiden= tial. It is intended solely for use by the recipient and others authorized = to receive it. If you are not the recipient, you are hereby notified that a= ny disclosure, copying, distribution or taking action in relation of the co= ntents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been auto= matically archived by Mimecast Ltd, an innovator in Software as a Service (= SaaS) for business. Providing a safer and more useful place for your human = generated data. Specializing in; Security, archiving and compliance. To fin= d out more visit the Mimecast website. --MCBoundary=_11611071550042651 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 "Checking for the overlap is certainly helpful= . If they all offer the same recommendations we can almost speak about indu= stry-wide consensus (at least on paper)."

Agree.
Ron

> On Nov 7, 2016, at 12:43 PM, Hannes Tschofenig <hannes.tschofenig@g= mx.net> wrote:
>
> of them. Checking for the overlap is certainly helpful. If they all > offer the same recommendations we can almost speak about industry-wide=
> consensus (at least on paper).

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain conf= idential information of Five9 and/or its affiliated entities. Access by the= intended recipient only is authorized. Any liability arising from any part= y acting, or refraining from acting, on any information contained in this e= -mail is hereby excluded. If you are not the intended recipient, please not= ify the sender immediately, destroy the original transmission and its attac= hments and do not disclose the contents to any other person, use it for any= purpose, or store or copy the information in any medium. Copyright in this= e-mail and any attachments belongs to Five9 and/or its affiliated entities= .


Disclaimer

The information contained in this communication from the send= er is confidential. It is intended solely for use by the recipient and othe= rs authorized to receive it. If you are not the recipient, you are hereby n= otified that any disclosure, copying, distribution or taking action in rela= tion of the contents of this information is strictly prohibited and may be = unlawful.

This email has been scanned for viruses and malware, a= nd may have been automatically archived by Mimecast Ltd, an innovato= r in Software as a Service (SaaS) for business. Providing a safer a= nd more useful place for your human generated data. Specializing in= ; Security, archiving and compliance. To find out more Click Here.

--MCBoundary=_11611071550042651-- From nobody Mon Nov 7 23:43:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30B8129440 for ; Mon, 7 Nov 2016 23:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.398 X-Spam-Level: X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, 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 9PIgkfOc8VMI for ; Mon, 7 Nov 2016 23:43:02 -0800 (PST) Received: from smtp.mu.afrinic.net (smtp.afrinic.net [IPv6:2001:43f8:90:606::169]) (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 22EC31293D8 for ; Mon, 7 Nov 2016 23:43:00 -0800 (PST) Received: from [2001:43f8:90:250:5879:d0c1:5501:9e3f] (port=55956 helo=rnt-eng2.dhcp.mu.afrinic.net) by smtp.mu.afrinic.net with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1c413X-000Bb5-Vj for saag@ietf.org; Tue, 08 Nov 2016 07:42:55 +0000 To: saag@ietf.org References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> From: Loganaden Velvindron Message-ID: <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> Date: Tue, 8 Nov 2016 11:42:54 +0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 07:43:03 -0000 On 11/5/16 5:25 AM, Keith Moore wrote: > Stephen Farrell suggested I bring this draft to your attention. This > was a rush job as the authors just started talking about this last > Friday, but it was written in response to recent DDoS attacks that > utilized easily-compromised IoT devices. I'm sure there are missing > pieces (I've identified a few since -00) and sections that could be > stated better (like the title of section 2.3.2), but hopefully this is > a useful start. > > https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ [Speaking for myself] That's a great start. Can you please consider adding section 2.6.3. Sandboxing techniques Device firmware SHOULD be designed to restrict processes attack surface by isolating them in sandboxing, in addition to privilege minization. In case of compromise, the attack surface is significantly reduced, particularly in the case of privilege minimization. [I'm thinking about OpenSSH and Linux seccomp-bpf sandbox, and also techniques like OpenBSD's pledge] > > Keith > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Nov 8 01:59:36 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEB8129461 for ; Tue, 8 Nov 2016 01:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 CX1VeQK0DIMh for ; Tue, 8 Nov 2016 01:59:29 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE4F129495 for ; Tue, 8 Nov 2016 01:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1478599169; x=1510135169; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+4eREGY5AAKHLnOQZOouoTbn3vy6KJxZmtiRvHw30GA=; b=1W5xg0vPXMU0g4ONSyH5ksgzY/k3MgMpGUgOGoNKehlGfV/gi7cpYgwH 75uH/K7klS8HGyiBVW1/fEbzmrPCrViVHncfnrxm1K0CxziPZhl3g7KDC /5N04pMM5wd/0ZKoqLvYOSRrO7KEN40r6l/NlAQakJDZPXdBTDR2cABi5 rfUKAuIveLoDNvnjW66x7GagTrLMDy2ikkTf5FLnjDv1hIGtnEDrf8VFb PMPpKyZVbhtIayVUU8cE08umM4kfA+ep9C8JI2j2s5sn/uUjuuI8mnymC hQwzBjgj7AIupf9OCOmLqzMZQeDMUHHR4fQRljTbkmfSlaKakLgkqoaJN Q==; X-IronPort-AV: E=Sophos;i="5.31,609,1473076800"; d="scan'208";a="114179441" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-c.UoA.auckland.ac.nz) ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Nov 2016 22:59:05 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.24) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 8 Nov 2016 22:59:05 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Tue, 8 Nov 2016 22:59:05 +1300 From: Peter Gutmann To: Hannes Tschofenig , saag Thread-Topic: [saag] draft-moore-iot-bcp-00 -- Best Current Practices for Securing IoT Devices Thread-Index: AQHSOTej1Q9sjMn/UUak+7Z+mGyorKDO2qvE Date: Tue, 8 Nov 2016 09:59:04 +0000 Message-ID: <1478599141459.30483@cs.auckland.ac.nz> References: <8b58793d-fdd0-42e6-ded5-be0ccbbecc44@gmx.net> In-Reply-To: <8b58793d-fdd0-42e6-ded5-be0ccbbecc44@gmx.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] draft-moore-iot-bcp-00 -- Best Current Practices for Securing IoT Devices X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 09:59:35 -0000 Hannes Tschofenig writes:=0A= =0A= >I was skeptical about the value of writing a document that offers guidelin= es=0A= >since one of the core problem with many IoT related security vulnerabiliti= es=0A= >is that those who develop IoT products simply do not read any security=0A= >recommendations nor do they re-use any existing security techniques either= =0A= >(at least it seems so).=0A= =0A= One thing about most (close to all?) of the IoT vulns that have come up is= =0A= that they're hack-like-it's-199x issues (I've heard that term at a number o= f=0A= IoT-hacking talks, the x varies from about 5 to 9), vulns that were common = in=0A= the non-IoT world fifteen to twenty years ago. So if you were lazy you cou= ld=0A= just take any standard security development text and use sed to replace "Un= ix"=0A= with "IoT". Hey, it's worth a try, it might get a bit more attention from = IoT=0A= devs once the magic keyword is specifically mentioned...=0A= =0A= OTOH I think you're right in your observation, the people I know who do IoT= =0A= (well, SCADA, which is somewhat different) development take security seriou= sly=0A= and often use multiple sources of secure-development practices, as well as= =0A= just safety/reliability-conscious practices in general, because when your= =0A= product has a lifetime of 10-15 years you can't cut corners at the developm= ent=0A= stage and you can't roll out a new version once it's deployed. OTOH the=0A= people doing IoT barely care about security, it's just "get it apparently= =0A= working and out the door as quickly and cheaply as possible".=0A= =0A= Peter.= From nobody Tue Nov 8 06:44:18 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5B7129C6D for ; Tue, 8 Nov 2016 06:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 IO0dmx-VrtMx for ; Tue, 8 Nov 2016 06:44:14 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 37C40129526 for ; Tue, 8 Nov 2016 06:44:14 -0800 (PST) X-AuditID: c1b4fb25-bf4b398000005623-61-5821e4bcbb81 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id BA.84.22051.CB4E1285; Tue, 8 Nov 2016 15:44:12 +0100 (CET) Received: from m46.nomadiclab.com (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.319.2; Tue, 8 Nov 2016 15:43:45 +0100 To: Keith Moore , References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> From: =?UTF-8?Q?Ari_Ker=c3=a4nen?= Message-ID: Date: Tue, 8 Nov 2016 16:43:45 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM2K7ou6eJ4oRBlOPqlhM+nqOzWJKfyeT A5PHkiU/mTwmnQgLYIrisklJzcksSy3St0vgynjV+5Wt4BdrxZopU5gaGF+ydDFycEgImEhs f+rSxcjFISSwjlFi1vIfbBDOWkaJa8sWMHcxcnIICxRL9C6cAGaLCNhKzPv8ih3EFhJwl3j4 +xALiM0GFP/dvocJZCivgL3EhMN8IGEWARWJm31zGUFsUYE0iZWPfjGB2LwCghInZz4Bu4FT wEPi1CsjkDCzgIXEzPnnGSFseYntb+cwQ2xSlbj67xXjBEb+WUi6ZyFpmYWkZQEj8ypG0eLU 4qTcdCNjvdSizOTi4vw8vbzUkk2MwMA7uOW36g7Gy28cDzEKcDAq8fB+mKYQIcSaWFZcmXuI UYKDWUmEd98NxQgh3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4 OKUaGHVVMs4ktvVt3b/a6Ce3u+fTq1XvGi7yfT7s0q+ydY72mdXci0K7g99xKfarRaxYYOTI N3d52y5lG+WYS2ocUl2FTznuzrAx4o+uqphaY9XYKz5HaQ+TqlDN1tLozN7kgienH+9hNv++ Zv+mjdlZK48r/Lhy3EJcISd1we/7S3YulQkQPVLwTYmlOCPRUIu5qDgRAKveLkw4AgAA Archived-At: Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 14:44:17 -0000 Hi, Also at the Thing-to-Thing Research Group we have a draft about security considerations for IoT: https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons Cheers, Ari On 05/11/16 03:25, Keith Moore wrote: > Stephen Farrell suggested I bring this draft to your attention. This was > a rush job as the authors just started talking about this last Friday, > but it was written in response to recent DDoS attacks that utilized > easily-compromised IoT devices. I'm sure there are missing pieces > (I've identified a few since -00) and sections that could be stated > better (like the title of section 2.3.2), but hopefully this is a useful > start. > > https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ > > Keith > > From nobody Tue Nov 8 07:03:01 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EEF129407 for ; Tue, 8 Nov 2016 07:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tSFt7JG6K31H for ; Tue, 8 Nov 2016 07:02:58 -0800 (PST) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::243]) (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 CB26A12007C for ; Tue, 8 Nov 2016 07:02:57 -0800 (PST) Received: by mail-vk0-x243.google.com with SMTP id w194so7800560vkw.3 for ; Tue, 08 Nov 2016 07:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IOBKJnusfMdl7ExbWNhaSJctzQdLLDeIq9p5s6vKre0=; b=kkBBLPnkD/iuDm2V1Fp5JIwdfouWMIQj8aIvuXuhQIePFvPRET0Xgj8DfQuAuCtXs1 gU3gVHM4PWdnocpxr8lkkBwnawDuLCXjoQCaLJRMpjI6Ov9R6EyAXJWHGE/UsdSdhMs1 hdSHNFUb/MJ+jSKBEBIg5/hNj0Jufwqsi/hHKx0/oqqlRAwCRgT8sBQHh3WbQxr9YXK9 U06uROrgRHumZzlJvGDwRyTAXnKlcVDdLp0iI1aO2LAh1hA48OMOyuuo9/DdAXrCqzJ3 tr8En9Tps/FUdHjUmhgqQkUqrjOg7tcy79vUI1xmM52yjiz8G1J1smy+VZ9hIqKdPB4p XTHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IOBKJnusfMdl7ExbWNhaSJctzQdLLDeIq9p5s6vKre0=; b=FeIST3JJ/xntmF+tSr0hcE8Q4HtjGt+y0h0dzsQ7b0XjqGoXSciTdEAxYlnKnqmGwU ZYsQRBgq/+419DCuuekSd/7rOL/PAMJy0LH5WVR/yyRcX1ATnsItWTsaNj5H/oFjHb3Y 0mTEH+ZVU/yrPqtyedHyMN1xYtBGU+gZx6YM5U+x+gEHc+oEXc0gPPdCeZdvLduw9WP1 DjRu7jWuevtB36Ys2D6s/LP6J/Cf81ksiw3WkrufSzFlR16CaHq6jnG2DxWR4Pg6E1RG keRI1x9FnwFNKpNpSTaK2h+QZNNi3DcMZoFL9uM/OSaUwRSTgx5rju0dmhYO9InOTm2U 4/uQ== X-Gm-Message-State: ABUngveecfQXAcV9WgKfW0A1gZgN5ig9sxx2eX1BNstZqwDAFh0lrypvA0IlJf25OnH8hrXcspqSVIauVo17ag== X-Received: by 10.31.178.66 with SMTP id b63mr8240451vkf.70.1478617376747; Tue, 08 Nov 2016 07:02:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Tue, 8 Nov 2016 07:02:56 -0800 (PST) In-Reply-To: <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> From: Watson Ladd Date: Tue, 8 Nov 2016 07:02:56 -0800 Message-ID: To: Loganaden Velvindron Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 15:03:00 -0000 On Mon, Nov 7, 2016 at 11:42 PM, Loganaden Velvindron wrote: > > > On 11/5/16 5:25 AM, Keith Moore wrote: >> Stephen Farrell suggested I bring this draft to your attention. This >> was a rush job as the authors just started talking about this last >> Friday, but it was written in response to recent DDoS attacks that >> utilized easily-compromised IoT devices. I'm sure there are missing >> pieces (I've identified a few since -00) and sections that could be >> stated better (like the title of section 2.3.2), but hopefully this is >> a useful start. >> >> https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ > [Speaking for myself] > > That's a great start. > > Can you please consider adding section 2.6.3. Sandboxing techniques > Device firmware SHOULD be designed to restrict processes attack surface > by isolating them in sandboxing, in addition to privilege minization. In > case of compromise, the attack surface is significantly reduced, > particularly in the case of privilege minimization. > > [I'm thinking about OpenSSH and Linux seccomp-bpf sandbox, and also > techniques like OpenBSD's pledge] Does OS sandboxing actually work? Real attackers attack. That means they have carefully studied the system call interface of operating systems to find bugs, which they can use to escape from running arbitrary code to violating all security properties. They don't break the sandbox layer but exploit the kernel instead. ASLR, N^X, CFG, and memory safety stop attacks. (That's not MMU, that's using a memory safe language) Sandboxing has limited effectiveness, and we should recommend memory safety as the easiest way to prevent RCE. I'm also disappointed to see no mention of web interface security. > >> >> Keith >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Nov 8 07:10:26 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AF412967D for ; Tue, 8 Nov 2016 07:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, 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 r2MIU26s9GQi for ; Tue, 8 Nov 2016 07:10:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706B31295AB for ; Tue, 8 Nov 2016 07:10:20 -0800 (PST) Received: from [192.168.91.155] ([80.92.115.71]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M3zG2-1cvGYP3HZS-00rUoq; Tue, 08 Nov 2016 16:10:08 +0100 To: Watson Ladd , Loganaden Velvindron References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 8 Nov 2016 16:10:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dIprxxAV6oevuPgCMQxEgVOjKAqHQCsfS" X-Provags-ID: V03:K0:fG3nAdVYpPunaHibj6FYuln82wZNECy9VRx1iZmIC7RFp2l21uz RQ8T2XbOKc8n9HJiJsTeGqDWyvJKO7QfJVM+pJYdg/6qYkc1iwZQY6MQLl9qOPqCuxOpchq +Hif7+W+Fmph+JZTasVWDGJT7hkro6dai1s4mZa7urqh89AppJ4S2QeyXMzpQ5CZ6W47P27 dRqvG6N+m9rI8rzGRvabg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3qV3NlifBl8=:0v3YYiGRW6BAiOc1dIuGue 9nOa894vwS3hrw5CeWk66GJiMaTjvQ7zJaLQMhUiDrt/oZ3+LZY+Ru4Xq6RBvY3cjPkaUIjWl ZY68/uC3Yg+3PuIU8t/B5hZKIQpjpIeaAD9QWWXgNifQtHPVN4xsB6FBGMNyWsJz7s4S5D8u6 EcS6sAsGfcvs6HGdOQBNDxNWfm7+xpSfCtBr43kjsD1w9jjvihqzFNMpuUAPVMyno9SK66+o8 uPxVVXONipFqaFfs7/HjXUPd3Ojq3a3wHHqQ5K9YlMpPFaOtMs78APtxvfj4/XMq1wVifJAtw Wk7HjFHBatXV0/Mul7bhnmdTFdUsZAv71we5tsdj3cmpBGwvXqIq6hAlWqueJFhnHLBgwXgtn 1E8QUozJBVrNAjivMfL7vTL9PBqTGRHsJTqt/Xrp/NOu61SlZWrHaeldN2DsEoDzOU2/mD6+s /gKDMwkZz53iLLq1NJ1i8/hRfcP8Q53Kh+ZKHN4hvx+A4QUmq9FKoX9hnAhY/041OI2o46f0x 2OTfYauyoatdrW7Kdxikoxr3jYnXhTa7+3UAt079oapmzEYyq47X+CtTYSjfMvKhTRMWyz9ZN cVEush83949EntlW+3++vVMbaPxTViv5N6nXIOSfHEW4prgJPOOeaC001UlFbdlh0TXeRpI4+ C3eTgv7FjY70QqAOzrcQH3t7Bn7YKunaL/ARzl731MZYY5uDiLxTOmqIFNGUvmYjTytwdGs9s WJdYKQAbSxydhI9ssn+i2fD4j1UFE9GaWFIwS1g8yYNB7In/ab4SbIL7C50= Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 15:10:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dIprxxAV6oevuPgCMQxEgVOjKAqHQCsfS Content-Type: multipart/mixed; boundary="LgW1k2ow59k7T2PtLkBMrS0u4AsWsGHjF"; protected-headers="v1" From: Hannes Tschofenig To: Watson Ladd , Loganaden Velvindron Cc: "saag@ietf.org" Message-ID: Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> In-Reply-To: --LgW1k2ow59k7T2PtLkBMrS0u4AsWsGHjF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We probably have do a bit of document scoping. Many embedded devices do not run Linux since they have no MMU. I would like to have guidelines that also consider those ~50 billion of currently deployed devices as wel= l. On 11/08/2016 04:02 PM, Watson Ladd wrote: >> [I'm thinking about OpenSSH and Linux seccomp-bpf sandbox, and also >> > techniques like OpenBSD's pledge] > Does OS sandboxing actually work? >=20 > Real attackers attack. That means they have carefully studied the > system call interface of operating systems to find bugs, which they > can use to escape from running arbitrary code to violating all > security properties. They don't break the sandbox layer but exploit > the kernel instead. >=20 > ASLR, N^X, CFG, and memory safety stop attacks. (That's not MMU, > that's using a memory safe language) Sandboxing has limited > effectiveness, and we should recommend memory safety as the easiest > way to prevent RCE. >=20 > I'm also disappointed to see no mention of web interface security. >=20 --LgW1k2ow59k7T2PtLkBMrS0u4AsWsGHjF-- --dIprxxAV6oevuPgCMQxEgVOjKAqHQCsfS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYIerNAAoJEGhJURNOOiAtKiQIAKEuclfMzt/vU5c0P95NkxXA NBu8tvs5iM4kKIo6gnIF/n2Yl2NoHg/YsEc454hF3/w52Cg1hA/HfwXuI25JSAGj PY3FDQBfhHbB1vC80MpBoJt5X86CBJTMoXJ/zZzfyGdIJuRqvw1cO6ny57hNitq5 N2VqrQAgNG8KsnJ7ABCbMI/4gpyFNUhDIEAkzMgPGQrS5Rd+HK719OeUgudP+Cxw NIO41craqYW/uMCKUnlkyO6+XFkvExm4ym/WV5CmGfRONXbwMMHQNTyie8DMsstv CHnfPjaqZ6EUCa9rQ4zXeqhMm45+Sc64u6sLKCA0hCW5+RXP74VtLtt0mhgA+xU= =F5It -----END PGP SIGNATURE----- --dIprxxAV6oevuPgCMQxEgVOjKAqHQCsfS-- From nobody Tue Nov 8 08:03:41 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73441298B1 for ; Tue, 8 Nov 2016 08:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.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 FBNzuAHNBaNP for ; Tue, 8 Nov 2016 08:03:36 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C04129781 for ; Tue, 8 Nov 2016 08:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6z+rbH+0RORG8GXpn4tlJ0q2b4S2MO71a0Clw9IWt8g=; b=XbICnuryQAYu/vAh94lDrKWr2dn/Ys8zgbODFckvn3VKH9jWsUuXtc0o1DwY3TkmenN8+1jmpRi6Yat7sCOdg5sjV7XFkK2xbZP7pdGVrIcAcmxouGWDrSPCynBZa4P6GAj3PcuJ1C7UEtw63XEluvxevtO/FIhQQ3KUMBoSJac= Received: from DB5P122CA0004.EURP122.PROD.OUTLOOK.COM (129.75.100.210) by DB5P122MB0006.EURP122.PROD.OUTLOOK.COM (129.75.100.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Tue, 8 Nov 2016 16:03:19 +0000 Received: from DB3FFO11FD024.protection.gbl (2a01:111:f400:7e04::162) by DB5P122CA0004.outlook.office365.com (2603:10a6:20:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6 via Frontend Transport; Tue, 8 Nov 2016 16:03:19 +0000 Authentication-Results: spf=none (sender IP is 40.103.22.100) smtp.mailfrom=philips.com; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (40.103.22.100) by DB3FFO11FD024.mail.protection.outlook.com (10.47.217.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.3 via Frontend Transport; Tue, 8 Nov 2016 16:03:19 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:4526; Count:54 Received: from HE1PR9003MB0234.MGDPHG.emi.philips.com (129.75.99.147) by HE1PR9003MB0236.MGDPHG.emi.philips.com (129.75.99.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Tue, 8 Nov 2016 16:03:18 +0000 Received: from HE1PR9003MB0234.MGDPHG.emi.philips.com ([129.75.99.147]) by HE1PR9003MB0234.MGDPHG.emi.philips.com ([129.75.99.147]) with mapi id 15.01.0707.006; Tue, 8 Nov 2016 16:03:18 +0000 From: "Garcia Morchon O, Oscar" To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , Keith Moore , "saag@ietf.org" Thread-Topic: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) Thread-Index: AQHSNwOffTjJvUZ5sUKd1X2HfG8cGKDPLvyAgAAUhVA= Date: Tue, 8 Nov 2016 16:03:18 +0000 Message-ID: <68453f17719b45a3afe0ee8607acd420@HE1PR9003MB0234.MGDPHG.emi.philips.com> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.6.209.22] X-MS-Office365-Filtering-Correlation-Id: 4f323bc1-365e-465b-0f17-08d407f0c22a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9003MB0236.MGDPHG.emi.philips.com X-IncomingHeaderCount: 54 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:40.103.22.100; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(428002)(55904004)(374574003)(85714005)(199003)(189002)(24454002)(13464003)(377454003)(97736004)(3846002)(105586002)(5001770100001)(66066001)(24736003)(189998001)(6116002)(50986999)(76176999)(7736002)(305945005)(102836003)(2900100001)(8746002)(7846002)(8936002)(81156014)(356003)(81166006)(8676002)(107886002)(2501003)(106116001)(92566002)(2906002)(106466001)(47776003)(68736007)(33646002)(586003)(5660300001)(54356999)(626004)(101416001)(50466002)(108616004)(230783001)(69596002)(86362001)(2950100002)(23756003)(87936001)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5P122MB0006; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD024; 1:TarsNfj7mLYZhDBZNMUTQgc+YPT3x/Dk/k+ubd/S/LZrvKJgyBkzMkUX2j/DOyKRuhOaQOpDjJQUs09Qtj69RSA6BgIoXHFZgG1TVQc3TI4Veyz0A0baIo5JUq/L04Mly1Vs1hM+CIIJC/y7K4wennW9WezmrrTAOIK0l+iBd3fcjNTJZsF0lZ8RHaEsRDTYVjoDWCUydH4XnZAQMStiwZy8J+i3s4a99359ErSGeD+2EbGVZvQEvE/yL87eLLAwyAH+I8cGXr1rUBw/ayWTZwXppIOR7KT43yQ+MNXBjdy6AiBjohjxkGnChcenQ60qyGYlzlK/2mzBuJA3NGnYsysJc/1eLmNnk3aJPWjXUpvtKnF/J+Zyjc/ODpfz5oEq0Q98BLyaAiSNGKD3EHsgKMZTNJTqBrFwsR5h5jIX80RS5PXu248A/k9EGHjud5NuCKGB8Jmp/JseAaXOnVqrA+OBAvHHXUu8EUZAAuNM3jEtKoNZPvA1d71VEncBpVNIGnm2U2cPw4UBj90dh/fX2w== X-CrossPremisesHeadersFiltered: DB3FFO11FD024.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0006; 2:E+VQtU1wzEl9gBUTMIFGkytf5KjQR+JJ+XYNZ/3d8dMTzZKscIwIDTLerAE13zxHziDMvWOMuw2Mm+bomeMfcXO881zDhKHteEX1/xeGIDJumZeahk8lchzVxE0ZzEolUz7PRuE9RYfNNPY8R/S0WnE4b8L9rfFyRJmbK3IDw4lqG+3RojIBhwlPPLObAnbSchBTlc4JKFH8xk+TcMuTMw==; 3:m2dgk41K5R6V91UBBehxTvEHLe1sDfSTZfuta3cCBKyTbDdHoxp3SR5sHejgLtkqhILGw0wjPQdwOWPe9qdFA8iRT5+jNWodlzrJDy0D69/I/qLckPJTTC/YRD3d6i44yOPRg+nsZmnh+Yxk4pL4PKFkHeaw1jsO7royCPT5KZuSAxsvdEh/6z7Df22wVi5Lvp7ZcLVX354ydSflVcobEPqOCBL8bqpvsVXkEJUe/elrpk4J0w64vDOv5hQHs9jP X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5P122MB0006; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0006; 25:Cq6jAq/XI8FNqpNqky6meShNxWUeTW3L0vOqcoVViidSTB8kGzuG1ajnBCXo2lH3OtLv5mj2/BO6l/w2ARNDjMutvBmN+i/rbHCDZBlxhWaAhkRLuwib2dOaYlx7spzcL1p3dioBzRlwahW+oIT90Sipzmx4TET3PpOU2b5C2tTqbFYRLOTQ+DmRXi7PeoTXl7uki28c/QMOyzQUGVyibxBF202uRSoUtfVkSf8KVNu5T10KI17+nDyV3QhY9lr8UyoMvrtskXNsapbmZaHNv/ImLoGj/P1dA9XNtyGTbUXez0F0Q7gSVF9iEoYwOFM05+PmyscJrGpACPA7d11mJOdioKyyCR7+adXZ9L1QlDapn1SsSlLnoX5mCEEpvkxHsdRH+vojTNRs4IM9MDx48EwWiX9Mbcw0p/hejT6lDT96EBs0DENeedDZZr5WrsV/PM3plxZ6Yo/yE0RWfRRKk+kkf6Blj0G5hMxkdkOuociLWnjQSwd+pBjWoiYSvSVr+hF0sk+TfRydIrznfwHexEkbBfa0/EnxD6bZ9lV3tF6jFhKsnYp15BrcmjwKYmNf/LM/jgplYMHZsZH6A88eEJlmBHoCu7VKa+36PkjAseOfPAXWEGAcxBuPJTSDr06eHc0QIhyf1wS/PV9oCtRwYtA+jlRnCJ/rqhdh9KHViw0TCllrxSpGfG9g9JBUxEOmK6YYmKT0A6u/TFhtj0ZiZSgM37cs50W9VXD1hbEX0p3sA1Zn5bjqILzGjM0gLqgHuUg+aaiD/oA6ZnsUuqpB+D1BKbI6U2F4nfIoFc7MJL2dhlKgyKRcbAC2WRAvGY8MlFu+21oXIdGp+76GQln3Y49oJabX+NCkoqSu7n/+s1+6QSh5jB0PSD54ZTi15sGKoLOnQnmmCsx1Q6BaLjnohJDEqw+ifn0qBwzYqQHWqfo= X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0006; 31:tTtQ7Mkv8iwhKrt36d1oRmVJlNd4J9wjIal8XQiJSt6NdFyl6pFXV17peCJD33WBg3o8RClS3PawNoG8S2UuN3mMnl2mzHMNwbpxR5yZns9UlgGarCTdE2S3gtT5NHsJd3RDXTXDnIv2Kf8yUh1WUGa78jwh/wxqEgvPfUoBv6M3C5Glyg/Dyn3czxe5Ux4IXqoaqt2kK3YTpl5XiZj7GCLxxIEvMdCT3wKqG9j3HzLhK0LrPNg6NFAycZpA03rQ; 20:vjiTxwczET105lurazpgT0QsexkkZqzVhAtPVI7GaR6ewZOSuLc8b6wqaLwoDVnUg2N/+yZsUas7WsCbyEMpVGB9FMink5nzrHBfunH/s9h6pQk5RcRz4yddnPZxvOwAQ/PyNeqGMcI2Fnb6asN47RTpFQcVrYonJ+lKvxWTi55IT2ltJkFa+r1FbYZvN/Eq/8Qlcthb148PgsnbcVVDzbh/+90KRaBFH81zgSsolROgNNZJyEKVSaI8Fh9/5YD4BdpzG5VHdWafnfYrrlYGj4YDtq2IMpaeUZj4uEyWknDRISyTC/Pi4AhjrjqjJKeMtqCZrny4vl46yhaLZo2xWLYl50H3XfYVtWgsTSq+MkQRz8hqCdzBSaWRYL/r7Amla9BMCcKRSSuyRRWloWnWRRk8jW3KGHbxwtzT7o5gIEu6hxxLM58LCHfY9BLxxuS5UZP3DKVPhF2lL1qn2wxm0XWVWO7nxghZxuqAYwE6rB3tiZuFNqSl/3Gn8Yh7YG35 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(13016025)(8121501046)(13018025)(5005006)(3002001)(10201501046)(6055026); SRVR:DB5P122MB0006; BCL:0; PCL:0; RULEID:; SRVR:DB5P122MB0006; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0006; 4:9Ow6s47+4IoWbPgra9jGmSFxGGdxUgLFEuiw6xuGDWtqk62OEx7nlv32+FpbIBiq/Jz0EFOKHVyz2U9QCe/S/xXYUzR+eeLOl73dmKdQA1+veKjZdZZAKzlH4jg4FDPx3HAa8+6IREa8dFiitZnSsZN+6cHNlGktSl15v1fDPHcXckIjUbvL+AGRDu4Y4WBPELlo5Pt95sMjaiHahs0oRJrh4fsJKIGGX8bYtNpdAsBPUi6Y5+PLX9ajkCAywaNrqyKGlWYNEkvVAed8zuT9jm32l23umFqRzJdQBGJRH7gj5pun8APpLhGJAn79/CsMRzyarBFgQspQJNQNQckA524vh9To+XphWz60b73vlIq5kwDULgJVy3rzuEWOjSe87iBynHBGaFcgRJKo5OiBuN2KVAIwRfDmbF+zWPcm3Cezi8bVecLGTefGBPhcrRO5z60W2GLuCjwJLtH246dyEjr8erSyIFbozGGpcEE94wzKr0VsYYALkacxc0+tutFeWXH4JQ94/CIICmsxy+C97Q== X-Forefront-PRVS: 01208B1E18 X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5P122MB0006; 23:lrLGtj4HAvrCqkj3HL38BGjZflIFpw+uVYTwCa6?= =?iso-8859-1?Q?99lAmmh2Hv2ebZpfAn/1+40OFGZ/YkH9ad8tea1Go1iSouKRGoM56gC2xL?= =?iso-8859-1?Q?2ICucBeNlrq830kT6KIvrozljopR2bg2f5ejPxR7QnQZhv818sd4amuYRH?= =?iso-8859-1?Q?kqguD8anws+eF09oRQM0tPVurablPyU1Wjmf2GJW2OWiezOqZ+aTaDHHuK?= =?iso-8859-1?Q?MxMDXcRq7SieErZOp0QbTt2Nc8Hd3q2oWP4CmOepmZViu0b+UEL1aVtcek?= =?iso-8859-1?Q?qf+DcKtWB1nCk8tChawOKIYyp4a9swyzAVhN8sPPtjq8vx9+rC5FlnzSr7?= =?iso-8859-1?Q?x/N2+F1meAQKbDCaFybxissafunyykV7lnq6c2BgVsND8nvTpFwcsWd26Q?= =?iso-8859-1?Q?Kfr2Eyuah6i4RUAbJbICz4QNfLixQnQyHTVXp0z+SbJrNl6c0Y3kieEixx?= =?iso-8859-1?Q?C2XxJbMqObZ7rjnpEEQSF1OZG7nhjVzzdg0UJInChKZbECiqwYVVQc0EAW?= =?iso-8859-1?Q?smF/2fpTw/HGvX5Qw4ogZpfse6Yu1SGPtNnLS/dMvkOW0WYpCaes8aSJwS?= =?iso-8859-1?Q?1O5LXjCZjjQKOugFY2LnXas0lALLhy4TUNssK1qbwqpO1itvb0GPSTwzDe?= =?iso-8859-1?Q?wYXInvmrg+VST6dW4eWOTVUjq15/iEj/OeoT544IxfZXw3tetwF37PBt2o?= =?iso-8859-1?Q?D+OjE7N5rjdc9yjnH3y0cyRFSVtf1//wAmt3LjCHF+tSXmA4H7VvnP9QNN?= =?iso-8859-1?Q?1d8KcT8fLhDRwppqtPGeCto9lxUCEIA2xm/EbbrbyOQNtBlRpBG1M3LGOo?= =?iso-8859-1?Q?mfhr5pIUiO4WW4T/jizGkkjvI2Otk8MPVOXrBffB8fzmXF/s+/NdL4YZ0W?= =?iso-8859-1?Q?UXJPz1X06hw8YTW0+VAkGIbJUwSHFM4FnUXBg29xLxpcFsmXEOi+V0g2C+?= =?iso-8859-1?Q?lRPUrXOYQmTzep6SWqcUC3S8/4mr5XP3LWmJJHacBqNJ36jANUupYOl9ty?= =?iso-8859-1?Q?dYytKXnN7ctFTlmQ/JfGBwACX6cZTT980REP+V31R9iRWecGOOSHyGxls5?= =?iso-8859-1?Q?ZNlcBMw7wIFYDhiuX/X+p4uTlUWWZGlVASMejowE0fvmtShzCrXdifMMTh?= =?iso-8859-1?Q?CXzYNYS2QtBX9wPZ6nH05O6lSk0sKC1g7KIgWVuQJ8c5DGhVHh4M0rmVUw?= =?iso-8859-1?Q?YLLs/LnJ2Cul86KIVlEd1GBGNroCc+gTls7yawve5tF5JI1M3K+b6TAPUE?= =?iso-8859-1?Q?gnQfxAD2RtFhHECgGWHRCHvdTz3rXs+1G5fBzps2fNXmOJcZR4dhykWCY1?= =?iso-8859-1?Q?XlYyKRDKGm4vFoT+TPPhHuUgggfA+ZIUBMOcbHVvFReQWKpd8xiz67QW4h?= =?iso-8859-1?Q?k2Fn3uaLUGZeTeSQdztAlPgO8k2Vi/p3Gy/5iCBXLHvfi/TG/BA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0006; 6:UOeeBpv/W4o5RGG3r8CAI5yqFPcSVaiSeNyG2bRTCMvUpoBjRACto7ZLLyesEMwtSTHiGbwcqh5pPpf3rYmo5+unynRvshCMYXKPJBvc0O3efJf+jwCMtLRdoMNchLrqlWodIK8vlOQpxqYIur6QIVOJ2hurce4W+DgNmAwGBJGprIGZwAR0MzvjziLicUCtGPM1KyMLgeZ4VbfZptgFC9OnYHCEcYHfuq3aKO5DsNjKBEj1bvnYSMNmjn3PI4HlTQRs+3ox48Npb2+7jXKZv6quT9Ig76HmhIheUghDNDeP9pSoWEceZGxd6lPsBKPY6sDX9zga6OHJqKLVEvBbyKhyVVssvIlkzjMVOAChLlE=; 5:9gpaZgyGUKbQC8Xzk+3zfwa3zSdHjqQ6YolQD2Pf0mFw3VbUI0dysi2JANjVtTkEsPTRDWQAaFAhN3f9B+jJ1/Ey8VJm0V35bofaGAHTCF4P/po95PziLVjqi1bUktPln/BoDuD7ej8Ezz+aY2ZUx4YRLJfy5wHrgSwxtoxcZ+g=; 24:WvOL7AQFLv1XasNONaON3sGLjfbzv7cSi1w2SulYW8j0tVDduNiFJb/f0lLfDxWj1lJ5w6qOCkCQFxwnh5EIVkALTWBtGjSgbSS2/P775hU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0006; 7:orP1Wh7AGLT0g13+RzZgFGpW6UyumkE4rIeDb/JOSrfdp/yGOB+PsVXkI9mdl9RokRss1CFZEmvnEdpZikpe+zsxZiR/bu/RasQdoNYHB65rdpuLUNzR6Ki1bYU61OSgFPKbKriDyCFHmh9W8E5cc8/c0k+mOYlyf8j0oRxF9xgk3KF20qXb9l0T5nDQIrMOXhJT4yNeNNHHL99hsd7dO8pLZdhNw3HAPhGPmSENejfl5C35UoDau/NbRrqbuKy7XVj8BDj/ISI/gIgYh5AVtJj1mZ0lmvhnOSIcgYNbG6Ma3RCpqcdI3FVqU0Hh1Q780eQjasloMFRLhzgTkZtiCwuxnrcOcw6EKSdTlwFwsh8= X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2016 16:03:19.6072 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[40.103.22.100]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5P122MB0006 X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 40.103.22.100 X-MS-Exchange-CrossPremises-AuthSource: DB3FFO11FD024.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: DB5P122MB0006.EURP122.PROD.OUTLOOK.COM Archived-At: Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 16:03:40 -0000 Hi Ari, Keith, indeed, the purpose is similar of the draft in the T2TRG is similar. It is = clear is that having a document in which we describe which aspects should b= e considered is very relevant. We are in the process of further updating our draft -- comments are welcom= e. Regards, Oscar. -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Ari Ker=E4nen Sent: Tuesday, November 08, 2016 9:44 AM To: Keith Moore; saag@ietf.org Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Secu= ring Internet of Things (IoT) Devices) Hi, Also at the Thing-to-Thing Research Group we have a draft about security co= nsiderations for IoT: https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons Cheers, Ari On 05/11/16 03:25, Keith Moore wrote: > Stephen Farrell suggested I bring this draft to your attention. This was > a rush job as the authors just started talking about this last Friday, > but it was written in response to recent DDoS attacks that utilized > easily-compromised IoT devices. I'm sure there are missing pieces > (I've identified a few since -00) and sections that could be stated > better (like the title of section 2.3.2), but hopefully this is a useful > start. > > https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ > > Keith > > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From wtpolk@gmail.com Fri Nov 4 08:11:33 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040E8129470 for ; Fri, 4 Nov 2016 08:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 l-uvgTToeJgu for ; Fri, 4 Nov 2016 08:11:31 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 48FEC1288B8 for ; Fri, 4 Nov 2016 08:11:28 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id v78so32471081ybe.3 for ; Fri, 04 Nov 2016 08:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=gff6EouO/3wks0nEgBsPUPYLCQhVbE63vKnrpAnCNcw=; b=NdN4KSzH/XUNzDA1f0O+UKBpclBAf5VkgT2MfW1tAiF7NLk52TdjfVZGyOuSQNWImA wQtopFV0jyUcEPhus3MSOAbtARmH1lWFa7j5emfNZuA0vIeiW0C7MFf6myp91YsvGA90 ryOaI8gTgjBmyT10BHjmDUkJnjFR6cac0jCQRGOlhFOluWBAcfCiihH6sS3bnWrhJWhi kYTcalVyiS949906ezuiOdiwI8zPFyH6GQ81ffLI3sKxM4akH+MZlpYEZcHqT5QJFfQJ KsOSLaqgOxBh4reUol74FlOPSJOW5CDuUPZXA7rX7vct0L/k0etWDMHTNyWUsPnRNMGb iJNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gff6EouO/3wks0nEgBsPUPYLCQhVbE63vKnrpAnCNcw=; b=UL3YLGIx3cGbeSzAFEENczuiOYjc25/ZREGIn/9lLL9sOXjWqiF8YvMAew/ajwKD7j z04Fz4KX5XvRzuf7tn5RWj/eC2gUMmwXL/PiWNApu+Q/juiaBmXRLFSsimVQ38OF61FJ rfdX02APWVSu9h7AHUzwm5zaRa/xHy+LavYUq85STVS8tRbhXbvcOvIeUWVZFYSsVPQh A3vBE56egCgvkctn6J6+R2d5infGQCzFWbqJjxMpN3MTm+tjbX3es77kquDirrGlGhYQ 99LBde4PEQukirfHEU7eg7QhUgPOGYHOI4VLZc8uOvN/nVrZAh8RHZg1dk4gQ1lKv+6c x+IQ== X-Gm-Message-State: ABUngveYbjCv+jdSxs3Jc2kCZTjCi8RMng4c6Tk60GGFCPMKV1iPSe/pRkwgs0Sac3qHj0qzq0Hgq/xp3xbE3g== X-Received: by 10.36.103.201 with SMTP id u192mr2116621itc.3.1478272287276; Fri, 04 Nov 2016 08:11:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.115.90 with HTTP; Fri, 4 Nov 2016 08:11:26 -0700 (PDT) From: Tim Polk Date: Fri, 4 Nov 2016 11:11:26 -0400 Message-ID: To: Saag@ietf.org Content-Type: multipart/alternative; boundary=001a114aa5469081bb05407b16d2 Archived-At: X-Mailman-Approved-At: Tue, 08 Nov 2016 08:20:04 -0800 Subject: [saag] Provenance of Diffie-Hellman groups in RFC 5114 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 15:15:00 -0000 --001a114aa5469081bb05407b16d2 Content-Type: text/plain; charset=UTF-8 Folks, The three Diffie-Hellman groups included in RFC 5114 were originally used by NIST to create test vectors to validate implementations, nothing more, and certainly not as a recommendation for people to use or adopt them operationally. We were not at that time concerned about trap doors in test vectors since we did not expect operational use of these groups. For operational use, traceability of generation is an important best practice. After some searching through our records and old source files, NIST cannot determine specifically how these Diffie-Hellman domain parameters were generated, although we think that they were generated internally at NIST. NIST sees no need to standardize or recommend these specific Diffie-Hellman groups for any use other than testing. We believe it is important that the provenance of any critical domain parameters recommended or required by a standard be fully explained. Therefore it would be appropriate for the IETF to remove or deprecate any inclusion of these groups in an RFC. One final note: We suspect that these groups were included to provide an option consistent with NIST SP 800-56A and simplify validation under NIST's Cryptographic Module Validation Program. However, NIST has accepted other Diffie-Hellman groups, including several groups specified in IKE and TLS, programmatically for some time. Further, an upcoming revision of NIST SP 800-56A will formally approve the commonly-used groups specified in IETF RFCs. Vendors that wish to comply with IETF standards and validate their module under CMVP can do so with the usual IETF groups. Thanks, Tim Polk --001a114aa5469081bb05407b16d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks= ,

The three Diffie-Hellma= n groups included in RFC 5114 were originally used by NIST to create test v= ectors to validate implementations, nothing more, and certainly not as a re= commendation for people to use or adopt them operationally.

=C2=A0 = =C2=A0 We were not at that time concerned about trap doors in test vectors = since we did not expect operational use of these groups.=C2=A0 For operatio= nal use, traceability of generation is an important best practice.=C2=A0 Af= ter some searching through our records and old source files, NIST cannot de= termine specifically how these Diffie-Hellman domain parameters were genera= ted, although we think that they were generated internally at NIST.

= =C2=A0 =C2=A0 NIST sees no need to standardize or recommend these specific = Diffie-Hellman groups for any use other than testing.=C2=A0 We believe it i= s important that the provenance of any critical domain parameters recommend= ed or required by a standard be fully explained.=C2=A0 Therefore it would b= e appropriate for the IETF to remove or deprecate any inclusion of these gr= oups in an RFC.

=C2=A0 =C2=A0 One final note: We suspect that these = groups were included to provide an option consistent with NIST SP 800-56A a= nd simplify validation under NIST's Cryptographic Module Validation Pro= gram.=C2=A0 However, NIST has accepted other Diffie-Hellman groups, includi= ng several groups specified in IKE and TLS, programmatically for some time.= =C2=A0 Further,=C2=A0 an upcoming revision of NIST SP 800-56A will formally= approve the commonly-used groups specified in IETF RFCs.=C2=A0 Vendors tha= t wish to comply with IETF standards and validate their module under CMVP c= an do so with the usual IETF groups.

Thanks,

Tim Polk
--001a114aa5469081bb05407b16d2-- From nobody Tue Nov 8 08:24:10 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368FF1294CC for ; Tue, 8 Nov 2016 08:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 cqDEfk7A3jWZ for ; Tue, 8 Nov 2016 08:24:06 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 C6925129434 for ; Tue, 8 Nov 2016 08:24:06 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id l124so180810704ywb.3 for ; Tue, 08 Nov 2016 08:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vZeyKTISpyft3a2gPemHtSQrV0z+76tvEr80aCBZ36U=; b=EuO2vu2F797nfBTWbWcsj0Aon4lTLcuOYTODVi3rMMeXKDhH/p4RaT2akMW1REjpwK 6plLD8julm5fpCRbQmEHyD2/myN0OBLruVZHO8fBCtVM5mdBcGdmGScH6/4j1yYU4eMI vNmGPlQvazp1tqTvbBoaNObYFcBVvJmxTvSfPmRHJMhym551ReEhVY/keiNCrVelvVL+ bY/VhyhbpirEX+5MTm60pDRr72+cwnlSdPGl3ltOQOPiakVrxwZrFAQgpnPsyeFX2fLe Ft5d9ml2VcyddWdyeohX/1sdToV5IpILAc7LzqEny3pVMmo4xNVGXOFLBc1ltoQSJHE2 nWEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vZeyKTISpyft3a2gPemHtSQrV0z+76tvEr80aCBZ36U=; b=T2l6E0ftaOvpPP4/hOBdSm/WXI2Zbw7SEOrGsEqe0uBpyDCj1d9IJPGlOqxJhzFACt jB2d4JdVU8hSbPDQIlv+LAXpG4DfI8nVulbkOYDWhYUCY6hWMy2yJYEOHtDilTLBw8IB qfaH9p13bV5CIdJqwkm2snE65uWr+qTc2aeX0wie3tsaSPUm3yptuc+CShglTR1kTswN zZu9lRH8186LSxAC8f9W6Yo/v4ix9djDzb/+ChcAofXr7hAEt9Z174ubbDb4PFC6HcYT dWjicTXHwGL0xvfIiOYo9Nn5AccCdwZDhX6TepkRg3D44W8MlMUw/4CAMc7fGqqDWQT+ 2GIQ== X-Gm-Message-State: ABUngvcxBa/wk6QIxAaoBaH9mteTbonvQF87/B3chilZUizZ1Y7GuiFBbo+bY5J52TzSHiINJErFPey0UMlCZg== X-Received: by 10.202.237.7 with SMTP id l7mr8247049oih.152.1478622245963; Tue, 08 Nov 2016 08:24:05 -0800 (PST) MIME-Version: 1.0 References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <68453f17719b45a3afe0ee8607acd420@HE1PR9003MB0234.MGDPHG.emi.philips.com> In-Reply-To: <68453f17719b45a3afe0ee8607acd420@HE1PR9003MB0234.MGDPHG.emi.philips.com> From: Adam Montville Date: Tue, 08 Nov 2016 16:23:55 +0000 Message-ID: To: "Garcia Morchon O, Oscar" , =?UTF-8?B?QXJpIEtlcsOkbmVu?= , Keith Moore , "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a113d2d1aba4b690540cc91d3 Archived-At: Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 16:24:09 -0000 --001a113d2d1aba4b690540cc91d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Would it be worthwhile to add this to the saag agenda, or is there otherwise some session for discussing the plethora of IoT security related material? On Tue, Nov 8, 2016 at 10:04 AM Garcia Morchon O, Oscar < oscar.garcia@philips.com> wrote: > Hi Ari, Keith, > > indeed, the purpose is similar of the draft in the T2TRG is similar. It i= s > clear is that having a document in which we describe which aspects should > be considered is very relevant. > > We are in the process of further updating our draft -- comments are > welcome. > > Regards, Oscar. > > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Ari Ker=C3=A4nen > Sent: Tuesday, November 08, 2016 9:44 AM > To: Keith Moore; saag@ietf.org > Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for > Securing Internet of Things (IoT) Devices) > > Hi, > > Also at the Thing-to-Thing Research Group we have a draft about security > considerations for IoT: > https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons > > > Cheers, > Ari > > On 05/11/16 03:25, Keith Moore wrote: > > Stephen Farrell suggested I bring this draft to your attention. This wa= s > > a rush job as the authors just started talking about this last Friday, > > but it was written in response to recent DDoS attacks that utilized > > easily-compromised IoT devices. I'm sure there are missing pieces > > (I've identified a few since -00) and sections that could be stated > > better (like the title of section 2.3.2), but hopefully this is a usefu= l > > start. > > > > https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ > > > > Keith > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > ________________________________ > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby > notified that any use, forwarding, dissemination, or reproduction of this > message is strictly prohibited and may be unlawful. If you are not the > intended recipient, please contact the sender by return e-mail and destro= y > all copies of the original message. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a113d2d1aba4b690540cc91d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would it be worthwhile to add this to the saag agenda, or = is there otherwise some session for discussing the plethora of IoT security= related material?

On = Tue, Nov 8, 2016 at 10:04 AM Garcia Morchon O, Oscar <oscar.garcia@philips.com> wrote:
=
Hi Ari, Keith,

indeed, the purpose is similar of the draft in the T2TRG is similar. It is = clear is that having a document in which we describe which aspects should b= e considered is very relevant.

We are in the process of further updating our draft --=C2=A0 comments are w= elcome.

Regards, Oscar.

-----Original Message-----
From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Ari Ker=C3= =A4nen
Sent: Tuesday, November 08, 2016 9:44 AM
To: Keith Moore; saag@ietf.org
Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Secu= ring Internet of Things (IoT) Devices)

Hi,

Also at the Thing-to-Thing Research Group we have a draft about security co= nsiderations for IoT:
https://tools.ietf.org/h= tml/draft-irtf-t2trg-iot-seccons


Cheers,
Ari

On 05/11/16 03:25, Keith Moore wrote:
> Stephen Farrell suggested I bring this draft to your attention. This w= as
> a rush job as the authors just started talking about this last Friday,=
> but it was written in response to recent DDoS attacks that utilized > easily-compromised IoT devices.=C2=A0 =C2=A0I'm sure there are mis= sing pieces
> (I've identified a few since -00) and sections that could be state= d
> better (like the title of section 2.3.2), but hopefully this is a usef= ul
> start.
>
> https://datat= racker.ietf.org/doc/draft-moore-iot-security-bcp/
>
> Keith
>
>

_______________________________________________
saag mailing list
saag= @ietf.org
https://www.ietf.org/mailman/listinfo/= saag

________________________________
The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message.

_______________________________________________
saag mailing list
saag= @ietf.org
https://www.ietf.org/mailman/listinfo/= saag
--001a113d2d1aba4b690540cc91d3-- From nobody Tue Nov 8 08:36:10 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D7412966E for ; Tue, 8 Nov 2016 08:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 lQ1CTQHEgv59 for ; Tue, 8 Nov 2016 08:36:03 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE34E129577 for ; Tue, 8 Nov 2016 08:36:02 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7FA71E203 for ; Tue, 8 Nov 2016 11:51:49 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F1CDE637A8 for ; Tue, 8 Nov 2016 11:36:01 -0500 (EST) From: Michael Richardson To: "saag@ietf.org" In-Reply-To: References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Tue, 08 Nov 2016 11:36:01 -0500 Message-ID: <23469.1478622961@obiwan.sandelman.ca> Archived-At: Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 16:36:09 -0000 Hannes Tschofenig wrote: > We probably have do a bit of document scoping. Many embedded devices do > not run Linux since they have no MMU. I would like to have guidelines > that also consider those ~50 billion of currently deployed devices as > well. **Many** of the devices involved in the recent attacks *DO* run Linux, and do have MMUs. (I don't consider routers and cameras to be IoT, even though the press does.) The price of MMUs is coming down significantly. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue Nov 8 12:09:58 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D471295A7 for ; Tue, 8 Nov 2016 12:09:44 -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_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.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 WyyrWrukik1J for ; Tue, 8 Nov 2016 12:09:41 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43F2129DDA for ; Tue, 8 Nov 2016 12:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mTXQYey6QeAKN0tinantg3ombfMNbZyv4T7yzNRnDBU=; b=uFmXWQnW6PJwTvD9xOlLREz24GO+Oy54Z4jMCc/KGAbBmfBKYiHcT1Pi/4EA1JSQDAHDhzb5yXv1VrcYEnVvx8JDfaJbcvjaasE6cCT+Gddh+ABkNq7M1LoHDnK5s4Vq4HeqlbuiTmVIq2hphT7AMgP9zJTXup27/vwDqYVSJIU= Received: from DB5P122CA0002.EURP122.PROD.OUTLOOK.COM (129.75.100.208) by HE1P122MB0027.EURP122.PROD.OUTLOOK.COM (129.75.100.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Tue, 8 Nov 2016 20:09:23 +0000 Received: from AM1FFO11FD018.protection.gbl (2a01:111:f400:7e00::185) by DB5P122CA0002.outlook.office365.com (2603:10a6:20:2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6 via Frontend Transport; Tue, 8 Nov 2016 20:09:23 +0000 Authentication-Results: spf=none (sender IP is 40.103.22.100) smtp.mailfrom=philips.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (40.103.22.100) by AM1FFO11FD018.mail.protection.outlook.com (10.174.64.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.3 via Frontend Transport; Tue, 8 Nov 2016 20:09:23 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:4757; Count:53 Received: from HE1PR9003MB0234.MGDPHG.emi.philips.com (129.75.99.147) by HE1PR9003MB0235.MGDPHG.emi.philips.com (129.75.99.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Tue, 8 Nov 2016 20:09:22 +0000 Received: from HE1PR9003MB0234.MGDPHG.emi.philips.com ([129.75.99.147]) by HE1PR9003MB0234.MGDPHG.emi.philips.com ([129.75.99.147]) with mapi id 15.01.0707.006; Tue, 8 Nov 2016 20:09:22 +0000 From: "Garcia Morchon O, Oscar" To: Adam Montville , =?utf-8?B?QXJpIEtlcsOkbmVu?= , Keith Moore , "saag@ietf.org" Thread-Topic: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) Thread-Index: AQHSNwOffTjJvUZ5sUKd1X2HfG8cGKDPLvyAgAAUhVCAAAd3gIAAPofg Date: Tue, 8 Nov 2016 20:09:22 +0000 Message-ID: <013c0c1d5ba948b28702bb01449196ac@HE1PR9003MB0234.MGDPHG.emi.philips.com> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <68453f17719b45a3afe0ee8607acd420@HE1PR9003MB0234.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.117.102.182] X-MS-Office365-Filtering-Correlation-Id: e131ffba-0fdd-4ccc-f639-08d408132216 Content-Type: multipart/alternative; boundary="_000_013c0c1d5ba948b28702bb01449196acHE1PR9003MB0234MGDPHGem_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9003MB0235.MGDPHG.emi.philips.com X-IncomingHeaderCount: 53 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:40.103.22.100; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(7916002)(2980300002)(428002)(24454002)(13464003)(55904004)(199003)(374574003)(85714005)(377454003)(189002)(68736007)(93886004)(3846002)(2501003)(2906002)(102836003)(790700001)(97736004)(626004)(66066001)(6116002)(7696004)(2900100001)(2950100002)(4326007)(108616004)(7846002)(9326002)(586003)(107886002)(87936001)(84326002)(356003)(230783001)(81156014)(81166006)(8936002)(189998001)(8676002)(7906003)(5001770100001)(101416001)(7736002)(4001430100002)(86362001)(33646002)(69596002)(50986999)(5660300001)(24736003)(512874002)(76176999)(54356999)(106116001)(106466001)(92566002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1P122MB0027; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM1FFO11FD018; 1:v64pVAlHCOc8VQb2ZrFb86HsRv2wyRAF/QxZmWEtuMbjL1/cC6bMKMGMI3R+ne8zVu7y83K6eDWwTVLe0IfF88rno35fzJKGjsF8/yatURVMqSx7cunn5jBhcM+4Q4oCqu5Mvt3CL5aiHwLhB1Z+dE48AIe6i4g4gbUNsNBbKdlx3HMqUAceHE0EPbJmp/F6oKf2x3N3oBhLNKB7x1F8YAwh/6oocYAuwz/2tV/oExXRUpZdgkZzAPZbHWABW34PxZ/ml9jCCfCEKWq478Cuo6+Jjvp31RHzvSLAa7tozRNAnXnmQyc9iFkk/5OqWz+aSuqB4nW/E1SZ0cQxpflU9IRaE9CFAVGfp6kfrEWDhCLfID9WJIeEjyMQsZ41EyE/IRj7uZR6amSxyGI0fZkvTI7NcLx093laKZK2IPmWN6fIgmMsCMfR/cvIR8rPa5hb3PNE4Qtt88raNp/7zWBfDKLV5CLsxTZNTlGSNT4hTD8dMZIb1OUfUtsAwUgL8XuenUZPrE/VRj3M1ZLLmGwzGQ== X-CrossPremisesHeadersFiltered: AM1FFO11FD018.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0027; 2:Uh0UMEkaWO8jnhv0XNkYj3vhBmiPQ5CsgC0ovL0Y5Wh9QwzbbLFgtoBPii7mJSibF8Awly+lsik8NrFknojluGVdTPAWgXW+YlrooaRxy5j7yx0N1efSDman+xmoUtT1UjNReb7wpwjEXin94+SztoyqvFpGZKymRaAuYJNcoEDP2W4X5JJMLGH8qhC9euoLwdIfQx5uOSoN9uoGeY7HPg==; 3:U5Oxh4D/rFfFRnhMFBZzm7N1D9++YX5JTLoNxA3X51/iPZogINDaXppT9WZEwPo0pjncEnQpSGyHCjoLzklgZ7yVKl6Dsg86A7IeW6m6CycSdMpLxeZZ2LSM7TXufbWXQibCzE/ZAgHUdwlml72huIFCgzRargXCIRd9mNsylymXNs+JD7vl++qy/uvJI8EvXIT6EevAuz5wbTTaE4jHN6KXVyaqmgOhOOhWPX8niQLbmQClWxzyyCsk0tYxd6EN X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1P122MB0027; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1P122MB0027; 25:4aDdU2O/KrAJuoOaZEp9QyObJmsMIbvTot4PZqN4N?= =?us-ascii?Q?VV4sulxh6uOyXN/sKxn3o6rFeOSd1mEfw5OyvpTU9pma4JjMHumKnB3rm+OI?= =?us-ascii?Q?Wwj6LlEA3zT0iGhKnjwWRpY5m4RBHNvdmE8Gu/c/Crn3rS5k0JMmhIv23OSq?= =?us-ascii?Q?xaXYL2oZTUPQQqfWtyRaeMBSI/Zr6zvx1FHvC+YLCofUBVbDSB4Gv1qAzGPj?= =?us-ascii?Q?BnifBixxgWzdUZ69C6vxCxV0bM/xkF/CRMFnaE6a+G3R8b+8g+3ntNvMIY6H?= =?us-ascii?Q?mKKy3GH7MjrY+H2IFEcqNKoeETdO2KU9MDPFiCTClfXQZNzLPmTMsZbYW76i?= =?us-ascii?Q?LdukNfXQSNvqdnWOI+a8NPT7M/GII3cf2N6I7aQL1g1TP3kqGgHBlhBAN6Hm?= =?us-ascii?Q?vPMy03oHUkBvD7j3sU3PdWu70O2KKVcAXG1WWBCMHw7qK23/Kl3l79Ja07bt?= =?us-ascii?Q?97K4pk4gTvPTRQWJcNVvrQLKxfDrvELKr++ZJnNOkvErQSBMK5n/CSyK9oh+?= =?us-ascii?Q?SR9Efe9A+fs1uxf4qzONwTbCGV38nVkHcS5sow1nCdyfFR+JBNPeFg+XKDUw?= =?us-ascii?Q?je79/tgnkGXM2s/4AVOJYlRzuNQq4dN++gpRxbs87CQLjGYir3ZTctR+MXSP?= =?us-ascii?Q?zPn9mQtpbficlZIyHuH9Bm3ofKxf6guq7p0ELOO4X/368aAPDCxecRhRnLDi?= =?us-ascii?Q?phs25ZJ8+NrkpkLNwV40TQX93qQkWTJLwcr4JsbNGRbcvp2UfDtxQw0noFpa?= =?us-ascii?Q?saJaeCDhh8L2QSLF52qaMI9Pmibm5enNhBfwTihsxmIV9M1lI3kgGkk7Yc0O?= =?us-ascii?Q?TwT46WjuZq1otFrrssmxIfq4kY/l0qc2boYU/gqqu3iqJdKu6T8muZM9KgMF?= =?us-ascii?Q?fH0NH9kkJG13KY/5WuoYnrADa8uFJOfXXn9kj/p1H7frYCAIIL2RVXwRCo2I?= =?us-ascii?Q?baweGkdAfI5hcftat03/WR6j2cMUatt0gs7dWZgbpZzpvxmhibtClQ5r4iiU?= =?us-ascii?Q?/fwaiO8pTsAvFoo6/c2t6m+j4qn+uFP5Hu5bk/hPSz19ytltnNB6h8/QCDst?= =?us-ascii?Q?NzPHOJ0nDr7d4eZ1v24cVdmkyc9?= X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0027; 31:3Gxjl1alSyJS9r2rnQ93AGNDcs+qGM2pkXbFl/5WVFYihGTHRTBI+Zjmltc35ScvZ4DBdhRAvwu7/mojEVcJV97YDlQWDFuK+wJF5pGd9t7qjoH9zvKb4fmdZMwqmZ+WNs5BE7tvHShrXip68yXYlUrdH5a4Ar37mkvh//e8lAywnbPxG8uN7TEsUeRMU1u+1Ec8h6zOzm2amcBPpGbXyeldynPw/IM5I7tIRa2c5UEDhAHboL2/oFBVNpOju5TBEmYnQ2A33CB6a9Uy6eStpg==; 20:duq5Z4UOgntfu8yPIYbPKyyC9NNUY9mQ5ZmPq/Ek7dpyVcEro0ghND4kTsQwL5iTkfWtn/L5LjKWy0awtA04whYhLpDyycRVn/MU6T78B8ybuLn1KbEwHPCSatik7DkdxpHX0lKXoZLKdX1zBHbarYPLxigNxY9UmdJR8I9zjGDqwEUOlZs+GBvIuX/EZcLAg5+IAtqlMxUrgbrB3/ENQ00lUtKdNjNs+op7CtCUKPsPURNh/LCklPvpBS71NIkiagobKddLWGjUCPs9GQ4vTrRphzZZDzViVEN2ldFZW0kFv2vUKaEERBiJKGw35gx+xNPednQpakjnwEwdhU29cl/4Lv4aFs2y4cpQkUSkE59cn2q1sFVhlvRG/SDavQRC8rDVht2rUezgsKolqDHReM1WYa+xp4you4U8SFjaf+a7thvN2xv7nJTIt1w+3W/OCI0TNbljTcoN0dnIcR3Yn0GJiTCFlWod8GdzFEF7ZdZFipoyx3xOFfwjVoaECgGk X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705)(21748063052155)(260087099026482); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(13018025)(13016025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:HE1P122MB0027; BCL:0; PCL:0; RULEID:; SRVR:HE1P122MB0027; X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0027; 4:vRhY6la0UtVdjNNlPgkSTiRNt9cssfiyOicvPM9EwEgMXAeAPzFCf9Eh6o6bvj+4mw8+7WcL1Qp0GTboVO6vuhdbRxuqFiyjHdw609e+KJ/CnhsekLUQoK65d1LkYjV2uQZ5s2w8i1sOjfWoWl0hCVmwGEkV2hWnQWC+Jnk9JWuqmn+YamA20F0Cs1DhIjaodScre16tHEIgSgFQYWMafQQHvpgrG7qfqTZyyUz1HhIQJOHejpseb8JEWeyPBoaO6NjwciJkFZV2ojuwLsICs2cxkWNoGVmlHi2a9Z/FLVAW9Wl2DxwnsdgZppbYtRkTm+4cLB+f4ux1DPRYhGRJhfUDjKdvVenRRhmozaOg/hgsntaAKH8z0T6nXMZwxwkE40eCoZD5uobWT5gCEut8bk3cBjsVEG3objlG82cBDXFR/3CKjJ8Wb6WuMYNHyF85XtuHBWwQHrCRGqFhVqDhBJ8CKqhM+1+hGWmPzKWefqRIJY74ajPsaj0ufx6QYSyvE2yQZ6dMH+EqZ8sJBIZY3N4rgKpR6W5vaF2ljO/6DnGsi++9TSMmw807J2uPVYEn/lMk4uhm56IfyiHAnIJKlA== X-Forefront-PRVS: 01208B1E18 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1P122MB0027; 23:PfGbcPVaG//TX+69USpEKuJx2JPej2612mZM7HCRW?= =?us-ascii?Q?a5JKJnTd9XaHmOSWPdw228RMrwsafb5vzHzjBY00hGpb+jhDXlyi9TfPvGyM?= =?us-ascii?Q?zzXA2rGLj2zt9aIYQq1lrK1Z2yP/TIN6qug3JUFfQH8qIxiWFnhhkokrtL3h?= =?us-ascii?Q?jtyRwM1IX4LByMF96XUfz1P/gVMsZkv4wwI+sIqwxXCzqKpJATeKMMrgPysf?= =?us-ascii?Q?a1SRXGIPCARdopsv9tY9bRsY7JBfM23kJ8y8NecIFObX5VMUHTqZeCHdfjqa?= =?us-ascii?Q?LU7crTIS8jmO20SN85CT9KNs8nwd41UrgdiiRsWtXIpMi5n/r6k0g+gGKzMv?= =?us-ascii?Q?DJGCoH0rwM6XtK2dZFdyD9BI3dqIWm5NvUHFsxdutQRQPar6H6iyflYmU5oN?= =?us-ascii?Q?s7oPm7TOnz7nyn1mrZavVGVsQucSg3sDZ9ru7Dlavs3EGcfLEdcyIvbWLgog?= =?us-ascii?Q?x6D55QMlPYuGSu7HQLdYw109pLIQF/gQJHHPmFe10M2KGdMIcYy60tXehEG+?= =?us-ascii?Q?IyjIKkvc3vVID7hRfBolcJVfjkRhTI/bz9HQno6RGD07v26G2WpMJagu4sM5?= =?us-ascii?Q?bVqmXxq+3o5gLF1Y+OfzuIxlmk2lLPux75mP/+N9tt9UrpvfFn8fGZzCG/9L?= =?us-ascii?Q?pe5dG7zEjZlfm75MLMBCp9rekvfEVUgAHbxipojWjjqQHd6GD/BACEatCFoW?= =?us-ascii?Q?5j8euYt5fFj+LiBVdCSZ/6DS3xuxNkCCydwlg+mCmwnsKiDhhHdJlfeEzPBa?= =?us-ascii?Q?Pe4BUGE1cVauix9c1i9o4l3gqcm7intoOo2/U+B2kJ83meJ8FTtQP/IkAH/1?= =?us-ascii?Q?dzTy2LNVJqY9KGtSpMLsR24MJ3sJ3L9uu780F8tE/XnYTiC3cC/4gqK8IeZz?= =?us-ascii?Q?qIASLhbtdIAHFWMRamJYFex+9n+Zi9uyyMHR6h20t3lq4Nm7ByEuM0Ca+Wsx?= =?us-ascii?Q?xcpNxjcaN8nc8cqYTU/VH1IXfjSHVCA5RW3ijn8/NK0/vRpnwmSLyKCoOzOb?= =?us-ascii?Q?I3XA2l/rNGBGREQKTIXJN08T5F6kfT2jy6tST0+OSY3yf3uMk//63WB//bnD?= =?us-ascii?Q?7VwmPpPDqKfIhRkHIjQwPjHqLjPEmZ7drEkD4f3VOF5Z8ZVGzADH1SmNxh9u?= =?us-ascii?Q?yShS4bXL/0/oLgabgMH9c52Jmy/TQdtdcMhlQJJjkhuJmO6PVUlYXredNoeT?= =?us-ascii?Q?CGO/9wU/A8jPI3PfeRJwOelFNJm9+ldhxqjxgvnf0T3zbGX7Uh4fA+aBhG1Q?= =?us-ascii?Q?QQw3oPgRFntCi8J037WhOht23ANTRNnJ+vUVAvtFfJIplEh8m7MS6TrJNBKu?= =?us-ascii?Q?fkR7ttlxdz9eAkxKWrt/28bzG/cOTN6Qg7LjSaExIbtAi3L8X3a2hCNOTNUw?= =?us-ascii?Q?jK2OUu+c8HdqWNBY7mmwFPq07UocNalVAX3KENmCQqd50UE?= X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0027; 6:ipIf29+E6GTbsmYtHZ0A5CJAVpZVNA2zes3FePWNXUWeYH/DRdeIvJZeNf9mwSkwAVfukNq8F4PnXqQVhNguldJC1vw6aqTHCQOozPt2dDQD39eGuc7Nom2jY2o3cTrBUr5hOlRL10s6Gm7vP8ZQkWalBPkNUsyaGlqcjN1aFOk/N/1XQdG+sNgNNqzr4vxIdX4P+zKyJuZWP5ySfvVRwE/tvb3aWLkEEat+nVN6SGaTQYCYExMV33EoAplBLimhWPdYwuXtXPErl4lpunTZ48D/U4XiQXJSMTCqzc1jkUrlb5J505tJz5etm31Vz3xr+g/qzKlbFPn4UXSQPH3iW3IPw+csMCD6h5gqvEWerAY=; 5:vEoBYBobTzdTV/dTjPRDfBkfxq+LPCly7EDN5ofEKpRptDqzR5srFG8VWl70EPPFf0EMeYeqlL7QjPpZHfdwfEX56HfrP2rhpfaRPnSqOFPqs+CwGL1GT+Aaqv9VrZvfOiI/rM9woxbblL6khDEHYg==; 24:yjVlY8br3/YpmEB9qBEhXVOU/odC8C808fFs+p7MS30KAuiYha3dhcE+B6hWeAyV8bxAzd6egXGNUcaUVAYDD3+tx5IuGTEwspaHVO01PWo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1P122MB0027; 7:oYBFrjlfSsoTwDma5itkxm0EaL7r7eFrLj/uhxlL5lQtBzN2JPao4oYVWK6gZJX6yQG3Kxikf2eOYGFwHqtYH3BQrvOKqDmeB5uipMObC8KMiBQ4HJ9pQmY/dPUXx6Me/KSzZehNjUswy7sVwgKWjcFSNQBaQHlPyKcuPh+xs5eW3//ttorUSrhSeM8eAFLMA5Cu+XcoUHoZj5gXFTLi4Ig5b08Oow0nxwwN6UOnKFMOn3yB02YiqzAVgpB4XRHORy1VmjJw8LvYTqamQnvgYVT7cyS3AoB3M9BHdCKr4MHlJZGZ/SWuB9ZDUTF39SbWzWGuZ4p0x2sGC6IZH7+G0NmJ0eGc84kfPVofjR2s/WQ= X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2016 20:09:23.4633 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[40.103.22.100]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P122MB0027 X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 40.103.22.100 X-MS-Exchange-CrossPremises-AuthSource: AM1FFO11FD018.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: HE1P122MB0027.EURP122.PROD.OUTLOOK.COM Archived-At: Cc: Mohit Sethi , "Kumar, Sandeep" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 20:09:44 -0000 --_000_013c0c1d5ba948b28702bb01449196acHE1PR9003MB0234MGDPHGem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWRhbSwNCg0Kd2Ugd2lsbCBiZSBkaXNjdXNzaW5nIG5leHQgc3RlcHMgZm9yIHRoZSBUMlRS RyBkcmFmdCBpbiB0aGUgVDJUUkcgbWVldGluZy4NCg0KUmVnYXJkcywgT3NjYXIuDQoNCkZyb206 IEFkYW0gTW9udHZpbGxlIFttYWlsdG86YWRhbS53Lm1vbnR2aWxsZUBnbWFpbC5jb21dDQpTZW50 OiBUdWVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNiAxMToyNCBBTQ0KVG86IEdhcmNpYSBNb3JjaG9u IE8sIE9zY2FyOyBBcmkgS2Vyw6RuZW47IEtlaXRoIE1vb3JlOyBzYWFnQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3NhYWddIGRyYWZ0LW1vb3JlLWlvdC1iY3AtMDAgKEJlc3QgQ3VycmVudCBQcmFj dGljZXMgZm9yIFNlY3VyaW5nIEludGVybmV0IG9mIFRoaW5ncyAoSW9UKSBEZXZpY2VzKQ0KDQpX b3VsZCBpdCBiZSB3b3J0aHdoaWxlIHRvIGFkZCB0aGlzIHRvIHRoZSBzYWFnIGFnZW5kYSwgb3Ig aXMgdGhlcmUgb3RoZXJ3aXNlIHNvbWUgc2Vzc2lvbiBmb3IgZGlzY3Vzc2luZyB0aGUgcGxldGhv cmEgb2YgSW9UIHNlY3VyaXR5IHJlbGF0ZWQgbWF0ZXJpYWw/DQoNCk9uIFR1ZSwgTm92IDgsIDIw MTYgYXQgMTA6MDQgQU0gR2FyY2lhIE1vcmNob24gTywgT3NjYXIgPG9zY2FyLmdhcmNpYUBwaGls aXBzLmNvbTxtYWlsdG86b3NjYXIuZ2FyY2lhQHBoaWxpcHMuY29tPj4gd3JvdGU6DQpIaSBBcmks IEtlaXRoLA0KDQppbmRlZWQsIHRoZSBwdXJwb3NlIGlzIHNpbWlsYXIgb2YgdGhlIGRyYWZ0IGlu IHRoZSBUMlRSRyBpcyBzaW1pbGFyLiBJdCBpcyBjbGVhciBpcyB0aGF0IGhhdmluZyBhIGRvY3Vt ZW50IGluIHdoaWNoIHdlIGRlc2NyaWJlIHdoaWNoIGFzcGVjdHMgc2hvdWxkIGJlIGNvbnNpZGVy ZWQgaXMgdmVyeSByZWxldmFudC4NCg0KV2UgYXJlIGluIHRoZSBwcm9jZXNzIG9mIGZ1cnRoZXIg dXBkYXRpbmcgb3VyIGRyYWZ0IC0tICBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KUmVnYXJkcywg T3NjYXIuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzYWFnIFttYWlsdG86 c2FhZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgQXJpIEtlcsOkbmVuDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNiA5 OjQ0IEFNDQpUbzogS2VpdGggTW9vcmU7IHNhYWdAaWV0Zi5vcmc8bWFpbHRvOnNhYWdAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NhYWddIGRyYWZ0LW1vb3JlLWlvdC1iY3AtMDAgKEJlc3QgQ3Vy cmVudCBQcmFjdGljZXMgZm9yIFNlY3VyaW5nIEludGVybmV0IG9mIFRoaW5ncyAoSW9UKSBEZXZp Y2VzKQ0KDQpIaSwNCg0KQWxzbyBhdCB0aGUgVGhpbmctdG8tVGhpbmcgUmVzZWFyY2ggR3JvdXAg d2UgaGF2ZSBhIGRyYWZ0IGFib3V0IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBJb1Q6DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0Zi10MnRyZy1pb3Qtc2VjY29ucw0K DQoNCkNoZWVycywNCkFyaQ0KDQpPbiAwNS8xMS8xNiAwMzoyNSwgS2VpdGggTW9vcmUgd3JvdGU6 DQo+IFN0ZXBoZW4gRmFycmVsbCBzdWdnZXN0ZWQgSSBicmluZyB0aGlzIGRyYWZ0IHRvIHlvdXIg YXR0ZW50aW9uLiBUaGlzIHdhcw0KPiBhIHJ1c2ggam9iIGFzIHRoZSBhdXRob3JzIGp1c3Qgc3Rh cnRlZCB0YWxraW5nIGFib3V0IHRoaXMgbGFzdCBGcmlkYXksDQo+IGJ1dCBpdCB3YXMgd3JpdHRl biBpbiByZXNwb25zZSB0byByZWNlbnQgRERvUyBhdHRhY2tzIHRoYXQgdXRpbGl6ZWQNCj4gZWFz aWx5LWNvbXByb21pc2VkIElvVCBkZXZpY2VzLiAgIEknbSBzdXJlIHRoZXJlIGFyZSBtaXNzaW5n IHBpZWNlcw0KPiAoSSd2ZSBpZGVudGlmaWVkIGEgZmV3IHNpbmNlIC0wMCkgYW5kIHNlY3Rpb25z IHRoYXQgY291bGQgYmUgc3RhdGVkDQo+IGJldHRlciAobGlrZSB0aGUgdGl0bGUgb2Ygc2VjdGlv biAyLjMuMiksIGJ1dCBob3BlZnVsbHkgdGhpcyBpcyBhIHVzZWZ1bA0KPiBzdGFydC4NCj4NCj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbW9vcmUtaW90LXNlY3VyaXR5 LWJjcC8NCj4NCj4gS2VpdGgNCj4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNhYWcgbWFpbGluZyBsaXN0DQpzYWFnQGlldGYub3JnPG1haWx0 bzpzYWFnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z YWFnDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5 IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRp bmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBl LW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhYWcgbWFp bGluZyBsaXN0DQpzYWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnDQo= --_000_013c0c1d5ba948b28702bb01449196acHE1PR9003MB0234MGDPHGem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBBZGFtLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+d2Ugd2lsbCBiZSBkaXNjdXNzaW5nIG5leHQgc3RlcHMg Zm9yIHRoZSBUMlRSRyBkcmFmdCBpbiB0aGUgVDJUUkcgbWVldGluZy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsIE9zY2FyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWRh bSBNb250dmlsbGUgW21haWx0bzphZGFtLncubW9udHZpbGxlQGdtYWlsLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxNiAxMToyNCBBTTxicj4NCjxiPlRv OjwvYj4gR2FyY2lhIE1vcmNob24gTywgT3NjYXI7IEFyaSBLZXLDpG5lbjsgS2VpdGggTW9vcmU7 IHNhYWdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzYWFnXSBkcmFmdC1tb29y ZS1pb3QtYmNwLTAwIChCZXN0IEN1cnJlbnQgUHJhY3RpY2VzIGZvciBTZWN1cmluZyBJbnRlcm5l dCBvZiBUaGluZ3MgKElvVCkgRGV2aWNlcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Xb3VsZCBpdCBiZSB3b3J0aHdoaWxlIHRvIGFkZCB0aGlzIHRvIHRoZSBzYWFnIGFn ZW5kYSwgb3IgaXMgdGhlcmUgb3RoZXJ3aXNlIHNvbWUgc2Vzc2lvbiBmb3IgZGlzY3Vzc2luZyB0 aGUgcGxldGhvcmEgb2YgSW9UIHNlY3VyaXR5IHJlbGF0ZWQgbWF0ZXJpYWw/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiA4LCAyMDE2IGF0 IDEwOjA0IEFNIEdhcmNpYSBNb3JjaG9uIE8sIE9zY2FyICZsdDs8YSBocmVmPSJtYWlsdG86b3Nj YXIuZ2FyY2lhQHBoaWxpcHMuY29tIj5vc2Nhci5nYXJjaWFAcGhpbGlwcy5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIEFyaSwgS2VpdGgsPGJyPg0KPGJyPg0KaW5kZWVkLCB0aGUgcHVycG9zZSBpcyBz aW1pbGFyIG9mIHRoZSBkcmFmdCBpbiB0aGUgVDJUUkcgaXMgc2ltaWxhci4gSXQgaXMgY2xlYXIg aXMgdGhhdCBoYXZpbmcgYSBkb2N1bWVudCBpbiB3aGljaCB3ZSBkZXNjcmliZSB3aGljaCBhc3Bl Y3RzIHNob3VsZCBiZSBjb25zaWRlcmVkIGlzIHZlcnkgcmVsZXZhbnQuPGJyPg0KPGJyPg0KV2Ug YXJlIGluIHRoZSBwcm9jZXNzIG9mIGZ1cnRoZXIgdXBkYXRpbmcgb3VyIGRyYWZ0IC0tJm5ic3A7 IGNvbW1lbnRzIGFyZSB3ZWxjb21lLjxicj4NCjxicj4NClJlZ2FyZHMsIE9zY2FyLjxicj4NCjxi cj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogc2FhZyBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWFn LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQXJpIEtlcsOkbmVuPGJyPg0KU2Vu dDogVHVlc2RheSwgTm92ZW1iZXIgMDgsIDIwMTYgOTo0NCBBTTxicj4NClRvOiBLZWl0aCBNb29y ZTsgPGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWFnQGll dGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbc2FhZ10gZHJhZnQtbW9vcmUtaW90LWJjcC0w MCAoQmVzdCBDdXJyZW50IFByYWN0aWNlcyBmb3IgU2VjdXJpbmcgSW50ZXJuZXQgb2YgVGhpbmdz IChJb1QpIERldmljZXMpPGJyPg0KPGJyPg0KSGksPGJyPg0KPGJyPg0KQWxzbyBhdCB0aGUgVGhp bmctdG8tVGhpbmcgUmVzZWFyY2ggR3JvdXAgd2UgaGF2ZSBhIGRyYWZ0IGFib3V0IHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIGZvciBJb1Q6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlydGYtdDJ0cmctaW90LXNlY2NvbnMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0Zi10MnRyZy1pb3Qtc2VjY29uczwv YT48YnI+DQo8YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KQXJpPGJyPg0KPGJyPg0KT24gMDUvMTEv MTYgMDM6MjUsIEtlaXRoIE1vb3JlIHdyb3RlOjxicj4NCiZndDsgU3RlcGhlbiBGYXJyZWxsIHN1 Z2dlc3RlZCBJIGJyaW5nIHRoaXMgZHJhZnQgdG8geW91ciBhdHRlbnRpb24uIFRoaXMgd2FzPGJy Pg0KJmd0OyBhIHJ1c2ggam9iIGFzIHRoZSBhdXRob3JzIGp1c3Qgc3RhcnRlZCB0YWxraW5nIGFi b3V0IHRoaXMgbGFzdCBGcmlkYXksPGJyPg0KJmd0OyBidXQgaXQgd2FzIHdyaXR0ZW4gaW4gcmVz cG9uc2UgdG8gcmVjZW50IEREb1MgYXR0YWNrcyB0aGF0IHV0aWxpemVkPGJyPg0KJmd0OyBlYXNp bHktY29tcHJvbWlzZWQgSW9UIGRldmljZXMuJm5ic3A7ICZuYnNwO0knbSBzdXJlIHRoZXJlIGFy ZSBtaXNzaW5nIHBpZWNlczxicj4NCiZndDsgKEkndmUgaWRlbnRpZmllZCBhIGZldyBzaW5jZSAt MDApIGFuZCBzZWN0aW9ucyB0aGF0IGNvdWxkIGJlIHN0YXRlZDxicj4NCiZndDsgYmV0dGVyIChs aWtlIHRoZSB0aXRsZSBvZiBzZWN0aW9uIDIuMy4yKSwgYnV0IGhvcGVmdWxseSB0aGlzIGlzIGEg dXNlZnVsPGJyPg0KJmd0OyBzdGFydC48YnI+DQomZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb29yZS1pb3Qtc2VjdXJpdHktYmNw LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbW9vcmUtaW90LXNlY3VyaXR5LWJjcC88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgS2VpdGg8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2FhZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86c2FhZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNhYWdAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFn IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z YWFnPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIGNvbmZpZGVu dGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGljYWJsZSBsYXcuIFRoZSBtZXNz YWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZShzKS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh bnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLA0KIG9yIHJlcHJvZHVjdGlvbiBvZiB0 aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3Jp Z2luYWwgbWVzc2FnZS48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNhYWcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnNhYWdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zYWFnQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_013c0c1d5ba948b28702bb01449196acHE1PR9003MB0234MGDPHGem_-- From nobody Tue Nov 8 13:12:25 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B8C129DDB for ; Tue, 8 Nov 2016 13:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 fj7Rg6ALnQeE for ; Tue, 8 Nov 2016 13:12:22 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 4CED7129487 for ; Tue, 8 Nov 2016 13:12:22 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id a197so270609444wmd.0 for ; Tue, 08 Nov 2016 13:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=biJeMRRYH7nt9jjMXE22ktm71q7uceUKdByigISJRGc=; b=aOvCaqRjrgnozQJ2mDbdNOzTuWjStQcmYZgBRW2wLXGsrhgjlAT9cGvoZAIlIGBz+4 xo0oEgxVj/VvGoOnLauSxDGuZGdlnG4R6pfhsxFyMnrLEEly3+p2aQrctBfgouDV1KOH 5blWYhzCZm94AknhraY8kcE1snsnv5GExLb9AddUqgiSFmd+eCFtTmWdHNsintJ1qq4z coQmzTNBqC1/mNIxYQFSpFzG4Ef0wWDcKngt9DPn9tL1V63HvD6bQfPoZctpFFcCyK21 s5Kzq6+omwl4kJWyubtMFTP7rQXsUmH3xaOrUNK7ViAySwCkMbbrdR+okC6Ao9c6dA/z NoLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=biJeMRRYH7nt9jjMXE22ktm71q7uceUKdByigISJRGc=; b=CMxbN5AK853QuR78/B0/gKthH32oqwLGuEUFPIbbvcXGJYsPpHe4qtyVEmSpGIx0Ew oducAgYfie8Ys7B/Z3Nu9g2JwH+C3WP/bwgYUNhdJj/dHdNHTCbcEGh/NGqfBWsDK7mf 86eI8gFsmW9K9CGhLXfvAK21D9imUDE2H8rWiEJzRRD4qYQl589j1d2WcUMbIEPE//2n xCErfni93ePWaOjvGPOgL+/4PCdN+UgMd0BG166Ly9Aot9WU4l7YbopGMnG92JJLWV6R 2r+3E1EwFH0kHR2JtAXxTPJzSA7VQsivY2RbJanfMEMWXQkPTBS0UmPLPDGxUkrk8yNl wJ3w== X-Gm-Message-State: ABUngvei5Kjv2Mk5GnUGvpXPIF/NAZ2IcPFleavML9seESREjuK4dL1wlzFU9rb3IDVJ91i1JQJNQNvUXRijaA== X-Received: by 10.28.131.1 with SMTP id f1mr16259736wmd.43.1478639540636; Tue, 08 Nov 2016 13:12:20 -0800 (PST) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.28.68.66 with HTTP; Tue, 8 Nov 2016 13:12:19 -0800 (PST) In-Reply-To: References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> From: Ben Laurie Date: Tue, 8 Nov 2016 21:12:19 +0000 X-Google-Sender-Auth: CoaIPotqto9Xhu2jElh5EggCOBA Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 21:12:24 -0000 On 8 November 2016 at 15:02, Watson Ladd wrote: > we should recommend memory safety as the easiest > way to prevent RCE. If only that were true. For example: https://access.redhat.com/security/cve/cve-2015-7501 Apparently memory safe languages evolve in complexity until they also allow RCE. From nobody Tue Nov 8 13:17:45 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372D8129AB7 for ; Tue, 8 Nov 2016 13:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LJ8oONFOExBw for ; Tue, 8 Nov 2016 13:17:42 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 DA2EE129493 for ; Tue, 8 Nov 2016 13:17:41 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id a197so270840744wmd.0 for ; Tue, 08 Nov 2016 13:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gETlr5MpW/Shw2Moohb35BZAHRFD1Dcyx4kGueirqHc=; b=t94Kkkn8r2RDGpJHkl2Pinyaedwi5uKegBqAwSlhM+nqf3kun7te3tKhTvfdljZSn1 VWxO6ejpXd7Jwj6ZPadHtotdkGFkmIPQ0OcE8oHdz+p2S7EdodPfo5PhNpgFm/d10k9m ABOZ3wcK7noWEpfQuw9zEYGnNzBYzcM/LBUUOCSu3E9BVcX1AKPnDghQ187DFCOQjkv/ Upb8lAY+La0nVIsIrlV6IFbNZk1Xad1OR3HVEituFavHS/yI4usbZTYrP7Wjf4FCLSrK 8tFqfJRZAkNgvPtyKECyO9dMaL3hL/7X9aKmzzHLR4zmzMMUuoIh8evUCp1ZjeOVaJWN iGjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gETlr5MpW/Shw2Moohb35BZAHRFD1Dcyx4kGueirqHc=; b=dyn+9eLyQbOZ8z8Xi308fGezJCaUnII2vKPbEBK/JYRnYWDj3LqU2yZ+seqHug6U5m DPkapgi3cAmPYcepAp3rK/tzkNKl7WkvCWVTtbBJCTzhxVHg0tHV9Yhmsvp3kUWhJhZd j2LiwpLS2H7Kaz5TlwlQNBNrxNNOAvzJMfJJG2kuuFgQPAnmQg9qmk0iFJunYgRvKe8y R2KYoWB5ea6rSsVhwgPLCvZnpBHzzZyunZHFABBrkUGsYMncgPkBFnhSZj4LaMgIbo/Z 17m1U1GVo0No/S+OiikyyO87fd2evEh0JmZW78jWq0tjx8z6a6JtuuSWcvMwDvFBw86C sLpQ== X-Gm-Message-State: ABUngvccKaPY3rLlOeDh9JV4r6IyKZaj4tSSRAo60c8YQk9Q2umo9keQ7fIuWpxF+JuN/zBvvY4yXXsJ76bRLQ== X-Received: by 10.194.14.196 with SMTP id r4mr15302995wjc.54.1478639860399; Tue, 08 Nov 2016 13:17:40 -0800 (PST) MIME-Version: 1.0 Sender: benlaurie@gmail.com Received: by 10.28.68.66 with HTTP; Tue, 8 Nov 2016 13:17:39 -0800 (PST) In-Reply-To: References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> From: Ben Laurie Date: Tue, 8 Nov 2016 21:17:39 +0000 X-Google-Sender-Auth: WnmxDRK8W51BIbG_IjkGjlRssjI Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 21:17:44 -0000 On 8 November 2016 at 15:02, Watson Ladd wrote: > On Mon, Nov 7, 2016 at 11:42 PM, Loganaden Velvindron wrote: >> >> >> On 11/5/16 5:25 AM, Keith Moore wrote: >>> Stephen Farrell suggested I bring this draft to your attention. This >>> was a rush job as the authors just started talking about this last >>> Friday, but it was written in response to recent DDoS attacks that >>> utilized easily-compromised IoT devices. I'm sure there are missing >>> pieces (I've identified a few since -00) and sections that could be >>> stated better (like the title of section 2.3.2), but hopefully this is >>> a useful start. >>> >>> https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ >> [Speaking for myself] >> >> That's a great start. >> >> Can you please consider adding section 2.6.3. Sandboxing techniques >> Device firmware SHOULD be designed to restrict processes attack surface >> by isolating them in sandboxing, in addition to privilege minization. In >> case of compromise, the attack surface is significantly reduced, >> particularly in the case of privilege minimization. >> >> [I'm thinking about OpenSSH and Linux seccomp-bpf sandbox, and also >> techniques like OpenBSD's pledge] > > Does OS sandboxing actually work? > > Real attackers attack. That means they have carefully studied the > system call interface of operating systems to find bugs, which they > can use to escape from running arbitrary code to violating all > security properties. They don't break the sandbox layer but exploit > the kernel instead. Nothing works perfectly, but sandboxing is not completely pointless: it reduces the attack surface, including (at least for some sandboxes) the kernel attack surface. Certainly seccomp-bpf claims this property, as does Capsicum. Also, even if we fixed every bug in the kernel, we'd still have security vulnerabilities in applications, which could be mitigated by sandboxing. Note that this is what the OP claims, not that it defends the kernel - which I agree is also useful. From nobody Tue Nov 8 14:31:10 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20070129AB7; Tue, 8 Nov 2016 14:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 v2O0p0RRmhXV; Tue, 8 Nov 2016 14:31:08 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC61E129A2A; Tue, 8 Nov 2016 14:31:07 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA8MUwYD030552; Tue, 8 Nov 2016 22:30:58 GMT Received: from 950129200 (248.206.189.80.dyn.plus.net [80.189.206.248]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uA8MUsxn030520 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 8 Nov 2016 22:30:57 GMT From: "Adrian Farrel" To: Date: Tue, 8 Nov 2016 22:30:52 -0000 Message-ID: <05c301d23a0f$c5f90f00$51eb2d00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdI6D0CAtZ8i+UmDQOyV9n81KQdOTg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22688.003 X-TM-AS-Result: No--5.417-10.0-31-10 X-imss-scan-details: No--5.417-10.0-31-10 X-TMASE-MatchedRID: 52PdSU396YIkEru8dDPv1a4lkQdsf0I6JdXjF5ArCFfjsTquy0JRi3C9 AyVdCQIh2zXv0ooOPsiMO9cHfks3twZeiTtfFXQ5dOc7KAdVCk4ZwC6xO3eE5UX5hc8ioB2+MQY WN5nDJFSrTeX6yrehf20JR9FhypxDlvnH+pxJKEq7vYqkCS0dL9aXm/w1hfBOS+D/9ULgnEyfgA 0BJtIcvWEun9a73A2SGPkZ+15TnmWSLsicvjCWX7420LFuMF+GJPNIV6GF8msCSZrAnTS0BlRcP yS77V9s4vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjOwBXM346/+xoQvZ/O/FJZybBqc1cz0xYkK8Y GWILN0ZDcGwnpFWbb8VbrNxagNKf Archived-At: Cc: sec-ads@ietf.org, 'Linda Dunbar' Subject: [saag] I2NSF status at IETF-97, Seoul X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 22:31:09 -0000 Meets, Monday 14th November, 2016, 15:50-17:50 Chairs: Linda Dunbar, Adrian Farrel Status * WG progress continues to be "steady" * Interim meetings were valuable for consolidating terminology and merging work ready for adoption * First WG drafts are now close to WG last call * WG has worked out which WG I-Ds it will not pursue to RFC * Chairs plan to reset milestone dates * No fights or massive contention in the WG Agenda and issues * Working Group Drafts status update - draft-ietf-i2nsf-terminology-02 Still stabilising, but making good progress - draft-ietf-i2nsf-problem-and-use-cases-02 Getting ready for last call - draft-ietf-i2nsf-framework-04 Needs another revision before last call - draft-ietf-i2nsf-client-facing-interface-req-01 Recently adopted * I2NSF Hackathon report Organised by Sungkyunkwan University * I2NSF Capability Informational Model - draft-xibassnez-i2nsf-capability Recently merged getting ready for adoption * Client Facing Interface info/data models Preparing for adoption - draft-kumar-i2nsf-client-facing-interface-im - draft-kim-i2nsf-consumer-facing-interface-dm * NSF Facing Interface info/data models Quite early work - draft-hares-i2nsf-capability-data-model-00 - draft-kim-i2nsf-nsf-facing-interface-data-model-00 - draft-zhang-i2nsf-info-model-monitoring * Other Drafts Quick posters for other work - draft-jeong-i2nsf-sdn-security-services-05 - draft-hyun-i2nsf-nsf-triggered-steering-00 and - draft-hyun-i2nsf-registration-interface-00 Adrian and Linda From nobody Thu Nov 10 07:26:13 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4AA1297BE for ; Thu, 10 Nov 2016 07:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7rfTzeMXa5Sd for ; Thu, 10 Nov 2016 07:26:10 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 300C11297A8 for ; Thu, 10 Nov 2016 07:26:02 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id x186so206073453vkd.1 for ; Thu, 10 Nov 2016 07:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c8wQztHG+aoDCqTlBnqRmw05RNfuyPsicLxtD5fXXBg=; b=OTaqLLU4DFOjvr5Wk4OQU4s8MqL2pnvHOgiV0ekmtkUbUqbFtNd4xEt+FcpyXdYp0E O3C3ORlpZq0RNr4jJcDprKz+vR3bjoZcSK6WqsphXPObJajRUnK9oIi6WAGR4DOtJKyl eFy+Kl2mPjjDHN1mvT0Fy3Rg2eZ0AlD34UQwiaUbSmqHtr+Zj4zaq0fPs3+tevujE0fE q3dpyAAv4vf4a53Goi0moFU+l8r8+lDpcvR+YYBIhXwsztdejV/z4LVIna0oQSfoLZBX YkNFkElmx9s2bb9iq4C4mP2CgCCmPKEmqVpLlLr0X2WqwayeTg1L549/b6ZhTdl22idQ yWyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c8wQztHG+aoDCqTlBnqRmw05RNfuyPsicLxtD5fXXBg=; b=TWzAVwF/2trJXhidvj8peF2Nbp6j2/hjddqFcE5RQcT2rSgpatMRhvxGcictgykFRK o0T7O9+l9jIx57VezI1+wCAwvVC0NDpobJcVQbfJGHUT50cJHK2nyEZE9HGF6aZf8hNi UCLRs/tz9We0eOB1Y/9yu+7Xp577lzkv55e6v098hDeWjJnvr6gm7QDiQY4VpnbqhZKn 6I3gftstqN08a9HiHQcQSeHne/PJBfvqN9WgIZazubCt11ulSF9OEi9paEDc0GTHZ/6G z+39jstH48NiTvrEejbzcGpkwdL5PYNNJg6y09nSRZY3TLB7GwE0SifFb6XV0ofczdup 7Eqw== X-Gm-Message-State: ABUngveBUZ2NtliU+/yM7v+QjKTvc6AicPHX5IzUn7JcBsY9vjBLsE1VEvxCnhtmYuhHN8XtmUnSETyyO8ZCNQ== X-Received: by 10.31.151.13 with SMTP id z13mr3904869vkd.41.1478791561288; Thu, 10 Nov 2016 07:26:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Thu, 10 Nov 2016 07:26:00 -0800 (PST) In-Reply-To: <6b0de3ed-fdcd-68a8-4af4-b9717e7b0077@ericsson.com> References: <1476749236821.94996@cs.auckland.ac.nz> <6b0de3ed-fdcd-68a8-4af4-b9717e7b0077@ericsson.com> From: Watson Ladd Date: Thu, 10 Nov 2016 07:26:00 -0800 Message-ID: To: Mohit Sethi Content-Type: multipart/alternative; boundary=001a1140fd58b5217f0540f3fd26 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] software update for teeny-weeny devices X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 15:26:11 -0000 --001a1140fd58b5217f0540f3fd26 Content-Type: text/plain; charset=UTF-8 On Oct 18, 2016 12:52 PM, "Mohit Sethi" wrote: > > Thanks for the pointer. This was indeed hilarious and sad to follow on Twitter. I think it highlights another important problem of bootstrapping/configuring IoT devices. At some point Mark has to run a port scanner to find out what IP address was assigned to his WiFi Kettle. > > But for his light bulb not working during dinner time, at least in this case I think he manually confirmed the firmware update. Perhaps the user can be better informed in future that the installing firmware updates may make the light bulb unusable for x amount of time. We've had light bulbs with the IQ of acephelic nematodes that when current goes in, go on and give light reliably. I expect that whatever intelligence is added to them, this will remain the case. > > Thanks > /--Mohit > > > > On 10/17/2016 08:07 PM, Peter Gutmann wrote: >> >> Mohit Sethi writes: >> >>> >>> For me scheduling of updates is important: I don't want my connected light >>> bulb to update at night when I am using it. >> >> So not this then: >> >> https://twitter.com/markrittman/status/785905327967498240/photo/1 >> >> (that was part of an 11-hour battle to get a WiFi kettle working). >> >> Peter. > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --001a1140fd58b5217f0540f3fd26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Oct 18, 2016 12:52 PM, "Mohit Sethi" <mohit.m.sethi@eri= csson.com> wrote:
>
> Thanks for the pointer. This was indeed hilarious and sad to follow on= Twitter. I think it highlights another important problem of bootstrapping/= configuring IoT devices. At some point Mark has to run a port scanner to fi= nd out what IP address was assigned to his WiFi Kettle.
>
> But for his light bulb not working during dinner time, at least in thi= s case I think he manually confirmed the firmware update. Perhaps the user = can be better informed in future that the installing firmware updates may m= ake the light bulb unusable for x amount of time.

We've had light bulbs with the IQ of acephelic nematodes= that when current goes in, go on and give light reliably. I expect that wh= atever intelligence is added to them, this will remain the case.


>
> Thanks
> /--Mohit
>
>
>
> On 10/17/2016 08:07 PM, Peter Gutmann wrote:
>>
>> Mohit Sethi <mohit.m.sethi@ericsson.com> writes:
>> =C2=A0
>>>
>>> For me scheduling of updates is important: I don't want my= connected light
>>> bulb to update at night when I am using it.
>>
>> So not this then:
>>
>> https://twitter.com/markrittman/status/<= wbr>785905327967498240/photo/1
>>
>> (that was part of an 11-hour battle to get a WiFi kettle working).=
>>
>> Peter.
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag

--001a1140fd58b5217f0540f3fd26-- From nobody Thu Nov 10 08:48:39 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7630912947F for ; Thu, 10 Nov 2016 08:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mrysnUmqRTqw for ; Thu, 10 Nov 2016 08:48:36 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 0CA8612995A for ; Thu, 10 Nov 2016 08:48:35 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id a197so379411606wmd.0 for ; Thu, 10 Nov 2016 08:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VanAtDR9NHqlEy35KDGJx8BZruO/tAcoyTgm3Zy3WM8=; b=RePqneaczlfY7puCpXLrnKdYrPE+8f2mB/8VSVykXddlVr1LqMaTIqpH7rKVCQorbW 3RXby6p/NTC1LWdpGSu/gVbA8Vqilld+LM0lbFJPP3fmLuMNEMV5gBuWiQmn+NQpKWSj 4Ox6JbZIPO9CI5vZqeGO3yeCa9pCJ6Q4JuklB4OdCfCdGMP5VutS/T/pW3Tk6P9df0bz r7mQ+4woGkAk481IIXyJCg9Iyz9+i6crDv9jvgTbtRRLb6cF33y8eJkBWZFAEedGIBW6 c2h6BXgM+pkT5FgahAv7p0f6VOZ+uh3lKuzZiFpGhmk+45cG3NaKDyFjtco5Ax9eOAdX p+DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VanAtDR9NHqlEy35KDGJx8BZruO/tAcoyTgm3Zy3WM8=; b=SeoQlbo3mDLaT4Dpc54BldXWe0AM4f5cqAoI6AOgknEKJhbfDVwpYScWXXpJE0K8ys tlVDgfXX8+HOm5mc0GMZUKvoo0ROgCGAvLO/MbR+Y5p3lQqYuVaeEQ68uK1q1CFjdfHg rCEIvcKfQFHJLAV6mRQDRUBTNkJMWRTk4qZaUPssCn/56RlbqsAo2yOIcgFABVQMQ7Pc Oy3oILypOciAl6iv9X1N1pfN4IOORvHzEJNHtyjyraULyXQjb+vy4zZl6Y+mpBghXvPO 9NY/XQmfTtczC3R7whZC3MuZWGH5UEaUfLeH/8HlPASGdfaVtDv6jEf0KpwX3P0glFDG tXZw== X-Gm-Message-State: ABUngvfhTV15+yqQEyXe3NcdIr81QujirGvQJ18qO7uPu1ztm/KNmmpeDXcw1S4X2I99Kw== X-Received: by 10.194.2.198 with SMTP id 6mr5998414wjw.51.1478796513498; Thu, 10 Nov 2016 08:48:33 -0800 (PST) Received: from [192.168.137.43] ([109.253.214.59]) by smtp.gmail.com with ESMTPSA id g184sm13903960wme.23.2016.11.10.08.48.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Nov 2016 08:48:32 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5E466F08-FAE9-4498-98C8-5AA7E4B493A1" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 10 Nov 2016 18:48:14 +0200 In-Reply-To: To: Watson Ladd References: <1476749236821.94996@cs.auckland.ac.nz> <6b0de3ed-fdcd-68a8-4af4-b9717e7b0077@ericsson.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Mohit Sethi , Security Area Advisory Group Subject: Re: [saag] software update for teeny-weeny devices X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 16:48:37 -0000 --Apple-Mail=_5E466F08-FAE9-4498-98C8-5AA7E4B493A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Nov 2016, at 17:26, Watson Ladd wrote: >=20 >=20 > On Oct 18, 2016 12:52 PM, "Mohit Sethi" > wrote: > > > > Thanks for the pointer. This was indeed hilarious and sad to follow = on Twitter. I think it highlights another important problem of = bootstrapping/configuring IoT devices. At some point Mark has to run a = port scanner to find out what IP address was assigned to his WiFi = Kettle. > > > > But for his light bulb not working during dinner time, at least in = this case I think he manually confirmed the firmware update. Perhaps the = user can be better informed in future that the installing firmware = updates may make the light bulb unusable for x amount of time. >=20 > We've had light bulbs with the IQ of acephelic nematodes that when = current goes in, go on and give light reliably. I expect that whatever = intelligence is added to them, this will remain the case. >=20 Certainly not. A lightbulb contacts either a server in your home or a = cloud service to ask whether it should let the current in or not. That = way you can tell it to turn on or off from half-way around the world.=20 And if you dare buy a competitor=E2=80=99s server to install in your = home, a software update will make sure that the bulb refuses to talk to = this server. Yoav --Apple-Mail=_5E466F08-FAE9-4498-98C8-5AA7E4B493A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 10 Nov 2016, at 17:26, Watson Ladd <watsonbladd@gmail.com> wrote:


On = Oct 18, 2016 12:52 PM, "Mohit Sethi" <mohit.m.sethi@ericsson.com> wrote:
>> Thanks for the pointer. This was indeed hilarious and = sad to follow on Twitter. I think it highlights another important = problem of bootstrapping/configuring IoT devices. At some point Mark has = to run a port scanner to find out what IP address was assigned to his = WiFi Kettle.
>
> But for his light = bulb not working during dinner time, at least in this case I think he = manually confirmed the firmware update. Perhaps the user can be better = informed in future that the installing firmware updates may make the = light bulb unusable for x amount of time.

We've had light bulbs with the IQ of acephelic nematodes that = when current goes in, go on and give light reliably. I expect that = whatever intelligence is added to them, this will remain the = case.


Certainly not. A lightbulb contacts either a server in your = home or a cloud service to ask whether it should let the current in or = not.  That way you can tell it to turn on or off from half-way = around the world. 

And if you dare buy a competitor=E2=80=99s server to install = in your home, a software update will make sure that the bulb refuses to = talk to this server.

Yoav

= --Apple-Mail=_5E466F08-FAE9-4498-98C8-5AA7E4B493A1-- From nobody Thu Nov 10 23:51:14 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A96129A26 for ; Thu, 10 Nov 2016 23:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 fxYCFdpCwGix for ; Thu, 10 Nov 2016 23:51:10 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B53129A23 for ; Thu, 10 Nov 2016 23:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1478850669; x=1510386669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WZ7RC00xrStbDD4nTubHze3i5Hy5rCbR2ZNoPbOob+s=; b=m9IpIZbMZgFCTFgpN2qdHrmoN7uuZ5alEVj6tlzhUx59pc7TeK7npo1c zmGMWU2UOVVQh65AWqXpknkTYoyJCFTDmG64RIHYgwSGq3zoZ/0DQS8q3 q0o+yFgobsl132a4A8IHLDCrAe6scZkFfEKP7UTvLYJHGlYgaBSms3k1m BRCZLNv5aeNSZpEYAubNCvdQ2QhZwtfNwZ2DGX+ujuMKGcqhmpReibG56 FA/ql41vlToSYofRhgDnwABdSfwu63yi3gkmW5cHgLGItpeIEq8VivVLD uxlcwDxuQkRdkET48VU56VoO5aadxDZGo5iR3y7wQIi3z07ZFagLM5HYA g==; X-IronPort-AV: E=Sophos;i="5.31,620,1473076800"; d="scan'208";a="114728896" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from uxcn13-tdc-a.uoa.auckland.ac.nz ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Nov 2016 20:51:05 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 11 Nov 2016 20:50:59 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 11 Nov 2016 20:50:59 +1300 From: Peter Gutmann To: Hannes Tschofenig , Watson Ladd , Loganaden Velvindron Thread-Topic: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) Thread-Index: AQHSNwOeEhudYcKwEki+rGU+A1iPFKDN33gAgAB68gCAAAH+AIAFFhzZ Date: Fri, 11 Nov 2016 07:50:58 +0000 Message-ID: <1478850654823.89451@cs.auckland.ac.nz> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 07:51:12 -0000 Hannes Tschofenig writes:=0A= =0A= >We probably have do a bit of document scoping. Many embedded devices do no= t=0A= >run Linux since they have no MMU. I would like to have guidelines that als= o=0A= >consider those ~50 billion of currently deployed devices as well.=0A= =0A= I think that would definitely be useful. We should distinguish between, at= =0A= least, desktop-PC equivalents (anything capable enough to Linux, in which c= ase=0A= just use any standard Unix good-housekeeping rules, you don't necessarily n= eed=0A= the same thing just with IoT stamped on it), and then real SCADA/embedded,= =0A= where you've got a single binary blob comprising the RTOS and the=0A= application(s) it runs, no MMU, and barely anything else.=0A= =0A= There's also a split in engineering terms between an Internet of=0A= Shi^H^H^HThings device (take the cheapest Arm-based reference design, shove= l=0A= Linux 2.6.x and equally old, unpatched binaries onto it, and throw it out t= o=0A= the public), and what I'd consider proper SCADA gear, stuff that's been=0A= properly designed and engineered, with environmental protection, fault-=0A= checking, and so on, something that won't break the first time you sneeze n= ear=0A= it, or that needs constant tending just to keep it going. IoS devices have= =0A= very different goals (cheap and quick, and if it breaks the vendor doesn't= =0A= really care) from SCADA (long engineering cycles, time to do it right but= =0A= often political impediments to doing so, and companies that have to stand= =0A= behind their products, often for decades after they've shipped).=0A= =0A= So the first question would be, how do you divide things up in order to dec= ide=0A= what goals need to be met, and what goals can actually be met?=0A= =0A= Peter.= From nobody Fri Nov 11 00:16:38 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793A9129A45 for ; Fri, 11 Nov 2016 00:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 gwAjRGuttkKN for ; Fri, 11 Nov 2016 00:16:34 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 89E8E1295DC for ; Fri, 11 Nov 2016 00:16:34 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id c184so58333550wmd.0 for ; Fri, 11 Nov 2016 00:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TMO2aLQ3fre9bRMsjpgnxAqXgznbswi/IxCkwwyqxQc=; b=E5/iwOgnN8EBleFVShx9DAu0b4/fODDHxpzdp4oi8d9DCT1tjwq+r7dKGUiiGWhEr2 Zvmy9j3vlCMn3+Us2YVFm6fhEF6rUjLH0rVv1Ln8VKJMVJUUstYmYhxzcbgNmTpPcko9 d+Nb3cGeeRKv+6NhRciJGtGnUZ5sy3qEJlmok= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TMO2aLQ3fre9bRMsjpgnxAqXgznbswi/IxCkwwyqxQc=; b=jXlUqXPzMN9TByTSRplzrC6AFyd4w+ArqsBlfbKbc9ZhehXZRV/cVRVMjzhIdcqTLd ZEuQA3IueQ00nvTKo0NltoBJGHR6LoZdMSIiXNyzbFWRqPqUGU6PuR7Y4wY3yHmpe9Fe 53b0GOAO83ChhMv0YSw3eIICChdQky4OvaukM7DNmaJFWomk9mrNBaRIH8ykeMfzXTMV nwbS9CAz0EaXnHUd7/8j6Mw/YoZ8Ltdjk932NpoXIN5AA4tQgsnsn5Xe01+0CO3jYvz7 /ZdG4EUsUikAfIU64rNDah9+w6kkYcDWMllRVzNz4DZxUlQvZXgJt83dj82ScPH0sIeD halw== X-Gm-Message-State: ABUngveLD1x0H0Dpg0KxkPY63Nn99C9pva/R2Mp4Al7OqDuQCDjCueP3mlvgFk8ISzC5yrHv1/f3rA3KvVl4jg== X-Received: by 10.194.105.104 with SMTP id gl8mr9120229wjb.83.1478852192938; Fri, 11 Nov 2016 00:16:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.115.6 with HTTP; Fri, 11 Nov 2016 00:16:32 -0800 (PST) In-Reply-To: <1478850654823.89451@cs.auckland.ac.nz> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <1478850654823.89451@cs.auckland.ac.nz> From: Adrian Hope-Bailie Date: Fri, 11 Nov 2016 10:16:32 +0200 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a1130d28aa2bf210541021bd0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 08:16:36 -0000 --001a1130d28aa2bf210541021bd0 Content-Type: text/plain; charset=UTF-8 How does your average consumer know if they're buying an Internet of Shi^H^H^HThings device or proper SCADA gear? Surely half the problem is educating price sensitive consumers about how to distinguish from well-priced good hardware and cheap crap? All the guidelines in the world will not stop people building crap to try and sell it cheap On 11 November 2016 at 09:50, Peter Gutmann wrote: > Hannes Tschofenig writes: > > >We probably have do a bit of document scoping. Many embedded devices do > not > >run Linux since they have no MMU. I would like to have guidelines that > also > >consider those ~50 billion of currently deployed devices as well. > > I think that would definitely be useful. We should distinguish between, at > least, desktop-PC equivalents (anything capable enough to Linux, in which > case > just use any standard Unix good-housekeeping rules, you don't necessarily > need > the same thing just with IoT stamped on it), and then real SCADA/embedded, > where you've got a single binary blob comprising the RTOS and the > application(s) it runs, no MMU, and barely anything else. > > There's also a split in engineering terms between an Internet of > Shi^H^H^HThings device (take the cheapest Arm-based reference design, > shovel > Linux 2.6.x and equally old, unpatched binaries onto it, and throw it out > to > the public), and what I'd consider proper SCADA gear, stuff that's been > properly designed and engineered, with environmental protection, fault- > checking, and so on, something that won't break the first time you sneeze > near > it, or that needs constant tending just to keep it going. IoS devices have > very different goals (cheap and quick, and if it breaks the vendor doesn't > really care) from SCADA (long engineering cycles, time to do it right but > often political impediments to doing so, and companies that have to stand > behind their products, often for decades after they've shipped). > > So the first question would be, how do you divide things up in order to > decide > what goals need to be met, and what goals can actually be met? > > Peter. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a1130d28aa2bf210541021bd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How does your average consumer know if they= 're buying an Internet of
Shi^H^H^HThings device or proper SCADA gear?

Surely half the p= roblem is educating price sensitive consumers about how to distinguish from= well-priced good hardware and cheap crap?

All the guidelines = in the world will not stop people building crap to try and sell it cheap

On 11 Nove= mber 2016 at 09:50, Peter Gutmann <pgut001@cs.auckland.ac.nz&g= t; wrote:
Hannes = Tschofenig <hannes.tschofen= ig@gmx.net> writes:

>We probably have do a bit of document scoping. Many embedded devices do= not
>run Linux since they have no MMU. I would like to have guidelines that = also
>consider those ~50 billion of currently deployed devices as well.

I think that would definitely be useful.=C2=A0 We should distinguish= between, at
least, desktop-PC equivalents (anything capable enough to Linux, in which c= ase
just use any standard Unix good-housekeeping rules, you don't necessari= ly need
the same thing just with IoT stamped on it), and then real SCADA/embedded,<= br> where you've got a single binary blob comprising the RTOS and the
application(s) it runs, no MMU, and barely anything else.

There's also a split in engineering terms between an Internet of
Shi^H^H^HThings device (take the cheapest Arm-based reference design, shove= l
Linux 2.6.x and equally old, unpatched binaries onto it, and throw it out t= o
the public), and what I'd consider proper SCADA gear, stuff that's = been
properly designed and engineered, with environmental protection, fault-
checking, and so on, something that won't break the first time you snee= ze near
it, or that needs constant tending just to keep it going.=C2=A0 IoS devices= have
very different goals (cheap and quick, and if it breaks the vendor doesn= 9;t
really care) from SCADA (long engineering cycles, time to do it right but often political impediments to doing so, and companies that have to stand behind their products, often for decades after they've shipped).

So the first question would be, how do you divide things up in order to dec= ide
what goals need to be met, and what goals can actually be met?

Peter.
_____________________= __________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--001a1130d28aa2bf210541021bd0-- From nobody Fri Nov 11 00:39:54 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1089A129A53 for ; Fri, 11 Nov 2016 00:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.019 X-Spam-Level: X-Spam-Status: No, score=-16.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 psvOnafkGXy9 for ; Fri, 11 Nov 2016 00:39:50 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E016129A5A for ; Fri, 11 Nov 2016 00:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2778; q=dns/txt; s=iport; t=1478853590; x=1480063190; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Z53enEh4u8MpUg7DoVUoH9Cz536QCaBHjPOktq2o33M=; b=BdVoBQPce40U73kl76nqDCvENY8I0W/BrRNlT3gLsiEZKQpK76bBzerl rpFqRL0p4CONA/pgV3HBdvzOr0L1y5igAab0ozCjPd0wrZTClYTKZcsyc Yu0ZXZEpBGhXXwHjPTMs7UswP/9Edzgc2e61+JBkdElO+EAOVr6JUwinY 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAwDZgiVY/xbLJq1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMzAQEBAQF6KaUclFuCB4YkAoJSEwECAQEBAQEBAWIohGIBAQQ?= =?us-ascii?q?jVhALGCMHAgJXBgEMCAEBiFuwIIIyi14BAQEBAQEBAQIBAQEBAQEBEg6IO4FVg?= =?us-ascii?q?QiHTIJdAQSIWJFjg0+BeosNiXuGIZFHIAIzZhELg2+BCjw9iA4BAQE?= X-IronPort-AV: E=Sophos;i="5.31,620,1473120000"; d="asc'?scan'208";a="689579304" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Nov 2016 08:39:48 +0000 Received: from [10.61.239.18] ([10.61.239.18]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uAB8dmCr022503; Fri, 11 Nov 2016 08:39:48 GMT To: Adrian Hope-Bailie , Peter Gutmann References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <1478850654823.89451@cs.auckland.ac.nz> From: Eliot Lear Message-ID: Date: Fri, 11 Nov 2016 09:39:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TmroTC3vNQt5FpjRg7foSTs8xC9LdQmsi" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 08:39:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TmroTC3vNQt5FpjRg7foSTs8xC9LdQmsi Content-Type: multipart/mixed; boundary="uPDGsqWVPuwEseESAjILT8qfNuESEn427"; protected-headers="v1" From: Eliot Lear To: Adrian Hope-Bailie , Peter Gutmann Cc: "saag@ietf.org" Message-ID: Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <1478850654823.89451@cs.auckland.ac.nz> In-Reply-To: --uPDGsqWVPuwEseESAjILT8qfNuESEn427 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/11/16 9:16 AM, Adrian Hope-Bailie wrote: > How does your average consumer know if they're buying an Internet of > Shi^H^H^HThings device or proper SCADA gear? > > Surely half the problem is educating price sensitive consumers about > how to distinguish from well-priced good hardware and cheap crap? > > All the guidelines in the world will not stop people building crap to > try and sell it cheap If we can make it easy for developers to do the right thing, or as much of the right thing as they can within their cost constraints, perhaps we can put some dent in the problem. I think that's possible with manufacturer usage descriptions (draft-ietf-opsawg-mud) when DHCP or LLDP are used. That addresses the base case where the device isn't infected in the first place, but not the case where it is. For that you need a mfgr cert. Eliot --uPDGsqWVPuwEseESAjILT8qfNuESEn427-- --TmroTC3vNQt5FpjRg7foSTs8xC9LdQmsi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJYJYPTAAoJEIe2a0bZ0nozrjIH/1Br6BXl2JNcUEqSfflLGEwc VCM0AAGlWM7LrXEkMRcpyM0DLLrygbPoHzI0QchcxImb2fqRjKgQ4RCbDI4NSZZX BDbAxpNMIR0K7ooOMXrCdyauO+IyHb9C++ar/E1LfYyp5HKnRPwoaadZQ9BkLKWB 3CyzY9NMrsk9M97ilkjwBuKJxfPt8GHeT5889O+OLKz5Ie8oYpHoDbqfZkd+jz64 u/GlCIRKmdMJX+2olxlD3alCmVUM5zGGOeuGhrIamhze+DxNAe4EMIax527PNAc0 g0r/TpslqFYDjF1e96Qd8m90YwmuZ92xnK/vAGh2htz33m8bhqnp6+PMac4sWbs= =v0/N -----END PGP SIGNATURE----- --TmroTC3vNQt5FpjRg7foSTs8xC9LdQmsi-- From nobody Fri Nov 11 01:00:18 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3E5129A79 for ; Fri, 11 Nov 2016 01:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 rOU7eAQHXJMR for ; Fri, 11 Nov 2016 01:00:15 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A82D129A53 for ; Fri, 11 Nov 2016 01:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1478854815; x=1510390815; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=p6BlcL+R/QraXup1rHz9f8HjIoBnUmPd3CIXa8iHlIY=; b=pBXJVZar4xXQHk8rtKx5qLbZzqidlHMAuXFZ64C6Z59djG6eYiRilLD4 +JEf/uodZmEcG1BiNYl6kZ7xPMx5p0CAg3TAR8I4+MBr8rfCg4fJc9Z6k Z5DfUxMPRiNK1hS84ScsjPBu3sBnaFACmZVZefXIB7mdlluST6ZpQqKnN 8vB3o4mylJLbCj5nUutbg6yX7cIJI++0uj3KM6woMvv/8H7hJq4t5vw6J Tdz6hIJZgExHv/Sr2qRtJgB3Qc74XBfUtTU6wb2TUEbCOmmLta0h1wDwI B2HW5k0j2Kb5nLHoCWkUVSDioOHTImWpmZN30EsFI3j9ONIPG4pnNaN2q A==; X-IronPort-AV: E=Sophos;i="5.31,620,1473076800"; d="scan'208";a="114733227" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Nov 2016 21:59:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 11 Nov 2016 21:59:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 11 Nov 2016 21:59:51 +1300 From: Peter Gutmann To: Adrian Hope-Bailie Thread-Topic: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) Thread-Index: AQHSNwOeEhudYcKwEki+rGU+A1iPFKDN33gAgAB68gCAAAH+AIAFFhzZ//8tWACAAOXljg== Date: Fri, 11 Nov 2016 08:59:51 +0000 Message-ID: <1478854787137.79505@cs.auckland.ac.nz> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <1478850654823.89451@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 09:00:16 -0000 Adrian Hope-Bailie =0A= =0A= >How does your average consumer know if they're buying an Internet of=0A= >Shi^H^H^HThings device or proper SCADA gear?=0A= =0A= If it's consumer-grade gear it's almost certainly IoS-grade equipment.=0A= =0A= >Surely half the problem is educating price sensitive consumers about how t= o=0A= >distinguish from well-priced good hardware and cheap crap?=0A= =0A= Not when you've got the marketing resource of an entire industry working=0A= against you.=0A= =0A= In any case though the point is to come up with a taxonomy of=0A= embedded/SCADA/IoT/whatever device types that represent typical use cases..= .=0A= =0A= Peter.=0A= From nobody Fri Nov 11 01:54:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33F71294FE for ; Fri, 11 Nov 2016 01:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 WpH01fRqCq_0 for ; Fri, 11 Nov 2016 01:54:10 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 A0220129451 for ; Fri, 11 Nov 2016 01:54:10 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id q124so48248838itd.1 for ; Fri, 11 Nov 2016 01:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=q+0+KMnhPWHZr7pEj7p8sWD7bVq1JfhEmXglui9S6wg=; b=kg3biNNuQ4J65eFzm9NuaXnX3P3IhttOHGHoSZA/RtyBt9EF4dzGpjEd1hvaQnHFtk 5F92dg8O9z58FhSBWKPeFH8xr8cf6SKUPgJCpjXZ0tF/h0JYGwGlhs5bk7MdyHE7X5hr O1xW4ekktv0t+YIdy00oF0Me2A2FKMnTGUPP85jdpQX3RNL4ngramYq+Np37U1A0w7Ph TwKmSurBbWrxH9NJCQTTN1a9JL1xWT1HRWMPwz5hOZZk1d2/7jxaJHixij+6mw/2w9Qw pccZ7CvrvsFWWJb0CEFbLsmygVJ8AonTTlmyWnt1GF8Omw0wAZvUGqWD/LeiitUZXgaX Pi9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=q+0+KMnhPWHZr7pEj7p8sWD7bVq1JfhEmXglui9S6wg=; b=mkeKFyg5SKpAVQYqLzxU4YbOiQWX1+Lff/E002Y1Zepgwx4uxurWOd7dsWrI0Yjeyz lvjuJ3v59ohn8lVRsvUd7XlWgOqzCazChcSdvM6yx5EV5PMW0oEXNxbL4vzdrWE60+SK bRrXhlHzQ67BUzqQInv0GFTu6gCaAV/BI3BEKA40nF8F1GmRTaFulDcZkA/CCQCgVndW RheRPPnIkcsOJ30pDBTXmAgFvu4Hdb7SVkVjmDw4pJ6BEg4qp8gLKJqDqSGUF5MN/PBl NoETJK0K0conjxj+wzV9a5r7cq9rKSk6qeQHQLiiuPm25FRDTUVKkGjG54DQUAHMFkKH 4wqg== X-Gm-Message-State: ABUngveoVXUopK78aTJ7g0FtX3MSm8ByWPM1cye94a0u0NQ4mWmBqU/KNkjgSsKFVF0rM7woJWJ5qGLGqB3MUw== X-Received: by 10.107.136.93 with SMTP id k90mr11939859iod.173.1478858049919; Fri, 11 Nov 2016 01:54:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.116.36 with HTTP; Fri, 11 Nov 2016 01:54:09 -0800 (PST) In-Reply-To: References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <1478850654823.89451@cs.auckland.ac.nz> From: Jeffrey Walton Date: Fri, 11 Nov 2016 04:54:09 -0500 Message-ID: To: Adrian Hope-Bailie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 09:54:11 -0000 On Fri, Nov 11, 2016 at 3:16 AM, Adrian Hope-Bailie wrote: > How does your average consumer know if they're buying an Internet of > Shi^H^H^HThings device or proper SCADA gear? > > Surely half the problem is educating price sensitive consumers about how to > distinguish from well-priced good hardware and cheap crap? > > All the guidelines in the world will not stop people building crap to try > and sell it cheap Most consumers won't know. Those who do know or attempt to learn will be further confused by marketing departments leading to a Market of Lemons. ARMv8 devices are a good example. When ARMv8 was first release, phone OEMs were the first to ship to consumers (some hand waiving). The relevant press release boasted about it. I purchased both phones for early testing to find out they were effectively in a 32-bit ARMv7 configuration running armhf images. Fast forward 18 months or so, and its the same situation. There are four commodity dev-boards available I know of running A53 architecture: * RaspberryPi-3 * ODROID-C2 * Pine64 * LeMaker HiKey RPI3 and ODRID are A53, but they lack CRC and Crypto extensions. Pine64 and HiKey are A53 and have the optional CRC+Crypto extensions. If you check the marketing literature, all of them appear to be the same. The RPI3 is the worse because its like the cell phones. Its marketed as ARMv8, but only got an armhf image. One of the RI3 FanBoi's believed there was no {performance|security} benefit to switching to AArch64 or Aarch32, and he actively lobbied against it t users. I know the board characteristics in practice because I purchased the actual boards and tested them. I was surprised to learn two of them lacked CRC+Crypto because that's one of the features I wanted when I purchased them. Jeff From nobody Fri Nov 11 01:54:59 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286641295E3 for ; Fri, 11 Nov 2016 01:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 j8CyzdpKwG8L for ; Fri, 11 Nov 2016 01:54:56 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 02BA2129451 for ; Fri, 11 Nov 2016 01:54:56 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id e187so60391262itc.0 for ; Fri, 11 Nov 2016 01:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ITtGmg7qSppdR3G5UT1Ka9aZs51qrGl/OUHyLRxnk+k=; b=LO1uEjzq6Y0FQrsr8Eye5clwGmV9+BfnAa/k7x+ErZDvq5695DL/M+jUYCKH+BqHvy azJQ/jl+Mq5SiJkm9Tkc6N9uev1yuqS2MLriI2p/0Kerv8q0bprUetyl3PK0o/yLutS1 41mNFjMNOr7A7NBH7JtfbC9pZvxCdsuRcGVTvTKCM0AoU6AChcMmRHrCI0Gdr3P3lMh0 rb1G7CK1cDx9iUUcQfzQfyvwd5iy6e/NgCISMOdIhD2ba8YhvL1VhBomVDIqbQvYtMDX BCi1VlTQAnU/mdKbJJ9xeAo2DCk8XwCnTiW0hrj4GenkVhg0jNFlF1BGBpzemYLV8gJW USsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=ITtGmg7qSppdR3G5UT1Ka9aZs51qrGl/OUHyLRxnk+k=; b=fhWrR9R14wZ6vzkFr892HZikSBXT0717hxhXwpGIXytLDQZdGVWoIJ+CwVvcfiMjqM 1tSs1cQ1H8yQc6edSCQnrXYPadNq+xyQycYs2XgfG60xfFJ77Th7vxKSTTo+cJwlu1YA tlmzlvq7zMi/Z4weHZ7xah77a3sAlBZ29RpGSikBssI9gH7PzgsV/1VHVu6FxiE7cDGX VIv2c/y4rrAfawlZM1jIzDSEvF2GRuqEQkm09yywdUn6VSHs3ToMZ6K8rPL6OISD1f5s e8f7bkxaRmGXyhIyIaeKMefGRrHat7mI31sko7WB0Wfc5otPJwVtdgQzO26dBPsmrVSG kGrg== X-Gm-Message-State: ABUngvcDRCmgJqhAEQQRwaquQXJjf6jif1ZmTHiHEX2aCZdSwQgAq/36Coiu/YVHY/T56JWRXLqSW5eR+I2EhQ== X-Received: by 10.36.125.75 with SMTP id b72mr7497999itc.62.1478858095444; Fri, 11 Nov 2016 01:54:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.116.36 with HTTP; Fri, 11 Nov 2016 01:54:54 -0800 (PST) In-Reply-To: <1478854787137.79505@cs.auckland.ac.nz> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <1478850654823.89451@cs.auckland.ac.nz> <1478854787137.79505@cs.auckland.ac.nz> From: Jeffrey Walton Date: Fri, 11 Nov 2016 04:54:54 -0500 Message-ID: To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 09:54:57 -0000 On Fri, Nov 11, 2016 at 3:59 AM, Peter Gutmann wrote: > Adrian Hope-Bailie > >>How does your average consumer know if they're buying an Internet of >>Shi^H^H^HThings device or proper SCADA gear? > > If it's consumer-grade gear it's almost certainly IoS-grade equipment. > >>Surely half the problem is educating price sensitive consumers about how to >>distinguish from well-priced good hardware and cheap crap? > > Not when you've got the marketing resource of an entire industry working > against you. +1 > In any case though the point is to come up with a taxonomy of > embedded/SCADA/IoT/whatever device types that represent typical use cases... +1 Jeff From nobody Fri Nov 11 12:30:47 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A42B1299A8 for ; Fri, 11 Nov 2016 12:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, 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 8jzJUY2OJ2T8 for ; Fri, 11 Nov 2016 12:30:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E053129972 for ; Fri, 11 Nov 2016 12:30:43 -0800 (PST) Received: from [192.168.91.155] ([183.102.9.2]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MhAAr-1cReoP24Hp-00MMKQ; Fri, 11 Nov 2016 21:30:37 +0100 To: Michael Richardson , "saag@ietf.org" References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <23469.1478622961@obiwan.sandelman.ca> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <3fdfeede-2bcf-688d-8a4b-06e2a5eb0c0d@gmx.net> Date: Fri, 11 Nov 2016 21:30:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <23469.1478622961@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NeoshgFqecGiUNSlh7gQdrwe1wxAoI51p" X-Provags-ID: V03:K0:15m0JjP8CZ2h4dl1p4dVaL1hvxBpbkeKRNPbiaMoleMP6HO//8I NzTAV87Ac6Ej/8PXkbtr+Da1HDLbl8OBZ1hDLXBaZUUcncdWopyx8/mTJunq0h5Csv5dZQo FvxNbKmMctmwF3w89x2Jb8QmiDyyrZukFk142Hp3lCs3j/+0NqkxwXydHn8nxuDWNKq8547 n021m5pfhBYZxYE1Pn4Bg== X-UI-Out-Filterresults: notjunk:1;V01:K0:BQCmhu3jO1w=:Gy5hzT958E8H6pDHgedUPz lUX0ogv2va6AMIR+Yr0R9ZIanWdmjmafwsaOf9ExT496iyLBSJH2qwiHQWUhrf3cCg3ZVtVvC o87VOIE7D6UO1DQTYp8iCow/fSwga8wMmPywi+iqRtjMgqttvOznzTOpTEcg4jfg3qvxf+6VC yLl1mMpIE8oOCe+wWagmvwEzgDGghqkAbBmoG/WBwkFK/sTEPtkaXpSiQJVoUp0vRAmEAW4e+ yOO+ArXB814PLJInHQ0FA+DI3K4/KF3LnJSnJEojFHVgW9Xw09V2Q6qfgPa+TpKLtgRN6H5Th 4bhkG/+6Nze2GilfPsijs2vNGJrFcwbc85Pqoh9rjtdNA2oitCMM31ToY3aPEI5uFlCx1A8Dg CRlWoF6q8pzmCHhTISVt6brwOJdk0EyBz5/JGpIVpMEIYjulOFLsH8gzQgJ4XqevWDznsJ5w2 EzgQhpq9Jq25WRqh8apPV2/davD+SKPj62IR1zMh0KwFGzJXSTD5GvpohkTXtOBC8zlf9EXSo Ld8abJnPfjamfbS6wwB9NWCt2zguFxRU8vP6VgE+vwZ6ke4AY7sMUYsXj9yTCoKoj7WWr1luG 7nMu7/UvGSrpCtjrs+kmTovaUnB8h+pDWAizIktDp214jHDFvM7PKMYVhJslGH4wCOwSvaHKw tLxKfNuNP50Tpy+BSZVYXzKqDKPe8VNHOlAjnkQ5K2bKYnCV+0zqsE74CqvDu3bN/ohHMWys6 lQlWu0vyMFNOUCZQNmFCjdIxaPwQwTRwp4D2Lb2P2wawp63uFNHPRtwzzt4= Archived-At: Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 20:30:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NeoshgFqecGiUNSlh7gQdrwe1wxAoI51p Content-Type: multipart/mixed; boundary="i7lNtRL2lpHWrhFSfs9D0Hc77rtnTANET"; protected-headers="v1" From: Hannes Tschofenig To: Michael Richardson , "saag@ietf.org" Message-ID: <3fdfeede-2bcf-688d-8a4b-06e2a5eb0c0d@gmx.net> Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <23469.1478622961@obiwan.sandelman.ca> In-Reply-To: <23469.1478622961@obiwan.sandelman.ca> --i7lNtRL2lpHWrhFSfs9D0Hc77rtnTANET Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The write-up is not only focused on this specific attack. It aims to be a more more generic to the broader IoT sector. Using high-end processors is a valid choice for many deployments but there are also sectors that need features of the M-class device as well, for example higher energy efficiency. In terms of scoping I am trying to say that the recommendations should not assume high-end device only. Ciao Hannes On 11/08/2016 05:36 PM, Michael Richardson wrote: > Hannes Tschofenig wrote: > > We probably have do a bit of document scoping. Many embedded devi= ces do > > not run Linux since they have no MMU. I would like to have guidel= ines > > that also consider those ~50 billion of currently deployed device= s as > > well. >=20 > **Many** of the devices involved in the recent attacks *DO* run Linux, = and > do have MMUs. (I don't consider routers and cameras to be IoT, even th= ough > the press does.) >=20 > The price of MMUs is coming down significantly. >=20 > -- > ] Never tell me the odds! | ipv6 mesh net= works [ > ] Michael Richardson, Sandelman Software Works | network archi= tect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [ >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --i7lNtRL2lpHWrhFSfs9D0Hc77rtnTANET-- --NeoshgFqecGiUNSlh7gQdrwe1wxAoI51p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYJipnAAoJEGhJURNOOiAtFqoH/RsArZCFR84eEQJsDXL+wK+M vB6zVK5FJqFukSLXwe1lQJA25nM0yFYWU5jjb67PsGkmS737DfyURoF13NScZvgS 4Z6nwZ+fbbsN/yAjNPXEl8xZ8TLXzr+Xvimu1LMPzbjDoLB/aKN33hyY7+mwkglD mHVsucR9FszI8UCBCeIMFgyW5kofyN2HrrMW3YgC6PRlrbul6IMB7nulMObd7KKH UAN/jy3gwAIRKwu222zNbOmN7QVGwehAJBB73aRm0e46rqVRBmBQTeT1WPPZ9MDJ Esyk6tPyw8RSX4wCKJ5g9popzx4az36MVUo4YgdH3fdJIPhaUROalQTsARMQggc= =WxGK -----END PGP SIGNATURE----- --NeoshgFqecGiUNSlh7gQdrwe1wxAoI51p-- From nobody Fri Nov 11 14:25:16 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02141294DC for ; Fri, 11 Nov 2016 14:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 2dpyIvIQ9ZRV for ; Fri, 11 Nov 2016 14:25:12 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 8E41912948D for ; Fri, 11 Nov 2016 14:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id uABMOx9f001470; Fri, 11 Nov 2016 23:24:59 +0100 (CET) Received: from [IPv6:2001:67c:370:144:d067:5c30:da5c:d92a] (unknown [IPv6:2001:67c:370:144:d067:5c30:da5c:d92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3tFvc96B2jz7yBN; Fri, 11 Nov 2016 23:24:57 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Carsten Bormann In-Reply-To: <1478854787137.79505@cs.auckland.ac.nz> Date: Sat, 12 Nov 2016 07:24:53 +0900 X-Mao-Original-Outgoing-Id: 500595893.170267-f1869405f39fdc2a474ef62b8f300eef Content-Transfer-Encoding: quoted-printable Message-Id: <3A0047BE-3C77-4D0C-BB5B-CE4AAF983228@tzi.org> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <1478850654823.89451@cs.auckland.ac.nz> <1478854787137.79505@cs.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 22:25:15 -0000 > In any case though the point is to come up with a taxonomy of > embedded/SCADA/IoT/whatever device types that represent typical use = cases... JFYI: To talk about classes of devices, we already have RFC 7228. The LWIG WG is now looking at updating this document. https://datatracker.ietf.org/doc/draft-bormann-lwig-7228bis/ This is work in progress, but we are very open to useful classification = to be added to this document. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Nov 11 23:37:01 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EAE1299CC for ; Fri, 11 Nov 2016 23:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 Mvuwsmbczsf3 for ; Fri, 11 Nov 2016 23:36:51 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D301299C7 for ; Fri, 11 Nov 2016 23:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1478936211; x=1510472211; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K2+P4ZEw7DguHWSrXfs9SKKu6vcBa4ZRlQd3NpLHsu8=; b=JWwUtFl3UNzeSwEkZG7CeBiyg6KkYXrWkfB+66nU9BmZCGlpWVVObQzO XS1sLLcGO3pF23ZAFpEpbocTG6Y95c3JLnqXqNXe3sn+rOzC9TCeDdMaq GiF/GhShZjixitgaC/ZTBudkt1kmVvGBVj69kLu3g0+g3sVOG8BJmGTwY MykkFqj6v2V642g876++8b8+L7njpREwDUB4QHH4WDUvGYzB4Oy6pJez6 jdxTkTDLOlCO7FSjIyO1alfxHUDZ4NqzNGQoLrcBAW9+XRTepOq/IdlAY 3drg2ZSErEZPiJgnkmw1pA52jJhIkT2G94tX3jFaFh5D8tQJO09usGlA7 g==; X-IronPort-AV: E=Sophos;i="5.31,625,1473076800"; d="scan'208";a="114807464" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Nov 2016 20:36:46 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 12 Nov 2016 20:36:46 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 12 Nov 2016 20:36:46 +1300 From: Peter Gutmann To: Adrian Hope-Bailie , "noloader@gmail.com" Thread-Topic: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) Thread-Index: AQHSNwOeEhudYcKwEki+rGU+A1iPFKDN33gAgAB68gCAAAH+AIAFFhzZ//8tWACAABtGgIACROL/ Date: Sat, 12 Nov 2016 07:36:45 +0000 Message-ID: <1478936199313.82022@cs.auckland.ac.nz> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <99b43920-ee16-3cb2-731b-941718749cf5@afrinic.net> <1478850654823.89451@cs.auckland.ac.nz> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 07:36:58 -0000 Jeffrey Walton writes:=0A= =0A= >Most consumers won't know. Those who do know or attempt to learn will be= =0A= >further confused by marketing departments leading to a Market of Lemons.= =0A= =0A= It's actually a bit more complicated than that. Most of the IoS wouldn't= =0A= exist if it wasn't for the S. If all that was available was industrial-=0A= strength SCADA devices running VxWorks then you wouldn't have WiFi-enabled= =0A= toothbrushes [0]. It's hard to find board shots of PLCs, but here's one:= =0A= =0A= http://www.mikroe.com/img/development-tools/pic/picplc4-v6/gallery/picp= lc4v6_01.jpg=0A= =0A= About 15-20% of the entire board area is the power supply and conditioning= =0A= circuitry, and it's pretty serious stuff, not just some woosy 3216 surface-= =0A= mount capacitor here and there. Now compare that to a Pi (the most visible= =0A= example of an IoT device), which has a basic switchmode converter to get th= e=0A= lower voltages needed by the board, and the protection is a polyfuse. Whic= h=0A= you may need to remove because the decision to use micro USB for power mean= s=0A= you can't power much of anything attached to the Pi so you need an external= ly-=0A= powered hub, and then need to hack either the hub or the Pi so you don't=0A= backpower it and fry something. You can end up spending more on the=0A= additional parts you need than you spent on the Pi itself, and it requires= =0A= endless nursing (the WiFi-dongle drivers are kernel-specific, so when you d= o a=0A= kernel upgrade it knocks itself off the net until you plug in an ethernet= =0A= cable and upgrade the drivers that way, and way too many other headaches, t= he=0A= SD cards tend to get corrupted a lot so you have to reinstall your OS image= ,=0A= etc).=0A= =0A= And that's the blessing and the curse of the Pi (and equivalent IoT things)= .=0A= By making it cheap, powered off a micro USB charger, running Linux, etc, it= 's=0A= very accessible. Anyone can throw together a product around a reference Ar= m=0A= board, and they inevitably do. If the same thing was done with an industri= al-=0A= grade device, it'd cost $400 per unit and run VxWorks, and there wouldn't b= e=0A= an IoT.=0A= =0A= Anyway, point is, we've got the IoS for better or for worse. Unfortunately= I=0A= can't think of any obvious way of dealing with it...=0A= =0A= Peter.=0A= =0A= [0] I was trying to think of something over-the-top ridiculous but then=0A= remembered that the real thing already exists.= From nobody Sat Nov 12 04:28:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF302129A41 for ; Sat, 12 Nov 2016 04:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CAFNgInO9iqB for ; Sat, 12 Nov 2016 04:28:09 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 123D9129551 for ; Sat, 12 Nov 2016 04:28:09 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id i88so18294713pfk.2 for ; Sat, 12 Nov 2016 04:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kDOuhtEeYfK6/I3nU6EB58upU9oUGs2yuQ9rEhiVpqs=; b=UEEgfU++43gQYcxl2lFF4AiHcHfWQIVm1RlSne48i1VAhJxh1pklFSL6ZScf6c/kNZ p3bu0Ku5OEddt51H0/BrLZ/w238+vS2g04UmAov6stxMKVpk/9aBb6+yYMlR0UjxfrCt nnDimFtqHDFVxir8x1IWcSFzSUJzhK3T7J3ORgW6aN96zYav3gBtz5t6/DzmmUoUB4Fc 7QH+ddlj5U1CuQo9LxaXBtakTeucfED6ttksfUKGJRLdNi7oq2x/3+ijux5rJl/MJjD1 Zh0XolgfylGegb0mUKUGT/jR2LJjQTNZOPf9shnBsRB8YEOcu6HEvcOpqQIN4PPan8EU otgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kDOuhtEeYfK6/I3nU6EB58upU9oUGs2yuQ9rEhiVpqs=; b=SpFasw7ffld/NtH1GftCPvq1X2z3uB8MAzyt422MR8C/iAZnLfH/5Ou1XMa3l3I62s V6hp/1IsZQktUSyboRRsHsY4/ULFGlmsJmwJl8AwmCdGOOput2Xi2oMH48dahmP6WsT6 cvjG/lk8yOQgLfJdEYTqXRdaAiYT960f4OaS1OHsPS4OAFP49Ujxhm7QtE5EdcPtaTml uzaqj9xisSKnvt3JW3bvBNp8mBMeMagLxkQxMQSliMbh5GLskfAcJDPiwu6Jyh2JudOr h+swXXS7qjJoTkCiULm4PhuhBw0l7m2ZPtjCCGcC7i1Bu3ZczK+oNqot04hxzA83dZUV OJhg== X-Gm-Message-State: ABUngvcF3YmAaDTMB/Ohow0Sa58OESLciIdGFY1WSe6lYwgSL0bHyxfFQKEEYFCmO+aPzw== X-Received: by 10.98.15.206 with SMTP id 75mr16852750pfp.105.1478953688681; Sat, 12 Nov 2016 04:28:08 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:f856:7ad5:9772:f033? ([2001:67c:370:144:f856:7ad5:9772:f033]) by smtp.gmail.com with ESMTPSA id sh9sm22216697pac.41.2016.11.12.04.28.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Nov 2016 04:28:07 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-8DF5C547-10D2-434A-A0E0-58A0167DDDA1 Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (14B100) In-Reply-To: <013c0c1d5ba948b28702bb01449196ac@HE1PR9003MB0234.MGDPHG.emi.philips.com> Date: Sat, 12 Nov 2016 21:27:59 +0900 Content-Transfer-Encoding: 7bit Message-Id: <08D37FA2-F2DE-4BC7-918C-1F96071FCEF9@gmail.com> References: <63ae04d9-9a31-498c-3333-2801a72338f0@network-heretics.com> <68453f17719b45a3afe0ee8607acd420@HE1PR9003MB0234.MGDPHG.emi.philips.com> <013c0c1d5ba948b28702bb01449196ac@HE1PR9003MB0234.MGDPHG.emi.philips.com> To: "Garcia Morchon O, Oscar" Archived-At: Cc: Mohit Sethi , "saag@ietf.org" , "Kumar, Sandeep" , Keith Moore Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2016 12:28:11 -0000 --Apple-Mail-8DF5C547-10D2-434A-A0E0-58A0167DDDA1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, We will also have a presentation providing a read out from the IoT software u= pdate workshop (IoTSU). The presentation is linked from the agenda for SAAG= . https://datatracker.ietf.org/meeting/97/agenda/saag/ This does not provide what you are looking for though. Thank you, Kathleen=20 Please excuse typos, sent from handheld device=20 > On Nov 9, 2016, at 5:09 AM, Garcia Morchon O, Oscar wrote: >=20 > Hi Adam, > =20 > we will be discussing next steps for the T2TRG draft in the T2TRG meeting.= > =20 > Regards, Oscar. > =20 > From: Adam Montville [mailto:adam.w.montville@gmail.com]=20 > Sent: Tuesday, November 08, 2016 11:24 AM > To: Garcia Morchon O, Oscar; Ari Ker=C3=A4nen; Keith Moore; saag@ietf.org > Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Sec= uring Internet of Things (IoT) Devices) > =20 > Would it be worthwhile to add this to the saag agenda, or is there otherwi= se some session for discussing the plethora of IoT security related material= ? > =20 > On Tue, Nov 8, 2016 at 10:04 AM Garcia Morchon O, Oscar wrote: > Hi Ari, Keith, >=20 > indeed, the purpose is similar of the draft in the T2TRG is similar. It is= clear is that having a document in which we describe which aspects should b= e considered is very relevant. >=20 > We are in the process of further updating our draft -- comments are welco= me. >=20 > Regards, Oscar. >=20 > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Ari Ker=C3=A4nen > Sent: Tuesday, November 08, 2016 9:44 AM > To: Keith Moore; saag@ietf.org > Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Sec= uring Internet of Things (IoT) Devices) >=20 > Hi, >=20 > Also at the Thing-to-Thing Research Group we have a draft about security c= onsiderations for IoT: > https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons >=20 >=20 > Cheers, > Ari >=20 > On 05/11/16 03:25, Keith Moore wrote: > > Stephen Farrell suggested I bring this draft to your attention. This was= > > a rush job as the authors just started talking about this last Friday, > > but it was written in response to recent DDoS attacks that utilized > > easily-compromised IoT devices. I'm sure there are missing pieces > > (I've identified a few since -00) and sections that could be stated > > better (like the title of section 2.3.2), but hopefully this is a useful= > > start. > > > > https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/ > > > > Keith > > > > >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 > ________________________________ > The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addres= see(s). If you are not the intended recipient, you are hereby notified that a= ny use, forwarding, dissemination, or reproduction of this message is strict= ly prohibited and may be unlawful. If you are not the intended recipient, pl= ease contact the sender by return e-mail and destroy all copies of the origi= nal message. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-8DF5C547-10D2-434A-A0E0-58A0167DDDA1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

We will a= lso have a presentation providing a read out from the IoT software update wo= rkshop (IoTSU).  The presentation is linked from the agenda for SAAG.

<= div>This does not provide what you are looking for though.

Thank you,
Kathleen 

Please excuse typos,= sent from handheld device 

On Nov 9, 2016, at 5:09= AM, Garcia Morchon O, Oscar <oscar.garcia@philips.com> wrote:

Hi Adam,<= /p>

 

we will be discussing next s= teps for the T2TRG draft in the T2TRG meeting.

 

Regards, Oscar.<= /span>

 

From: Adam Montvi= lle [mailto:adam.w.montville@g= mail.com]
Sent: Tuesday, November 08, 2016 11:24 AM
To: Garcia Morchon O, Oscar; Ari Ker=C3=A4nen; Keith Moore; saag@ietf.org
Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices fo= r Securing Internet of Things (IoT) Devices)

 

Would it be worthwhile to add this to the saag agenda= , or is there otherwise some session for discussing the plethora of IoT secu= rity related material?

 

On Tue, Nov 8, 2016 at 10:04 AM Garcia Morchon O, Osc= ar <oscar.garcia@philips.com<= /a>> wrote:

Hi Ari, Keith,

indeed, the purpose is similar of the draft in the T2TRG is similar. It is c= lear is that having a document in which we describe which aspects should be c= onsidered is very relevant.

We are in the process of further updating our draft --  comments are we= lcome.

Regards, Oscar.

-----Original Message-----
From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Ari Ker=C3=A4nen
Sent: Tuesday, November 08, 2016 9:44 AM
To: Keith Moore; saag@iet= f.org
Subject: Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Secur= ing Internet of Things (IoT) Devices)

Hi,

Also at the Thing-to-Thing Research Group we have a draft about security con= siderations for IoT:
https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons


Cheers,
Ari

On 05/11/16 03:25, Keith Moore wrote:
> Stephen Farrell suggested I bring this draft to your attention. This wa= s
> a rush job as the authors just started talking about this last Friday,<= br> > but it was written in response to recent DDoS attacks that utilized
= > easily-compromised IoT devices.   I'm sure there are missing p= ieces
> (I've identified a few since -00) and sections that could be stated
= > better (like the title of section 2.3.2), but hopefully this is a usefu= l
> start.
>
> https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/
>
> Keith
>
>

_______________________________________________
saag mailing list
saag@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/saag

________________________________
The information contained in this message may be confidential and legally pr= otected under applicable law. The message is intended solely for the address= ee(s). If you are not the intended recipient, you are hereby notified that a= ny use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful.= If you are not the intended recipient, please contact the sender by return e= -mail and destroy all copies of the original message.

_______________________________________________
saag mailing list
saag@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/saag

____________________= ___________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman= /listinfo/saag
= --Apple-Mail-8DF5C547-10D2-434A-A0E0-58A0167DDDA1-- From nobody Sat Nov 12 18:09:58 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24D612954D for ; Sat, 12 Nov 2016 18:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 BmQLV8KXaYx4 for ; Sat, 12 Nov 2016 18:09:56 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 81122129464 for ; Sat, 12 Nov 2016 18:09:56 -0800 (PST) X-AuditID: 1209190c-c87ff70000005ac9-59-5827cb725c96 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 36.93.23241.27BC7285; Sat, 12 Nov 2016 21:09:55 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id uAD29sGe011574; Sat, 12 Nov 2016 21:09:54 -0500 Received: from dhcp-8693.meeting.ietf.org (dhcp-8693.meeting.ietf.org [31.133.134.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAD29n1Y030132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 12 Nov 2016 21:09:53 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_CA9A3162-8109-4EE4-A62E-4F60965235F5" Date: Sun, 13 Nov 2016 11:09:49 +0900 Message-Id: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrFt8Wj3C4MBKNYuGnfkWU/o7mRyY PHbOusvusWTJT6YApigum5TUnMyy1CJ9uwSujEfP1zEWLBKsWPW8n72BcQJ/FyMnh4SAicTa y52sXYxcHEICbUwSc3bdZIRwNjJKvD78iQnCucIkserbNVaQFjYBVYn5K28xgdjMAgkSM7fe ZgSxhQXkJbZseAZWwwJU8+DnMrAaXgErib6e5SwQ9RYS25a/ZwOxRQQEJR70TWKBqNGT2LT+ LRPESbIST04uYpnAyDsLyYpZSMog4toSyxa+ZoawNSX2dy9nwRTXkOj8NpF1ASPbKkbZlNwq 3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjOBAleTZwXjmjdchRgEORiUeXo5M9Qgh1sSy 4srcQ4ySHExKorzvVIBCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgnHQbK8aYkVlalFuXDpKQ5 WJTEef+7fQ0XEkhPLEnNTk0tSC2CycpwcChJ8DacAmoULEpNT61Iy8wpQUgzcXCCDOcBGu4F UsNbXJCYW5yZDpE/xagoJc67+BhQQgAkkVGaB9cLSiTyrW2TXzGKA70izLsepJ0HmITgul8B DWYCGjwjTgVkcEkiQkqqgfF6jvi7mYLNR3ZfW3kg8ruon/yEtxsSlzjvXHSBqWqpaUlQosyj +IROK05rqfe8wRIXC0JDUk1fHSw7ciCAebXK8wbuhLPmJVqbzb2YtftnzPgfos8TH36n4FXc rRIF162rzV6909ew3Gczw+PuuqDfjg5H2Zg4lq3REA18vnDP8awr9wxfBiixFGckGmoxFxUn AgDE3wEX/wIAAA== Archived-At: Subject: [saag] Vectors of Trust (VoT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 02:09:58 -0000 --Apple-Mail=_CA9A3162-8109-4EE4-A62E-4F60965235F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, The Vectors of Trust draft was published to this list back in July for = comment, but no discussion was received at the time. We would like to = move this forward as an AD-sponsored informational RFC (under = Kathleen=E2=80=99s aegis).=20 The current draft is available here (it hasn=E2=80=99t changed since = July): https://tools.ietf.org/html/draft-richer-vectors-of-trust-03 = We=E2=80=99d appreciate review and any commentary that people might have = before this document goes to the next step. Thank you, =E2=80=94 Justin= --Apple-Mail=_CA9A3162-8109-4EE4-A62E-4F60965235F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

The= Vectors of Trust draft was published to this list back in July for = comment, but no discussion was received at the time. We would like to = move this forward as an AD-sponsored informational RFC (under = Kathleen=E2=80=99s aegis). 

The current draft is available here (it = hasn=E2=80=99t changed since July):

https://tools.ietf.org/html/draft-richer-vectors-of-trust-03

We=E2=80=99d = appreciate review and any commentary that people might have before this = document goes to the next step.

Thank you,

 =E2=80=94 = Justin
= --Apple-Mail=_CA9A3162-8109-4EE4-A62E-4F60965235F5-- From nobody Sat Nov 12 21:27:24 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4860312951A for ; Sat, 12 Nov 2016 21:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 MoGy-DnXpz5J for ; Sat, 12 Nov 2016 21:27:21 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADBB1296D1 for ; Sat, 12 Nov 2016 21:27:19 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1AD26496C3A; Sun, 13 Nov 2016 05:27:19 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id EF42A496C0A; Sun, 13 Nov 2016 05:27:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479014838; bh=pw6zPqbpLsMGs5nDbhZd6LAJG5OSHAxejV4QffBRDnU=; l=5056; h=From:To:Date:References:In-Reply-To:From; b=l4zf1VbRJrYkS9eYD1Pk087Amk0+PreFPA/h4xXDvqN0MYotP/mbJY8xuWPomevfy dlGgkKyJMDk4TRoaf75dyrNIYmJC11LqvgQuINL6LyYC1aBnqX8qNQavbBCD2t6LYq MabRHpWi1DqZF4mtJh/gjyfYjPskKPLIy/b7ft1s= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id EA7CA98082; Sun, 13 Nov 2016 05:27:18 +0000 (GMT) Received: from USTX2EX-DAG1LAG.msg.corp.akamai.com (172.27.27.106) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 12 Nov 2016 23:27:18 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1lag.msg.corp.akamai.com (172.27.27.106) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 12 Nov 2016 23:27:18 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1178.000; Sat, 12 Nov 2016 23:27:18 -0600 From: "Salz, Rich" To: Justin Richer , "saag@ietf.org" Thread-Topic: [saag] Vectors of Trust (VoT) Thread-Index: AQHSPVMLoFmz9d7S5UGXS+JZb12396DWYYhw Date: Sun, 13 Nov 2016 05:27:17 +0000 Message-ID: <3926b25426ea436ba9a8d0510faac599@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> In-Reply-To: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.87] Content-Type: multipart/alternative; boundary="_000_3926b25426ea436ba9a8d0510faac599ustx2exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Vectors of Trust (VoT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:27:23 -0000 --_000_3926b25426ea436ba9a8d0510faac599ustx2exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0b29rIGEgcXVpY2sgcmVhZCBvZiB0aGUgZHJhZnQuICBXaHkgYXJlIHNvbWUgdmFsdWVzIDAg MSAyIGFuZCBvdGhlcnMgYXJlIGEgYiBjPw0KV2h5IGlzbuKAmXQgdGhlIG9uLXRoZS13aXJlIHJl cHJlc2VudGF0aW9uIGlkZW50aWNhbCBmb3Igb3BlbmlkIHNhbWwgYW5kIHRydXN0d2F2ZT8NCg0K DQotLQ0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVu U1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoN Cg== --_000_3926b25426ea436ba9a8d0510faac599ustx2exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSB0b29rIGEgcXVpY2sgcmVhZCBvZiB0aGUgZHJhZnQuJm5ic3A7IFdoeSBh cmUgc29tZSB2YWx1ZXMgMCAxIDIgYW5kIG90aGVycyBhcmUgYSBiIGM/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPldoeSBpc27igJl0IHRoZSBvbi10aGUtd2lyZSByZXByZXNlbnRhdGlv biBpZGVudGljYWwgZm9yIG9wZW5pZCBzYW1sIGFuZCB0cnVzdHdhdmU/Jm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS0mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkg VGVjaG5vbG9naWVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1lbWJlciwgT3BlblNT TCBEZXYgVGVhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTTogcmljaHNhbHpAamFi YmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3926b25426ea436ba9a8d0510faac599ustx2exdag1mb1msgcorpak_-- From nobody Sat Nov 12 21:32:59 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89600129459 for ; Sat, 12 Nov 2016 21:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 E2SFcnBck48i for ; Sat, 12 Nov 2016 21:32:57 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 EC73D1293D9 for ; Sat, 12 Nov 2016 21:32:56 -0800 (PST) X-AuditID: 12074422-95bff70000001b28-78-5827fb07dc36 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 68.90.06952.70BF7285; Sun, 13 Nov 2016 00:32:55 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id uAD5WsoC027102; Sun, 13 Nov 2016 00:32:55 -0500 Received: from dhcp-8693.meeting.ietf.org (dhcp-8693.meeting.ietf.org [31.133.134.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAD5Wo9q027888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Nov 2016 00:32:53 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_6C2FD143-93C9-44BE-9157-8E0FC7191F92" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <3926b25426ea436ba9a8d0510faac599@ustx2ex-dag1mb1.msg.corp.akamai.com> Date: Sun, 13 Nov 2016 14:32:49 +0900 Message-Id: <737CF632-E83D-4C38-99DE-FA04411D0CA0@mit.edu> References: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> <3926b25426ea436ba9a8d0510faac599@ustx2ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IR4hRV1mX/rR5hcG66qcX/LZ0sFlP6O5kc mDwmH1nA7LFkyU+mAKYoLpuU1JzMstQifbsErozWr+8ZC1Y4VJxa2MHewLjNrIuRg0NCwERi bhd/FyMXh5BAG5PE25Z1LBDORkaJE6sPsUE4V5gkVk/qYQXpYBZIkGho0uti5OTgFdCT2LT+ LRNIWFhAS2JagxVImE1AVWL+yltMIDanQLDEqU8TmUFsFqD4u6PTGSGmKEscv+oHYvIKWEkc X1kJsaiRUeLX+SPsIOUiICUzHzCC2BICshJPTi5imcDIPwvhhllIbgCxmQW0JZYtfM0MYWtK 7O9ezoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5xanJusXJiXl5qUW6pnq5mSV6qSmlmxhBAc3u orSDceI/r0OMAhyMSjy8HJnqEUKsiWXFlbmHGCU5mJREed+pAIX4kvJTKjMSizPii0pzUosP MUpwMCuJ8Lp9B8rxpiRWVqUW5cOkpDlYlMR5Gdy/hgsJpCeWpGanphakFsFkZTg4lCR4j/4E ahQsSk1PrUjLzClBSDNxcIIM5wEafg2khre4IDG3ODMdIn+KUVFKnHfDO6CEAEgiozQPrheU cORb2ya/YhQHekWY9xVIOw8wWcF1vwIazAQ0eEacCsjgkkSElFQD49R9BueVdcNCTC86PPta 5/rjSnBsKptDap+opZrRRv5T3866tW3mKGnbcveu+NN4pcYM6XPyggyxR3Pv88jdceHgz9mQ dWnbVQ83oTMl95cs9bJq8XufzsU8d+6O/b1fb6Tylj4+M/MQ98vf165wvcxfJ2FgsqR7b8XK TRPcHrz/wuDCLnhnqRJLcUaioRZzUXEiAMnYF9kTAwAA Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Vectors of Trust (VoT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:32:58 -0000 --Apple-Mail=_6C2FD143-93C9-44BE-9157-8E0FC7191F92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rich, Thanks for the review and your questions. The numeric values are intended for components that have a natural order = and potentially subsumptive definitions. Identity proofing, for example, = is usually going to just get *more* proofed. The alphabetic values are = intended to be for more set-based components that may or may not have a = full overall natural order. Authentication methods, for instance, might = have a loose order to them but won=E2=80=99t likely have a universal = single order. We intended to have communicated this in the following = paragraph, but I would be happy to make this clearer if we can: The value for a given component within a vector of trust is defined by its demarcator character followed by a single digit or lowercase ASCII letter in the range "[0-9a-z]". Categories which have a natural ordering SHOULD use digits, with "0" as the lowest value. Categories which do not have a natural ordering, or which can have an ambiguous ordering, SHOULD use letters. Categories MAY use both letter style and number style value indicators. For example, a category could define "0" as a special "empty" value while using letters such as "a", "b", "c" for normal values can to differentiate between these types of options. On the wire formats: I agree they should be the same, and they will be = before this goes final. Notably, the SAML example needs to be updated to = use the same on-the-wire representation as OIDC. I=E2=80=99ve reached = out to a couple of SAML gurus for help with getting that done properly. = What=E2=80=99s in there now is from an old draft and I=E2=80=99m not = enough of a SAML person to take a stab at it myself. Thank you, =E2=80=94 Justin > On Nov 13, 2016, at 2:27 PM, Salz, Rich wrote: >=20 > I took a quick read of the draft. Why are some values 0 1 2 and = others are a b c? > Why isn=E2=80=99t the on-the-wire representation identical for openid = saml and trustwave?=20 > =20 > =20 > --=20 > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz --Apple-Mail=_6C2FD143-93C9-44BE-9157-8E0FC7191F92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Rich,

Thanks for the review and your questions.

The numeric values are = intended for components that have a natural order and potentially = subsumptive definitions. Identity proofing, for example, is usually = going to just get *more* proofed. The alphabetic values are intended to = be for more set-based components that may or may not have a full overall = natural order. Authentication methods, for instance, might have a loose = order to them but won=E2=80=99t likely have a universal single order. We = intended to have communicated this in the following paragraph, but I = would be happy to make this clearer if we can:

   The value for a =
given component within a vector of trust is defined
   by its demarcator character followed by a single digit or lowercase
   ASCII letter in the range "[0-9a-z]".  Categories which have a
   natural ordering SHOULD use digits, with "0" as the lowest value.
   Categories which do not have a natural ordering, or which can have an
   ambiguous ordering, SHOULD use letters.  Categories MAY use both
   letter style and number style value indicators.  For example, a
   category could define "0" as a special "empty" value while using
   letters such as "a", "b", "c" for normal values can to differentiate
   between these types of options.


On the wire formats: I agree they = should be the same, and they will be before this goes final. Notably, = the SAML example needs to be updated to use the same on-the-wire = representation as OIDC. I=E2=80=99ve reached out to a couple of SAML = gurus for help with getting that done properly. What=E2=80=99s in there = now is from an old draft and I=E2=80=99m not enough of a SAML person to = take a stab at it myself.

Thank you,
 =E2=80=94 = Justin

On Nov 13, 2016, at 2:27 PM, Salz, Rich = <rsalz@akamai.com> wrote:

I took a quick read of the draft.  = Why are some values 0 1 2 and others are a b c?
Why isn=E2=80=99t the on-the-wire = representation identical for openid saml and trustwave? 
 
 
-- 
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitter: = RichSalz

= --Apple-Mail=_6C2FD143-93C9-44BE-9157-8E0FC7191F92-- From nobody Sat Nov 12 21:34:53 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44B4129459 for ; Sat, 12 Nov 2016 21:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 g3EcfWdgmyFX for ; Sat, 12 Nov 2016 21:34:49 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id BDA501293D9 for ; Sat, 12 Nov 2016 21:34:49 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 52B1A200007; Sun, 13 Nov 2016 05:34:49 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 37426200003; Sun, 13 Nov 2016 05:34:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479015289; bh=iH/HzNKB276NxtaU8tyq1V/cAGdmiFOB+ybJB/wE1UM=; l=5968; h=From:To:CC:Date:References:In-Reply-To:From; b=kOQ3lkl9TnIVZ67d1rOv8uzvFx67tXNiZgrXj6rsN6vd5eBmI37c5OCUgSLi/zM6u C1XrF2+PBEchu0mIyuM7k5z20Z/jdhLo7hITTfRvVB0LtaH1jAxVtWxwp2O3Yfoxx0 KBAru3xGmwUvF7xazA42+U762yrK4Gdcc/NoBs2k= Received: from email.msg.corp.akamai.com (ustx2ex-cas3.msg.corp.akamai.com [172.27.25.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 346271E084; Sun, 13 Nov 2016 05:34:49 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 12 Nov 2016 23:34:48 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1178.000; Sat, 12 Nov 2016 23:34:48 -0600 From: "Salz, Rich" To: Justin Richer Thread-Topic: [saag] Vectors of Trust (VoT) Thread-Index: AQHSPVMLoFmz9d7S5UGXS+JZb12396DWYYhwgABnJID//5uo0A== Date: Sun, 13 Nov 2016 05:34:47 +0000 Message-ID: <41bc8924704d4e68a452d009a80d4227@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> <3926b25426ea436ba9a8d0510faac599@ustx2ex-dag1mb1.msg.corp.akamai.com> <737CF632-E83D-4C38-99DE-FA04411D0CA0@mit.edu> In-Reply-To: <737CF632-E83D-4C38-99DE-FA04411D0CA0@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.87] Content-Type: multipart/alternative; boundary="_000_41bc8924704d4e68a452d009a80d4227ustx2exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Vectors of Trust (VoT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:34:51 -0000 --_000_41bc8924704d4e68a452d009a80d4227ustx2exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R2xhZCB0byBoZWFyIHRoZXJlIHdpbGwgYmUgYSBzaW5nbGUgd2lyZSBmb3JtYXQuICBJ4oCZZCBv ZmZlciB0byBoZWxwIHdpdGggU0FNTCBidXQgaGF2ZSBmcmFua2x5IHB1cmdlZCBtb3N0IFhTRCBh bmQgU0FNTCBmcm9tIG15IHdvcmtpbmcgc2V0Lg0KDQpUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlv biwgYnV0IEkgZG9u4oCZdCB0aGluayBhIG5hdHVyYWwgb3JkZXJpbmcgbWFrZXMgc2Vuc2U6IGlz IGEgdGh1bWJwcmludCBiZXR0ZXIgdGhhbiB2b2ljZT8gIFNocnVnLCBZTU1WLg0KDQotLQ0KU2Vu aW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NMIERldiBU ZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg== --_000_41bc8924704d4e68a452d009a80d4227ustx2exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5h bWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkdsYWQgdG8gaGVhciB0aGVyZSB3aWxsIGJlIGEgc2luZ2xlIHdp cmUgZm9ybWF0LiZuYnNwOyBJ4oCZZCBvZmZlciB0byBoZWxwIHdpdGggU0FNTCBidXQgaGF2ZSBm cmFua2x5IHB1cmdlZCBtb3N0IFhTRCBhbmQgU0FNTCBmcm9tIG15IHdvcmtpbmcgc2V0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24sIGJ1dCBJIGRvbuKAmXQgdGhpbmsgYSBu YXR1cmFsIG9yZGVyaW5nIG1ha2VzIHNlbnNlOiBpcyBhIHRodW1icHJpbnQgYmV0dGVyIHRoYW4g dm9pY2U/Jm5ic3A7IFNocnVnLCBZTU1WLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tJm5ic3A7DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hu b2xvZ2llczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NZW1iZXIsIE9wZW5TU0wgRGV2 IFRlYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SU06IHJpY2hzYWx6QGphYmJlci5h dCBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_41bc8924704d4e68a452d009a80d4227ustx2exdag1mb1msgcorpak_-- From nobody Sat Nov 12 21:36:47 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63393129459 for ; Sat, 12 Nov 2016 21:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 5Ovo4CT_HJzq for ; Sat, 12 Nov 2016 21:36:44 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 077CC1293D9 for ; Sat, 12 Nov 2016 21:36:43 -0800 (PST) X-AuditID: 12074425-2f3ff700000010f7-3f-5827fbeb603d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 44.B0.04343.BEBF7285; Sun, 13 Nov 2016 00:36:43 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id uAD5agwr027354; Sun, 13 Nov 2016 00:36:42 -0500 Received: from dhcp-8693.meeting.ietf.org (dhcp-8693.meeting.ietf.org [31.133.134.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAD5abQx028388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 13 Nov 2016 00:36:41 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_E5844E51-3472-4947-AF84-5DCD073880D8" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <41bc8924704d4e68a452d009a80d4227@ustx2ex-dag1mb1.msg.corp.akamai.com> Date: Sun, 13 Nov 2016 14:36:37 +0900 Message-Id: References: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> <3926b25426ea436ba9a8d0510faac599@ustx2ex-dag1mb1.msg.corp.akamai.com> <737CF632-E83D-4C38-99DE-FA04411D0CA0@mit.edu> <41bc8924704d4e68a452d009a80d4227@ustx2ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hRV1n39Wz3CYNUcTov/WzpZLKb0dzI5 MHlMPrKA2WPJkp9MAUxRXDYpqTmZZalF+nYJXBkTb85gLTinW9E98T1TA+MH9S5GDg4JAROJ Vz1ZXYxcHEICbUwS+9rns0M4GxklLs3pY+1i5ARyrjBJrJunA2IzCyRIbL62hQnE5hXQk9i0 /i0TyCBhAS2JaQ1WIGE2AVWJ+StvgZVwCgRLPGu5xwJSwgIU779QBWIyCyhLHL/qBzHESmLO k//MEFu/M0rc3PWJBSQhAlIz8wEjiC0hICvx5OQilgmM/LOQHDELyREQcW2JZQtfM0PYmhL7 u5ezYIprSHR+m8i6gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5qka6FXm5miV5qSukmRlBIs7uo 7mCc89frEKMAB6MSDy9HpnqEEGtiWXFl7iFGSQ4mJVHedypAIb6k/JTKjMTijPii0pzU4kOM EhzMSiK8bt+BcrwpiZVVqUX5MClpDhYlcd7/bl/DhQTSE0tSs1NTC1KLYLIyHBxKErxmwNgV EixKTU+tSMvMKUFIM3FwggznARo+8RfI8OKCxNzizHSI/ClGRSlx3vIPQAkBkERGaR5cLyjl yLe2TX7FKA70ijBvHMgKHmC6gut+BTSYCWjwjDgVkMEliQgpqQZG29XHXa+uLe/XS/35r+Z8 +p3IFyWV06Waohc0VM+sPzd59dxPPxpC7LPWWld0Hy5ZVRVczPTgfeb8VMY3br3SOrWTrnx6 P/vwxE2sZ3g2fZ25UyzpBmPdXbWFzGaatyw0lr6/MSdYfle0xvmqaX9zdhgGO82fdGOFe8SH 9U5SjZO4vR9ty8i6o8RSnJFoqMVcVJwIAP+6kUgUAwAA Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Vectors of Trust (VoT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:36:45 -0000 --Apple-Mail=_E5844E51-3472-4947-AF84-5DCD073880D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2016, at 2:34 PM, Salz, Rich wrote: >=20 > Glad to hear there will be a single wire format. I=E2=80=99d offer to = help with SAML but have frankly purged most XSD and SAML from my working = set. > =20 > Thanks for the explanation, but I don=E2=80=99t think a natural = ordering makes sense: is a thumbprint better than voice? Shrug, YMMV. This is precisely why the authentication method category doesn=E2=80=99t = use numbers =E2=80=94 I=E2=80=99ve seen (online) fights break out over = this! :) Letters still convey *some* order, but it=E2=80=99s less of an = implied rank than a digit. =E2=80=94 Justin > =20 > --=20 > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz --Apple-Mail=_E5844E51-3472-4947-AF84-5DCD073880D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 13, 2016, at 2:34 PM, Salz, Rich <rsalz@akamai.com> = wrote:

Glad to hear there will be a single wire = format.  I=E2=80=99d offer to help with SAML but have frankly = purged most XSD and SAML from my working set.
 
Thanks for the = explanation, but I don=E2=80=99t think a natural ordering makes sense: = is a thumbprint better than voice?  Shrug, YMMV.

This is precisely why the authentication method = category doesn=E2=80=99t use numbers =E2=80=94 I=E2=80=99ve seen = (online) fights break out over this! :) Letters still convey *some* = order, but it=E2=80=99s less of an implied rank than a = digit.

 =E2=80=94 = Justin

 
-- 
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitter: = RichSalz

= --Apple-Mail=_E5844E51-3472-4947-AF84-5DCD073880D8-- From nobody Sat Nov 12 21:53:00 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8A312949B for ; Sat, 12 Nov 2016 21:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 hFltOLvFdxJW for ; Sat, 12 Nov 2016 21:52:56 -0800 (PST) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 860ED12943A for ; Sat, 12 Nov 2016 21:52:56 -0800 (PST) Received: from dummy.name; Sun, 13 Nov 2016 05:52:55 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-74B02A25-CD3F-4B77-BF8C-DEF20549315B Mime-Version: 1.0 (1.0) From: Steve Crocker X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Sun, 13 Nov 2016 14:52:52 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> <3926b25426ea436ba9a8d0510faac599@ustx2ex-dag1mb1.msg.corp.akamai.com> <737CF632-E83D-4C38-99DE-FA04411D0CA0@mit.edu> <41bc8924704d4e68a452d009a80d4227@ustx2ex-dag1mb1.msg.corp.akamai.com> To: Justin Richer Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Vectors of Trust (VoT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 05:52:58 -0000 --Apple-Mail-74B02A25-CD3F-4B77-BF8C-DEF20549315B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Use colors. Sent from my iPhone > On Nov 13, 2016, at 2:36 PM, Justin Richer wrote: >=20 >=20 >> On Nov 13, 2016, at 2:34 PM, Salz, Rich wrote: >>=20 >> Glad to hear there will be a single wire format. I=E2=80=99d offer to he= lp with SAML but have frankly purged most XSD and SAML from my working set. >> =20 >> Thanks for the explanation, but I don=E2=80=99t think a natural ordering m= akes sense: is a thumbprint better than voice? Shrug, YMMV. >=20 > This is precisely why the authentication method category doesn=E2=80=99t u= se numbers =E2=80=94 I=E2=80=99ve seen (online) fights break out over this! := ) Letters still convey *some* order, but it=E2=80=99s less of an implied ran= k than a digit. >=20 > =E2=80=94 Justin >=20 >> =20 >> --=20 >> Senior Architect, Akamai Technologies >> Member, OpenSSL Dev Team >> IM: richsalz@jabber.at Twitter: RichSalz >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-74B02A25-CD3F-4B77-BF8C-DEF20549315B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Use colors.

Sent from my iPhone=

On Nov 13, 2016, at 2:36 PM, Justin Richer <jricher@MIT.EDU> wrote:


On Nov 13, 2016, at 2:34 PM, Salz, Rich <rsalz@akamai.com> wrote:

Gl= ad to hear there will be a single wire format.  I=E2=80=99d offer to he= lp with SAML but have frankly purged most XSD and SAML from my working set.<= o:p class=3D"">
 
Thanks for the explanation, but I d= on=E2=80=99t think a natural ordering makes sense: is a thumbprint better th= an voice?  Shrug, YMMV.

This is precisely why the authenticati= on method category doesn=E2=80=99t use numbers =E2=80=94 I=E2=80=99ve seen (= online) fights break out over this! :) Letters still convey *some* order, bu= t it=E2=80=99s less of an implied rank than a digit.

 =E2=80=94 Justin

 
<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(= 31, 73, 125);" class=3D"">-- 
Senior Architect, Akamai= Technologies
Member, OpenSSL Dev Team<= /span>
IM: ri= chsalz@jabber.at Twitt= er: RichSalz

___________________= ____________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailma= n/listinfo/saag
= --Apple-Mail-74B02A25-CD3F-4B77-BF8C-DEF20549315B-- From nobody Sun Nov 13 09:10:22 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0161294EF for ; Sun, 13 Nov 2016 09:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] 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 ejTXGU6NbA9g for ; Sun, 13 Nov 2016 09:10:17 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 5E8A6126FDC for ; Sun, 13 Nov 2016 09:10:17 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2BDA0780396 for ; Sun, 13 Nov 2016 18:10:14 +0100 (CET) To: saag@ietf.org References: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> From: Denis Message-ID: <31816977-af59-6f61-5c43-13332b39d775@free.fr> Date: Sun, 13 Nov 2016 18:10:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> Content-Type: multipart/alternative; boundary="------------A8A1522C9CC850FFCEEA7FAB" Archived-At: Subject: Re: [saag] Vectors of Trust (VoT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 17:10:21 -0000 This is a multi-part message in MIME format. --------------A8A1522C9CC850FFCEEA7FAB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello Justin, I have several comments on this draft: 1. The intended status of the document is unclear. The content of the draft states "Experimental" while the request is now for "Informational". Considering its content, it should not be Informational. 2. The introduction states: This document defines a mechanism for measuring and signaling several aspects of digital identity and authentication transactions that are used to determine a level of trust in that transaction. The wording "level of trust" is not adequate. Someone trusts (or does not trust) someone else for something. So it is a binary function. The title of the document" Vectors of Trust" is not adequate either. 3. IMO, the four orthogonal components considered in this draft : identity proofing, primary credential usage, primary credential management and assertion presentation are not adequate. This will be explained in detail later on in this email. An identity provider acting as a trusted third party on behalf of a user makes assertions about the user to the relying party. From the point of view of the relying party, there are two information when receiving a signed assertion that would need to be known: 1)the strength of the authentication mechanism that has been used between the user and the identity provider. Such strength could be represented on a linear scale. 2)for each individual attribute present in the assertion: a)*how***that attribute has been verified by the identity provider ? and b)*when*****(i.e. a date) that attribute has been /lastly /verified by the identity provider ? How the verification of an attribute has been done might have two forms: "open loop" or "close loop". To illustrate these concepts let us use the case of an attribute like a postal address. Case 1: Open loop: the postal address has been verified using a passport at the time the user presented the passport to the identity provider. Case 2: Close loop: Initially the postal address has been verified using a passport at the time the user presented the passport to the identity provider, but the identity provider is sending from time to time a letter to that postal address that allows it to make sure that the user is still receiving letters to that address. Let us now consider the four dimensions of the vector proposed in the current draft: The current proposal considers the "Identity Proofing dimension to define, overall, how strongly the set of identity attributes have been verified and vetted". This approach mixes the previous concepts which is inappropriate. The current proposal considers the "primary credential usage dimension defines how strongly the primary credential can be verified by the IdP". This seems to map to the first information proposed here above: the strength of the authentication mechanism that has been used between the user and the identity provider. The current proposal considers the "primary credential management dimension conveys information about the expected life cycle of the primary credential in use, including its binding, rotation, and revocation. In other words, the use and strength of policies, practices, and security controls used in managing the credential at the IdP and its binding to the intended individual". This dimension should be merged with the previous one. The current proposal considers the "Assertion Presentation dimension defines how well the given digital identity can be communicated across the network without information leaking to unintended parties, and without spoofing". First of all, the "digital identity" should be generalized into "attributes". After reading the sentence several times, I must admit that I have difficulties to understand the meaning and the usefulness of such information fromthe point of view of a relying party. IMO, both the content and the title of the draft should be changed. I would propose to consider: -at the level of the assertion, the strength of the authentication mechanism that has been used between the user and the identity provider before obtaining the assertion. Such strength would be represented using a linear scale. -at the level of every attribute contained in an assertion, how (e.g. open loop or close loop) and when (e.g. a date) that attribute has been lastly verified by the identity provider ? This can be seen as : - a "a single dimensional level of confidence" related to an assertion as a whole, and - a "two dimensional level of confidence" related to every attribute present in an assertion. Note that I am purposely using the wording "level of confidence" rather than "level of trust". Denis > Hi all, > > The Vectors of Trust draft was published to this list back in July for > comment, but no discussion was received at the time. > We would like to move this forward as an AD-sponsored informational > RFC (under Kathleen’s aegis). > > The current draft is available here (it hasn’t changed since July): > > https://tools.ietf.org/html/draft-richer-vectors-of-trust-03 > > We’d appreciate review and any commentary that people might have > before this document goes to the next step. > > Thank you, > > — Justin > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------A8A1522C9CC850FFCEEA7FAB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello Justin,


I have several comments on this draft:


1. The intended status of the document is unclear. The content of the draft states "Experimental" while the request is now for "Informational".
    Considering its content, it should not be Informational.

 

2. The introduction states:

This document defines a mechanism for measuring and signaling several aspects of digital identity and authentication transactions
that are used to determine a level of trust in that transaction.

   The wording "level of trust" is not adequate. Someone trusts (or does not trust) someone else for something. So it is a binary function.
   The title of the document" Vectors of Trust" is not adequate either.

 

3. IMO, the four orthogonal components considered in this draft : identity proofing, primary credential usage, primary credential management
    and assertion presentation are not adequate. This will be explained in detail later on in this email.

   An identity provider acting as a trusted third party on behalf of a user makes assertions about the user to the relying party.
   From the point of view of the relying party, there are two information when receiving a signed assertion that would need to be known:

1)     the strength of the authentication mechanism that has been used between the user and the identity provider.
Such strength could be represented on a linear scale.

2)     for each individual attribute present in the assertion:

a)     how that attribute has been verified by the identity provider ?

and

b)     when (i.e. a date) that attribute has been lastly verified by the identity provider ?


How the verification of an attribute has been done might have two forms: "open loop" or "close loop".

To illustrate these concepts let us use the case of an attribute like a postal address.

Case 1: Open loop: the postal address has been verified using a passport at the time the user presented the passport to the identity provider.

Case 2: Close loop: Initially the postal address has been verified using a passport at the time the user presented the passport to the identity provider,
               but the identity provider is sending from time to time a letter to that postal address that allows it to make sure that the user is still receiving letters
               to that address.

Let us now consider the four dimensions of the vector proposed in the current draft:

The current proposal considers the "Identity Proofing dimension to define, overall, how strongly the set of identity attributes have been verified and vetted".
This approach mixes the previous concepts which is inappropriate.

The current proposal considers the "primary credential usage dimension defines how strongly the primary credential can be verified by the IdP".
This seems to map to the first information proposed here above: the strength of the authentication mechanism that has been used between the user
and the identity provider.

The current proposal considers the "primary credential management dimension conveys information about the expected life cycle of the primary credential
in use, including its binding, rotation, and revocation. In other words, the use and strength of policies, practices, and security controls used in managing
the credential at the IdP and its binding to the intended individual". This dimension should be merged with the previous one.

The current proposal considers the "Assertion Presentation dimension defines how well the given digital identity can be communicated across the network
without information leaking to unintended parties, and without spoofing". First of all, the "digital identity" should be generalized into "attributes".
After reading the sentence several times, I must admit that I have difficulties to understand the meaning and the usefulness of such information
from the point of view of a relying party.

IMO, both the content and the title of the draft should be changed. I would propose to consider:

-          at the level of the assertion, the strength of the authentication mechanism that has been used between the user and the identity provider
before obtaining the assertion. Such strength would be represented using a linear scale.

-          at the level of every attribute contained in an assertion, how (e.g. open loop or close loop) and when (e.g. a date)
that attribute has been lastly verified by the identity provider ?


This can be seen as :

   -  a "a single dimensional level of confidence" related to an assertion as a whole, and

   -  a "two dimensional level of confidence" related to every attribute present in an assertion.

Note that I am purposely using the wording "level of confidence" rather than "level of trust".


Denis


Hi all,

The Vectors of Trust draft was published to this list back in July for comment, but no discussion was received at the time.
We would like to move this forward as an AD-sponsored informational RFC (under Kathleen’s aegis). 

The current draft is available here (it hasn’t changed since July):


We’d appreciate review and any commentary that people might have before this document goes to the next step.

Thank you,

 — Justin


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--------------A8A1522C9CC850FFCEEA7FAB-- From nobody Mon Nov 14 18:27:27 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4F2129698 for ; Mon, 14 Nov 2016 18:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 z5BYXBtk2zpV for ; Mon, 14 Nov 2016 18:27:25 -0800 (PST) Received: from smtp112.iad3a.emailsrvr.com (smtp112.iad3a.emailsrvr.com [173.203.187.112]) (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 CE5871296E9 for ; Mon, 14 Nov 2016 18:27:08 -0800 (PST) Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E211F25114 for ; Mon, 14 Nov 2016 21:27:02 -0500 (EST) Received: from app24.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D984624FD2 for ; Mon, 14 Nov 2016 21:27:02 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from app24.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Mon, 14 Nov 2016 21:27:02 -0500 Received: from ogud.com (localhost [127.0.0.1]) by app24.wa-webapps.iad3a (Postfix) with ESMTP id 0631FC032D for ; Mon, 14 Nov 2016 21:27:02 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: ogud@ogud.com, from: ogud@ogud.com) with HTTP; Mon, 14 Nov 2016 21:27:02 -0500 (EST) Date: Mon, 14 Nov 2016 21:27:02 -0500 (EST) From: "Olafur Gudmundsson" To: saag@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20161114212702000000_39004" Importance: Normal X-Priority: 3 (Normal) X-Type: html X-Auth-ID: ogud@ogud.com Message-ID: <1479176822.023525824@apps.rackspace.com> X-Mailer: webmail/12.6.2-RC1 Archived-At: Subject: [saag] DANE report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 02:27:26 -0000 ------=_20161114212702000000_39004 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A =0ADANE did not meet at IETF-97. =0AThe working group has one document = to process, it is in a second WGLC we expect either submit the document or= shutdown the working group at the conclusion of the WGLC. =0A =0AOlafur=0A= ------=_20161114212702000000_39004 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

=0A

DANE did not meet at IETF-97. 

=0A

The working = group has one document to process, it is in a second WGLC we expect either = submit the document  or shutdown the working group at the conclusion o= f the WGLC. 

=0A

 

=0A

Olaf= ur

=0A

 

 ------=_20161114212702000000_39004-- From nobody Mon Nov 14 20:56:55 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96517129A06 for ; Mon, 14 Nov 2016 20:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 tADske0XOP0V for ; Mon, 14 Nov 2016 20:56:42 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 96036129A02 for ; Mon, 14 Nov 2016 20:56:42 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id q124so169057251itd.1 for ; Mon, 14 Nov 2016 20:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=jstIjI/C16Re3avAcZ9/ZCH5DnQ94s1TUDu2hW4sHR4=; b=Wi3f0M1zDNM33Pv5UZmQT8YfZeVoOSe0adlelLR3Uj+eKhnxcrVn6Rr4SCT2VmIpyq owWAZqg0QFYSsVnMO+Op4jHXcMLo1wYUse/ZwsmXLMntWrraiWhPyWVv+QygsR77cjRp VQ7uu7RWMiYNrr4lBr+QHPqAKOs0FBNt6DZw6wHsZwQPWmmkzimpzvDn9yGXqEa7idp0 z4vceUlVP3m5Kb2FYZ4TrwImlajL/L1H+YqAhhJftsl2ufH4qsLfhe4u7V0YCsZUHz9I 04VpmK9JlmD6SURvB/3TuVFA+Yb81ZdabvksrX0vW061HTQeQV0UJzhynhio9lEZFMUu oCQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jstIjI/C16Re3avAcZ9/ZCH5DnQ94s1TUDu2hW4sHR4=; b=dTvxl8ysxlGEiyonWaOFURdpCsqWKjw7297qpVmVK4D6Gk9qB6UWA9Q18TwZPRBz/9 7aFR4Um//+9PYMKUwfGXd6VJ8XMXn5GPt8UebcBt1Y4abLBtBbfRL0n+/k2DeomhIyMV lvFz/SVQIYuohVjaL+Rc5RJ7CedQu6h2AWzfMaZiLr5BSxa7xGkrE8AZU+5P6eI3KLJf 6nljlI0KLqHSYFXsRAq4uGjpl8Vu0l5NOzyxj2ne9zQj96oyglzU7PWxRWWPaJGebzhA 66f0oUryM6svAbnjYWdCDMVSLRO4ouxxwPx7w8bocCQCeK/GGOkq5Mu23Aot+Wm2Q5VQ EAyA== X-Gm-Message-State: ABUngvcGdCtytPjPVIP6c5h9ZY/G+fqCqcfGmQDVHALGKUF+CX6139ZJ9SHaKYObMB0w7UpPxIegmBzQ4Qinqg== X-Received: by 10.157.43.109 with SMTP id f42mr7503455otd.77.1479185801802; Mon, 14 Nov 2016 20:56:41 -0800 (PST) MIME-Version: 1.0 From: Adam Montville Date: Tue, 15 Nov 2016 04:56:31 +0000 Message-ID: To: saag Content-Type: multipart/alternative; boundary=001a11c15dae45fa7a05414fc85f Archived-At: Subject: [saag] SACM Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 04:56:53 -0000 --001a11c15dae45fa7a05414fc85f Content-Type: text/plain; charset=UTF-8 SACM met today and we discussed our architectural approach, how to get software identifiers collected from endpoints, and open issues with our information model. We also started considering how we can keep our information model minimized but extendable based on some real-world state collection data. Next steps include enumerating the functions/interfaces and data that we need flowing through the SACM environment to support our vulnerability assessment scenario. Adam --001a11c15dae45fa7a05414fc85f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SACM met today and we discussed our architectural approach= , how to get software identifiers collected from endpoints, and open issues= with our information model.=C2=A0 We also started considering how we can k= eep our information model minimized but extendable based on some real-world= state collection data. =C2=A0

Next steps include enumer= ating the functions/interfaces and data that we need flowing through the SA= CM environment to support our vulnerability assessment scenario.

Adam
--001a11c15dae45fa7a05414fc85f-- From nobody Mon Nov 14 23:13:20 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0098129A14 for ; Mon, 14 Nov 2016 23:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1qhRozJ9Hsp9 for ; Mon, 14 Nov 2016 23:13:11 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 0623A129A17 for ; Mon, 14 Nov 2016 23:13:11 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id q130so125234328qke.1 for ; Mon, 14 Nov 2016 23:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=Th7/UHGu6lyS1HTTGAqqP7pOhZ6BHXVBeoNU6v3POLE=; b=wPRSrKjpmEhUB16rPGncPdT6E8hvBm8TpuGEQB15hplFDYTCQvtA+MfivAzzwL36dA koRHyIQ6ftdVv+63RhAfdn7osftH1gof5o+c4PfVxZIittGgRkcLDmYtVayHfiMQRWLq acSbSA0r+X0/OrY41XCnpw3cmQC7bah3Y30hU4Db5i29rBGTdSaPRMsz8TKsYdSirAkR rOK10CAArEbIQxE3a8BDwQ/9MN4N5hhYMvq56zybXaSLpO2oapNYEhiD3W9EvKBW1U83 5tfWZ3iOH4MknCXcK6xBY9NAkdn5ej9QxBqa7iHoYq1fJgRGMEclwXH+i6zn6soZ/Pro VSFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Th7/UHGu6lyS1HTTGAqqP7pOhZ6BHXVBeoNU6v3POLE=; b=C3wwu/5PUDRYkC/hlllXdBHm8uFPBiTQVjApz9WGULSMlqFSAMQ+t/3ZL86Ok/3W8R uhrLuOnjrpzNTNPqyLPatRPayLrUnMp/VK4Qi+Y7mntVTr0I3vwCnlj2kNwtAgAp2C90 gMIqLBOZtlvHktP1sGPpH6825fGQJ6qLRgg3OfekBe5iVC9m0bqXlru0qSdcxd+w7Hu3 R5Z7HUn+gcTCEyfpct9+h/7NEQge/NOswpxvV7JHpuUr59jgcBGozC1/qXK8sy8XRhbP eMfaiq3NDU3UPBjGdWwLUm+vIt9d0pN1bQIsldDXnm+R6GLvTqD6hBo4xyQbL7mzpG5j sGTA== X-Gm-Message-State: ABUngvfRj704eSYJbWoEiTNG7yCbp9iAlinU6UARPzfFt9l6WKirwKKsWwyO2R+32PPkwt+Mk5awHxZk5Qc8rg== X-Received: by 10.55.133.134 with SMTP id h128mr14136074qkd.190.1479193989871; Mon, 14 Nov 2016 23:13:09 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.140.92.241 with HTTP; Mon, 14 Nov 2016 23:13:09 -0800 (PST) From: Barry Leiba Date: Tue, 15 Nov 2016 16:13:09 +0900 X-Google-Sender-Auth: o0FnjswhRumRGEnzkTebfxopiz4 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] OPENPGP report for IETF 97 Inbox x X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 07:13:13 -0000 The OPENPGP working group is not meeting at IETF 97. The document editor has gone quiet recently, and the chairs need to do some planning between ourselves and to light some fires. That will happen soon. Barry and Daniel From nobody Tue Nov 15 22:42:25 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21D61294F7 for ; Tue, 15 Nov 2016 22:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 QveVoBYvMoNt for ; Tue, 15 Nov 2016 22:42:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 DB2A11293EE for ; Tue, 15 Nov 2016 22:42:21 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uAG6gHej029664 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 16 Nov 2016 08:42:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uAG6gHs1020851; Wed, 16 Nov 2016 08:42:17 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22571.65481.295343.484167@fireball.acr.fi> Date: Wed, 16 Nov 2016 08:42:17 +0200 From: Tero Kivinen To: saag@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: [saag] IPsecME report for IETF 97 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:42:24 -0000 We have two documents just to be published as RFCs (DDoS and safecurves), and two more ready for IETF Last Call (mandatory to implement algorithms in IKEv2 and IPsec). Other documents are progressing, but are mostly waiting for the pipeline to clear before starting to progress them. This includes TCP encapsulation, Split Dns, EdDSA and Implicit IV. We have had good progress in the Quantum Resistance after Berlin, and we have now updated draft to match the requirements we agreed on the list. This document should be ready for the WG adoptation. We had few new issues and work to be proposed. First issue is the interoperability issue with PSS and PKCS1 v1.5 signatures formats. New work include compressed representation of IKEv2 payloads and using UDP encapsulation for ESP for load-balancing reasons. We did not yet agree whether the WG will start working on those items. Finally we had presentation not directly related to the IPsec, but about making change to the MSEC (which uses IKEv1). -- kivinen@iki.fi From nobody Tue Nov 15 22:49:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA3612951A for ; Tue, 15 Nov 2016 22:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 VHmiQXi75765 for ; Tue, 15 Nov 2016 22:49:52 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 635841294D4 for ; Tue, 15 Nov 2016 22:49:52 -0800 (PST) X-AuditID: 12074423-f63ff70000000e08-7d-582c018e43a9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 82.23.03592.E810C285; Wed, 16 Nov 2016 01:49:50 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id uAG6nnfV012841; Wed, 16 Nov 2016 01:49:50 -0500 Received: from dhcp-8693.meeting.ietf.org (dhcp-8693.meeting.ietf.org [31.133.134.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAG6niDt007329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Nov 2016 01:49:48 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> Date: Wed, 16 Nov 2016 15:49:43 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE20C10-A02E-455E-8169-1B9F52EEB384@mit.edu> To: saag@ietf.org X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6notvHqBNhMG+GjUXDznyLKf2dTA5M Hjtn3WX3WLLkJ1MAUxSXTUpqTmZZapG+XQJXxsW2o4wFzRYVD5YvZWtg3KndxcjJISFgIvF3 2xTWLkYuDiGBNiaJJ7v/M0M4Gxkllv2awwThXGGSWHT0IStIC7OAusSfeZeYQWxeAT2JTevf AhVxcAgLKEt8+wA2lU1AVWL+yltMIDangLXE2ZPrwGwWoPj7BWsZIcZYSGxb/p4NwtaWWLbw NdRIK4krF6+A1QsB2S+PfGMBsUUEBCUe9E1igbhaVuLJyUUsExgFZiG5aBaSi2YhGbuAkXkV o2xKbpVubmJmTnFqsm5xcmJeXmqRrplebmaJXmpK6SZGcJi6KO9gfNnnfYhRgINRiYd3gbp2 hBBrYllxZe4hRkkOJiVR3s/bgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeN/9A8rxpiRWVqUW 5cOkpDlYlMR5/7t9DRcSSE8sSc1OTS1ILYLJynBwKEnwbmTQiRASLEpNT61Iy8wpQUgzcXCC DOcBGn4cpIa3uCAxtzgzHSJ/ilFRSpyX+TvQVgGQREZpHlwvKI3It7ZNfsUoDvSKMC8PMKkI 8QBTEFz3K6DBTECDd5lrgAwuSURISTUwatSc/sfUl7M+vbwxw/2UjG73uXPid8KP6i6evvP5 k5nmjYtqwuWbyiMb5ttaxgrzep+xu6fy8pnN1nxtDmmBv8YWLr62zbxOP+bd8WJVn3Z21dE5 f5nK5nB9vxBn/Nl89kM3edNtaiGK959Ntlm967dW67NT/bP5bff8/DFnAbPQH57X++eeVmIp zkg01GIuKk4EAIaqktv+AgAA Archived-At: Subject: Re: [saag] Vectors of Trust (VoT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:49:55 -0000 Denis, Thanks for the review of the draft and your comments on it.=20 I=E2=80=99ve talked with Kathleen and we=E2=80=99re debating whether to = move this to Experimental or keep it as Informational. Either approach = is fine with me.=20 I disagree that =E2=80=9CTrust=E2=80=9D is a binary term. I believe that = it naturally has a gradient, even in digital systems like this, even if = the final result of the authorization process is a binary decision. = While I agree that =E2=80=9Ctrust=E2=80=9D is a loaded term, I believe = it=E2=80=99s appropriate for use here. Overall, while your insights are appreciated, it really seems to me that = you=E2=80=99re looking for a different solution to a different problem = from what we=E2=80=99re trying to solve here with VoT. I can hope that = any such future solution would be compatible enough to be used in = parallel where necessary. Thank you, =E2=80=94 Justin > Hello Justin, >=20 >=20 > I have several comments on this draft: >=20 >=20 > 1. The intended status of the document is unclear. The content of the=20= > draft states "Experimental" while the request is now for = "Informational". > Considering its content, it should not be Informational. >=20 > 2. The introduction states: >=20 > This document defines a mechanism for measuring and signaling several=20= > aspects of digital identity and authentication transactions > that are used to determine a level of trust in that transaction. >=20 > The wording "level of trust" is not adequate. Someone trusts (or=20= > does not trust) someone else for something. So it is a binary = function. > The title of the document" Vectors of Trust" is not adequate = either. >=20 > 3. IMO, the four orthogonal components considered in this draft :=20 > identity proofing, primary credential usage, primary credential = management > and assertion presentation are not adequate. This will be = explained=20 > in detail later on in this email. >=20 > An identity provider acting as a trusted third party on behalf of = a=20 > user makes assertions about the user to the relying party. > =46rom the point of view of the relying party, there are two=20 > information when receiving a signed assertion that would need to be = known: >=20 > 1)the strength of the authentication mechanism that has been used=20 > between the user and the identity provider. > Such strength could be represented on a linear scale. >=20 > 2)for each individual attribute present in the assertion: >=20 > a)*how***that attribute has been verified by the identity provider ? >=20 > and >=20 > b)*when*****(i.e. a date) that attribute has been /lastly /verified by=20= > the identity provider ? >=20 >=20 > How the verification of an attribute has been done might have two = forms:=20 > "open loop" or "close loop". >=20 > To illustrate these concepts let us use the case of an attribute like = a=20 > postal address. >=20 > Case 1: Open loop: the postal address has been verified using a > passport at the time the user presented the passport to the = identity > provider. >=20 > Case 2: Close loop: Initially the postal address has been verified > using a passport at the time the user presented the passport to = the > identity provider, > but the identity provider is sending from time to > time a letter to that postal address that allows it to make sure > that the user is still receiving letters > to that address. >=20 > Let us now consider the four dimensions of the vector proposed in the=20= > current draft: >=20 > The current proposal considers the "Identity Proofing dimension to > define, overall, how strongly the set of identity attributes have > been verified and vetted". > This approach mixes the previous concepts which is inappropriate. >=20 > The current proposal considers the "primary credential usage > dimension defines how strongly the primary credential can be > verified by the IdP". > This seems to map to the first information proposed here above: = the > strength of the authentication mechanism that has been used = between > the user > and the identity provider. >=20 > The current proposal considers the "primary credential management > dimension conveys information about the expected life cycle of the > primary credential > in use, including its binding, rotation, and revocation. In other > words, the use and strength of policies, practices, and security > controls used in managing > the credential at the IdP and its binding to the intended > individual". This dimension should be merged with the previous = one. >=20 > The current proposal considers the "Assertion Presentation = dimension > defines how well the given digital identity can be communicated > across the network > without information leaking to unintended parties, and without > spoofing". First of all, the "digital identity" should be > generalized into "attributes". > After reading the sentence several times, I must admit that I have > difficulties to understand the meaning and the usefulness of such > information > fromthe point of view of a relying party. >=20 > IMO, both the content and the title of the draft should be changed. I=20= > would propose to consider: >=20 > -at the level of the assertion, the strength of the authentication=20 > mechanism that has been used between the user and the identity = provider > before obtaining the assertion. Such strength would be represented = using=20 > a linear scale. >=20 > -at the level of every attribute contained in an assertion, how (e.g.=20= > open loop or close loop) and when (e.g. a date) > that attribute has been lastly verified by the identity provider ? >=20 >=20 > This can be seen as : >=20 > - a "a single dimensional level of confidence" related to an=20 > assertion as a whole, and >=20 > - a "two dimensional level of confidence" related to every=20 > attribute present in an assertion. >=20 > Note that I am purposely using the wording "level of confidence" = rather=20 > than "level of trust". >=20 >=20 > Denis >=20 >=20 > > Hi all, > > > > The Vectors of Trust draft was published to this list back in July = for=20 > > comment, but no discussion was received at the time. > > We would like to move this forward as an AD-sponsored informational=20= > > RFC (under Kathleen=E2=80=99s aegis). > > > > The current draft is available here (it hasn=E2=80=99t changed since = July): > > > > https://tools.ietf.org/html/draft-richer-vectors-of-trust-03 > > > > We=E2=80=99d appreciate review and any commentary that people might = have=20 > > before this document goes to the next step. > > > > Thank you, > > > > =E2=80=94 Justin > > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Nov 15 23:47:27 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8304E129657 for ; Tue, 15 Nov 2016 23:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 Lgk2ewLuApCa for ; Tue, 15 Nov 2016 23:47:24 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 68C4A1294E4 for ; Tue, 15 Nov 2016 23:47:24 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C4017433427 for ; Wed, 16 Nov 2016 07:47:23 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A0C5843341C for ; Wed, 16 Nov 2016 07:47:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479282443; bh=EB6p9kFaqkpqVcPmIl5jycIrf1yI2+5CRcDMC2j9vlc=; l=4013; h=From:To:Date:From; b=CxUxUXbeRVuPl6sOOQBXU01rYek8jJmPiWmLsCq1LVQLVjBrkkQpQjyxu99LpCaPT N1Z3uDv0ylOlHTaVcVWpAkQ3A+CMF/H3sjbo5BnlieQaG2TB+0BcbDb4rvZQ+Nl3ch Qb9KHtDWNQGjQ1SsNj1jcHaAr+D7ONT086CV47J0= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 9D46D1FDBF for ; Wed, 16 Nov 2016 07:47:23 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 16 Nov 2016 02:47:22 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 16 Nov 2016 02:47:23 -0500 From: "Salz, Rich" To: "saag@ietf.org" Thread-Topic: ACME reportrs Thread-Index: AdI/3Oo0RUFv9megTMKBF1KeX7esxw== Date: Wed, 16 Nov 2016 07:47:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.100] Content-Type: multipart/alternative; boundary="_000_a730bb13aad84b6598fcc32943f48cfbusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [saag] ACME reportrs X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 07:47:26 -0000 --_000_a730bb13aad84b6598fcc32943f48cfbusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ACME met Wednesday. Since the last IETF we resolved almost all issues on o= ur main document, and at the meeting we agreed on proposed resolution for a= ll others. When the new draft is issued, we'll enter WGLC and promote this = as an "implementor's draft," like HTTP-bis did. We'll consider it frozen un= til next IETF, and either re-enter last call or forward up for IESG review = at the next IETF. We had also adopted a CAA draft, had an initial presentation from Yaron on = short-lived certs, and a heads-up on STIR interest on using ACME to get cer= ts for phones. So between now and the next IETF we'll also have discussion= about re-chartering to add these new work items. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_a730bb13aad84b6598fcc32943f48cfbusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ACME met Wednesday.  Since the last IETF we res= olved almost all issues on our main document, and at the meeting we agreed = on proposed resolution for all others. When the new draft is issued, weR= 17;ll enter WGLC and promote this as an “implementor’s draft,” like HTTP-bis did. We’ll consider it frozen until next= IETF, and either re-enter last call or forward up for IESG review at the n= ext IETF.

 

We had also adopted a CAA draft, had an initial pres= entation from Yaron on short-lived certs, and a heads-up on STIR interest o= n using ACME to get certs for phones.  So between now and the next IET= F we’ll also have discussion about re-chartering to add these new work items.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_a730bb13aad84b6598fcc32943f48cfbusma1exdag1mb1msgcorpak_-- From nobody Tue Nov 15 23:53:24 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88FD1294D3 for ; Tue, 15 Nov 2016 23:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xRjC7N2rqNdF for ; Tue, 15 Nov 2016 23:53:21 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 33EF512945B for ; Tue, 15 Nov 2016 23:53:21 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id d2so41588724pfd.0 for ; Tue, 15 Nov 2016 23:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=qiRQbArHkr0PfpMsVG0GJqRf4mFMhmoqd15RDrK4cBc=; b=CWQDO5Z98HcPV0Ywop8U1tesc3y4Q4RyxX2CXikSkSgE1tWAlmpwU+S6WoywZpTdAE 7Ejdi+27tnCvj7Af4GZ3nIq6sKvW6Q+ePDzQW09nI5hT1J0B86CMof39n1s62v7Pc5qN GlV4vNchHVQpT6JmeryL51bGA6pK1RA8J+6gFZNW1EMEsL7FfeWRs+tWM4RC9+tNug+F OP8FSUAMNO451W816EiGHz5/s2wtGg8rGrRg7HRLeObuIeOFAKdjvQ66j1FJ5yOuPN/e btuUjH+QD8ev0toz4iJThfKwNum03ZgjzQnRskF6Quxtm5R4tJPzCmKNbdVBlMh8gqMx 5+cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=qiRQbArHkr0PfpMsVG0GJqRf4mFMhmoqd15RDrK4cBc=; b=NGNS/h/gVwfTRvCLdLZcG8xo7jSW0ORaq17xdIOrhOCDDmQZ9kYIcgAKjAffOQwPPJ DqigGCYMug1zHw9GSaR15+bGG8iTK78sBbyn7+C3mNzXdTb26p3fMB1j/rbULr92JKkr XWqvUJrw6QdMs48W1Qz7EO4EhqiEU2XLq22G5vaXof1eciyZ6o7TthRy44P4AMUSIyM4 MHCs+mSN81rUs7pl832vX+2GFOc/6zHLTwu+IMJwlaURQ/xKjLD7elz9erTdnmogRz49 2hTFFzMnj0zuArQcARGZwtP/S9TmMvSC7OjvMK/gSHG3XeTBKowsnNpjCVK88gh8/irA u0YA== X-Gm-Message-State: ABUngvc2ZkFW5t7MztVy6kyyHRasU9+W4/7R0Jc0buH6wZ4U9z+wOdlM8XS1b6q5OOvUPA== X-Received: by 10.99.62.13 with SMTP id l13mr5439728pga.112.1479282800665; Tue, 15 Nov 2016 23:53:20 -0800 (PST) Received: from t2001067c03700128f55bc8492fd75e89.v6.meeting.ietf.org ([2001:67c:370:128:f55b:c849:2fd7:5e89]) by smtp.gmail.com with ESMTPSA id s8sm50214413pfj.45.2016.11.15.23.53.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 23:53:20 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Wed, 16 Nov 2016 16:53:08 +0900 To: Security Area Advisory Group X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [saag] SecEvent report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 07:53:23 -0000 SecEvent met for the first time Wednesday morning. The proponents = presented the use cases and the two candidate drafts. We have not yet adopted any documents, but there are candidate drafts. = These will be revised and then we=E2=80=99ll issue a call for adoption. Yoav From nobody Wed Nov 16 00:15:48 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD1612968F for ; Wed, 16 Nov 2016 00:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 RkrfKjd8N-lS for ; Wed, 16 Nov 2016 00:15:45 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9AE129684 for ; Wed, 16 Nov 2016 00:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1479284142; d=isode.com; s=june2016; i=@isode.com; bh=dR1puTmuwSLI3D8OZLmbYqbz6KZv7ISGV7myDEuDY2g=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WjWSge3FPdjkEYlin/H87kq2kC4T5lWEw6J36JD/adGXHssUmlHPta+D5UG5kbGWFO70cy ZknxAgphdLa2suMbg2TFzMibOaJgz7B2l3XGA3OLb6prwAtGjAU78UywEnp+uMS4l7w3nK 44v/8UZJzoTwQJTRottBZau9d9WtzuE=; Received: from [31.133.133.241] (dhcp-85f1.meeting.ietf.org [31.133.133.241]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 16 Nov 2016 08:15:42 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov Date: Wed, 16 Nov 2016 17:30:51 +0900 Message-Id: To: saag@ietf.org X-Mailer: iPad Mail (14A456) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-0A191664-1915-4235-A0A1-B3BA2F4DC625 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] CFRG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:15:47 -0000 --Apple-Mail-0A191664-1915-4235-A0A1-B3BA2F4DC625 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable CFRG met for 2 hours on Monday for 2 hours. We had several interesting prese= ntations: update on AES-GCM-SIV document, on re-keying, on new MAC algorithm= to use in NTP, update on hash-based signatures draft. There was also a foll= owup discussion on post quantum cryptography. Also, since the meeting in Berlin, Crypto Review Panel was created. See for the list of c= urrent members and completed reviews. It will be used for reviewing selected= CFRG documents, as well as crypto related documents submitted to ISE or upo= n request from Security ADs. --Apple-Mail-0A191664-1915-4235-A0A1-B3BA2F4DC625 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
CFRG met for 2 hours on Monday for 2 hours. We had several interesting presentations: update on AES-GCM-SIV document, on re-keying, on new MAC algorithm to use in NTP, update on hash-based signatures draft. There was also a followup discussion on post quantum cryptography.

Also, since the meeting in Berlin, Crypto Review Panel was created. See <https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%20Panel> for the list of current members and completed reviews. It will be used for reviewing selected CFRG documents, as well as crypto related documents submitted to ISE or upon request from Security ADs.

--Apple-Mail-0A191664-1915-4235-A0A1-B3BA2F4DC625-- From nobody Wed Nov 16 00:31:09 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95BC1296AC for ; Wed, 16 Nov 2016 00:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 gePJEj06tUdn for ; Wed, 16 Nov 2016 00:31:06 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 8DC29129634 for ; Wed, 16 Nov 2016 00:31:06 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id x23so74090824pgx.1 for ; Wed, 16 Nov 2016 00:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:to; bh=AUXwlQUFKsm6WMgrH7gkWLs/Q+mASbhBZiQStyv9X1E=; b=SI7rJW7FbQS3BKv/xEy1k0gzQ3qF5NMZNeJGvRs1afOz4DBjATrtY2xugOHcXD1tlC qQ00++ObPwhmf+LX3aXY8rmMrBP5zObYp9kzNobVFEjVYnkr1V+LMS9SdIC0uR/AZSUJ PrMZV9NQxmXp4iQHv9On6eEaD7L2X0hCAcPde8h9ydl3IePu4/mAiT0D1KTSsVMpzZog 88xXdsgTIJlA+4BFpduJ17mKOqFTRJBgr9y+AW0sdgUCIQmaFz0BZQPDFFKc+voao/gw FI8APbEIj8dpXb+1KokC+g0+5vbLidtsaOn+LQNsxWKZ7EsRkn/LeYqW6BUHqzuC/KCq MEcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:to; bh=AUXwlQUFKsm6WMgrH7gkWLs/Q+mASbhBZiQStyv9X1E=; b=Q7n/v1vrcbR4/adOAG8aceL68m4TjuNzGwIUp2tQZmem8MgGwRhlzpjD/vp2mqSFBh FL5qy0L07mNytSxdIDSj+08cndzElCKfmBXlHnByvdUqNG+HyxhH2/48ABMCX5EK83KM oAxWzp/G3Gw577c9bsfcspFFXYhrQFTZd4uByw72ENNarWitvlYZ24TQtVXeQPGG89B0 Uz771RahaMIuN52FfXnchwKC8sZ9xUldf8wi+1Ry4qCeepPE0JxT8DK7R5AJiU1PJo3l EVW58qt3S6H2bJAjY1EhWnwKrjj7DGg/8oakYhr4f+HREsn2uGBVIIFQN5woaOV/nDX3 MVlQ== X-Gm-Message-State: ABUngvf3B0bYzsO1m/dOYmlr5R3AYfs96wWy9fL/hlJmG2RA4r3dTkf6q0x6nnQDJ6ZDAw== X-Received: by 10.99.123.22 with SMTP id w22mr5723179pgc.155.1479285066016; Wed, 16 Nov 2016 00:31:06 -0800 (PST) Received: from [31.133.132.184] (dhcp-84b8.meeting.ietf.org. [31.133.132.184]) by smtp.gmail.com with ESMTPSA id 131sm50625752pfx.92.2016.11.16.00.31.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 00:31:05 -0800 (PST) From: kathleen.moriarty.ietf@gmail.com Content-Type: multipart/alternative; boundary=Apple-Mail-CA523971-4B60-4A95-9834-4D0F3B33C027 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 16 Nov 2016 17:30:56 +0900 Message-Id: <75D6B190-D39A-4FFA-BF9C-A3D413E94A1D@gmail.com> References: To: saag@ietf.org X-Mailer: iPhone Mail (14B100) Archived-At: Subject: [saag] Fwd: [tcpinc] FW: NomCom Cal for Feedback and Office Hours: IETF 97 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:31:08 -0000 --Apple-Mail-CA523971-4B60-4A95-9834-4D0F3B33C027 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable If you haven't provided feedback to Nomcom, please consider doing so this we= ek.=20 Thank you. Please excuse typos, sent from handheld device=20 Begin forwarded message: > From: "Black, David" > Date: November 16, 2016 at 3:04:02 PM GMT+9 > To: tcpinc > Subject: [tcpinc] FW: NomCom Cal for Feedback and Office Hours: IETF 97 >=20 > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of N= omCom Chair 2016 > Sent: Friday, November 11, 2016 8:19 PM > To: IETF Announcement List > Cc: ietf@ietf.org > Subject: NomCom Cal for Feedback and Office Hours: IETF 97 >=20 > All - >=20 > Please consider entering your feedback for the 2016-2017 NomCom early this= > week. We'll be doing on site interviews in Seoul and would appreciate your= =20 > inputs as we sort through our options. We have nominees for the IETF Chair= =20 > and the IAOC in addition to the IESG and IAB this cycle: >=20 > https://datatracker.ietf.org/nomcom/2016/feedback/ >=20 > If you have general feedback areas or positions please send email to: >=20 > nomcom-2016 @ ietf.org >=20 > On-site in Seoul you can also give your feedback directly to the NomCom=20= > either by talking with any NomCom Member (identified with an orange dot on= =20 > their badge). The full list of members can be found here: >=20 > https://datatracker.ietf.org/nomcom/2016/ >=20 > or drop by during our open office hours: >=20 > MONDAY 11/14/16 =20 >=20 > 1530-1550 Beverage and Snack Break - 3rd, 5th and 6th Floor Foyers > NomCom Office Hour: Studio 8, 6th floor >=20 > TUESDAY 11/15/16 =20 >=20 > 1530-1550 Beverage and Snack Break - 3rd, 5th and 6th Floor Foyers > NomCom Office Hour: Studio 8, 6th floor =20 >=20 > THURSDAY 11/17/16 =20 >=20 > 1210-1330 Break > NomCom Office Hour: Studio 8, 6th floor =20 > and > 16:50 =20 > NomCom Office Hour: Studio 8, 6th floor =20 >=20 > Thanks - >=20 > Lucy Lynch > NomCom Chair 2016-2017 >=20 > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc --Apple-Mail-CA523971-4B60-4A95-9834-4D0F3B33C027 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If you haven't provided feedback to No= mcom, please consider doing so this week. 

Thank you.

Please excuse typos, sent from handheld device =

Begin forwarded message:

From: "Black, David" <David.Black@dell.com>
Date: November 16, 2016 at 3:04:0= 2 PM GMT+9
To: tcpinc <tcpin= c@ietf.org>
Subject: [tcpinc] FW: NomCom Cal for Feedbac= k and Office Hours: IETF 97

-----Original Message-----
From: IETF-Anno= unce [mailto:ietf-announce= -bounces@ietf.org] On Behalf Of NomCom Chair 2016
Sent: = Friday, November 11, 2016 8:19 PM
To: IETF Announcement List=
Cc: ietf@ietf.org
Subject: NomCom Cal for Feedback and Office Hours: IETF 97

All -

Please co= nsider entering your feedback for the 2016-2017 NomCom early this
= week. We'll be doing on site interviews in Seoul and would appreciate y= our
inputs as we sort through our options. We have nominees= for the IETF Chair
and the IAOC in addition to the IESG an= d IAB this cycle:

https://datatracker.ietf.org/nomcom/20= 16/feedback/

If you have general feedba= ck areas or positions please send email to:

nomcom-2016 @ ietf.org

On-site in Seoul you can also give your feedback directly to th= e NomCom
either by talking with any NomCom Member (identifi= ed with an orange dot on
their badge). The full list of mem= bers can be found here:

https://datatracker.ietf.org/nomcom/2016/=

or drop by during our open office hour= s:

MONDAY    11/14/16   &nbs= p;

   1530-1550    Bev= erage and Snack Break - 3rd, 5th and 6th Floor Foyers
 = ;  NomCom Office Hour: Studio 8, 6th floor

<= span>TUESDAY    11/15/16    

=    1530-1550    Beverage and Snack Break - 3rd, 5= th and  6th Floor Foyers
   NomCom Office Ho= ur: Studio 8, 6th floor    

THUR= SDAY    11/17/16    

&= nbsp;  1210-1330    Break
   NomCo= m Office Hour: Studio 8, 6th floor    
and=
   16:50    
   No= mCom Office Hour: Studio 8, 6th floor    
=
Thanks -

Lucy Lynch
NomCom Chair 2016-2017

_________________= ______________________________
Tcpinc mailing listTcpinc@ietf.org
https://www.ietf.= org/mailman/listinfo/tcpinc
= --Apple-Mail-CA523971-4B60-4A95-9834-4D0F3B33C027-- From nobody Wed Nov 16 00:33:41 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C631294A2 for ; Wed, 16 Nov 2016 00:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 UHE4obB5gUCI for ; Wed, 16 Nov 2016 00:33:37 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 959211294AE for ; Wed, 16 Nov 2016 00:33:37 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id f188so76662822pgc.3 for ; Wed, 16 Nov 2016 00:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:from:mime-version:date:subject:message-id :references:to; bh=AUXwlQUFKsm6WMgrH7gkWLs/Q+mASbhBZiQStyv9X1E=; b=z0eDnunFyjyzPrFFalYviJk+rIyPW+gNMpWhvhpvlO5e+nnipFlODT3oqB9M3WVsJt h1zOKCat4Qt8tNVF7JSlOjLcTbkzR9/xwbixTFIZBtXVuvKjD1xiNSEMLiNJ+qVBLqaR Tdnsvy2jVXvS1lYRNutO/z1Ga31CV2aFvxeq1aUsekf8BG+4rsfOIZDC708GneFpnVO2 +yH1xcjBoJidZfnfd1K+gAUs5G7i0Roz2FDXNUGTA3Q5e7UVII1B18WA0GObGRbqWyVl gYokUT5bhJdJ3bQepoihYjd5QwScUsFXNHrPGaRVwpupUUL/EA/SK+P31gVlioyccsoN 77Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:references:to; bh=AUXwlQUFKsm6WMgrH7gkWLs/Q+mASbhBZiQStyv9X1E=; b=f1AmY7SK1uGo6Po6NIKs1bHQ/du/QtmFgm73gQIYNoCKz9h6w8Y48ks8Qsci3V78sO mnFJ9RwncqYSdTAk3SGDZ4t/gm9iBmOXLV7UKl0ljTw8z2HvxSsErtw2osloSEB/E81z 3otmIFp04cfTpeKqGZ+8eEP86NdGmFw/8PNZbSiWICl/4ypbX+hR3+ps7+9vDebRZZJx ax1qMsLy+LUGar3EeJ+LVSvohzacdxW3wAN4Ua8ZZJf0TRsXK2awMKLuSQXnWd6bKmwW f04pu0QQwPTSahVa4AiSwrjaCzi9buKaqbYqp3mCJRoSK1DxGLCOmACwaErrVWoBsUP4 PAPQ== X-Gm-Message-State: ABUngvfxwJYBsGTvjv3uOJlUmOoFGimbsoxgIqVirWRw9nLQFxfpSOxRmawDKTRvapyARQ== X-Received: by 10.99.189.1 with SMTP id a1mr5736978pgf.142.1479285217019; Wed, 16 Nov 2016 00:33:37 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:7402:5168:b1e:3339? ([2001:67c:370:128:7402:5168:b1e:3339]) by smtp.gmail.com with ESMTPSA id m19sm18019495pfi.24.2016.11.16.00.33.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 00:33:36 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-CA523971-4B60-4A95-9834-4D0F3B33C027 Content-Transfer-Encoding: 7bit From: kathleen.moriarty.ietf@gmail.com Mime-Version: 1.0 (1.0) Date: Wed, 16 Nov 2016 17:30:56 +0900 Message-Id: <75D6B190-D39A-4FFA-BF9C-A3D413E94A1D@gmail.com> References: To: saag@ietf.org X-Mailer: iPhone Mail (14B100) Archived-At: Subject: [saag] Fwd: [tcpinc] FW: NomCom Cal for Feedback and Office Hours: IETF 97 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:33:40 -0000 --Apple-Mail-CA523971-4B60-4A95-9834-4D0F3B33C027 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable If you haven't provided feedback to Nomcom, please consider doing so this we= ek.=20 Thank you. Please excuse typos, sent from handheld device=20 Begin forwarded message: > From: "Black, David" > Date: November 16, 2016 at 3:04:02 PM GMT+9 > To: tcpinc > Subject: [tcpinc] FW: NomCom Cal for Feedback and Office Hours: IETF 97 >=20 > -----Original Message----- > From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of N= omCom Chair 2016 > Sent: Friday, November 11, 2016 8:19 PM > To: IETF Announcement List > Cc: ietf@ietf.org > Subject: NomCom Cal for Feedback and Office Hours: IETF 97 >=20 > All - >=20 > Please consider entering your feedback for the 2016-2017 NomCom early this= > week. We'll be doing on site interviews in Seoul and would appreciate your= =20 > inputs as we sort through our options. We have nominees for the IETF Chair= =20 > and the IAOC in addition to the IESG and IAB this cycle: >=20 > https://datatracker.ietf.org/nomcom/2016/feedback/ >=20 > If you have general feedback areas or positions please send email to: >=20 > nomcom-2016 @ ietf.org >=20 > On-site in Seoul you can also give your feedback directly to the NomCom=20= > either by talking with any NomCom Member (identified with an orange dot on= =20 > their badge). The full list of members can be found here: >=20 > https://datatracker.ietf.org/nomcom/2016/ >=20 > or drop by during our open office hours: >=20 > MONDAY 11/14/16 =20 >=20 > 1530-1550 Beverage and Snack Break - 3rd, 5th and 6th Floor Foyers > NomCom Office Hour: Studio 8, 6th floor >=20 > TUESDAY 11/15/16 =20 >=20 > 1530-1550 Beverage and Snack Break - 3rd, 5th and 6th Floor Foyers > NomCom Office Hour: Studio 8, 6th floor =20 >=20 > THURSDAY 11/17/16 =20 >=20 > 1210-1330 Break > NomCom Office Hour: Studio 8, 6th floor =20 > and > 16:50 =20 > NomCom Office Hour: Studio 8, 6th floor =20 >=20 > Thanks - >=20 > Lucy Lynch > NomCom Chair 2016-2017 >=20 > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc --Apple-Mail-CA523971-4B60-4A95-9834-4D0F3B33C027 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If you haven't provided feedback to No= mcom, please consider doing so this week. 

Thank you.

Please excuse typos, sent from handheld device =

Begin forwarded message:

From: "Black, David" <David.Black@dell.com>
Date: November 16, 2016 at 3:04:0= 2 PM GMT+9
To: tcpinc <tcpin= c@ietf.org>
Subject: [tcpinc] FW: NomCom Cal for Feedbac= k and Office Hours: IETF 97

-----Original Message-----
From: IETF-Anno= unce [mailto:ietf-announce= -bounces@ietf.org] On Behalf Of NomCom Chair 2016
Sent: = Friday, November 11, 2016 8:19 PM
To: IETF Announcement List=
Cc: ietf@ietf.org
Subject: NomCom Cal for Feedback and Office Hours: IETF 97

All -

Please co= nsider entering your feedback for the 2016-2017 NomCom early this
= week. We'll be doing on site interviews in Seoul and would appreciate y= our
inputs as we sort through our options. We have nominees= for the IETF Chair
and the IAOC in addition to the IESG an= d IAB this cycle:

https://datatracker.ietf.org/nomcom/20= 16/feedback/

If you have general feedba= ck areas or positions please send email to:

nomcom-2016 @ ietf.org

On-site in Seoul you can also give your feedback directly to th= e NomCom
either by talking with any NomCom Member (identifi= ed with an orange dot on
their badge). The full list of mem= bers can be found here:

https://datatracker.ietf.org/nomcom/2016/=

or drop by during our open office hour= s:

MONDAY    11/14/16   &nbs= p;

   1530-1550    Bev= erage and Snack Break - 3rd, 5th and 6th Floor Foyers
 = ;  NomCom Office Hour: Studio 8, 6th floor

<= span>TUESDAY    11/15/16    

=    1530-1550    Beverage and Snack Break - 3rd, 5= th and  6th Floor Foyers
   NomCom Office Ho= ur: Studio 8, 6th floor    

THUR= SDAY    11/17/16    

&= nbsp;  1210-1330    Break
   NomCo= m Office Hour: Studio 8, 6th floor    
and=
   16:50    
   No= mCom Office Hour: Studio 8, 6th floor    
=
Thanks -

Lucy Lynch
NomCom Chair 2016-2017

_________________= ______________________________
Tcpinc mailing listTcpinc@ietf.org
https://www.ietf.= org/mailman/listinfo/tcpinc
= --Apple-Mail-CA523971-4B60-4A95-9834-4D0F3B33C027-- From nobody Wed Nov 16 00:52:20 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50302129542 for ; Wed, 16 Nov 2016 00:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_MIMEOLE=1.899, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org 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 9t4Dmw_-3cJK for ; Wed, 16 Nov 2016 00:52:16 -0800 (PST) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3C5129634 for ; Wed, 16 Nov 2016 00:52:11 -0800 (PST) Received: from seraph (dhcp-814a.meeting.ietf.org [31.133.129.74]) by gondrom.org (Postfix) with ESMTPSA id 27575631B6; Wed, 16 Nov 2016 09:52:07 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=f1K37pubsBmTHmojD49naiJIDXaZaUH9QQd8sx7b7xa5oIniKwu5qO0MFTLqXlaii0yKeqRVn4CMoyoai3bwp+zbyAZrb57vitKIIusC4qRrn0u7kkS7U8duVPoLXjZ3p+T190NPJGvQ152TC42ZttLi8gef6LHk8bzp+CNvmS4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:Thread-Index:Content-Language:Importance; From: "Tobias Gondrom" To: Date: Wed, 16 Nov 2016 17:51:53 +0900 Message-ID: <012201d23fe6$b018f7e0$104ae7a0$@gondrom.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_01D24032.2001D860" X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdI/5bRjfF/KEXiHS6C3DGKOpYxMlg== Content-Language: en-us Importance: Low Archived-At: Subject: [saag] DOTS report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:52:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0123_01D24032.2001D860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The DOTS WG has not met yet. The DOTS WG meeting is scheduled for Friday 9:30 KST. We have a very full agenda for the upcoming meeting. Looking at use cases, requirements, architecture, information model and several protocol proposals. And there was one design team meeting on Tuesday about the use cases and will be another design team meeting about the protocol drafts on Thursday (at 12:10KST at Studio 7 on 6th floor). Best regards, Tobias & Roman (co-chairs DOTS) ------=_NextPart_000_0123_01D24032.2001D860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The DOTS WG has not met yet. The DOTS WG meeting is = scheduled for Friday 9:30 KST.

We = have a very full agenda for the upcoming meeting.

Looking at use cases, requirements, architecture, = information model and several protocol proposals.

 

And there = was one design team meeting on Tuesday about the use cases and will be = another design team meeting about the protocol drafts on Thursday (at = 12:10KST at Studio 7 on 6th floor).

 

Best = regards,

 

Tobias & Roman

(co-chairs DOTS)

------=_NextPart_000_0123_01D24032.2001D860-- From nobody Wed Nov 16 01:58:54 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC261296B9 for ; Wed, 16 Nov 2016 01:58:53 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 6-M5i9YZrhXW for ; Wed, 16 Nov 2016 01:58:51 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 9BA0C129476 for ; Wed, 16 Nov 2016 01:58:51 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id c20so200909380itb.0 for ; Wed, 16 Nov 2016 01:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Ra01f2J1psKTYvHzvrkcOurNNGEbx05/OOWlnA6scQw=; b=Dou07HeRd3M0JTYEW/ysVGa8tjDPiy0PBtnItwhQpQK0ksgVeVa9uyRa/VfPkhgd9X Mu7mMGFt/kkcxB9G828Ps6+UlbU4dNK4zqh90EmejbX+DP9Qybct6WJUbSGln5uDg7Ay V0qrkqzRXYoJTAfJ7UHn2MeQ17l9cJeYtoE/KBLZhGawODi5sjKpVFHWdLXYNNQYlH8H sVyy3HPelVJmIU7udX1zJ6wYs0Qa4yZcOjh/MyjDvKpGuRlaO9GNSj/wmbLfmlyB6IRQ 1S+TP7s3Hl3v6T0JdNzjMpb4fYdEltocB7mBQPl9eczylWhHFf6UZWHtyIXUGKgHQBso jn4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ra01f2J1psKTYvHzvrkcOurNNGEbx05/OOWlnA6scQw=; b=OKG0g+fa5oJDCo0tMkA7cM7swAspEfff2NSTK0eAzueyuUZOSEe9ywXeJ0+n4P2cnG cclc9h5qq1N/4K2XiQ9kXWXIIXrKqhwNSp+RVItI9qW+bVCy8zkajM7Ppndh/wwNycX/ CgAyECdAxCjLvgg8NUDqt0ni2pU9HdNeBVbL77BqX10ZE5M6Rny8dJVVkq45s6vhtFnL HOwEnCK+As+S1+GhUbzo/CNmakHgMa8SekVrODLhJZu6Hq8UuUkWCCoVqszWgztlZ4iZ RKbHpI9wf8HGol7b2+j8/qY09jbNUbpaBTDO4Ind8CZnjNElwCRaZ/0zf/g2tlkZRtTk lOAw== X-Gm-Message-State: ABUngvdbt/hdZttQ3fJ77XK61TnTmEmMkRkSoec8Mbo2kAQanLhdJmuFt72C0zKu21LMkcKhqkYS/44h7SF8Kg== X-Received: by 10.36.29.136 with SMTP id 130mr7386933itj.57.1479290330646; Wed, 16 Nov 2016 01:58:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.118.216 with HTTP; Wed, 16 Nov 2016 01:58:30 -0800 (PST) From: Joseph Salowey Date: Wed, 16 Nov 2016 18:58:30 +0900 Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a114396e4ad9b030541681edf Archived-At: Subject: [saag] TLS working group report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 09:58:53 -0000 --001a114396e4ad9b030541681edf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The TLS working group met on Tuesday afternoon and will meet again on Friday. TLS 1.3 is in working group last call and final cryptographic review. The cryptographic review will continue until the end of January. We spent most of the first session resolving issues raised during last call. If you plan on reviewing the draft please do it soon. There was consensus in the room to keep the name of the protocol as TLS 1.3. There were several TLS 1.3 implementations interoperating at the IETF 97 Hackathon. draft-ietf-tls-rfc4492bis and draft-ietf-tls-ecdhe-psk-aead will be going to working group last call soon. We=E2=80=99re going to ask our AD to invo= ke some process to uplift 5289 from Informational to Standards Track. --001a114396e4ad9b030541681edf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The TLS working group met= on Tuesday afternoon and will meet again on Friday.=C2=A0 TLS 1.3 is in wo= rking group last call and final cryptographic review.=C2=A0 The cryptograph= ic review will continue until the end of January.=C2=A0 We spent most of th= e first session resolving issues raised during last call.=C2=A0 If you plan= on reviewing the draft please do it soon.=C2=A0 There was consensus in the= room to keep the name of the protocol as TLS 1.3.=C2=A0 There were several= =C2=A0TLS 1.3 implementations interoperating at the IETF 97 Hackathon.=C2= =A0

draft-ietf-tls-rfc4492bis and draft-ietf-tls-ecdhe-psk-aead will = be going to working group last call soon. =C2=A0We=E2=80=99re going to ask our AD to invoke some process to up= lift 5289 from Informational to Standards Track.

<= /div> --001a114396e4ad9b030541681edf-- From nobody Wed Nov 16 03:26:48 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FE0129784; Wed, 16 Nov 2016 03:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497] 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 aJWhEXw6K-7q; Wed, 16 Nov 2016 03:26:45 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 38FAD12978C; Wed, 16 Nov 2016 03:26:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tJhmK1g64z3Hs; Wed, 16 Nov 2016 12:26:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1479295601; bh=o2/1TUeOGluJhZZ6YxupBa0E/OUgh9ATdO39gFE5zcM=; h=Date:From:To:Subject; b=fvtbPHrtEn12I8exXInO1xser6p4fKzaZ8so2aNUP5tB7gb1Bcl76DvtRsisQTr6T sHAc2ptW784g3gmp8DFCXvDRThE6QKatZr2J6QW5Dw2Atlz1Tztbvfjx74BfAOhN/v bL6aRwo0/0nnkKa/uepVdnvwAfpESbymFpoougng= 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 yoNYU5LXL_X2; Wed, 16 Nov 2016 12:26:40 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 16 Nov 2016 12:26:40 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 636A65C83A; Wed, 16 Nov 2016 06:26:38 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 636A65C83A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5EF1E40B7E88; Wed, 16 Nov 2016 06:26:38 -0500 (EST) Date: Wed, 16 Nov 2016 06:26:38 -0500 (EST) From: Paul Wouters To: saag@ietf.org, Trans Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [saag] Trans report for IETF 97 Seoul X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 11:26:47 -0000 We had a short meeting - Discussed the 6962bis document. * People agreed with section 5.1 MUST -> Should change. Eran will provide text in updated version. * Privacy concerns (personal certificates) out of scope for bis document (provided Section 5.1 is changed from MUST to SHOULD) * Once Section 5.1 is changed, document is ready for IESG. * Historic STH fetching - Agreement it does not affect bis document and can be done in new work for Log Monitoring API - Name Redaction * Some interest and new ideas. Continue discussion on mailing list - Threat document. Chairs asked for Editor on document as current author has been unavailable and updates discussed on the list take too long to get into the document. Eran volunteered (Thanks!) - Some new interest in binaries logging - No update to dnssec or gossip documents - Expect-CT header in TLS: To be discussed thursday at httpbis - Interest in Log monitoring API - to happen on the list. Paul and Melinda From nobody Wed Nov 16 05:27:35 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A890C12957A for ; Wed, 16 Nov 2016 05:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.017 X-Spam-Level: X-Spam-Status: No, score=-16.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 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 vsTiOwaOc74x for ; Wed, 16 Nov 2016 05:27:32 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26081294C3 for ; Wed, 16 Nov 2016 05:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3282; q=dns/txt; s=iport; t=1479302850; x=1480512450; h=from:to:subject:date:message-id:mime-version; bh=OWI0LDsDrbEyPMssDokb1mJCEFdOaFb1cfANeJnKl6o=; b=VFkIcN0TKz9OooVT1l30pfo5fgPHRLg8KnlYI0lzjAP31pMo8rlVB/Vg OFF9+E/L6niNGtNHCW4rxKJJNPJj3H52IX/q0+62qbjySKjIjHOWH9EJz 7hEAs3CxZ+HRuzzb91YH9hGh0+ofqfG9K8sFx7ws8itGzSmvooZ2Fy/cP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAwCbXSxY/4YNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgnNEAQEBAQEfWIEAB7QMgw2CDoIHKIYVgXlAEwECAQEBAQEBAWIdC4R?= =?us-ascii?q?oI2gBDAE9AgQwJwSIfw6iJY98gimLYgEBAQcBAQEBHgWMOYJ4EQGDIIJdBZRah?= =?us-ascii?q?WgBhj2KKoFwjjOHQooUASABNF0qhTlyAYU8gSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,500,1473120000"; d="scan'208,217";a="349091336" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2016 13:27:30 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uAGDRT4s019043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 16 Nov 2016 13:27:29 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 16 Nov 2016 08:27:29 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 16 Nov 2016 08:27:29 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "saag@ietf.org" Thread-Topic: ANIMA WG report Thread-Index: AQHSQA0tiWSlfwVWDUKPJvpUZzz4lA== Date: Wed, 16 Nov 2016 13:27:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.108.90] Content-Type: multipart/alternative; boundary="_000_D4519EBE199263ncamwingciscocom_" MIME-Version: 1.0 Archived-At: Subject: [saag] ANIMA WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 13:27:34 -0000 --_000_D4519EBE199263ncamwingciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QU5JTUEgbWV0IHRvZGF5IGFuZCBtZWV0cyBhZ2FpbiBvbiBGcmlkYXkgbW9ybmluZy4gIFRvZGF5 4oCZcyBzbG90IGZvY3VzZWQgb24gdXBkYXRlcyB0byB0aGUgR1JBU1AsIEFDUCBhbmQgQlJLU0kg ZHJhZnRzLg0KVXBkYXRlIHRvIG5laWdoYm9yIGRpc2NvdmVyIGluIHRoZSBBdXRvbm9taWMgQ29u dHJvbCBQbGFuZSAoQUNQOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1h bmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFuZS0wNCkNCk5vdyBhbGxvd3MgdGhlIHVzZSBvZiBh IOKAnERpc2NvdmVyeSBVbnNvbGljaXRlZCBMaW5rIExvY2Fs4oCdIG1lY2hhbmlzbSB0byBhbGxv dyBmb3IgYW4gaW5zZWN1cmUgaW5zdGFuY2Ugb2YgR1JBU1AgdG8gZW5hYmxlIGJvb3RzdHJhcHBp bmcNCnVzZSBjYXNlcy4gIFRoZSB1cGRhdGUgaXMgYWxzbyByZWZsZWN0ZWQgaW4gR1JBU1AgKGh0 dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1hbmltYS1ncmFzcC0wOC50 eHQpDQoNClRoZXJlIHdhcyBhbHNvIGRpc2N1c3Npb24gb2YgdGhlIHZvdWNoZXIgcmV2b2NhdGlv biBpbiBCUktTSSB0byBhbGxvdyBmb3IgYmV0dGVyIGNvb3JkaW5hdGlvbiB3aXRoIGVmZm9ydHMg aW4gb3RoZXIgd29ya2luZyBncm91cHMuDQpPdGhlciBkaXNjdXNzaW9ucyBhbmQgcHJlc2VudGF0 aW9ucyB3aWxsIGNvbnRpbnVlIG9uIEZyaWRheSBhbmQgb24gdGhlIGVtYWlsIHJlZmxlY3Rvci4N Cg0KTmFuY3kuDQo= --_000_D4519EBE199263ncamwingciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5BTklNQSBtZXQg dG9kYXkgYW5kIG1lZXRzIGFnYWluIG9uIEZyaWRheSBtb3JuaW5nLiAmbmJzcDtUb2RheeKAmXMg c2xvdCBmb2N1c2VkIG9uIHVwZGF0ZXMgdG8gdGhlIEdSQVNQLCBBQ1AgYW5kIEJSS1NJIGRyYWZ0 cy48L2Rpdj4NCjxkaXY+VXBkYXRlIHRvIG5laWdoYm9yIGRpc2NvdmVyIGluIHRoZSBBdXRvbm9t aWMgQ29udHJvbCBQbGFuZSAoQUNQOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLTA0Ij5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJv bC1wbGFuZS0wNDwvYT4pPC9kaXY+DQo8ZGl2Pk5vdyBhbGxvd3MgdGhlIHVzZSBvZiBhIOKAnERp c2NvdmVyeSBVbnNvbGljaXRlZCBMaW5rIExvY2Fs4oCdIG1lY2hhbmlzbSB0byBhbGxvdyBmb3Ig YW4gaW5zZWN1cmUgaW5zdGFuY2Ugb2YgR1JBU1AgdG8gZW5hYmxlIGJvb3RzdHJhcHBpbmc8L2Rp dj4NCjxkaXY+dXNlIGNhc2VzLiAmbmJzcDtUaGUgdXBkYXRlIGlzIGFsc28gcmVmbGVjdGVkIGlu IEdSQVNQICg8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWll dGYtYW5pbWEtZ3Jhc3AtMDgudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2Ry YWZ0LWlldGYtYW5pbWEtZ3Jhc3AtMDgudHh0PC9hPik8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlRoZXJlIHdhcyBhbHNvIGRpc2N1c3Npb24gb2YgdGhlIHZvdWNoZXIgcmV2b2NhdGlv biBpbiBCUktTSSB0byBhbGxvdyBmb3IgYmV0dGVyIGNvb3JkaW5hdGlvbiB3aXRoIGVmZm9ydHMg aW4gb3RoZXIgd29ya2luZyBncm91cHMuPC9kaXY+DQo8ZGl2Pk90aGVyIGRpc2N1c3Npb25zIGFu ZCBwcmVzZW50YXRpb25zIHdpbGwgY29udGludWUgb24gRnJpZGF5IGFuZCBvbiB0aGUgZW1haWwg cmVmbGVjdG9yLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFw cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+TmFuY3kuPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D4519EBE199263ncamwingciscocom_-- From nobody Wed Nov 16 13:22:33 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BF6129588 for ; Wed, 16 Nov 2016 13:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 nXYkP8U50GGs for ; Wed, 16 Nov 2016 13:22:30 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 B4E45129456 for ; Wed, 16 Nov 2016 13:22:28 -0800 (PST) X-AuditID: 12074424-62fff700000043c5-0e-582cce12cfbf Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 5E.48.17349.21ECC285; Wed, 16 Nov 2016 16:22:27 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id uAGLMQfm011354 for ; Wed, 16 Nov 2016 16:22:26 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uAGLMNER001369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 16 Nov 2016 16:22:25 -0500 Date: Wed, 16 Nov 2016 15:22:23 -0600 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20161116212222.GC86797@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUixG6nrit8TifCYNYVfosp/Z1MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOLJkHVNBG3vF+em9jA2M71m7GDk5JARMJO4f2M/UxcjFISTQ xiSx/thnVgjnKKPEucuHWSCcl0wST+fOYgRpYRFQlVgxbQsziM0moCLR0H0ZzBYREJR40DcJ qIGDQ1hATOL3HTeQMC/QhrkN91khbEGJkzOfsIDYzAJaEjf+vWQCKWcWkJZY/o8DJCwqoCzR MOMB8wRG3llIOmYh6ZiF0LGAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZG cCC5qOxg7O7xPsQowMGoxMMrUaQTIcSaWFZcmXuIUZKDSUmUd8MxoBBfUn5KZUZicUZ8UWlO avEhRgkOZiUR3k2ngHK8KYmVValF+TApaQ4WJXFeBvev4UIC6YklqdmpqQWpRTBZGQ4OJQne V2eAGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGS4HU8BYXJOYWZ6ZD5E8x6nK82/zuAZMQS15+XqqU OO+GA0BFAiBFGaV5cHNACUAie3/NK0ZxoLeEeb3PAlXxAJMH3KRXQEuYgJbsEQBbUpKIkJJq YCySfMRgw/Pg1a3M5z4fdLhzG+cVLXHycJZaU653xU1LcFfqBLm23cpXPpQzRxst1FRvPXlu iUHpr9gklc48m7gJ4enH6iPOys7tK5l4+MlJr4Wf2fnffK5lmD9ZZ0f3ASe3xV0ndte+277c Xtv1xquIsOPPtt5ZOuHofqNT4rdOmLUYprAvO6nEUpyRaKjFXFScCADHriqX2wIAAA== Archived-At: Subject: [saag] kitten report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 21:22:32 -0000 kitten is not meeting in Seoul. Since Berlin, we published RFC 8009 (AES Encryption with HMAC-SHA2 for Kerberos 5) and have sent draft-ietf-kitten-rfc6112bis and draft-ietf-kitten-pkinit-freshness to the IESG. draft-ietf-kitten-pkinit-alg-agility and draft-ietf-kitten-rfc5653bis should be ready soon as we try to clear some of the backlog of documents that has accumulated. We have been getting help with document shepherding from Matt Rogers, giving the chairs some more time for other organizational tasks. We are happy with our experiment in declaring WG consensus without an explicit WGLC period, but do not have our tracking infrastructure set up quite how we want yet. We have some exciting individual documents waiting in the wings for SPAKE/multifactor preauthentication and improved service discovery using DNS that we hope to adopt as WG documents before Chicago. -Ben From nobody Wed Nov 16 16:06:50 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F321295AD; Wed, 16 Nov 2016 16:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 x-vBrkMRYpqV; Wed, 16 Nov 2016 16:06:47 -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 E1AA4129478; Wed, 16 Nov 2016 16:06:46 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4677828B003B; Wed, 16 Nov 2016 19:06:46 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3F3411F8056; Wed, 16 Nov 2016 19:06:46 -0500 (EST) From: Sandra Murphy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2016 19:06:45 -0500 Message-Id: <8456FC7C-17B6-4AC6-B113-3B987DEBCC75@parsons.com> To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: sidr chairs , Sandra Murphy Subject: [saag] SIDR report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:06:48 -0000 Meeting: 15:20-17:50 Thursday Afternoon session II, Chris Morrow = chairing WG highlights and status summary: =E2=80=A2 one new RFC since last IETF =E2=80=A2 12 drafts in or past publication requested status =E2=80=A2 4 in AD Evaluation, 2 in IETF Last Call =E2=80=A2 7 drafts still active in the working group =E2=80=A2 Great level of comment from the AD on BGPsec protocol =E2=80=A2 SIDR will be moving work to SIDROps - short discussion = of SIDROps on agenda =E2=80=A2 two interop/testing discussions on agenda (Sandy Murphy not present in Seoul) =E2=80=94Sandy= From nobody Wed Nov 16 16:26:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0673B1295E1 for ; Wed, 16 Nov 2016 16:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 GVZQ-_eDI13l for ; Wed, 16 Nov 2016 16:26:01 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 20BDC1295DE for ; Wed, 16 Nov 2016 16:26:01 -0800 (PST) Received: from dhcp-89c4.meeting.ietf.org (dhcp-89c4.meeting.ietf.org [31.133.139.196] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAH0Pw5n002843 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 16 Nov 2016 18:26:00 -0600 (CST) (envelope-from rjsparks@nostrum.com) To: saag@ietf.org From: Robert Sparks Message-ID: <49043617-08de-3127-aa9f-265a70b49554@nostrum.com> Date: Thu, 17 Nov 2016 09:25:58 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Remember that reports can be held in the datatracker X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:26:02 -0000 I see a bunch of reports to the list that haven't been added to the tracker. That's ok if you don't want to enter them, but I wanted to make sure people remembered that you _can_ add the report so that it's available in the proceedings and from your group page. Look for the "Status Update" line on your group's charter page. RjS (ps. I already have a request from Rich to have the datatracker send the report to the list when you enter it into the tracker so you only have to do work in one place.) From nobody Wed Nov 16 16:33:08 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713FA12946F for ; Wed, 16 Nov 2016 16:33:07 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.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 v7xX5_0PaFmn for ; Wed, 16 Nov 2016 16:33:05 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 D0D83126579 for ; Wed, 16 Nov 2016 16:33:05 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id f188so84489483pgc.3 for ; Wed, 16 Nov 2016 16:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=SHUx7LglZ+iovKKPJeU3YArEXAq7OAW3HWlIfRQuf4U=; b=wIwXKx2svyR92DFeqtlQ5hr0c+qWdwi3sAzds1Mr3FssM+HdtgaAtyRV7YqfX1jgHS Ns5hceBOD8EC7iF6RVwvgNl/7+tSISXxxrp4TvYaZp7nOr0sDiHqgmaUiHLwTTQkT3WO 0DGGfsqyh+4CQ5YUSbA6611I3vRmHdJWgLqSsHQWK1pvOW8M5xdww/bGTFHrcqjlJQtQ C4phXj1gWD6U6dMYbujpOus1Zn5Ap+NgZgiKJbwl5GUesPpf/UWp1nb93zKtt92qZ8wp xYKvhSENMTx1AenAm8rrON1e/FZyfuK1GgXoAW9EmG4UetCmIGOjXLzwhN9lpEY8dxmV AxRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=SHUx7LglZ+iovKKPJeU3YArEXAq7OAW3HWlIfRQuf4U=; b=XAjxQmJuo3UMlgpDS7OeDWnOphHSRVdXY7ZLt67KOTE32+6sBVQFqCT8jOFaHBixxf Ir70WZB/nV0vlN3CBeaU6+VDc0hZ27pJANHDwDC7pfNow/A2tc/klfO8w6LP9hhK3Cbr 72MYf09y79W+O+FsRmFX+IXJrgx8vsydS3BbOxkefQi1EvNa0TYjd7ukVDCuY7lZ+bjW 9aQ/JOBckXXA5/fcelXYsah0Gx1tWIhZEbf66rLmoWD5Qk3e8ogGzjvCbGb2wrmIXou7 y8tQpQ+CcSx095CEJpp1xVuK7aECWVw9olPCyaKtGhSXr2ILoV6iqMqeQX95nu0TM9Is 4J4w== X-Gm-Message-State: ABUngvenTsoEkmB3PUAsKDhN2mvvlQyES5luplmnHE7sTF9vZ0lLnr7usMx4ve3vaUiU2g== X-Received: by 10.98.74.142 with SMTP id c14mr490723pfj.139.1479342785216; Wed, 16 Nov 2016 16:33:05 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:459c:839f:4966:2f08? ([2001:67c:370:128:459c:839f:4966:2f08]) by smtp.gmail.com with ESMTPSA id t21sm445335pfa.1.2016.11.16.16.33.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 16:33:04 -0800 (PST) To: saag@ietf.org From: Leif Johansson Message-ID: Date: Thu, 17 Nov 2016 01:32:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [saag] tokbind @ IETF97 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:33:07 -0000 The tokenbinding WG met in Seoul this week. After the meeting a WGLC was called for the core document set: - draft-ietf-tokbind-https-06 - draft-ietf-tokbind-negotiation-05 - draft-ietf-tokbind-protocol-10 Best R Leif & John From nobody Wed Nov 16 16:37:13 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87269126579 for ; Wed, 16 Nov 2016 16:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 HBhHv4aWg_oW for ; Wed, 16 Nov 2016 16:37:01 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC63212946F for ; Wed, 16 Nov 2016 16:37:01 -0800 (PST) Received: from t2001067c03700128054c0053f6180e95.v6.meeting.ietf.org ([2001:67c:370:128:54c:53:f618:e95]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1c7AhH-0005C7-WC; Thu, 17 Nov 2016 00:37:00 +0000 From: Wendy Seltzer To: saag@ietf.org Organization: W3C Message-ID: <87b3316e-fc86-f56d-5687-b8fc86e6d103@w3.org> Date: Wed, 16 Nov 2016 19:36:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [saag] W3C update (CSP, WebAppSec, WebAuthn, WebCrypto) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:37:05 -0000 An update on security-related W3C activities: Content Security Policy Level 2 is a W3C Proposed Recommendation; development is ongoing in CSP Level 3 https://www.w3.org/TR/CSP2/ https://www.w3.org/TR/CSP/ Secure Contexts is a Candidate Recommendation, recommending that user agents enable some features only when minimum standards of authentication and confidentiality are met. https://www.w3.org/TR/secure-contexts/ Web Authentication Working Group is actively developing the WebAuthn API based on FIDO2.0 Submissions https://www.w3.org/webauthn/ https://www.w3.org/TR/webauthn/ WebAppSec WG active work includes Upgrade Insecure Requests, Mixed Content, Secure Contexts (all in Candidate Recommendation); CSP Level 3, Referrer Policy, Permissions API, UI Security (Ironframe). https://www.w3.org/2011/webappsec/ https://github.com/w3c/webappsec WebCrypto WG is very nearly done, really! https://w3c.github.io/webcrypto/Overview.html Hardware Based Secure Service CG has a draft report https://rawgit.com/w3c/websec/gh-pages/hbss.html We held a Blockchain and the Web Workshop: https://www.w3.org/2016/04/blockchain-workshop/report Web Payments now includes several drafts and implementations underway: https://www.w3.org/Payments/WG/ Payment Request API; Payment Method IDs; Basic Card Payment; HTTP API 1.0; HTTP Messages 1.0; Web Payments Overview Overview of related groups, including Web Payments: https://www.w3.org/Security/ --Wendy -- Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office) Policy Counsel and Domain Lead, World Wide Web Consortium (W3C) http://wendy.seltzer.org/ +1.617.863.0613 (mobile) From nobody Wed Nov 16 17:24:47 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2155E1295FB for ; Wed, 16 Nov 2016 17:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, 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 uT_2yWWp5Zuj for ; Wed, 16 Nov 2016 17:24:32 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 E491E1295D8 for ; Wed, 16 Nov 2016 17:24:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8BBAE623CE for ; Wed, 16 Nov 2016 20:24:22 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TN9KbLFMEO69 for ; Wed, 16 Nov 2016 20:24:19 -0500 (EST) Received: from lx120e.htt-consult.com (dhcp-8dd3.meeting.ietf.org [31.133.141.211]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 2DE23623D2 for ; Wed, 16 Nov 2016 20:24:17 -0500 (EST) To: saag@ietf.org From: Robert Moskowitz Message-ID: <54a72cb6-0eaf-f334-31fb-2779cf5e2077@htt-consult.com> Date: Thu, 17 Nov 2016 10:24:12 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] IEEE 802.1 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 01:24:46 -0000 I really can't report too well of other groups under 802... 802.1AEcg http://www.ieee802.org/1/pages/802.1aecg.html Adds support for Provider Bridges and similar devices. What this means in practice includes a company using 802.1AE encryption between two campus bridges and securing the crossing of a provider's ethernet MAN. We are also considering how this may be used in 802.1CB redundent rings in automotive ethernet and other similar uses. 802.1ARcg http://www.ieee802.org/1/pages/802.1aecg.html Adds SHA-384 and P-384 into DevID. This impacts ANIMA and RESTCONF (zerotouch) use of iDevID. And any other areas using 1AR certificates. Document restructuring is so extensive, that this is now a standard revision, 802.1AR-rev, rather than just an addendum. Restructuring also would make for a fast PAR to add other algorithms like EDDSA (I did comment to add this now, but it was rejected). 802.1Xck http://www.ieee802.org/1/pages/802.1ck.html Modeling of 802.1X in Yang. This may be of import to NETCONF and others. Really producing some interesting view into the 802.1X architecture. 802E http://www.ieee802.org/1/pages/802e.html Privacy Considerations for IEEE 802 technologies Nothing new within 802E, but a major presentation over in 802.11: https://mentor.ieee.org/802.11/dcn/16/11-16-1492-00-0wng-privacy-issues-in-802-11-networks.pptx Basically, it looks pretty bad in 802.11 for privacy... Bob From nobody Tue Nov 22 23:20:31 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8600C129557 for ; Tue, 22 Nov 2016 23:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Y9Equ68hToMc for ; Tue, 22 Nov 2016 23:20:27 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 06D09129502 for ; Tue, 22 Nov 2016 23:20:27 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id w33so3807284qtc.3 for ; Tue, 22 Nov 2016 23:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=eoLXgt5kmhWz6PRtO0wt+ROv/AzxFR18QQJJp2dp+QE=; b=UpsuNVJqKpix9b0qWgN/ajPYRTzH299n7xJcmC/DAmtwDY+L4rpLElsKkbY3sGgyVl nAODKq+71eYYJHqwm8bRCo0qbku7EXoHuZzJFMzL1/sZQo2ESZe9nSmoNXK3xEf02xoZ ad5h6B/hNnwC/8/szZWNX34YrOEq0oOYjXKa6URrc0evsNkfxIV6JDnCOmXqGYff2daj J7slct2CvGvdlE9OqohkbyzEENXXvAyY7Sztq7A8/xYpM6sUecMLFD/qSD3rs84LZ6Cr JgRwYuatit19X2S+MFuJbXysYamQF63DzXX8vRwH73djVXhV/ikAN+0QulrNdDVDNb7M 4Slg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eoLXgt5kmhWz6PRtO0wt+ROv/AzxFR18QQJJp2dp+QE=; b=lGwNU9KiwnLnxEk97lOqKAEX5xolSjEBxzOrqYVmf7CLYywSzfAmQdhr6janCOAqAQ Sv+T5pEV0lNB6fHLMjJdvuRhpwqmiY/2bv+HMfAOpL1vQNKnluvM7i/lnvPUxQ09W+Mu 7jxi3gB3OaOqwpBglFaFLjEbROcwvRc6/VNMoBBriy7RdbhjxqK4sMJvXUxploLhwZCt 7pf+ctJlWV+wtbAlid7XQkiJRWIhCNbBDWtGEcv9ItHi3CaS9wodCbQX2HD25PzOmJ8A 7z3RABBbky/Fu0FxiBxsoTzN5m3Cs3auKr1gd4Tro92viZGvIU1im7SqB2wFfYKXLhv7 gV2g== X-Gm-Message-State: AKaTC00x6jgZo5HeUN2zXP7XjKpciMECQC3gE/XS+rniLcJ0Q+u572/8kIPta9rtw8xpX1+Bu+d0yfn8O4xISA== X-Received: by 10.237.51.167 with SMTP id v36mr1488758qtd.46.1479885626021; Tue, 22 Nov 2016 23:20:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.169.22 with HTTP; Tue, 22 Nov 2016 23:19:45 -0800 (PST) From: Nikos Mavrogiannopoulos Date: Wed, 23 Nov 2016 08:19:45 +0100 Message-ID: To: IETF SAAG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 07:20:29 -0000 Hi, RFC5280 and its update (6818), reference IDNA2003 (rfc3490) for storing internationalized DNS names. However, IDNA2003 is already obsolete standard (it seems it was already deprecated when RFC6818 was published [0]) and in practice phased out. What is the current best practice on internationalized names with certificates? Is it transparently switch to IDNA2008 (rfc5890), and let software figure out the reverse mappings to utf8 somehow? Or is it store UTF-8 dns names on the certificate, and let the software comparing DNS names do any mapping it deems necessary prior to comparison? regards, Nikos [0]. https://www.ietf.org/mail-archive/web/pkix/current/msg28386.html PS. I'm resending to saag due to no re-actions in ietf-pkix list From nobody Wed Nov 23 07:23:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15376129A2A for ; Wed, 23 Nov 2016 07:23:04 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 dbkVs0DC9MQD for ; Wed, 23 Nov 2016 07:23:02 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AECE129A0C for ; Wed, 23 Nov 2016 07:23:01 -0800 (PST) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9ADDD284B0A for ; Wed, 23 Nov 2016 15:23:00 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 23 Nov 2016 10:22:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF SAAG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF SAAG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 15:23:04 -0000 > On Nov 23, 2016, at 2:19 AM, Nikos Mavrogiannopoulos = wrote: >=20 > Hi, > RFC5280 and its update (6818), reference IDNA2003 (rfc3490) for > storing internationalized DNS names. However, IDNA2003 is already > obsolete standard (it seems it was already deprecated when RFC6818 was > published [0]) and in practice phased out. What is the current best > practice on internationalized names with certificates? >=20 > Is it transparently switch to IDNA2008 (rfc5890), and let software > figure out the reverse mappings to utf8 somehow? >=20 > Or is it store UTF-8 dns names on the certificate, and let the = software > comparing DNS names do any mapping it deems necessary prior to > comparison? The DNS subjectAltName in certificates is of type IA5String, which only supports ASCII, not UTF-8. RFC 6125 covers this topic, the content expected by correctly implemented verifiers is A-labels. Therefore, certificates must contain IDNA encoded hostnames in the DNS subjectAltName, and verifiers connecting to UTF-8 hostnames must convert them to A-label form in order to construct the reference identifier that is checked against the certificate: https://tools.ietf.org/html/rfc6125#section-6.4.2 6.4.2. Checking of Internationalized Domain Names If the DNS domain name portion of a reference identifier is an internationalized domain name, then an implementation MUST convert any U-labels [IDNA-DEFS] in the domain name to A-labels before checking the domain name. In accordance with [IDNA-PROTO], A-labels MUST be compared as case-insensitive ASCII. Each label MUST match in order for the domain names to be considered to match, except as supplemented by the rule about checking of wildcard labels (Section 6.4.3; but see also Section 7.2 regarding wildcards in internationalized domain names). This is implemented (e.g.) in Postfix and the next release (3.2 in ~January 2017) is moving from IDNA2008 transitional to full IDNA2008 which changes the encoding of German eszet (=C3=9F) and a couple of other glyphs to match current registry practice. FWIW, this is also documented in OpenSSL (I can't cite this as an authoritative source of course, since I added that text): https://www.openssl.org/docs/man1.1.0/crypto/X509_check_ip_asc.html https://www.openssl.org/docs/man1.1.0/crypto/X509_check_host.html Per section 6.4.2 of RFC 6125, name values representing international domain names must be given in A-label form. ... (same text in both manpages) I am in the process of adding DANE support to the TLS stack in Haskell, and incidentally adding similar commentary to the documentation there. --=20 Viktor. From nobody Wed Nov 23 09:56:43 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF4512A0DC for ; Wed, 23 Nov 2016 09:56:41 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 cn9618XofZIV for ; Wed, 23 Nov 2016 09:56:40 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1679F12A1C4 for ; Wed, 23 Nov 2016 09:55:40 -0800 (PST) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1F536284B0A for ; Wed, 23 Nov 2016 17:55:39 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 23 Nov 2016 12:55:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF SAAG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF SAAG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 17:56:42 -0000 > On Nov 23, 2016, at 10:22 AM, Viktor Dukhovni = wrote: >=20 >>=20 >> Is it transparently switch to IDNA2008 (rfc5890), and let software >> figure out the reverse mappings to utf8 somehow? One more comment. It seems that perhaps you were thinking that verifiers would have to convert A-label IDNA names from certificates *back* to UTF-8 for comparison with the reference identifier. That would not be right, instead the verifier needs to convert a UTF-8 name to A-labels to compare against the certificate. One reason this is needed, is that UTF-8 names can represent the "." between domain name labels in 4 different ways (lifted the Haskell DANE survey code I am working on): -- Besides U+002E (full stop) IDNA allows DNS labels to be -- separated by any of the Unicode variants U+3002 (ideographic -- full stop), U+FF0E (fullwidth full stop), and U+FF61 -- (halfwidth ideographic full stop). dots :: [Char] dots =3D map chr [0x002E, 0x3002, 0xFF0E, 0xFF61] All of these map to just 0x002E in the A-label form. So for at least (and other reasons) the mapping from the UTF-8 representation to the A-label form is many-to-one and is thus not reversible. The A-label form is the `canonical' form of the name for equality comparison. --=20 Viktor.= From nobody Wed Nov 23 11:11:04 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02D5129B41 for ; Wed, 23 Nov 2016 11:11:01 -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] 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 kY4E3I7XgZsX for ; Wed, 23 Nov 2016 11:11:00 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF7129AE0 for ; Wed, 23 Nov 2016 11:11:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id C853110ED9 for ; Wed, 23 Nov 2016 19:10:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZNJtkc3CJy7 for ; Wed, 23 Nov 2016 19:10:59 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id E8FE510ED3 for ; Wed, 23 Nov 2016 19:10:58 +0000 (UTC) Date: Wed, 23 Nov 2016 14:10:56 -0500 From: Andrew Sullivan To: saag@ietf.org Message-ID: <20161123191056.GL68855@mx2.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 19:11:02 -0000 Hi, On Wed, Nov 23, 2016 at 12:55:35PM -0500, Viktor Dukhovni wrote: > One reason this is needed, is that UTF-8 names can represent the "." > between domain name labels in 4 different ways (lifted the Haskell > DANE survey code I am working on): > > -- Besides U+002E (full stop) IDNA allows DNS labels to be > -- separated by any of the Unicode variants U+3002 (ideographic > -- full stop), U+FF0E (fullwidth full stop), and U+FF61 > -- (halfwidth ideographic full stop). > > dots :: [Char] > dots = map chr [0x002E, 0x3002, 0xFF0E, 0xFF61] > > All of these map to just 0x002E in the A-label form. So for > at least (and other reasons) the mapping from the UTF-8 > representation to the A-label form is many-to-one and is > thus not reversible. Just a bit of pedantry, but possibly useful for those looking for the relevant information. Strictly speaking, IDNA does not "allow" the mapping in question. IDNA works on labels, not on domain names. There are _lots_ of ways that domain names could be represented in a system. This includes encoding U-labels as non-Unicode text encodings (such as ISO 8859-* or Shift JIS), using separator characters other than U+002E, representing the labels in NFD, and so on. RFC 5895 (the "mappings" document) specifies some mappings that could be done to input that appears to be a domain name prior to processing the input as a series of U-labels under IDNA. One of those mappings contemplates U+3002 (but not other code points) as a separator character. UTS#46 is a Unicode Technical Standard that was arguably published to address some dissatisfacton on the part of UTC with the IETF consensus. In section 2.3, it specifies that a "label" is a substring of a "domain name", and labels are separated by label-separators which are the list you posted. (I note that this specification of "domain name" and "label" is actually at odds with STD 13. UTS#46 claims that it uses the term "domain name" as it is used in RFC 3490, though I'm not totally convinced that's correct. There's anyway a certain bitter irony in this, because the somewhat imprecise use of "domain name" in 3490 is one of the things that IDNA2008 -- which obsoletes 3490 -- was trying to fix.) Many implementations use UTS#46, however, for mapping, so it is probably wise to treat those characters as potential separators of labels and map them into U+002E before continuing with processing. None of those characters is an accepable character in a U-label, so there shouldn't be a problem. Remember, also, that the dots in domain names aren't part of the wire protocol. They only appear in presentation format. DNS libraries know what to do with the dots, so mapping to U+002E ought to be safe. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 23 12:46:25 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B90129A26 for ; Wed, 23 Nov 2016 12:46:24 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 sPUZSLFWfAQu for ; Wed, 23 Nov 2016 12:46:21 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7797A1294BA for ; Wed, 23 Nov 2016 12:46:21 -0800 (PST) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 818D7284B0A for ; Wed, 23 Nov 2016 20:46:20 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <20161123191056.GL68855@mx2.yitter.info> Date: Wed, 23 Nov 2016 15:46:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161123191056.GL68855@mx2.yitter.info> To: IETF SAAG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF SAAG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 20:46:25 -0000 > On Nov 23, 2016, at 2:10 PM, Andrew Sullivan = wrote: >=20 >> dots :: [Char] >> dots =3D map chr [0x002E, 0x3002, 0xFF0E, 0xFF61] >>=20 >> All of these map to just 0x002E in the A-label form. So for >> at least (and other reasons) the mapping from the UTF-8 >> representation to the A-label form is many-to-one and is >> thus not reversible. >=20 > Just a bit of pedantry, but possibly useful for those looking for the > relevant information. Thanks for the clarification, appreciated! > Strictly speaking, IDNA does not "allow" the mapping in question. > IDNA works on labels, not on domain names. There are _lots_ of ways > that domain names could be represented in a system. [...] Yes, I was aware of this, sorry if the original language gave anyone a contrary impression. [ Indeed in that same Haskell DANE survey code I am working on, the IDNA library encodes one label at a time, and is not based UTS#46. That library unfortunately implements = IDNA2003, and a Haskell IDNA2008 remains to be implemented. So at present I still get the wrong (transitional) encoding of "eszet" et. al.] > RFC 5895 (the "mappings" document) specifies some mappings that could > be done to input that appears to be a domain name prior to processing > the input as a series of U-labels under IDNA. One of those mappings > contemplates U+3002 (but not other code points) as a separator > character. Yes, I got the separator list list from: https://tools.ietf.org/html/rfc3490#section-3.1 3.1 Requirements IDNA conformance means adherence to the following four requirements: 1) Whenever dots are used as label separators, the following characters MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full stop). Which is what made it into Postfix, which, by the way, like many other IDNA applications now uses UTS#46 via "icu4c". I see that indeed the IDNA2008 list of "dots" is shorter: https://tools.ietf.org/html/rfc5895#page-5 4. [IDNA2008protocol] is specified such that the protocol acts on the individual labels of the domain name. If an implementation of this mapping is also performing the step of separation of the parts of a domain name into labels by using the FULL STOP character (U+002E), the IDEOGRAPHIC FULL STOP character (U+3002) can be mapped to the FULL STOP before label separation occurs. There are other characters that are used as "full stops" that one could consider mapping as label separators, but their use as such has not been investigated thoroughly. This step was chosen because some input mechanisms do not allow the user to easily enter proper label separators. Only the IDEOGRAPHIC FULL STOP character (U+3002) is added in this mapping because the authors have not fully investigated the applicability of other characters and the environments where they should and should not be considered domain name label separators. Given that Postfix added EAI support in 2014, we should perhaps have referenced 5895 and not 3490, but that's mostly moot, since icu4c = handles the conversion of non-ASCII domain names, and we only process the = special 3490-style dots for ".example.com" sub-domain patterns, which would = otherwise be rejected by icu4c. > UTS#46 is a Unicode Technical Standard that was arguably published to > address some dissatisfacton on the part of UTC with the IETF > consensus. In section 2.3, it specifies that a "label" is a substring > of a "domain name", and labels are separated by label-separators which > are the list you posted. (I note that this specification of "domain > name" and "label" is actually at odds with STD 13. UTS#46 claims that > it uses the term "domain name" as it is used in RFC 3490, though I'm > not totally convinced that's correct. :-) > There's anyway a certain bitter > irony in this, because the somewhat imprecise use of "domain name" in > 3490 is one of the things that IDNA2008 -- which obsoletes 3490 -- was > trying to fix.) Many implementations use UTS#46, however, for > mapping, so it is probably wise to treat those characters as potential > separators of labels and map them into U+002E before continuing with > processing. Yep, running code plays a strong role in defining practice. [ Perhaps = if IDNA2008 had come with a portable C implementation, more applications would have conformed to IDNA2008 where it differs from UTS#46... ] --=20 Viktor. From nobody Fri Nov 25 00:11:24 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B05412954B for ; Fri, 25 Nov 2016 00:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CDM2cMHuN7FN for ; Fri, 25 Nov 2016 00:11:14 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 2B80D12953D for ; Fri, 25 Nov 2016 00:11:14 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id x190so71111053qkb.0 for ; Fri, 25 Nov 2016 00:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-transfer-encoding; bh=42438iwQPDg4bgJudqXr/qw3FOhAmK/2hqvVJAQcPRA=; b=tzfYkjYHncmb3t3XHhu9ZJmY5KaPxUiqRgVDLUk/1gtDw/n6VsmM1PC9ZVa9kHaxnW j4Bg3Lj1PYK9MEDoOifiwGAMcOeIdN5O0cdFcFnZIO6Jehc0vngw2CAvYIptJm/CzAx7 4j8dhz9/er+VS4Q4tr2Ow2ewVfR6buB07TbdJ08LEJoqOOFt2JcX2Qt9hxAI5CUjPFQV t4Q3Lm5iT4HaoDL57U5jIeyWqHhPaogWrEYMdhDEcHiCBXbWSRfVPwhPRXKPAwo2FH0A AkteywIIJtbCvAjyB2aJJOIpQFO4qjaATAzrL+yUec9gwibMZdScyN+3aTvE/bIu1r55 DYwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-transfer-encoding; bh=42438iwQPDg4bgJudqXr/qw3FOhAmK/2hqvVJAQcPRA=; b=W0aHhL9IVrg1dqkQJe2zS5PWu4ZpApDLDlxfe6EN9O7cUa0ZKHZlbZbz4vRxEPf53J Fll3yAxluzq0ficTJ8zD4VrusmY0Jw9Wifmu+hiqGcSHOICvXVt1z9cudSq63f/8uLPp AP9fYz8Zwm+muT31arAxFR5UfQt4Qy96/LSjkjpWtKIj/ef1gDqeTDhFap/qsTgDUIRh PjpLMK5Xh1XXYPVHixPJhsNfgWkxlOifAPaCUtDZmH8kAm/Hy42uRuRf/2sh2QUN9Qg8 oqpcS80Xeo+Ye7vgqtKQ9RkYzP5RNJGvQBy2FklyZdKpatQ56QgWXhTCr+ltN9Xs9tfJ NL7w== X-Gm-Message-State: AKaTC00kqJXCFhCVfOtki0cJk+sESqFfT3QlnuMP0GZxD/8n8JAzZeFfFhJ/wlucUeLXBDHOBfxz0DgE+1aHlA== X-Received: by 10.55.137.4 with SMTP id l4mr5191236qkd.310.1480061473179; Fri, 25 Nov 2016 00:11:13 -0800 (PST) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.12.169.22 with HTTP; Fri, 25 Nov 2016 00:10:32 -0800 (PST) In-Reply-To: References: From: Nikos Mavrogiannopoulos Date: Fri, 25 Nov 2016 09:10:32 +0100 X-Google-Sender-Auth: prPqiAbcF4u1uVUDd9AwsUrT92c Message-ID: To: IETF SAAG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 08:11:23 -0000 On Wed, Nov 23, 2016 at 4:22 PM, Viktor Dukhovni w= rote: > >> On Nov 23, 2016, at 2:19 AM, Nikos Mavrogiannopoulos wrote: >> >> Hi, >> RFC5280 and its update (6818), reference IDNA2003 (rfc3490) for >> storing internationalized DNS names. However, IDNA2003 is already >> obsolete standard (it seems it was already deprecated when RFC6818 was >> published [0]) and in practice phased out. What is the current best >> practice on internationalized names with certificates? >> >> Is it transparently switch to IDNA2008 (rfc5890), and let software >> figure out the reverse mappings to utf8 somehow? >> >> Or is it store UTF-8 dns names on the certificate, and let the software >> comparing DNS names do any mapping it deems necessary prior to >> comparison? > > The DNS subjectAltName in certificates is of type IA5String, which > only supports ASCII, not UTF-8. RFC 6125 covers this topic, the > content expected by correctly implemented verifiers is A-labels. RFC5280 is specific (section 7.2) on how internationalized names are handled and does not reference RFC6125 (nor RFC6125 updates RFC5280). Even though RFC6125 links to IDNA2008 (RFC5890), RFC5280 references IDNA2003 (RFC3490), and is very specific on how to store (ToAscii) and present (ToUnicode). The RFC6125 instructions are largerly vague and do not cover the reverse mapping of names (ToUnicode) for example. > This is implemented (e.g.) in Postfix and the next release (3.2 > in ~January 2017) is moving from IDNA2008 transitional to full > IDNA2008 which changes the encoding of German eszet (=C3=9F) and a > couple of other glyphs to match current registry practice. That's my point. It seems a logical thing to do, and I was also planning to do that for gnutls, but doing it violates RFC5280. The main problem that I see with the automatic upgrade to IDNA2008 is that the reverse is not easy to achieve, i.e, applications cannot display the real name of the certificate, but instead something like xn--oxaaa.xn--kxawhkp. One could use the ToUnicode operation of TR#46 but still that is guessing expected by the implementers. regards, Nikos From nobody Fri Nov 25 01:37:55 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEDC1294EF for ; Fri, 25 Nov 2016 01:37:53 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 ErGSJalZpJtN for ; Fri, 25 Nov 2016 01:37:49 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC3A129566 for ; Fri, 25 Nov 2016 01:37:46 -0800 (PST) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 84420284B67 for ; Fri, 25 Nov 2016 09:37:45 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 25 Nov 2016 04:37:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF SAAG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF SAAG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 09:37:53 -0000 > On Nov 25, 2016, at 3:10 AM, Nikos Mavrogiannopoulos = wrote: >=20 > That's my point. It seems a logical thing to do, and I was also > planning to do that for gnutls, but doing it violates RFC5280. The > main problem that I see with the automatic upgrade to IDNA2008 is that > the reverse is not easy to achieve, i.e, applications cannot display > the real name of the certificate, but instead something like > xn--oxaaa.xn--kxawhkp. One could use the ToUnicode operation of TR#46 > but still that is guessing expected by the implementers. Firefox has no problem displaying that site in the address bar as: http://=CE=B3=CE=B3=CE=B3.=CE=BD=CE=AF=CE=BA=CE=BF=CF=82/ while the reverse mapping may not be exactly the Greek that was originally entered to create xn--oxaaa.xn--kxawhkp, it is an unambiguous form of that input, no guessing, which is stable under further repeated decoding/encoding. So applications can, as needed, just decode the punycode back to the relevant UTF-8 code-points. Displaying A-labels in some suitable encoding is not something that a library like GnuTLS should be doing. That falls squarely into the application space, where the application may need to map from UTF-8 to some other local encoding, and perhaps only conver labels whose alphabets the user can read. While I can generally distinguish code points in Latin and Cyrillic, showing me certificate names in Chinese, Arabic or Tamil is rather pointless, the for me, the punycode is much more usable. GnuTLS just needs to be able to compare reference identifiers with certificate content. Mapping certificate content back to A-labels to UTF-8 is not IMHO something that GnuTLS should be doing. --=20 --=20 Viktor. From nobody Fri Nov 25 02:26:48 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1DD1296A8 for ; Fri, 25 Nov 2016 02:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 s0lzXsOF81cf for ; Fri, 25 Nov 2016 02:26:42 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 8DF00129A27 for ; Fri, 25 Nov 2016 02:26:34 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id x190so73929789qkb.0 for ; Fri, 25 Nov 2016 02:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-transfer-encoding; bh=IeBq0j0ekw3bAQuw7DM5zp9Cf5ySTxGDNGrazDdHsxA=; b=tFZuoWtXuP03tOM3I0hfWdypzv0cGnvfFmCayxLliIt+GIjbFIAs1vVWp5BtrgXH4j jUll6hoOVIa0lmEM3XaJywWLTkziK0LbalekxmJWEKOJ7k/GXN9S4cZkpNyAXMiQf6x1 6Q5YdQaR5XNDEZjhJYLVlS1gABx6VQeOoiOzK3ouvyp4YmIdxHBDDrI0tUVS4aeBQxCj 4pEXa0Enl07LFziWNHUt0wKFAtAd4Apc7PpfDSOLgxz0PsKBKjvSTmgCwro3t34DFsFa BIIDn/lE8KpQ2Nh5dNm61zotot+T9KTNGiBbkHnupL6dIp9mEDOs0CHWcvmcwxaW+4e7 e8+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-transfer-encoding; bh=IeBq0j0ekw3bAQuw7DM5zp9Cf5ySTxGDNGrazDdHsxA=; b=HpAVJLdBD23c+tCKUrsZogggBdbf2ZwdNvUH0efWCoEoN3nS6AUDhjHotIgn24jtTx AFx1OFuPHdIp1PFSDwQs+zMUUBT4oWoGNFR4soejSt5V1Df4rWn5l/e4uUw88yIOxs/c Ut+1oQ0ZdlRV8G/Pa55YTZJ1jea+G7LA5hToNmIpYXXMD/EPvrBUEhAUzJwDWwT3VIdl 6TtZHZuAMazPsVJObCCw0ZgGhH3vjeUo/2YTah/OuKiRXCfxKMR720kq/4FDsDXfGzw2 E9MthEmkoOXjE5sOu4dL1e3E7lWsMHT4ERkeH0cqg/BSqGBZUt9dP0tL1u/gNfrJDQjU KphQ== X-Gm-Message-State: AKaTC00dHQoyM/Oggz0P167ZZLAw0KZT6IQfcZYfUHvhVE8l+6lW46tCczCM5dXtYIwh+HKsD49kAdZMNLF9AQ== X-Received: by 10.55.125.194 with SMTP id y185mr5756676qkc.38.1480069593567; Fri, 25 Nov 2016 02:26:33 -0800 (PST) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.12.169.22 with HTTP; Fri, 25 Nov 2016 02:25:53 -0800 (PST) In-Reply-To: References: From: Nikos Mavrogiannopoulos Date: Fri, 25 Nov 2016 11:25:53 +0100 X-Google-Sender-Auth: yQEGzFiaZ-x8EEXK0-48ngFLo9w Message-ID: To: IETF SAAG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 10:26:47 -0000 On Fri, Nov 25, 2016 at 10:37 AM, Viktor Dukhovni wrote: >> That's my point. It seems a logical thing to do, and I was also >> planning to do that for gnutls, but doing it violates RFC5280. The >> main problem that I see with the automatic upgrade to IDNA2008 is that >> the reverse is not easy to achieve, i.e, applications cannot display >> the real name of the certificate, but instead something like >> xn--oxaaa.xn--kxawhkp. One could use the ToUnicode operation of TR#46 >> but still that is guessing expected by the implementers. > > Firefox has no problem displaying that site in the address bar as: > > http://=CE=B3=CE=B3=CE=B3.=CE=BD=CE=AF=CE=BA=CE=BF=CF=82/ That's good, though I guess that other browsers wouldn't. > while the reverse mapping may not be exactly the Greek that was > originally entered to create xn--oxaaa.xn--kxawhkp, it is an > unambiguous form of that input, no guessing, which is stable under > further repeated decoding/encoding. So applications can, as needed, > just decode the punycode back to the relevant UTF-8 code-points. > > Displaying A-labels in some suitable encoding is not something that > a library like GnuTLS should be doing. That falls squarely into the > application space, where the application may need to map from UTF-8 > to some other local encoding, and perhaps only conver labels whose > alphabets the user can read. While I can generally distinguish code > points in Latin and Cyrillic, showing me certificate names in Chinese, > Arabic or Tamil is rather pointless, the for me, the punycode is much > more usable. > > GnuTLS just needs to be able to compare reference identifiers with > certificate content. Mapping certificate content back to A-labels > to UTF-8 is not IMHO something that GnuTLS should be doing. You raise different points with the above, though I disagree with them. Expecting all applications to handle this gracefully is a recipe for disaster (you can actually verify that by checking today how many applications except firefox do that). It is the job of the components that handle (store,generate,use) these structures to convert to and from the needed formats. regards, Nikos From nobody Fri Nov 25 09:20:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD44A129654 for ; Fri, 25 Nov 2016 09:20:10 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 9TgzZ1Anu1FO for ; Fri, 25 Nov 2016 09:20:09 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F6C129655 for ; Fri, 25 Nov 2016 09:20:09 -0800 (PST) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 6C0CA284B0A for ; Fri, 25 Nov 2016 17:20:08 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 25 Nov 2016 12:20:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1D7E7BAA-C9E9-4766-9669-73A2D57C47C5@dukhovni.org> References: To: IETF SAAG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: IETF SAAG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 17:20:11 -0000 > On Nov 25, 2016, at 5:25 AM, Nikos Mavrogiannopoulos = wrote: >=20 > You raise different points with the above, though I disagree with > them. Expecting all applications to handle this gracefully is a recipe > for disaster (you can actually verify that by checking today how many > applications except firefox do that). It is the job of the components > that handle (store,generate,use) these structures to convert to and > from the needed formats. Applications that never expected multi-byte encodings such as UTF-8 are likely to mishandle UTF-8 strings. You can certainly provide a new function that returns UTF-8 decoded peer names from the certificate (you can't decode all the subjectAltNames in all cases, some will hold custom OIDs whose meaning you don't know), but FWIW my advice is to return the DNS names as verbatim A-labels from the certificate. For example, an application that obtained the peername from MX or SRV records starts out with A-labels, and giving at UTF-8 names back is likely counterproductive and may result in incorrect behaviour. Displaying incorrect names from certificates is very UI-specific, and I strongly recommend (as a long-timea TLS pplication developer, not recently new OpenSSL team member) that you avoid taking on that responsibility. Applications are better off seeing the actual certificate content. If they are UTF-8 aware, they can call the relevant UTS#46 (or other library) calls. --=20 Viktor. From nobody Fri Nov 25 09:30:44 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0129129501 for ; Fri, 25 Nov 2016 09:30:43 -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] 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 sA492SOifSGD for ; Fri, 25 Nov 2016 09:30:42 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB4C129658 for ; Fri, 25 Nov 2016 09:30:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id C75A3112A2 for ; Fri, 25 Nov 2016 17:30:41 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9EdggmT5eEf for ; Fri, 25 Nov 2016 17:30:41 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id E5FAA10ED3 for ; Fri, 25 Nov 2016 17:30:40 +0000 (UTC) Date: Fri, 25 Nov 2016 12:30:39 -0500 From: Andrew Sullivan To: saag@ietf.org Message-ID: <20161125173038.GA68855@mx2.yitter.info> References: <20161123191056.GL68855@mx2.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [saag] backward compatibility, running code, and limits to perfection (was Re: IDNA2008 and PKIX certificates) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 17:30:44 -0000 On Wed, Nov 23, 2016 at 03:46:20PM -0500, Viktor Dukhovni wrote: > > There's anyway a certain bitter > > irony in this, because the somewhat imprecise use of "domain name" in > > 3490 is one of the things that IDNA2008 -- which obsoletes 3490 -- was > > trying to fix.) Many implementations use UTS#46, however, for > > mapping, so it is probably wise to treat those characters as potential > > separators of labels and map them into U+002E before continuing with > > processing. > > Yep, running code plays a strong role in defining practice. [ Perhaps if > IDNA2008 had come with a portable C implementation, more applications > would have conformed to IDNA2008 where it differs from UTS#46... ] The reason I'm following up is that this has direct relevance to things that saag discusses. The _reasons_ that IDNA2008 didn't conform with the running code of IDNA2003 in all cases are outlined in RFC 4690, but at least three issues were significant in the backwards-incompatibility corner cases. The first was the built-in mapping of IDNA2003, which made certain things impossible and therefore ruled certain widely-used strings in certain scripts impossible to write under IDNA. The second was that IDNA2003 used the wrong kind of normalization, which meant that it was round-trip lossy. The third was that internationalizing common label practices in the DNS required internationalizing LDH, not permitting every possible character in Unicode (this is why emoji "don't work" with IDNA -- they're not letters or digits. Of course, some people have tried ot use them anyway). The idea in the idnabis WG was that, if we were going to have to break something, we should break it as early as possible so that the installed base is smaller. The position of some others in the industry is that something once released onto the Internet must be made stable forever. So remaining backward compatible for all time becomes a hard requirement. I think the IETF traditions militate in favour of the first of these views, and I note that the security practice has certainly tended that way. The second option means that any mistake will haunt us forever, making the requirement for perfection in even Proposed Standards even higher than it is today. I think we're going to need to confront this problem more and more often over time. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Nov 25 09:35:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B16112960E for ; Fri, 25 Nov 2016 09:35:02 -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] 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 mUFCfE6w5eMj for ; Fri, 25 Nov 2016 09:35:01 -0800 (PST) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 42635129461 for ; Fri, 25 Nov 2016 09:35:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id F2384112A2 for ; Fri, 25 Nov 2016 17:35:00 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8eLWVFBka7J for ; Fri, 25 Nov 2016 17:35:00 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 3C36510ED3 for ; Fri, 25 Nov 2016 17:35:00 +0000 (UTC) Date: Fri, 25 Nov 2016 12:34:58 -0500 From: Andrew Sullivan To: saag@ietf.org Message-ID: <20161125173458.GB68855@mx2.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 17:35:02 -0000 On Fri, Nov 25, 2016 at 09:10:32AM +0100, Nikos Mavrogiannopoulos wrote: > planning to do that for gnutls, but doing it violates RFC5280. The > main problem that I see with the automatic upgrade to IDNA2008 is that > the reverse is not easy to achieve, i.e, applications cannot display > the real name of the certificate, but instead something like > xn--oxaaa.xn--kxawhkp. One could use the ToUnicode operation of TR#46 > but still that is guessing expected by the implementers. This is not correct. Any valid A-label under IDNA2008 corresponds to _exactly_ one U-label under IDNA2008, and conversely. Indeed, this is one problem that IDNA2008 was designed to fix, because in IDNA2003 it isn't true (which caused trouble). There should be no guessing of any kind. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Nov 25 09:57:18 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D379129642 for ; Fri, 25 Nov 2016 09:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jn9kZ35L3qAs for ; Fri, 25 Nov 2016 09:57:15 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 A862B1296A4 for ; Fri, 25 Nov 2016 09:57:15 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 12so84167141uas.2 for ; Fri, 25 Nov 2016 09:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=acbEsiS+HHiC20GCEWvUu5jxlCAjgJUlaApoe0+KBPI=; b=jCi6jrzbUPQHF+uUdXox6u1lS+5j6JwfWrzrwZGerrRmkcLLjK+kiZbFvlaPgexSZv pPACAxwOSa4J2K05xyPTL5iLHEjf2OBLy8aAKN9bLGo6vcTmB/+ozq7pfdhSLmO75vtT 24R0vpgrKkeUdtKikIQdsJtqr9JplfhpcHPig03MkpqPLwojP0ZKI7Jl0bcXTfe7/FEC rBsxvd1pBn2bm9L2DYkZJ277TRuUYgwt9p2Hdw1ni0ecRJVdE+lwiWgC/sN1eyRWW5YC MyuUgVnz+hYIpAQ8cEDki+maPW8vm5RDjdYBIecSBwZj7arjEjWUHjx3cORHnn2eNdzr ctOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=acbEsiS+HHiC20GCEWvUu5jxlCAjgJUlaApoe0+KBPI=; b=MaxH19VKNWXogEmFzuZGI61rCRP/seBswLJtSNgqHydrlAAGVAsM4PqzopYZ2gcwXc 7iMdGEbwU2dEFuX90ENo4qs7RnkRuPWXVoezI/2tRuQgBnf5JPVcqueHzlpxLI9QNEPm b9iEs/8kBYvd064dXamW/rJ0UqbrkC/2CCMCFMwj/IIXtEaOWXC9dGUPDMuyg6mG38U1 SI3PPwi8wADHr/EKeFwyX646xWICwu2N6P7z5dI2uouKPuLyKmKo4GOdrNFveTlDf4n7 cir7c7QjqihJ70o7EJN13sZA4WxNGadvrsxt78V76Ku1a+DhLQm2Jmq82AGF71Xo3PH5 xoUg== X-Gm-Message-State: AKaTC03lx7CaJmqjxiNRev6InF8L6G1dsvUsxPIvTheIEZea5THXbcO9qWqRi7YPgV0UQQDe083mkaLqYolDXA== X-Received: by 10.176.3.84 with SMTP id 78mr6679705uat.117.1480096634742; Fri, 25 Nov 2016 09:57:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Fri, 25 Nov 2016 09:57:14 -0800 (PST) In-Reply-To: <20161125173458.GB68855@mx2.yitter.info> References: <20161125173458.GB68855@mx2.yitter.info> From: Watson Ladd Date: Fri, 25 Nov 2016 12:57:14 -0500 Message-ID: To: Andrew Sullivan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 17:57:17 -0000 On Fri, Nov 25, 2016 at 12:34 PM, Andrew Sullivan wrote: > On Fri, Nov 25, 2016 at 09:10:32AM +0100, Nikos Mavrogiannopoulos wrote: >> planning to do that for gnutls, but doing it violates RFC5280. The >> main problem that I see with the automatic upgrade to IDNA2008 is that >> the reverse is not easy to achieve, i.e, applications cannot display >> the real name of the certificate, but instead something like >> xn--oxaaa.xn--kxawhkp. One could use the ToUnicode operation of TR#46 >> but still that is guessing expected by the implementers. > > This is not correct. Any valid A-label under IDNA2008 corresponds to > _exactly_ one U-label under IDNA2008, and conversely. Indeed, this is > one problem that IDNA2008 was designed to fix, because in IDNA2003 it > isn't true (which caused trouble). > > There should be no guessing of any kind. There are two parsers involved: the parser the machine has for unicode strings, and the parser my eyes have for unicode strings. These are different, even after normalization. I can't tell the difference between SMALL CYRILLIC O and SMALL LATIN O, or SMALL GREEK OMICRON, let alone the various Georgian curly fries, or the smiling animals of Luwian. A user interface for security critical manual comparison of strings needs to restrict the output character set significantly and in a culturally aware way. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Nov 25 13:36:10 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ED712995D for ; Fri, 25 Nov 2016 13:36:08 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 8hqPVVVKof3a for ; Fri, 25 Nov 2016 13:36:07 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC551296F4 for ; Fri, 25 Nov 2016 13:36:06 -0800 (PST) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A4CED284B0A for ; Fri, 25 Nov 2016 21:36:05 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 25 Nov 2016 16:36:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <45788B03-8EFD-4C50-97B5-73BD8E684736@dukhovni.org> References: <20161125173458.GB68855@mx2.yitter.info> To: "saag@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] IDNA2008 and PKIX certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "saag@ietf.org" List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 21:36:08 -0000 > On Nov 25, 2016, at 12:57 PM, Watson Ladd = wrote: >=20 > A user interface for security critical manual comparison of strings > needs to restrict the output character set significantly and in a > culturally aware way. And firefox seems to make some effort to get this right. While the = all-Greek domain is displayed in Greek letters, a fake g=D0=BE=D0=BEgl=D0=B5.com = (the two 'o' glyphs and the 'e' glyph are Cyrillic) displays as undecoded A-labels: xn--ggl-tdd6ba.com ditto with Chrome and Safari. And also for all three with = www.xn--h-7sb7bav.com (=D1=83=D0=B0h=D0=BE=D0=BE.com). By contrast, "=D0=B3=D0=BE=D0=BE=D0=B3=D0= =BB=D0=B5.com" displays in Cyrillic. Which IMHO supports the view that the underlying crypto toolkit should avoid decoding and = leave that decision to the UI layer. Of course we're still left with "=D0=BC=D0=B0=D1=81.com" and some other = potentially confusing glyphs, but dealing with that is still a UI issue. --=20 Viktor. From nobody Mon Nov 28 12:37:44 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE25129527 for ; Mon, 28 Nov 2016 12:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, 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 CwPlp9exrOaS for ; Mon, 28 Nov 2016 12:37:40 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 7643D12951A for ; Mon, 28 Nov 2016 12:37:39 -0800 (PST) Received: (qmail 12156 invoked by uid 0); 28 Nov 2016 20:37:39 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 28 Nov 2016 20:37:39 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id DYdc1u00E2UhLwi01YdfcV; Mon, 28 Nov 2016 13:37:39 -0700 X-Authority-Analysis: v=2.1 cv=Zpp+dbLG c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=L24OOQBejmoA:10 a=PYnjg3YJAAAA:8 a=1XWaLZrsAAAA:8 a=48vgC7mUAAAA:8 a=tGX7uwomAAAA:8 a=tBhPLD96AAAA:8 a=DIuwlW7QAAAA:8 a=vne1KDPhXOphdXCTBkoA:9 a=gCBT6Z9c0CumDoC3:21 a=lcPvkZYco9BHERaC:21 a=QEXdDO2ut3YA:10 a=w2FDxLsVxOQA:10 a=96-UuAdfYG6OSYlHWuPe:22 a=nJcEw6yWrPvoIXZ49MH8:22 a=w1C3t2QeGrPiZgrLijVG:22 a=ZFOOzkjxzLGrPE5HuMia:22 a=TAqhABdwLwsUAq963ofv:22 a=1ZZb5QvCDXP2RM4y_ECg:22 Received: from c-73-202-80-238.hsd1.ca.comcast.net ([73.202.80.238]:63483 helo=[192.168.11.53]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cBSgC-0002wc-3A for saag@ietf.org; Mon, 28 Nov 2016 13:37:36 -0700 To: IETF SAAG From: =JeffH Message-ID: <07810806-e205-ce79-b5a1-d0ce24baff66@KingsMountain.com> Date: Mon, 28 Nov 2016 12:37:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 73.202.80.238 X-Exim-ID: 1cBSgC-0002wc-3A X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-202-80-238.hsd1.ca.comcast.net ([192.168.11.53]) [73.202.80.238]:63483 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 2 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [saag] Call for Papers: 3rd International Conference on Security (SSR 2016) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 20:37:42 -0000 fyi, the papers for the below are announced.. http://csrc.nist.gov/groups/ST/ssr2016/accepted-papers.html ..and the proceedings volume is up on gbooks... Security Standardisation Research: Third International Conference, SSR 2016, Gaithersburg, MD, USA, December 5–6, 2016, Proceedings https://books.google.com/books?id=S7aVDQAAQBAJ ### From: saag on behalf of Russ Housley Date: Monday, February 29, 2016 at 9:02 AM To: IETF SAAG Subject: [saag] Call for Papers: 3rd International Conference on Security (SSR 2016) Call for Papers SSR 2016: 3rd International Conference on Security Standardization Research 5th-6th December 2016, NIST, Gaithersburg, MD, USA http://csrc.nist.gov/groups/ST/ssr2016/ Over the last two decades a huge range of standards have been developed covering many different aspects of cyber security. These documents have been published by national and international formal standardization bodies, as well as by industry consortia. Many of these standards have become very widely used - to take just one example, the ISO/IEC 27000 series have become a commonly used basis for managing corporate information security. Despite their wide use, there will always be a need to revise existing security standards and to add new standards to cover new domains. The purpose of this conference is to discuss the many research problems deriving from studies of existing standards, the development of revisions to existing standards, and the exploration of completely new areas of standardization. Indeed, many security standards bodies are only beginning to address the issue of transparency, so that the process of selecting security techniques for standardization can be seen to be as scientific and unbiased as possible. This conference is intended to cover the full spectrum of research on security standardization, including, but not restricted to, work on cryptographic techniques (including ANSI, IEEE, IETF, ISO/IEC JTC 1/SC 27, ITU-T and NIST), security management, security evaluation criteria, network security, privacy and identity management, smart cards and RFID tags, biometrics, security modules, and industry-specific security standards (e.g. those produced by the payments, telecommunications and computing industries for such things as payment protocols, mobile telephony and trusted computing). Papers offering research contributions to the area of security standardization are solicited for submission to the SSR 2016 conference. Papers may present theory, applications or practical experience in the field of security standardization, including, but not necessarily limited to: * access control * biometrics * cloud computing * critical national infrastructure (CNI) protection * consistency and comparison of multiple standards * critiques of standards * cryptanalysis * cryptographic protocols * cryptographic techniques * evaluation criteria * formal analysis of standards * history of standardization * identity management * industrial control systems security * internet security * interoperability of standards * intrusion detection * key management and PKIs * management of the standardization process * mobile security * network security * open standards and open source * payment system security * privacy * regional and international standards * RFID tag security * risk analysis * security controls * security management * security protocols * security services * security tokens * smart cards * telecommunications security * trusted computing * web security Papers addressing the following more general topics are particularly welcome: * Do standards processes promote complexity that detracts from security? * Are there processes or approaches that can minimize complexity? * Are there technical areas in which standards are misaligned with the security models developed in research? Studies that show areas of misalignment are interesting, as is work that aims to improve alignment. * How long does it take for good ideas to propagate from research to standards to adoption and deployment? How long does it take for security problems in standards to be identified by the research community? How can we improve communication between these communities in order to expedite both of these processes? * What is the impact of nationally-driven security research on international security standards? * Are there cases in which a security standard was done well or done poorly? Studies that describe processes that should (or should not) be emulated are welcome. * Is Open Source replacing security standards development organizations, or changing the way that they operate? What are the implications on security standards? Submissions must be original and must not substantially duplicate work that any of the authors has published elsewhere or has submitted in parallel to any journal or to any other conference or workshop that has published proceedings. All accepted papers will be published in the conference proceedings, and it is intended that these proceedings will be published in the Springer-Verlag Lecture Notes in Computer Science (LNCS) series (www.springer.com/lncs), as has been the case for the two preceding conferences in the series. The proceedings will be available at the conference. Papers published in the LNCS series are indexed by both EI and ISTP. Authors of accepted papers must guarantee that their paper will be presented at the conference, and at least one author of every accepted paper must register for the conference. All submissions will be blind-reviewed. Papers must be anonymous, with no author names, affiliations, acknowledgements, or obvious references. A submitted paper should begin with a title, a short abstract, and a list of keywords. Clear instructions for the preparation of a final proceedings version will be sent to the authors of accepted papers. Authors are strongly recommended to submit their papers in the standard LNCS format (see http://www.springer.com/computer/lncs?SGWID=0-164-0-0-0 for details), with length at most 15 pages (excluding bibliography and appendices). Committee members are not required to review more pages than this, so papers should be intelligible within this length. Submissions not meeting these guidelines risk rejection without consideration of their merits. The conference will take place at the NIST headquarters in Gaithersburg, Maryland, USA. Papers must be submitted using the EasyChair conference management system at: https://easychair.org/conferences/?conf=ssr20160 Please send any enquiries to: ssr2016-0@easychair.org Key dates Deadline for submissions: Monday, 30 May 2016 (23:59 Hawaii) Notifications to authors: Monday, 8 August 2016 Camera ready due: Monday, 19 September 2016 Opening of conference: Monday, 5 December 2016 Conference organisation General Chair Lily Chen, NIST, USA Programme Committee Chair David McGrew, Cisco, USA Chris Mitchell, RHUL, UK Programme Committee: Colin Boyd, Norwegian University of Science and Technology (NTNU) Nancy Cam-Winget, Cisco Systems Liqun Chen, Hewlett Packard Labs Takeshi Chikazawa, IPA Cas Cremers, University of Oxford Scott Fluhrer, Cisco Systems Aline Gouget, Gemalto Feng Hao, Newcastle University Jens Hermans, KU Leuven - ESAT/COSIC and iMinds Dirk Kuhlmann Xuejia Lai, Shanghai Jiaotong University Pil Joong Lee, Postech Peter Lipp, Graz University of Technology Joseph Liu, Monash University Javier Lopez, University of Malaga Catherine Meadows, NRL Jinghua Min, China Electronic Cyberspace Great Wall Co., Ltd. Atsuko Miyaji Valtteri Niemi, University of Helsinki Pascal Paillier, CryptoExperts Kenneth Paterson, Royal Holloway, University of London Sihan Qing, School of Software and Microelectronics, Peking University Kai Rannenberg, Goethe University Frankfurt Matt Robshaw, Impinj Christoph Ruland, University of Siegen Mark Ryan, University of Birmingham Kazue Sako, NEC Ben Smyth, Huawei Jacques Traore, Orange Labs Claire Vishik, Intel Corporation (UK) Debby Wallner, National Security Agency Michael Ward, MasterCard William Whyte, Security Innovation Yanjiang Yang, Huawei Singapore Research Center Jianying Zhou, Institute for Infocomm Research From nobody Tue Nov 29 13:49:20 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0787C129544 for ; Tue, 29 Nov 2016 13:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 Gx5ZoW1IAPzM for ; Tue, 29 Nov 2016 13:48:56 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 2AD10129C93 for ; Tue, 29 Nov 2016 13:48:56 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id x190so189971663qkb.0 for ; Tue, 29 Nov 2016 13:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=WhvcS/4X5GyCoznkZSQSouX5j7PywZdmdp6cPAKiFbM=; b=Or+58kB3hWCk0EOulxwI3nGolqAivzqKFmo94naylyHcARcy9jbvc2OEelwr9tdtdr d0lsWMWZobZbsoysZqVJ4yrWpDkX2/8ASNgiBnobYbVDsRWZmOo6/3Oxw0e6cLH22i/x ZzUrjyGYb5y/fx/Et7JoXJKRHrmi7KQCurE/SluR+U1OecwgPnPib6SsilKGg19dS7bB QdbFuVCe81wtDy+uqZACcm/S6+bRgwNmqMpBPfdipNwKwS1miMRiM1InFKp5AgiUFjW6 qs3Y/NAWw6hBzfI/hLvzIG0tqKI4NH5G+h8ayC/1xjbgpeZwP0yPiWodtyVcE5QDx5jX sZ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=WhvcS/4X5GyCoznkZSQSouX5j7PywZdmdp6cPAKiFbM=; b=F6S8qllf7qHGfa8Eh2cMUylpUNwWnDITOaclLHDDLDFLNy/AI/KxxWbzZoIQSmDX5j 2RxE7e2k5z0OoQfCzRMypQCqcTJkrs9Ksvl5OdSxrgJI2eSeDpG5bSuLKPPykPqSyClq rmsJR5qC0Xn+wN117qZd30ZPT2eYHWFu5LhjQ5o43X+BoJ4EbKIin8PIBi0nsd/CnFcG 2v++pp7qDz2Yq4E/4cu0SYuz6HV0k4sc1qPN/DP/B2yLpwTcB2fNVOvnSXBYTlVMITLj GR/BtvIMwU5u3dDTGN80VSGTfvJJBbnV0hCpqVoRrjKpTi2+mUk1M34Ep1hVE5Ticplc fPEA== X-Gm-Message-State: AKaTC00kC0gGe7YfR0MsGWv15XNCsm4e/6jcAfv6Yzuju4BGPDWXKNiJ8xSYbKS9BD8iRg== X-Received: by 10.55.123.133 with SMTP id w127mr25094308qkc.298.1480456132791; Tue, 29 Nov 2016 13:48:52 -0800 (PST) Received: from [192.168.1.118] (c-69-140-116-172.hsd1.md.comcast.net. [69.140.116.172]) by smtp.gmail.com with ESMTPSA id n188sm31749675qkc.30.2016.11.29.13.48.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 13:48:51 -0800 (PST) To: saag@ietf.org From: Michael StJohns Message-ID: <4a303aa0-1a9a-7bee-f347-94477a7dfa1a@nthpermutation.com> Date: Tue, 29 Nov 2016 16:48:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] RFC 3552bis Suggested Text/Structure X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 21:49:19 -0000 This is in response to Stephen's message of 18 October. In addition to traditional security considerations sections which focus on threats *to* the protocol, it's becoming obvious (especially with IOT style devices becoming prevalent) that we also need to be thinking about threats *from* the protocol to the IETF. So here goes: Outline: - Threats to the Internet from protocol choices in this document -- Stateless Query Response protocols (e.g., UDP-based protocols) UDP based protocols such as ECHO and DNS have the potential to be used as Denial of Service amplifiers..... -- Data source protocols without adequate rate and congestion detection mechanisms Protocols where a client can trigger a server to send data without throttling [based on network congestion or other useful techniques] have the potential to be used as DOS sources and amplifiers... -- Cyber-physical protocols without adequate authentication, authorization and confidentiality --- Confidentiality Sensor data without adequate protection including but not limited to environmental measurements and audio and video surveillance has both privacy and safety and health considerations. There may also be implicit real-world (i.e. marketable) value in the data being transmitted that needs to be protected. --- Authentication & Authorization Sensor data without adequate protection on closed-loop feedback systems (e.g., temperature measures used to control heating systems) can result in triggered real-world actions that may be have safety and health considerations. Specifically, if sourced sensor data cannot be verified as authentic (originated by a trusted source, unchanged in transmission), making process decisions on such data is problematic. Actuator control without adequate protection (e.g., decontamination lighting systems, security and locking systems, industrial control systems, etc) may have safety and health considerations and could result in injury or loss of life. This is also tied to Authorization - the actuator needs both an identity and a privilege to be authenticated prior to actuation. -- IOT - general --- Quantity has a quality all of its own IOT systems have the potential to deploy one or more orders of magnitude of internet connected entities than current applications/services. Does a protocol designed for use among cluster of 1K, 10K or 100K+ systems have sufficient protections to prevent wholesale attacks against the system (e.g. does compromise of one or a few devices compromise most or all of the devices?). Botnets are well understood at DDOS enablers. Are there other new forms of attack coming with IOT scale Botnets? Can threats from distributed intelligence based systems be mitigated against in protocol designs for IOT devices? Are there approaches the backbone can use to mitigate? --- Near zero cost security IOT systems seem to have special sensitivity for any additional costs due to the desire to churn out very cheap devices. Issues with software reuse (one bad stack in 30 different designs for example), software replacement (is a $5 device really designed for *real* management), and lack of a related human (contrast with routers, switches, servers, laptops etc which generally have a human that "manages" them vs an IOT device that might be thrown out of a plane or scattered in a city) have already crept in. What mitigations can we supply that are both cheap and effective? Are there protocol techniques that are especially applicable? Do we try not to publish protocols which can't be made "secure enough"? --- Clocks, we don't need no stinking clocks IOT systems, related to many of the items above, may not have a good sense of real-time. Do the security techniques propose adequately compensate for insecure or missing time? For sensor systems, are anti-replay mechanisms sufficient for the system design goals? ___________________ The above is somewhat stream of consciousness - not all of these bullet points can be reduced to practice in a security requirements section, and there *will* be others that pop up. But this is at least a start for a new section for 3552Bis. Mike