From nobody Fri May 6 03:11:15 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 8AD0D12D0E3 for ; Fri, 6 May 2016 03:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ZFl4LLgmvXo6 for ; Fri, 6 May 2016 03:11:10 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 6914712B069 for ; Fri, 6 May 2016 03:11:10 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u46AB6Dx017071 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 6 May 2016 12:11:07 +0200 From: Simon Josefsson To: Jeffrey Walton References: OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:160506:saag@ietf.org::NfEHTWcpFsjnR8YN:2ttU X-Hashcash: 1:22:160506:noloader@gmail.com::vlyql66L4Hl/Mf6X:4/BR Date: Fri, 06 May 2016 12:11:05 +0200 In-Reply-To: (Jeffrey Walton's message of "Sat, 9 Apr 2016 22:58:56 -0400") Message-ID: <87vb2rts1y.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Standard Crypto Algorithm Name (SCAN) for Deterministic Signatures (RFC 6979) 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, 06 May 2016 10:11:13 -0000 --=-=-= Content-Type: text/plain Jeffrey Walton writes: > What are the standard algorithm names for deterministic signatures > when applied to DSA and ECDSA? > > DSA, DSA/SHA-1 and friends are usually fine for most cases, but I'm > working in an area that needs more precision so an object factory can > serve up the correct type. I am not aware of any well established names. How about we introduce some? The obvious suggestion would be: DDSA: Deterministic Digital Signature Algorithm DECDSA: Deterministic Elliptic Curve Digital Signature Algorithm One could argue that the best solution is to change all implementations of non-deterministic (EC)DSA to be deterministic. Having non-determinism appears to serve no significant benefit and has significant known concerns. Is anyone aware of significant valid technical reason for not using the deterministic variant of (EC)DSA generally? RFC 6979 mentions: Conversely, lack of randomization may have adverse effects in some advanced protocols, e.g., related to anonymity in some voting schemes. As a rule of thumb, deterministic DSA or ECDSA can be used in lieu of the genuine DSA or ECDSA, with no additional security issues, if the overall protocol would tolerate another deterministic signature scheme, in particular RSA as specified in PKCS #1 [RFC3447] (with "type 1" padding, not PSS) or ISO 9796-2 [ISO-9796-2]. The list of protocols in which deterministic DSA or ECDSA is appropriate includes Transport Layer Security (TLS) [RFC5246], the Secure SHell (SSH) Protocol [RFC4251], Cryptographic Message Syntax (CMS) [RFC5652] and derivatives, X.509 public key infrastructures [RFC5280], and many others. However I believe these more advanced protocols require more of the signature system than what (EC)DSA were designed to offer, and that they ought not to rely on (EC)DSA directly but a specialized variant of them. Lack of references in the RFC to particular protocols makes my theory hard to evaluate though. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJXLG25AAoJEIYLf7sy+BGdJk8H/3I374zM1Yxux9l6oz38bb75 gjxcNfoVJ5ZFoZrhLPKamLUAodkD2gD8dxrlspQtratMKNZ4I14Pkgw7MHhE8tZS 6cn49EGorsJOj3fTcqqe1WswDF2QogLVvazO0y+c+2m/PppvQCgUqcl01fhlc9M2 JrEqH+Q6kWi/EVV35FkdG1mvjEXlxDQo7P5vkOT0Rr81W7HFYSFIThH7EXUh7kHD lzYis9tNqEbbmRZQJzYRDs+fQLBLQYmnTPSeG1Z1b2Phw3RLYiT+r7dO+P8Srq43 Kjr4EhFUeMuTp7m7xwIrPOY1DlLQOQl/OykD8/JKvwAdfC8fEjQI8Z8+8c+wtfs= =MPMh -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 10 09:37:42 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 8F01E12D769 for ; Tue, 10 May 2016 09:37:39 -0700 (PDT) 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=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 Hw4dsI2BVmMI for ; Tue, 10 May 2016 09:37:37 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 B417312D537 for ; Tue, 10 May 2016 09:37:36 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id o133so23461521vka.0 for ; Tue, 10 May 2016 09:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=DBZJ56izBPPt3D8TFDk067PFlcbnxdzxEMhjhpETQZw=; b=TsnBYsKQirs3lcP5ujVn7E09WSbcd6ge3OQS1WVxnk0RJKYK9Vrudmw3XyqES7uddP /lYdNKsKNeX3EHcf4owmqTmr3UQRIF7O4VzRJcizuUici/m5wRyT0/fSGpLbpMORb4hg GhfaAoU+gpqnotRKkS/sqqqB3HLGLM4Tlhp/vNib8BQPYysXs/UdIVYkqLB8uBpA+h9n wWXb+K0YfGWze5PYih0w0/79rC/gjeW7uaLAdmOX+++5P7BS1lAX93hQTP9NDmJgZxnp MrvXqFe1jUbkeaxS5j6rODAAthwWBxlCWbQN011AYn/67adfa8sjf/8jrVHGF7aQLJbH zSIw== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=DBZJ56izBPPt3D8TFDk067PFlcbnxdzxEMhjhpETQZw=; b=ViCf4/VkMzcYTsvfjKEv0oQ6edSuvaXWohKi1ZpxWa3SxzAxEJ0Wh2Ej7RpBnaWLtm tonRezOH9+Xyk4skafg12EOVQG9phxi5drH/U82B5S1+NdJ3FuIP+PsVU5KC60JdjPpX VdrOCOd0tUIpdoBAnH1U2xO6HDi1MrsqjShOH1O117fVjRJUrr6Nec+2IUu5qHiuw7/O q3N2pb0IDQJRwnggtWIzdw/2xnEtpRIyZeLtx8pIinmi+VqPA7EfbVELQO2R0kJWfkpc MGKkCqPf+7/QQFvPCeuJml2UzpQtrKBL3oTx1z/HkWyMK5Te2HO4VEnfq4Tcn9snZKO7 Qtvg== X-Gm-Message-State: AOPr4FXQVkIQrzkyYE8e2rVZL+d4gyAO3+rEqJ2hTAmKOqdw5/7Bsg9mM/hFNGJn2Ov1mPBdMLXl+B+4UahtrQ== MIME-Version: 1.0 X-Received: by 10.176.64.100 with SMTP id h91mr21927602uad.56.1462898255802; Tue, 10 May 2016 09:37:35 -0700 (PDT) Received: by 10.176.64.68 with HTTP; Tue, 10 May 2016 09:37:35 -0700 (PDT) In-Reply-To: <0b6da32b373d478ea724435984209bd9@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0b6da32b373d478ea724435984209bd9@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 10 May 2016 09:37:35 -0700 Message-ID: From: Watson Ladd To: "Salz, Rich" , "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [saag] [Cfrg] CFRG Review Panel - Draft Charter 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, 10 May 2016 16:37:39 -0000 On Tue, May 10, 2016 at 9:29 AM, Salz, Rich wrote: > To repeat what I said at BA, I think this is a great idea. I think it ca= n also be very useful to help populate our "pipeline" of security oriented = folks. Toward that end, I would encourage getting this written up in thing= s like ACM, and passed around the academic community. It would probably ne= ed a couple of paragraphs (no more than that) giving brief background on IE= TF CFRG and how you get to do cool things like security review of the next = version of TLS :) So we are changing the IETF process to enable this panel to review all drafts that might benefit, not just ones submitted to CFRG? (CC'ng SAAG because I feel people would be interested and they already have a similar process, but more extensive) > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue May 10 09:46:15 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 5A7FC12D779 for ; Tue, 10 May 2016 09:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 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=-0.996, 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 Oibh5dQDdI42 for ; Tue, 10 May 2016 09:46:11 -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 2A24312D75E for ; Tue, 10 May 2016 09:46:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 15CDCBE3E; Tue, 10 May 2016 17:46:07 +0100 (IST) 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 NbpDP6nbU-dv; Tue, 10 May 2016 17:46:05 +0100 (IST) Received: from [172.20.10.8] (unknown [172.56.3.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9BE09BE38; Tue, 10 May 2016 17:46:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1462898765; bh=pdiCqPjYnpzyecpa5hu5HF8MWAFjJrSHZuXEROXoy2w=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=VweZa/jno4PPTDjncrGph/ODmBgdSkvMndmEq6D2hVfE8H6jIyuxp5aTF8tnqz+SR vuaLjXq5wG64atJpN7cT60ZaHTCQUTLJHdLMvfeKff5RAMtFac7Z5y4Geru/YE/znm 4gFX44KD2rQje9EUsbCEJvQpI6gbFTKdn5e+iqS4= To: Watson Ladd , "Salz, Rich" , "saag@ietf.org" References: <0b6da32b373d478ea724435984209bd9@usma1ex-dag1mb1.msg.corp.akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57321049.6020900@cs.tcd.ie> Date: Tue, 10 May 2016 17:46:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060208010109030000090006" Archived-At: Cc: "cfrg@irtf.org" Subject: Re: [saag] [Cfrg] CFRG Review Panel - Draft Charter 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, 10 May 2016 16:46:14 -0000 This is a cryptographically signed message in MIME format. --------------ms060208010109030000090006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/05/16 17:37, Watson Ladd wrote: > On Tue, May 10, 2016 at 9:29 AM, Salz, Rich wrote: >> To repeat what I said at BA, I think this is a great idea. I think it= can also be very useful to help populate our "pipeline" of security orie= nted folks. Toward that end, I would encourage getting this written up i= n things like ACM, and passed around the academic community. It would pr= obably need a couple of paragraphs (no more than that) giving brief backg= round on IETF CFRG and how you get to do cool things like security review= of the next version of TLS :) >=20 > So we are changing the IETF process to enable this panel to review all > drafts that might benefit, not just ones submitted to CFRG? (CC'ng > SAAG because I feel people would be interested and they already have a > similar process, but more extensive) No there is no formal change to IETF process here. If the cfrg review panel idea works well, that's something that the IETF could consider later. In the meantime, if cfrg have some more qualified folks with cycles to do reviews, then those reviews are very welcome and can be fed into the current IETF process, in the same way as comments from any qualified person. Cheers, S. >=20 >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >=20 >=20 >=20 --------------ms060208010109030000090006 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTAx NjQ2MDFaMC8GCSqGSIb3DQEJBDEiBCBfxF0CuplKQcr0hiFpxtq8U2y8NOO6QqrZz/Q/mCnl azBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCDjQBVETNsG6bKcojSU26P275JiFjtxMXutwrrMwVRC7Go3b1sYJfw 2RT0teT43eYC+MGljv1qhuhISe+/srNTdQCK26DDDE/+lHOMGLmhGtQN4/D1xQGDv8GeotVn uFKEwGBjbhFB66be709s42sB/Xn4UEv1MHbrgxkBtkCJDtgwuut8PfRuxwbZn1cZkIjmM3X+ kCU292VYcjPBUHZM2NkHEmdPIeAfab2dvdbx922PtW++0AkDo9OmzWSCF1fEOVb14p9ubr/k 85oPkH9OqB8Uz4FB4WpN2UC8FjbQMfTgrlxe+3jfkyXN219v+RyGifskWNAtOTIDr7JN2y3W AAAAAAAA --------------ms060208010109030000090006-- From nobody Fri May 13 11:46: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 1073F12D509 for ; Fri, 13 May 2016 11:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 mBnXCebmKJ8Q for ; Fri, 13 May 2016 11:46:54 -0700 (PDT) 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 1FF0C12D516 for ; Fri, 13 May 2016 11:46:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 12FA3203BC; Fri, 13 May 2016 14:52:34 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0F85E638BE; Fri, 13 May 2016 14:46:53 -0400 (EDT) From: Michael Richardson To: "Dan Harkins" In-Reply-To: <9ac247d9e695571d48464e6e6d8d8228.squirrel@www.trepanning.net> References: <57070855.6020801@restena.lu> <27684.1460125258@obiwan.sandelman.ca> <9ac247d9e695571d48464e6e6d8d8228.squirrel@www.trepanning.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Archived-At: Cc: Stefan Winter , saag@ietf.org Subject: Re: [saag] IoT device authentication is overrated 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, 13 May 2016 18:46:56 -0000 --=-=-= Content-Type: text/plain Dan Harkins wrote: > An alternative to certificates or distribution of shared keys is > raw public keys in the form of something like a QR code [1] on the > backside or packing list of some headless device (like a thermometer). > The scanned public key is "trusted" because of where the QR code was > obtained and can therefore be used to authenticate the headless device. So effectively, what you've done is just swapped the "public" and "private" labels for the two halves of the public key. Or if you prefer, swapped the sign and encrypt operations. > [2] https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf An interesting and prescient read! It's nice to know that my suggestion of duck imprinting wasn't original, that a smarter person thought of it first: it makes my use of it in much less controversial :-) > The headless device can "trust" the entity that scanned its public > key through a variant of the Resurrecting Ducking [2]-- when it is > unprovisioned it accepts imprinting from the first device that knows > its public key similar to a duckling imprinting it's "mom" as the > first thing that moves and makes a sound. I really enjoyed the introduction of the new terms: reverse metempsychosis. escrowed seppuku device to be endowed with two souls I think that the mechanism that you've suggested is entirely a reasonable mechanism for interchangeable (consumer/retail) grade devices that come by the pallet load. There are a number of issues, particularly in the industrial and commercial building (lighting specifically) settings, which make this very simple and direct approach problematic. It amounts to that the people doing the physical installation are not trusted --- conceptually, one could do the imprinting in another location by a trusted entity, and then pass the devices on to be installed. The idea that we might do such a thing was discussed at length at the 2012 IAB (Paris) workshop in IoT security: the context that EKR introduced was that someone had systematically collected the QR codes from the boxes of thousands/millions of smart light bulbs (An employee at BIGBOXRETAILER.com). The devices continued on to be installed and used by individuals. The attack is what happens to the grid if you simultaenously turn on/off that many lightbulbs. The group spent most of the day talking about this scenario. So there are a whole bunch of problems that make this an unrealistic attack in my opinion. The first is that as observed by you and Andersen in Resurrecting Duck, that the once used, the QR code can't be used again; access would get replaced during that exchange. So having reaped all these codes, one either uses them immediately, causing the device to be unimprintable by the end user. Or the end uses the codes and imprints the bulb, and again replaces the identity. Or, if they find the device already imprinted, they "resurrect" the device, then the old access goes away. One question that I have thought about this situation is why use public keys at all. A symmetric key printed in a QR code might also be useable and simpler. It's also unclear why it should be a key at all, as opposed to just some opaque bearer token. If we call the thing the device the IDevID, and the thing that is printed on the outside and Ownership Token, then you wind up with the mechanisms exactly as envisioned in ANIMA and NETCONF. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVzYhGYCLcPvd0N1lAQKfGAgAiL4O0k40jIsuMSJi713GB/4+erjYqNil CPrTfvVNS5zEfwlo7kIq2S2wildApRh6HYjDVwfxjMWQ6bufqvuW84nbadPk+3Vt GsvY5O+dkMlzhtQI2Sz8X7alVqQQJLPzBqOAQGJAWEpFab0EvPSqdXEOZGwka4AQ bj97v2sBjOauj+sSzWOaUBIYMkr2vV4w9rB2RK5gQ/wEJfgWmFDTq5lC5jvHnWDf 8rZLg6vr4D6Qb0ESNwuwLjDi3qUbtrEuZpgtZm06/3Kpvyv0RXndu+tQHAh+y2SV 3K4oflqFgsQFV0h/DGcGk0uW8Mhn6KfC8YHqW76fGA71JV/DuKbTOg== =r3rv -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 13 11:53: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 8A03312D683 for ; Fri, 13 May 2016 11:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, 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 fo0mdiVNufIr for ; Fri, 13 May 2016 11:53:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB2E12D67D for ; Fri, 13 May 2016 11:53:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0F4A7203BC for ; Fri, 13 May 2016 14:59:04 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 005A3638BE for ; Fri, 13 May 2016 14:53:22 -0400 (EDT) From: Michael Richardson To: "saag\@ietf.org" In-Reply-To: References: <57070855.6020801@restena.lu> <27684.1460125258@obiwan.sandelman.ca> <9ac247d9e695571d48464e6e6d8d8228.squirrel@www.trepanning.net> <1364310E-0FB6-4DD1-9E8D-E9EEB9F86580@cisco.com> <3172a882c8d16658639e62844ff1455a.squirrel@www.trepanning.net> <5EC37D7C-8125-4668-9778-F4D9544E99C4@cisco.com> <9a529d2db5087e7e6e2540736afd6068.squirrel@www.trepanning.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Archived-At: Subject: Re: [saag] IoT device authentication is overrated 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, 13 May 2016 18:53:25 -0000 --=-=-= Content-Type: text/plain Alan DeKok wrote: > So I am cynical about the comment that only one device knows the > corresponding private key. It would be good to find a way to *ensure* > that the devices are properly provisioned. > For me, that means *I* will provision a new public/private key to the > device. It's critical that the only activity that the Ownership Token can provide for is to provision a new key. Whether a new private key is generated or not is another consideration. > Your scheme may work most of the time... but I pity the poor IT guy > who receives a shipment of IoT devices, scans the first QR code... and > has 1000 devices respond "That's me!" Assuming that they don't also all have the same MAC address, then this is actually okay: the process picks one, provisions the domain specific key, and then goes on to pick another. > Perhaps derive a symmetric key from a pre-provisioned public/private > key, and the MAC address of the device? The shame of sending multiple > devices with the same MAC address is a *lot* higher than the shame of > shipping multiple devices with the same public/private key. I advocate that the IDevID have the MAC address built-in to it, and the device use that. Many new devices don't have seperate MAC address PROMs, it's all stored in the same device flash. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVzYinYCLcPvd0N1lAQLAFAf/RXL5wHxDJGrebpqQSGEmHZbOo4rO6HKE eHCiQYLNoOryBpKIdJZaavxfszhL9Qc827DZsKolwmUyzRngWGqcQxl+qMVRUE5m wEC2xf/Dq2lwOY7gzujqcB2uf9ZcjtgbV9tThE9ir1Z+rVOgg1DRY1IsrRLgPK6p hgfzKUJtaQAUSEiNYTygFPL8wzzDW+6SIo0qehcSgqqGMG3d2/r4Gd1TLBbe9yUj P5UJy2ecdUDUB5WISQCh9azPBEsbEVLYZwWEPCRchkKCnhrLVwG6woCl5amylD64 OOzebArwZykwh9om3lmY5j9WD9m1tfyyfx+2o/4ZH+YvmPa+bdMEjg== =FG5h -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 17 08:32: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 81C7C12D6E9 for ; Tue, 17 May 2016 08:32:12 -0700 (PDT) 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 3TQXNbmDEFc4 for ; Tue, 17 May 2016 08:32:11 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 5A3DE12B04E for ; Tue, 17 May 2016 08:32:11 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id f66so24635550vkh.2 for ; Tue, 17 May 2016 08:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=/VkfGoSwmdYsMzZQKCy7kPYtALM0smcEr4F+XfCHDgI=; b=t/9BYf0Ci21ebZ7ekRt5CUZP62J2pyKj5A2WBv4tayr+DwddWKAKy4hDmbAuhzgL3u qPeF31VSWiNDeI28kyYS+VI24gSbfuZmslHS+qrJHiXbZ7FaqwZEjL4ine90Vk+UakZj iIGU3T9UpYPpYx2hGBE1q3Olcc9fJ+vc/0a/SHhfftKpJqxxyZxqskhyhYaSr1SWWPjZ x0Q/b1A1GefJOiRkXR7hYj134ppSdeRqE6LNn6ZkQQiaNQk/eRLouyL+tquiZkXpI3/h JoaPqg7riVA/31gB6EFH7Y/1C3shNbo0TYHZX60oLpqq7sqsvukvL6HJK85UIyrFfXYu yjyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=/VkfGoSwmdYsMzZQKCy7kPYtALM0smcEr4F+XfCHDgI=; b=FAt9HcCr/zH5tAWgPMOPQ8ZW2TrbKkEPHyKN2KriZVaZ8Tut5Sj7WJriePs2kbj3Z/ I/mL8W8EbhH0ox+ZYPPOyLwczndv9EKlIJOc2E9LcBUnWinvuNbg2zVQ1CIgHo6SRSfV cPnh8yOtMIljthXpCNUmYeME++gx6EbatY6jDUA7ZbuMHMT1syh8cojGVJ9CtdMJvVYW +QaacYmD2xPlAZyRfzd/v/14KF+nReIOsGFdqkTRimhb49H87Kg+eYa9zC7KXe+c8yYQ JPRW+lzJTaNF7aLW2Pij/pO6BX8219ACK1PszatmGRVJrYKmbH/5C6Jm491JM8Q+OtGM pTUw== X-Gm-Message-State: AOPr4FUyGIBTV9f2qOBTbkWppLpOXhS+ZyYhVPj2Iy3B+bxLON0YVYR9SOk1frXZen0O5a0f3dqPQzyVWH4EIw== MIME-Version: 1.0 X-Received: by 10.31.221.68 with SMTP id u65mr1000539vkg.25.1463499130493; Tue, 17 May 2016 08:32:10 -0700 (PDT) Received: by 10.159.54.231 with HTTP; Tue, 17 May 2016 08:32:10 -0700 (PDT) Date: Tue, 17 May 2016 11:32:10 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Security area working group chairs 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, 17 May 2016 15:32:12 -0000 Hello, We occasionally have openings for chair positions or need to appoint chairs to a new working group and figured it would be a good idea to ask on SAAG rather than just the individual lists in case we can broaden the pool of candidates a bit. If you are interested and have to time to volunteer, please send a note to Stephen and me. We are looking at options for IPSecMe and OpenPGP at the moment. We do have to make sure we are matching up chairs well with the responsibilities & technical expertise that is already covered versus what is needed. As such, it makes picking chairs a bit more tricky. Having a good pool to look at for these groups as well as future ones would be helpful. Thank you! -- Best regards, Kathleen & Stephen From nobody Tue May 17 17:25: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 2A48A12DAFC for ; Tue, 17 May 2016 17:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 W8FIv1QBmlxZ for ; Tue, 17 May 2016 17:25:04 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A31712DAFA for ; Tue, 17 May 2016 17:25:03 -0700 (PDT) Received: from [100.68.251.15] (unknown [152.206.104.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 00FAD82886; Wed, 18 May 2016 02:24:59 +0200 (CEST) References: To: "privsec-program@iab.org" , "saag@ietf.org" From: Fernando Gont X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: Message-ID: <573B3FAE.7090807@si6networks.com> Date: Tue, 17 May 2016 11:58:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: =?UTF-8?Q?Iv=c3=a1n_Arce?= Subject: [saag] On numeric identifiers (Fwd: Re: 6man w.g. last call for ) 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, 18 May 2016 00:25:05 -0000 Folks, FYI. At the last privsec and saag meetings we did a presentation on predictable numeric identifiers (draft-gont-predictable-numeric-ids). And we essentially noted how this is a problem that has persisted for 30+ years, despite efforts (e.g. Bellovin and others) to fix some instances of these. Year 2016, I read this argument in favor of embedding a link-layer address in the IPv6 IID (wasting 18 bits of entropy (0xfffe thing), using a layer-2 identifier for a ayer-3 scope, etc., etc.). The fact that people keep pushing this sort of flawed logic should give you yet another datapoint regarding the motivation for writing draft-gont-predictable-numeric-ids. (and could also be considered an invitation to weigh in in the corresponding discussion :-) ). Thanks, Fernando -------- Forwarded Message -------- Subject: Re: 6man w.g. last call for Date: Sat, 14 May 2016 10:55:26 +0900 From: Lorenzo Colitti To: Brian E Carpenter CC: IETF IPv6 Mailing List I continue to oppose this document. This draft says that existing address generation mechanisms are bad for privacy, and proceeds to change them. But there is nothing wrong with the existing address generation mechanisms as if the link-layer addresses are not stable, (e.g., random MAC addresses), and a growing body of IETF work This draft forbids implementations from using existing address generation mechanisms using random MAC addresses, which is a perfectly valid way to address the privacy problem this draft is purportedly solving, and is an approach standardized in other IETF work, for example, https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-08#section-2.1 (now in RFC editor queue). Here are several examples of how this draft forbids using address generation mechanisms with random MAC addresses.   The recommendations in this document apply only in cases where   implementations otherwise would have configured a stable IPv6 IID   containing a link layer address. ...   In standardized recommendations for IPv6 IID generation meant to   achieve particular security and privacy properties, it is therefore   necessary to recommend against embedding link-layer addresses in IPv6   IIDs. ...   By default, nodes SHOULD NOT employ IPv6 address generation schemes   that embed the underlying link-layer address in the IID. These statements should not say "link-layer address". They should say "stable link-layer-address" or "non-ephemeral link-layer-address" or "link-layer address that are not known to be ephemeral". Worse, consider this normative text:   The entire text of Section 4 of [RFC2464] is replaced with the   following text:   ---------------- cut here -------------- cut here ----------------   The Interface Identifier [AARCH] for an Ethernet interface MUST be   generated as specified in [RFCXXXX]. This explicitly prohibits an implementation from taking a random MAC address and forming an EUI-64 address out of it. On Fri, May 13, 2016 at 5:43 AM, Brian E Carpenter > wrote: With the clarifying references to RFC4941, I think this document is in good shape and ready to be advanced.   Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From nobody Tue May 17 17:32:23 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 3A72A12D5EE for ; Tue, 17 May 2016 17:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 IgUs_gaTDJkM for ; Tue, 17 May 2016 17:32:20 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7934612D5C5 for ; Tue, 17 May 2016 17:32:20 -0700 (PDT) Received: from [100.68.251.15] (unknown [152.206.104.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 99C5A82889; Wed, 18 May 2016 02:25:34 +0200 (CEST) To: "privsec-program@iab.org" From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <573B59B3.8080306@gont.com.ar> Date: Tue, 17 May 2016 13:49:39 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Dave Thaler , "saag@ietf.org" , =?UTF-8?Q?Iv=c3=a1n_Arce?= Subject: [saag] Definition of "numeric identifiers" (draft-gont-predictable-numeric-ids) 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, 18 May 2016 00:32:21 -0000 Folks, While presenting at the last IETF (IIRC this was during the privsec program meeting) some folks suggested that we might want to tweak the term "numeric ids", since some folks could mistakenly think we're also referring to numeric identifiers such as those assigned by the IANA (e.g., protocol numbers). So, I could think of this alternative: * "Dynamically-assigned Numeric Identifiers" Please let us know if this would work for you as a better term/title for the I-D, or whether you can think of something better/more precise. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue May 17 17:32:32 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 4B38212D15D for ; Tue, 17 May 2016 17:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 bFKt5q4k-P4i for ; Tue, 17 May 2016 17:32:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED84912B032 for ; Tue, 17 May 2016 17:32:20 -0700 (PDT) Received: from [100.68.251.15] (unknown [152.206.104.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 588DA8288A; Wed, 18 May 2016 02:25:26 +0200 (CEST) To: Stephen Farrell , "saag@ietf.org" , "privsec-program@iab.org" References: <570C2883.7010201@si6networks.com> <570C2ACD.7040605@cs.tcd.ie> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <573B5875.3090705@si6networks.com> Date: Tue, 17 May 2016 13:44:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570C2ACD.7040605@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [Privsec-program] Moving forward draft-gont-predictable-numeric-ids 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, 18 May 2016 00:32:22 -0000 Hi, Stephen, Are there any updates on this one? -- We're in the process of working on an update, such that we can post a rev well before the submission cutoff for the next IETF (hopefully two revs). Thanks! Best regards, Fernando On 04/11/2016 06:53 PM, Stephen Farrell wrote: > > > On 11/04/16 23:43, Fernando Gont wrote: >> Folks, >> >> We got a lot of good feedback both on-list and off-list since we >> published version -00 of our ID, and we're working on a rev to address >> such feedback (thanks a lot!). >> >> During our presentation at saag, we got some feedback on possible ways >> to move this document forward. So we'd like folks to comments on this >> meta issue, such that we can possibly address this one in the next rev >> of this document. >> >> Option #1: Keep the document "as is" -- i.e., address technical >> feedback, but keep al the contents in the same document. >> >> Option #2: Split the document into three documents: >> >> 1) A Informational document which discusses all the attacks that >> have affected IETF protocols due to predictable numeric IDs >> >> 2) A second document (BCP) that would update RFC3552 and would >> basically contain what's currently in Section 9 of our I-D. >> >> 3) A third (BCP) document with what's left from #1 and #2 above. >> (i.e., categories, and possible algorithms for each). >> >> >> Any other "option"? / Thoughts? > > Yes, I think your #1 vs. "something else" is good enough input > for the moment. (And I'd be in the "something else" camp myself > fwiw.) > > I'd like to have a chance to chat with Kathleen about how we > think might be best to update 3552 before we ask folks to > commit to an opinion here. (That'll take a few more weeks as > Kathleen is still on parental leave.) > > Updating 3552 involves more than just this issue, and arguably > ought not be particularly driven by this issue, so I'd prefer > that we ask another question about that later on and not right > now. > > So, I'd ask for your patience and for patience from other > readers of this. > > Thanks, > S. > > PS: Fernando - if your thesis that it takes us 40 years to fix > stuff is correct, then I'm sure you'll also be entirely happy > to be patient for a few weeks too:-) > > >> >> Thanks! >> >> Best regards, >> > > > > _______________________________________________ > Privsec-program mailing list > Privsec-program@iab.org > https://www.iab.org/mailman/listinfo/privsec-program > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri May 20 09:53:06 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 23E7112DE20 for ; Fri, 20 May 2016 09:53:04 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 48jBQ6v-DfBr for ; Fri, 20 May 2016 09:53:01 -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 6197912DE1E for ; Fri, 20 May 2016 09:53:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CBF87BE32 for ; Fri, 20 May 2016 17:52:58 +0100 (IST) 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 QZgAGeXzZNt7 for ; Fri, 20 May 2016 17:52:53 +0100 (IST) 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 6362ABE2C for ; Fri, 20 May 2016 17:52:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463763173; bh=2MfVkTl44CjeXm+JQjM+1yay9xdAPBD8kxck2SdLFhk=; h=Subject:References:To:From:Date:In-Reply-To:From; b=cjsQpgX3mjX7oyV5Jk7i/FpZd61aJWoqQjax5RsZkN+Vk7kJZzlxT4e8co88FcYcS 8hrUy127ew5cFbvvAFWIBjoc15veJLtd0YBNoBLaAnDMS0G4tkHfw4a+rakpxZFdGF 06+wZ60F7BoAeLX2pZXXW7qvwzEI6pfgsy8PfwOw= References: <20160519190608.15572.7838.idtracker@ietfa.amsl.com> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <20160519190608.15572.7838.idtracker@ietfa.amsl.com> Message-ID: <573F40E5.2080205@cs.tcd.ie> Date: Fri, 20 May 2016 17:52:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160519190608.15572.7838.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070402080501000104060905" Archived-At: Subject: [saag] New SEC AD will be needed (was: Fwd: NomCom 2016-2017 Call for Volunteers) 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, 20 May 2016 16:53:04 -0000 This is a cryptographically signed message in MIME format. --------------ms070402080501000104060905 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, Two things: 1. Please volunteer for nomcom if you're qualified. It's important that there's a good pool of folks from which to randomly select and even better if there's good security clue within that set. See below for details. 2. However... if you'd like to be a SEC AD please don't volunteer for nomcom. We'll be needing a new SEC AD this time around as I will not be re-upping (a 4th-term wouldn't be at all stylish:-) and being picked for nomcom rules you out. I guess there's a corollary there too - if you figure you might get arm-twisted into putting your name in for SEC AD (which we do do, and will do again:-) then you might escape that by getting selected for nomcom. And speaking of which, if you're interested in doing the SEC AD gig this time or sometime in the future please don't hesitate to contact Kathleen or I if you've any questions about that or just want to chat - we're more than happy to describe what's involved and what's needed. Cheers, S. -------- Forwarded Message -------- Subject: NomCom 2016-2017 Call for Volunteers Date: Thu, 19 May 2016 12:06:08 -0700 From: NomCom Chair 2016 Reply-To: ietf@ietf.org To: IETF Announcement List Subject: NomCom 2016-2017 Call for Volunteers The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 7437, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 7437, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are: IETF =3D 91 (Honolulu) \ 92 (Dallas) \ 93 (Prague) -*** ANY THREE! 94 (Yokohama) / 95 (Buenos Aires) / If you qualify, please volunteer. Before you decide to volunteer, please remember that anyone appointed to this Nomcom will not be considered as a= candidate for any of the positions that the 2016 - 2017 Nomcom is responsible for filling. Some 229 people have already volunteered by ticking the box on the IETF 9= 5 registration form. 131 of these have been verified as eligible. I will contact all of these shortly. Thank you for volunteering! The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Lou Berger IAB: Ralph Droms Russ Housley Robert Sparks Andrew Sullivan Dave Thaler Suzanne Woolf IESG: Jari Arkko (GEN) Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC) Joel Jaeggli (OPS) Terry Manderson (INT) Alvaro Retana (RTG) All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all other areas have 2 ADs. Thus, all areas (with the= exception of GEN) have at least one continuing AD. The primary activity for this nomcom will begin in July 2016 and should b= e completed in January 2017. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. While being a nomcom member does require some time commitment it is also a very rewarding experience. As a member of the nomcom it is very important that you be able to attend IETF97 (Seoul) to conduct interviews. Being at IETF96 (Berlin) is useful for orientation. Being at IETF98 is not essential. Please volunteer by sending me an email before 23:59 UTC June 20, 2016, a= s follows: To: nomcom-chair-2016@ietf.org Subject: Nomcom 2016-17 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 5 business days statin= g whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2016/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next few weeks. Thank you! Lucy Lynch llynch@civil-tongue.net nomcom-chair-2016@ietf.org --------------ms070402080501000104060905 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MjAx NjUyNTNaMC8GCSqGSIb3DQEJBDEiBCC1P1lbBhTNOZMnex0DlDadNh7wd7Xt2jGGPTRQLN/0 1TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCGhGygp3sCI3EiNMZN+MsBnvYTlgDSL1HbVyezLTmaDtJo1KhHYlm3 r3Kz8TI9Jko1en0nEhxTLjWa9IQ7fcxW+dD6qlR/2x0fwRZVbY1Ac/MF9cnRRwG0ogh2/8mt RVizUEm1M/otPXMemwgzM+luTTJXPL579Yiz+uws4CGgzPNfBmV0HQ4JyWhPgczXX31lfonS P7LkEiIAndwoGjje+BYgTPgz77JzAUPcNxL9awtGx6+B4KBH+6wMsUbKYJhe1jmwhuSpNdJ9 nMHTCCwMojjHgQzXt2MOnO7YRTUP3tPuBLB80PP54yeyVIzNY6VhE3zvPGfgDkbGq7NUAcxW AAAAAAAA --------------ms070402080501000104060905-- From nobody Sat May 21 12:15:28 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 064E112D579 for ; Sat, 21 May 2016 12:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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.426, SPF_PASS=-0.001] autolearn=unavailable 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 AkEo5QP8sXOh for ; Sat, 21 May 2016 12:15:26 -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 4B9AA12D1AC for ; Sat, 21 May 2016 12:06:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 83BCABE2C for ; Sat, 21 May 2016 20:06:41 +0100 (IST) 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 kxzcNhrpvM62 for ; Sat, 21 May 2016 20:06:36 +0100 (IST) 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 4EAFBBE35 for ; Sat, 21 May 2016 20:06:36 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463857596; bh=uQSW1MT2KSF+2IXDQ00UnDnPktdRzCw2gyRZWb3OawU=; h=To:From:Subject:Date:From; b=HpQhoGlNYwqD5nyRktruLa+9DY1OBzg/FFjcwjyfA1caSz0krwzZOEzeVRTSTTAJ+ vavZ/9yTFT7/1pGWswL1kXKeP16lqVOUSgtQGR6d7TT8Jvtq3XazpMdOAaZSHL9mIL lb2JV+q3XX63pffuKslz2w4d29/EyHlEdbIZbANI= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5740B1B7.8010100@cs.tcd.ie> Date: Sat, 21 May 2016 20:06:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020803040400080805000603" Archived-At: Subject: [saag] ART area wg proposed on a SIP/SRTP security BCP 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, 21 May 2016 19:15:27 -0000 This is a cryptographically signed message in MIME format. --------------ms020803040400080805000603 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, As the subject says, the art area are thinking of doing a BCP on SIP/SRTP security. Proposed charter is at [1]. It'd be great if some folks more interested in security were to help out there. (If you're willing, just go ahead and do it, but no harm if you want to tell Kathleen and I you're up for it.) Thanks, S. [1] https://datatracker.ietf.org/wg/sipbrandy/charter/ --------------ms020803040400080805000603 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MjEx OTA2MzFaMC8GCSqGSIb3DQEJBDEiBCDRQEPAOBlweUM5ETW/P4nUrD1g4zlmsSw8RW7lbyZV bTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCuyTAxDujM23lmae6eyK1QlPSC7QsDPX+fmQz5Jub0Qb7NC/3zH+1i 2RET/ZDJ5q7RdmVcoRhWTYF+xUpnxX0JODIEHMYj1lpSXdZYNgF6ZbBHiIi57QR+vldcgTAH YTqZIpZGCZycSYVGTfqldFMkgUxqrLQn5fxsIKr4JPFJqzxkIllpNYcOhQuFqI4ijr98eJVQ aEce9QD0Xmeq5N7KbMh8iXTuHQ1+lQqtvWCu9T5RtQFoYJZq6+SIDW5jrpp0rXft4XOdcjO+ 5kbf0eTL1R0DIzlZyenukAM3B/CuO8bHjTbt/QZcVTLQqfI7W32r0PryztDpbV1a48Nrk20Y AAAAAAAA --------------ms020803040400080805000603-- From nobody Tue May 24 12:19: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 636AF12D9DE for ; Tue, 24 May 2016 12:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-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 CHYXJP7PvWAS for ; Tue, 24 May 2016 12:18:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F010D12D9EF for ; Tue, 24 May 2016 12:18:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3D9681E335; Tue, 24 May 2016 15:24:00 -0400 (EDT) Date: Tue, 24 May 2016 15:24:00 -0400 From: Jeffrey Haas To: saag@ietf.org Message-ID: <20160524192400.GA9721@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [saag] Fate of BFD extended authentication mechanisms 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, 24 May 2016 19:18:58 -0000 Security-folk, Partially as a response to work concluded in the KARP Working Group, there was previously some effort to enhance the cryptographic authentication mechanisms present in BFD. The core BFD protocol is described in RFC 5880, including its authentication mechanisms. The two main documents covering this work are below: https://tools.ietf.org/html/draft-ietf-bfd-generic-crypto-auth-06 https://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-05 To somewhat tritely summarize the work in these two documents, the generic doc provides for: - Increase the number space of authentication sequence number to 64 bits from 32. - Provide a larger numbering space for key identifiers, from 8 bits to 16 bits. - Re-using this structure for all future types rather than making it a property of the individual authentication section for a given mechanism. The hmac-sha doc describe SHA-2 variants of ciphers. In general, these are understood to be the Right Things to do for BFD. However, lack of interest in the industry from either vendors or customers, and lack of drive from within the working group have contributed to these documents going stale. There is also the secondary issue that as a result of the speed at which BFD operates and the fact it is often operating under extremely constrained compute resources, even existing ciphers are not well deployed in spite of the known weaknesses in the strength of those ciphers. There is a separate effort beginning in BFD that may mitigate these issues, but I have requested the authors of that draft to contact the security area separately to discuss their proposal: https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ Now to my question: It's generally understood that implementations of security mechanisms often lag their specifications. It's also generally understood that you want those specifications to exist because when you need them, it's possibly already too late. Given this, I'm looking at options to help drive the BFD generic crypto and hmac-sha document to publication. As mentioned, the interest in the BFD WG is low. My question is what is the perceived status of security related documents that are on the Experimental track? For these documents to progress on the standards track, they'd have to have some likelihood of being deployed. That point is, as above, unclear. -- Jeff From nobody Tue May 24 19:03: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 7D27712D0F2 for ; Tue, 24 May 2016 19:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.226 X-Spam-Level: X-Spam-Status: No, score=-4.226 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 clJcRKuIzWWu for ; Tue, 24 May 2016 19:03:05 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651C712D188 for ; Tue, 24 May 2016 19:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1464141786; x=1495677786; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=f4N7E7hsZfVDP3aj3w0itbZ0RboFlWM1G61JWNobNGI=; b=2aod78KQJshBDLblYw3DIqKS7powBuxAXBvKLCABhbl7knLIZVipDo4G hrsd45Z2QRM56ZjHwalddObLXhQZhOHQWFbEMbJZfbelhBYLPskH0XT7+ uhOigpOk1MNLFH7We4ZAfhb4ror51+LylBVsdAWJEHiz+mreVjlQlKrpM RpkTXdamgBl3rUsScs6fne7mefKYNSwOT+TBUulF/qDytRnRUYrSKBrvj Uuo2nez6WY08mamEk+48v3r0sKkx5RhFTqtyU2CqArqNk3idsO6hHKk+q qmf3CsmR2KFFvgbICzWzo4o0j63qfmGqCJ+rBfg9/PSJX33iqUITnHqGB g==; X-IronPort-AV: E=Sophos;i="5.26,362,1459771200"; d="scan'208";a="87802255" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 May 2016 14:03:02 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Wed, 25 May 2016 14:03:02 +1200 From: Peter Gutmann To: Jeffrey Haas , "saag@ietf.org" Thread-Topic: [saag] Fate of BFD extended authentication mechanisms Thread-Index: AQHRtfEof+1eZMaIyU6aLbo3s0ujkZ/I5xnS Date: Wed, 25 May 2016 02:03:00 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C89DBD@uxcn10-5.UoA.auckland.ac.nz> References: <20160524192400.GA9721@pfrc.org> In-Reply-To: <20160524192400.GA9721@pfrc.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Fate of BFD extended authentication mechanisms 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, 25 May 2016 02:03:09 -0000 Jeffrey Haas writes:=0A= =0A= >Partially as a response to work concluded in the KARP Working Group, there= =0A= >was previously some effort to enhance the cryptographic authentication=0A= >mechanisms present in BFD.=0A= =0A= Boston Fire Department? Big F**cking Deal? Bad Fur Day? Bidirectional=0A= Forwarding Detection? Binary File Descriptor? Block Flow Diagram? Base= =0A= Flood Depth? Bowling for Dollars? Blood Fire Death?=0A= =0A= Peter.=0A= From nobody Tue May 24 22:47:07 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 18C6212DA47 for ; Tue, 24 May 2016 22:47:07 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=junipernetworks.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 w-BEF5rIeOxO for ; Tue, 24 May 2016 22:47:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5958812DA4A for ; Tue, 24 May 2016 22:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e4e7Q7HBzYDDIqQuMX+shfBpnxOfOPl5lzbThMEvDlA=; b=WdVPqEhc4GzdzeuBNPp+wKABzSEpdwkipp87BqA8RpxWf5Fk3JHyUWNeCHa0bmZ5kuzJmp+1dLks9CELef3SlWj1PM/r6A+R9B9Fnc0vg9MNfMp7bpF/6kP70PIk9WW7j/WwDdqYgqoLVRIy1YJfm8Fn2XeOCbb3Iz5y0fhJ7G4= Received: from CO2PR05CA026.namprd05.prod.outlook.com (10.141.241.154) by CO2PR0501MB805.namprd05.prod.outlook.com (10.141.244.139) with Microsoft SMTP Server (TLS) id 15.1.501.7; Wed, 25 May 2016 05:46:37 +0000 Received: from BL2FFO11FD021.protection.gbl (2a01:111:f400:7c09::160) by CO2PR05CA026.outlook.office365.com (2a01:111:e400:1429::26) with Microsoft SMTP Server (TLS) id 15.1.497.12 via Frontend Transport; Wed, 25 May 2016 05:46:37 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; cs.auckland.ac.nz; dkim=none (message not signed) header.d=none;cs.auckland.ac.nz; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Wed, 25 May 2016 05:46:35 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 24 May 2016 22:45:58 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u4P5jvJ40776; Tue, 24 May 2016 22:45:57 -0700 (PDT) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id E36621141B; Tue, 24 May 2016 22:45:56 -0700 (PDT) To: Peter Gutmann In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C89DBD@uxcn10-5.UoA.auckland.ac.nz> References: <20160524192400.GA9721@pfrc.org> <9A043F3CF02CD34C8E74AC1594475C73F4C89DBD@uxcn10-5.UoA.auckland.ac.nz> Comments: In-reply-to: Peter Gutmann message dated "Wed, 25 May 2016 02:03:00 -0000." From: "Mark D. Baushke" Date: Tue, 24 May 2016 22:45:54 -0700 Message-ID: <84176.1464155154@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(9170700003)(47776003)(81166006)(117636001)(19580405001)(8676002)(586003)(92566002)(53416004)(76506005)(8936002)(6806005)(19580395003)(86362001)(48376002)(106466001)(1220700001)(2906002)(87936001)(50466002)(110136002)(189998001)(105596002)(4326007)(5003600100002)(2810700001)(2950100001)(50986999)(76176999)(54356999)(11100500001)(15975445007)(77096005)(5003940100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB805; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD021; 1:1Mb+L57BfF6q153Oq3E1NgqB5VV0xBE4k9sjSVQQECwDq/UBM+Ne0bdjjhUCbS7rsmlSQogw0n5FhSX1vEc80/hYEkx0WZemVw60qmHnDH10OYsM+jau2w68EjAd4uhHSueAB9taCYkkDk+mLCcgtkhWQdEEC0XTZM9JGIpx3aqz3y/Q90bnMTDFtqDpmNjfhTeR09OuCEc+bDAn0eV4FMO1giB/URelW97Dl2+xFenWjC7/qU0UHolXPYmMTnKNxPmp1ZKsbPybNp41B/seTUHOLsZFkpkz/OJDjrwyi2K6i79vsx0EbbFMa0E4EralVdiXW1rhRiMzSSfPyXsXPRRfw3XBPHDe3bIHZiLKr2H845G+nTmXjANLbC/eUTW2tVTscEMrv3tJObe0kpvP+DD8E+n1JxOq1Y7xj2iThSLqge1GINFK0+sTj8gzrG2c8IGgCxrA8pAufrbJvnXulKo8BV3S7iU5+kQ8mwSZo0U= X-MS-Office365-Filtering-Correlation-Id: 5eb8896f-e638-4ca1-0ec4-08d3845fef54 X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB805; 2:oOmmRm7BS3FzfU0q4zq3CeklXC2kHtQwm2zhsZRP+oupAYJEcfHNig+I6FNd5744yxhelBJ6NXeNzFiXwDIRLqulPPcJO/RUfHU0d/+NjROb8AAIdD/sAsPcWbP+prrVTLYphaFNXVYVmH9eUJZCJTcBBGaUtxju+PhTVtXEtFYuU1T0azmAA3isoOwEqtm/; 3:7wi1gd4SliC2xhZKJJ5Bhu8tK9ZT5ZQMIlhftDpdLZES12mLkfLwVWXdgtalwNGrKdw5L2YpDv9InZYYCEOgm4jA2REQr9PbNmAxVz+yASZpqnZXcIgOsFf3T8T8gozLtAkDMwk0JKgRQq+dYN8zu7SGCK8zZVRPSDMv1B9pxlMvOj9JxaTdCjnKr91rlnl3dDh5y/m5Ylx2b+qf9ZQPR2tiIqHumdb21NPL4uYmtf4= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB805; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB805; 25:tWrrL5VGfKGfEA7BQKEnyLENhB2lzKRgxdUeW5by3j0i48xLhfST0kMJx7u4JZbFGf36ts6zTIUx1FUIE5PwgCAciHBUnIAAX6shEjBnKhLlV7raZPu6sRHZYVT2QYH4OOgEEvs2uzWOKmXadeqeyVePgEAKl4jA7Tr8Uc0Axp+qQCGW5wcBggZ7xgrCxfc1NEP2eQmiSILFOOBkXoLaP5jTfkIePPTDesCy6WNe+XAxcfqL8u373rHmVkrx5Pg2Blp6wURFN5ONF/MgzZJnvVB1H+29NUH6ti8awgn9oiXDNxuzPVE6WTmVodbPpOx7xXG05qPX4qq6wdqt/9KWdDcTFHephWNuAiT0E0nbwCkXur/wMk1yRI/JT/MmxbYAQMKs5ZUXQxscurXKkoK8c5jGnOyQkROrtqGlvaDJ+CjgNYZfgj7m7+C9cF+sO3VS1tFX8utqk/PgwjNppzpPteZvVzxYrOsp58N5gEdazvm4FSVVRx57CYKmDcR425exljbyg5r5Ov5Z95BlnePTNVALtyQAb/FU4pdR6d48KSOpkwAVlTfuR9EhRtKpO0mgg75ZiSCeUpGQABXjvaYvyiwlldgVeWNlpAbcUfhIvxyrdhQbBrmNlEkvwHwEgOnKNd/8E7ItGd4AxpqTz8eXzZFvydKb3smo9lf9evvwFW4Lm13DC4fjA5Yi3DvPWp1C1G8DZL1dR4a+pJFoS304DMNtRCpsguEq5Og95I8PdDzcvr2ORc5rmAWgNfxYEwyCUEwpbiFFt1PzXbcjwqskHigRvB/C6u4DLEczNTAMoFUqEYb22aMJwFHnfhuolO9d4CiAiqziOD+9JvTKbkvmn0lHsjtL2ZSOL9FEkus9x6MqcJn5dn9Al+TwaeogBLkW X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB805; 20:qKw0Kfba+NyKsFITzwqDUz4kzNfCSpthyHp2hodQykfIUIcH4J55RiLeN+dNhJ2Vw9V0Nb8Q+R0zHjLNHeGoaGymhM5fpa7E3kI5rqE6cwuahcmqF3ojCmnKzD+eJajv1VVNqQ5DN6voPYNf71dLlkS3pHME5O1V9FyMyXA7AU4nUH24tu9wzj/PTCkZTJTnavNRv51Hf4qWy8AKejwUYK0k11dbwsDfUey39QeS6UyH4fBU3Aqhy5nnyLpTG5tUIrFOABAkAaWGN/M/XITGYUmo3eC2jP3Pkwsk8pTik3fqVPYq8QxSCbgx/czzzKchZDY/qvOX+FILVgLLmJCyhtT4z6vHRK4aHoLboj5aTZ+Jg/PWLB4DKziHGTIBFv+5YCzWvlhjm/OCU1d/gjs6CSZsztm+DHSarRb9FekVs7eofs2re3qK0zoxNvwAW69oW+iz5ds5+yYSp3YGJh97JXwkQvFnXgm+igoGTbTm7RqidTmXrEMNpy+vh2wItLNx X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13017025)(13024025)(13018025)(5005006)(13015025)(13023025)(3002001)(10201501046)(6055026); SRVR:CO2PR0501MB805; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB805; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB805; 4:ScRQkoagimaxaLgHbcWZiDr7Gvsf3aO5pokXJeDI/Vz9Et3c8l10LJ13QxBRPG5Tju22SKvvFEk9Quq06x+d4FXMlG+XiItR0dJQGm5yf58G21zcyMj8wtHN1Fnuth4N124m/zkb6PE3zkr/9jbKqKR322zpmsyI85TRFDrUVFC/gUkcnAXJxuqVlJRgndqMmN0cQWkMkA29I/I2u0Bu7vuGJi8X6QlbMHCYRmvIuGpUyyRtzfWSuH4R1e9gEe+D17JSoDOXXa28tfqJ5SdT/KB+U0C1ZSnEVxw/FqXxy7xNv7aYruwXDZW0wVNyOzzKbCtU2NnKP9juW6dYvnCG6Sw8BWun8wAdbsDQUMJm2JuWXMrzprsPe0PKhJs8T4UKkwp/tX/ht2p+P0RMFdYGmCPQgrdMlB4YeBONjnTDjIoaEBdOwfpYFXkLcPuij46925H1ZzjluvVur9vC/N/NsLCfT2ipgul7zOhEvQyF1Bo= X-Forefront-PRVS: 09538D3531 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR0501MB805; 23:B5VZF6JhC4S9vnqhRICoI32KARm5w4vOtN64kWK2?= =?us-ascii?Q?8BmPD0l8mlqApazZpPuvEPrpDWTHx5M55qwapAzjUPhfYzM3ddKKJrMdLtoy?= =?us-ascii?Q?D0ZDCB7IHaELvte+Q2x5pX93H5bT4H4cFNRPeN4vASH92VPAbv5/vc8BTeM3?= =?us-ascii?Q?kh0pAd69/IT3JbEqN3qS98eXjFbAXZiIERqm1f6cq+GYguSkQLBM5g5H43sm?= =?us-ascii?Q?KDkYY468O7loZj/1vnVP9VWoxWNsosI7ZXzbC8RU5sN4cBfPf4NLpupAfgjy?= =?us-ascii?Q?1ILh81qz7+qVWfp4o3vKKvu5AP9qbH7qkvPBVPFB9T47O1NDdz/a6NxSTkSr?= =?us-ascii?Q?KgtVBgWKpyhoxb4l7iCiboaCr/cHn95+G9NDflLre1nU0c3ZxTOkY+Jp14UP?= =?us-ascii?Q?IN3LNRyGAp46UzL1J/sUtIpbh92m4X8q6mFVRkJD4vYgrD5bRRMj8BXnONjI?= =?us-ascii?Q?NBYvvZpbmKvBnDD8+floahQvHo29JwNIF6D7agy4a/Bqk7s+rxJlv+CN4vOK?= =?us-ascii?Q?IWC8f+uJ5PbNHNVoLVs/b25YJ6oHt/LsLQa+RJ83/2HuNvB3Kf6PxvUFY84V?= =?us-ascii?Q?/xR1EYcNj+GTWlFK7iTb/Uf1LbCFESxfLAsirlDK08oZFZJU2Ar0yzJJchwG?= =?us-ascii?Q?n42dUV2NXpZk3LL6we7Dtz9zDys040ZPf8GJGzbC0xisR2iYvQYoGym8DAGE?= =?us-ascii?Q?42qeP1VAqEApJ6jlDLUGLKiGFtcZ1FwCiOgW1AQ85Frj8uv0QMQ1F7HFRGVf?= =?us-ascii?Q?J2+SCPKrErYq3hpmKHNEMY7F3CQz/jKNEHtdV48Qwru0NPR3Jsb5eIGE4RGL?= =?us-ascii?Q?W9CnmVWWbt5j7BvRnkUGXcBCIa1zHfDDP01GKkN2EQi5+vfE11wIFmY+ijnz?= =?us-ascii?Q?t8b+MfTM+EJPOCJ3zFWNgpigz0u5KV1cjUc7wexiDh21k26QNqli84kmMp/Y?= =?us-ascii?Q?0nMB9DTIBJswGFeFToTsnA0aoTMUZvd53+iovLA/daoI53vhjWYiAOj5t+/q?= =?us-ascii?Q?XARAmI/XYf1T7Io/zUr2cWwjq+fug0c95XFO4Sk8MxAEsg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB805; 5:DMZIlSWdTBXtFdaci70WnPk+HyWPTQMUrcmkoK6ToDGnm+ddeexSWrjnQ6aVcfjTr1aSuQdTOqV42vCMlpUVNaQZ40m2Ws/K1HnooY5abeEzirqVcbDmrNZx1pvZP8wXs4LVwgZL+3n3wiTGuXPu6g==; 24:sqWa+J9SisUNXq8xMjBgPB4XSWo+7OFAM8pvQImm53slHz8US3QaJXDFe9D349DpgNLMBTzISlxCXyjL51usNTfIG6ZMSXfv296iEDKfzDQ=; 7:oFdkXyWebwbA8uZgojnNXCuQVcL33/IYP6YnyAov+1JOmY0iqYX7UElp0Lq8bKWKNyIxx7cKLpjtyPTdlJp05YR6MR7hFNoeTA5kRybUgyxiZS/bhWvKvQOZPV1uk+kxa3AHZa3CiWAW39yYaoNOI8TDaroBvBZI5IRKyEZbxHogP9JamszN5+XSZ4/InSkO SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 May 2016 05:46:35.7962 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB805 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Fate of BFD extended authentication mechanisms 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, 25 May 2016 05:47:07 -0000 Hi Peter, Peter Gutmann writes: > Jeffrey Haas writes: > > >Partially as a response to work concluded in the KARP Working Group, > >there was previously some effort to enhance the cryptographic > >authentication mechanisms present in BFD. > > Boston Fire Department? Big F**cking Deal? Bad Fur Day? Bidirectional > Forwarding Detection? Binary File Descriptor? Block Flow Diagram? Base > Flood Depth? Bowling for Dollars? Blood Fire Death? My guess would be this one: IETF BFD WG => Bidirectional Forward Detection (bfd) https://datatracker.ietf.org/wg/bfd/documents/ And I suspect that this is the effort at hand... Optimizing BFD Authentication https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ See also RFCs: 5880 5881 5882 5883 5884 7130 7330 7331 7419 7226 Of course, I could be wrong and one of your suggestions might be correct. :-) Enjoy! -- Mark From nobody Wed May 25 07:22: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 849FF12D6CA for ; Wed, 25 May 2016 07:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-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 Yrd7HzjfrXSA for ; Wed, 25 May 2016 07:22:52 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D275612B041 for ; Wed, 25 May 2016 07:22:50 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id F0BC71E1CC; Wed, 25 May 2016 10:28:13 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Jeffrey Haas In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C89DBD@uxcn10-5.UoA.auckland.ac.nz> Date: Wed, 25 May 2016 10:22:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C1CC683-9C14-4FF1-9FD9-7EA2337AF0A3@pfrc.org> References: <20160524192400.GA9721@pfrc.org> <9A043F3CF02CD34C8E74AC1594475C73F4C89DBD@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Fate of BFD extended authentication mechanisms 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, 25 May 2016 14:22:53 -0000 Peter, > On May 24, 2016, at 10:03 PM, Peter Gutmann = wrote: >=20 > Jeffrey Haas writes: >=20 >> Partially as a response to work concluded in the KARP Working Group, = there >> was previously some effort to enhance the cryptographic = authentication >> mechanisms present in BFD. >=20 > Boston Fire Department? Big F**cking Deal? Bad Fur Day? = Bidirectional > Forwarding Detection? Binary File Descriptor? Block Flow Diagram? = Base > Flood Depth? Bowling for Dollars? Blood Fire Death? You cut off the next immediate sentence: The core BFD protocol is described in RFC 5880, including its authentication mechanisms. Jokes about the acronym aside (I've heard them all before), please stop = the trolling. While I generally have good intentions toward Doing The = Right Thing for security issues, the security ADs will happily confirm = my patience for the process is weak at the best of times. -- Jeff= From nobody Thu May 26 16:24: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 B67D712D874 for ; Thu, 26 May 2016 16:24:01 -0700 (PDT) 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, 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 gNmPH6YOANzd for ; Thu, 26 May 2016 16:23:58 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B8C12D6A0 for ; Thu, 26 May 2016 16:23:58 -0700 (PDT) Received: from [192.168.3.104] (192-174-17-190.fibertel.com.ar [190.17.174.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E10D28017A; Fri, 27 May 2016 01:23:51 +0200 (CEST) To: Stephen Farrell , "saag@ietf.org" , "privsec-program@iab.org" References: <570C2883.7010201@si6networks.com> <570C2ACD.7040605@cs.tcd.ie> <573B5875.3090705@si6networks.com> From: Fernando Gont Message-ID: <5747850A.1090009@si6networks.com> Date: Thu, 26 May 2016 19:21:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <573B5875.3090705@si6networks.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [Privsec-program] Moving forward draft-gont-predictable-numeric-ids 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, 26 May 2016 23:24:02 -0000 Ping? On 05/17/2016 01:44 PM, Fernando Gont wrote: > Hi, Stephen, > > Are there any updates on this one? -- We're in the process of working on > an update, such that we can post a rev well before the submission cutoff > for the next IETF (hopefully two revs). > > Thanks! > > Best regards, > Fernando > > > > > On 04/11/2016 06:53 PM, Stephen Farrell wrote: >> >> >> On 11/04/16 23:43, Fernando Gont wrote: >>> Folks, >>> >>> We got a lot of good feedback both on-list and off-list since we >>> published version -00 of our ID, and we're working on a rev to address >>> such feedback (thanks a lot!). >>> >>> During our presentation at saag, we got some feedback on possible ways >>> to move this document forward. So we'd like folks to comments on this >>> meta issue, such that we can possibly address this one in the next rev >>> of this document. >>> >>> Option #1: Keep the document "as is" -- i.e., address technical >>> feedback, but keep al the contents in the same document. >>> >>> Option #2: Split the document into three documents: >>> >>> 1) A Informational document which discusses all the attacks that >>> have affected IETF protocols due to predictable numeric IDs >>> >>> 2) A second document (BCP) that would update RFC3552 and would >>> basically contain what's currently in Section 9 of our I-D. >>> >>> 3) A third (BCP) document with what's left from #1 and #2 above. >>> (i.e., categories, and possible algorithms for each). >>> >>> >>> Any other "option"? / Thoughts? >> >> Yes, I think your #1 vs. "something else" is good enough input >> for the moment. (And I'd be in the "something else" camp myself >> fwiw.) >> >> I'd like to have a chance to chat with Kathleen about how we >> think might be best to update 3552 before we ask folks to >> commit to an opinion here. (That'll take a few more weeks as >> Kathleen is still on parental leave.) >> >> Updating 3552 involves more than just this issue, and arguably >> ought not be particularly driven by this issue, so I'd prefer >> that we ask another question about that later on and not right >> now. >> >> So, I'd ask for your patience and for patience from other >> readers of this. >> >> Thanks, >> S. >> >> PS: Fernando - if your thesis that it takes us 40 years to fix >> stuff is correct, then I'm sure you'll also be entirely happy >> to be patient for a few weeks too:-) >> >> >>> >>> Thanks! >>> >>> Best regards, >>> >> >> >> >> _______________________________________________ >> Privsec-program mailing list >> Privsec-program@iab.org >> https://www.iab.org/mailman/listinfo/privsec-program >> > > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon May 30 03:27: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 A0A8612D1A8 for ; Mon, 30 May 2016 03:26:59 -0700 (PDT) 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 71zbtBSxgwIj for ; Mon, 30 May 2016 03:26:58 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 2B84512B034 for ; Mon, 30 May 2016 03:26:58 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id c189so217208842vkb.1 for ; Mon, 30 May 2016 03:26:58 -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=UmjmoO8LBVR8uTKe1RRm+VqHPevsBUdmhD0ZAzWRpGc=; b=BaUu3fYqkxR2iAf40p57thibKwkeaPNsODOomcmWDjBGievaBOnVP0RG0BLwicDIu8 fnEJvF+ERmjVx3265xNFcEK+DX4a5ZX3tWBiueEz/08nZedL4jWjravF0WEw8hLmXZTU BMTklA5W8xC391ZcxxRbLHTpFbtW+mrMRM3KXMCu4KJ0qhglXm8pcy7VLRvD4lmYXD5A QCrAXY9CS/oxpAzMu/d+gCY0r8sw/56ipl53hG5vosQr5iwZcHf+KaWwMro2pz+/E9we GeNgNABgKb44U/svILHgBVroAX4FJDQeefIMR6lfZFuJFghRsS4kDPVZlmKtlC5RiqG3 aAYA== 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=UmjmoO8LBVR8uTKe1RRm+VqHPevsBUdmhD0ZAzWRpGc=; b=VAToheBrDeEh/OBu3PbUp41pvTEbbIQ383s7uu93AlbuZf2IqWpdpc6D5dLTtXEWt1 Lfy6qoL/EdtM3tGp8uZyb/UTI/zHdz3t7ETdhtcQKWnI4W0h9K0ncA2GKd33BZ/EpNwf 50H8DSK/rI9vJ4aWGaWGxgCVvWfcDUIqN5eKKJKt1LtdQWNB5ikiUAHnvNnVE7I4wURi K96EqkkCLZ5kKGiETQWLTLchMxkSPZYNBo3/+gBXF7ugFuSx18Ckl99YZHoI5RwVcu0u bphoBDSAIX0DG5e22eH3HNynejUUzvkuTxUKib/Fet6EKvUckSFokDNHeGgTIZvD6dW0 vL2Q== X-Gm-Message-State: ALyK8tLaVNEq8O6/WeDtltU/9BhmTJ32XmAa9ISF2SaQJ+z0Y8KuOrDmQdihkO6PQlabZ0tIOcObsnBHmWhFSw== X-Received: by 10.31.84.2 with SMTP id i2mr14305377vkb.132.1464604017208; Mon, 30 May 2016 03:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.132 with HTTP; Mon, 30 May 2016 03:26:17 -0700 (PDT) From: Nikos Mavrogiannopoulos Date: Mon, 30 May 2016 12:26:17 +0200 Message-ID: To: IETF SAAG , philliph@comodo.com Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] PKIX - TLS Feature Extension 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, 30 May 2016 10:26:59 -0000 Hi, RFC7633 describes a PKIX certificate extension to indicate mandatory to be present TLS extensions (called feature extensions in the text). In particular this draft while generic, is mainly about requiring an OCSP staple from the connecting server if the certificate mandates it. However, the rfc text doesn't go into details on how to do that. My understanding and as far as I've seen in practice certificates will include a "Feature" extension containing integer 5 which is the OCSP status request. If the reading above is correct, how does this scale with status_request_v2 (which has TLS extension ID 17)? How could the certificate be used to indicate that the server can provide any of these TLS extensions? Should both the numbers 5,17 be listed as TLS features (which can also mean that both TLS extensions must be used), or having 5 listed is sufficient? regards, Nikos From nobody Tue May 31 10:15: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 55B3812D865 for ; Tue, 31 May 2016 10:15:54 -0700 (PDT) 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 dEqAxUuQuvZP for ; Tue, 31 May 2016 10:15:51 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 6B6F812D856 for ; Tue, 31 May 2016 10:15:50 -0700 (PDT) Received: (qmail 14527 invoked by uid 1004); 31 May 2016 17:15:48 -0000 Received: from clofcgmail2.cl.office.comodo.net (HELO clofcgmail2.cl.office.comodo.net) (10.104.70.204) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 31 May 2016 18:15:48 +0100 Received: (qmail 12939 invoked by uid 1012); 31 May 2016 17:15:47 -0000 Received: from pool-96-230-12-42.bstnma.fios.verizon.net (HELO galifrey.hallambaker.com) (96.230.12.42) (smtp-auth username philliph, mechanism plain) by clofcgmail2.cl.office.comodo.net (qpsmtpd/0.84/v0.84-169-ga857589) with (AES256-SHA encrypted) ESMTPSA; Tue, 31 May 2016 13:15:47 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "philliph@comodo.com" In-Reply-To: Date: Tue, 31 May 2016 13:15:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <23F24B75-9B2E-41E5-8405-457421C370A2@comodo.com> References: To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF SAAG Subject: Re: [saag] PKIX - TLS Feature Extension 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, 31 May 2016 17:15:55 -0000 Yes, that is exactly what is done and the reason that the spec is = written the way it is. > On May 30, 2016, at 6:26 AM, Nikos Mavrogiannopoulos = wrote: >=20 > Hi, > RFC7633 describes a PKIX certificate extension to indicate mandatory > to be present TLS extensions (called feature extensions in the text). > In particular this draft while generic, is mainly about requiring an > OCSP staple from the connecting server if the certificate mandates it. >=20 > However, the rfc text doesn't go into details on how to do that. My > understanding and as far as I've seen in practice certificates will > include a "Feature" extension containing integer 5 which is the OCSP > status request. >=20 > If the reading above is correct, how does this scale with > status_request_v2 (which has TLS extension ID 17)? How could the > certificate be used to indicate that the server can provide any of > these TLS extensions? Should both the numbers 5,17 be listed as TLS > features (which can also mean that both TLS extensions must be used), > or having 5 listed is sufficient? >=20 > regards, > Nikos