From pipnflinx@gmail.com Tue Oct 3 07:07:15 2017 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 6E2C6134605 for ; Tue, 3 Oct 2017 07:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYodPubCtoWA for ; Tue, 3 Oct 2017 07:07:14 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 39AFC13448E for ; Tue, 3 Oct 2017 07:07:14 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id 88so1070141uar.0 for ; Tue, 03 Oct 2017 07:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Bmf2SryieRDaVbkMZC7OfKo5eJqRKuvFzGIT53Ez7Z0=; b=TA7OSmukBf8dC//skBIKUW5rxzHxy3xQWxiKbxHd2mZVGArOu0Im2McIBnc5Qde4hq YARTlF94K8y2HrMIryk+3PIqiP60j/PHukctmO6RHGT4UkNYKjb7hT1TnoMF0OUIxKKZ ZjFHxPWaSiKkjCRKdwL+kVV+v8v86ZfbXVvcAO8znw98oZrISVpi6IHJWGI7KakmDmDD bA8YiY5NTc0d2BOSJWRuzZcyqr/Ip+PdNF+G9ndnCezTfNnlRinPU80nHzMplVfJmDyM LDpxe90nI/2NjyBx1vutHcL+4y5ivfP9qzH731uWYnlzeuhGLa2aVMtv/aYTJFivaNW8 QN0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Bmf2SryieRDaVbkMZC7OfKo5eJqRKuvFzGIT53Ez7Z0=; b=HfsgU3AcLeG9VfZkKHq2kImFf8IaGvNyHdHOmGBO/53QgwZBR4/Yr1+bo+8XAVo1nC Gg9kxbEzHdShXqkOkTjX8LQOJzdqW+dnfHcUhqfVPaomZj+vNuuFxlrR5fdElrWCNxl7 h7XPenYlrOEcGWd99yV4ZDQGy3ap+ceZCUh06aYLegZ/8DBV9wqxnBv4O7rK5IDeFtyh sahYkTTFMmAhhe6tbFQO+7HiVKYTYVgGU5sLRUItdWGkY0T7z8SdjfdmBbHSai8Ep6ev aK7aTXEUSc4RKvREHCv0SeIcwjiLaT38IhpaBVYuNz+bzenSD5MliLGivxib57ngprZX Bz9Q== X-Gm-Message-State: AMCzsaUqHVhbbPBAQHjTnRuks9yAG+vImU1GkpLS7M05wbI1e0rcp9UV DnADpy8Ue8Ej9VVLJsTc+WSGAqC3jh8zObGguyY= X-Google-Smtp-Source: AOwi7QB8Klk6JWcYlr0mlesM1yrNkjIaAbZOaGbtWeFsDzOLaPuNmB6IchI/xU0cjFxoQ0lOJktK6OjoOn9ZRd1XUqE= X-Received: by 10.176.86.70 with SMTP id z6mr4286461uaa.103.1507039632929; Tue, 03 Oct 2017 07:07:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.110.4 with HTTP; Tue, 3 Oct 2017 07:07:12 -0700 (PDT) From: Peter Alexander Date: Tue, 3 Oct 2017 10:07:12 -0400 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary="f403045e1834fbb77f055aa501cf" Archived-At: Subject: [saag] Guidance for writing Internet-Drafts? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 14:08:33 -0000 --f403045e1834fbb77f055aa501cf Content-Type: text/plain; charset="UTF-8" Greetings! Some years ago myself, and another individual drafted a patent application for a novel use of IPSec which enhanced security between endpoints. Since then the application has been rejected, and the company has been dismantled. My co-author at the time mentioned how cool it would be if we could turn the idea into an RFC eventually. I have finally decided to begin looking into that. Having never written an Internet-Draft I would greatly appreciate some guidance (beyond the Guidelines to Authors of Internet-Drafts) regarding a formal submission. I do hope that I have found the correct place for this discussion. Cheers, Peter Alexander --f403045e1834fbb77f055aa501cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings!

Some years ago myself, and a= nother individual drafted a patent application for a novel use of IPSec whi= ch enhanced security between endpoints. Since then the application has been= rejected, and the company has been dismantled. My co-author at the time me= ntioned how cool it would be if we could turn the idea into an RFC eventual= ly. I have finally decided to begin looking into that.

=
Having never written an Internet-Draft I would greatly appreciate some= guidance (beyond the Guidelines to Authors of Internet-Drafts) regarding a= formal submission.

I do hope that I have found th= e correct place for this discussion.

Cheers,=C2=A0=

Peter Alexander
--f403045e1834fbb77f055aa501cf-- From nobody Tue Oct 3 10:10:33 2017 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 76A3D134F8E for ; Tue, 3 Oct 2017 10:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10uo8qQM-NDH for ; Tue, 3 Oct 2017 10:10:29 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160DD134F83 for ; Tue, 3 Oct 2017 10:10:26 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id m72so11678987wmc.0 for ; Tue, 03 Oct 2017 10:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dTmoAGGtaPqiEye7d3Z2daxa7F17AVjSPMjtMm8rLvk=; b=jdniFN0cZxxja3QddWui6I26Hg8X7KCx6mPSwr0Uv34uOmScpuz/AKBh7L2ud4WVai aH7Sc7IAmtnnrkGAXHEBAniyFjomUA11yIz9/SaEwje9fTO9z8taH9bt6OUsrL7c4i9V AFUXbU3q39V/8M2AG8R0UDtfeQqtmeVBUDpWdF/Qk7R7UEpIYXZo9uIzkT8kNoIOSOuY OqtXZIrxk8Hs7boQFY5I9NplSRbjIlarCS69LZBYEYff/PjOLo3pK8HeeOE9G7NL/jMF 58DiyWGDt6fxrNRMeKwe+MinZHWFlM+V1CsZw9CiDo7U/Ulaxwt4CTNLuIpztiHpTNeg rSpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dTmoAGGtaPqiEye7d3Z2daxa7F17AVjSPMjtMm8rLvk=; b=szYW5NtTL9NiYQ4upRiSKR6aN6addK5uB6Cbu5mCfPuqihDGQ3iXAHizyqpDjgIthp 7tzTx6kneLpoy4qlQCBSCTXkAWwqhqqfhNiHaecz9+xqLnyAmWkUbtLCJ9kncR/hfmvK HrgI3lfVy4//XBXodL2haQWq/2hdjXQJgjt5sopyLRJ+wjrjB0LaD4n6i3L3wnfmoHq+ o9BPIyNFaxWwVaw6y6UfpzX+UjKyEFmgYbKTNJUryGyr+7E0Vy9f6ub4reCh0FM+PBxJ S6nm6+cXgbZETwt5gd+jyoVr18CB4biUUk34hiYLGG+fI5opwfwFqVmYnl8Zhl7oXSlm uBiQ== X-Gm-Message-State: AHPjjUhlmXaHT3BdeUWo6pDPPOrRhLPAn1vDs9AV+ZsXINoWqj/9IDea 59YFonKLzu54eqvPDesZFYo= X-Google-Smtp-Source: AOwi7QDcX7OPLhtQjmAxdpbBpBslYBqD94MjCJcRs1clxGxj6QQNun3iDdBLoWttNFXtL9X5AwiFog== X-Received: by 10.80.185.68 with SMTP id m62mr25407702ede.239.1507050624618; Tue, 03 Oct 2017 10:10:24 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m1sm12334165edd.56.2017.10.03.10.10.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Oct 2017 10:10:23 -0700 (PDT) From: Yoav Nir Message-Id: <9E9F9413-6A06-4151-8012-5E8CA2AB5397@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C4B2EE3C-8A12-4E3C-B353-D3EADB6850E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 3 Oct 2017 20:10:21 +0300 In-Reply-To: Cc: Security Area Advisory Group To: Peter Alexander References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] Guidance for writing Internet-Drafts? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 17:10:31 -0000 --Apple-Mail=_C4B2EE3C-8A12-4E3C-B353-D3EADB6850E7 Content-Type: multipart/alternative; boundary="Apple-Mail=_32D5C556-08E8-4227-B272-021FDCD2E9F2" --Apple-Mail=_32D5C556-08E8-4227-B272-021FDCD2E9F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Peter 1. Find some draft that looks like what you want. For example, let=E2=80=99= s pick https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-01 = 2. Click that =E2=80=9CXML=E2=80=9D tag at the top. You=E2=80=99ll get = https://tools.ietf.org/id/draft-nir-ipsecme-eddsa-01.xml = 3, Download the file and rename it to something like = draft-alexander-ipsecme-enhanced-security-00.xml 4. The format is not too complicated. You can edit it to have your = content. 5. Either install the utility xml2rfc or use the online converter at = https://xml2rfc.tools.ietf.org 6. Repeat until you like what it looks like. 7. Submit on the draft submission page: = https://datatracker.ietf.org/submit/ = Then, when there=E2=80=99s a draft, you can start a thread about the = content either here on on the IPsec mailing list: = https://www.ietf.org/mailman/listinfo/ipsec = HTH Yoav > On 3 Oct 2017, at 17:07, Peter Alexander wrote: >=20 > Greetings! >=20 > Some years ago myself, and another individual drafted a patent = application for a novel use of IPSec which enhanced security between = endpoints. Since then the application has been rejected, and the company = has been dismantled. My co-author at the time mentioned how cool it = would be if we could turn the idea into an RFC eventually. I have = finally decided to begin looking into that. >=20 > Having never written an Internet-Draft I would greatly appreciate some = guidance (beyond the Guidelines to Authors of Internet-Drafts) regarding = a formal submission. >=20 > I do hope that I have found the correct place for this discussion. >=20 > Cheers, >=20 > Peter Alexander > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_32D5C556-08E8-4227-B272-021FDCD2E9F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Peter

1. Find some draft that looks like what you want.  For = example, let=E2=80=99s pick https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-01
2. Click that =E2=80=9CXML=E2=80=9D tag at the top. = You=E2=80=99ll get https://tools.ietf.org/id/draft-nir-ipsecme-eddsa-01.xml
3, Download the file and rename it to something like = draft-alexander-ipsecme-enhanced-security-00.xml
4. = The format is not too complicated. You can edit it to have your = content.
5. Either install the utility xml2rfc or = use the online converter at https://xml2rfc.tools.ietf.org
6. = Repeat until you like what it looks like.
7. Submit = on the draft submission page: https://datatracker.ietf.org/submit/

Then, when there=E2=80=99s= a draft, you can start a thread about the content either here on on the = IPsec mailing list: https://www.ietf.org/mailman/listinfo/ipsec

HTH

Yoav

On 3 Oct 2017, at 17:07, Peter = Alexander <pipnflinx@gmail.com> wrote:

Greetings!

Some years ago myself, and another individual drafted a = patent application for a novel use of IPSec which enhanced security = between endpoints. Since then the application has been rejected, and the = company has been dismantled. My co-author at the time mentioned how cool = it would be if we could turn the idea into an RFC eventually. I have = finally decided to begin looking into that.

Having never written an Internet-Draft = I would greatly appreciate some guidance (beyond the Guidelines to = Authors of Internet-Drafts) regarding a formal submission.

I do hope that I have = found the correct place for this discussion.

Cheers, 

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

= --Apple-Mail=_32D5C556-08E8-4227-B272-021FDCD2E9F2-- --Apple-Mail=_C4B2EE3C-8A12-4E3C-B353-D3EADB6850E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlnTxH0ACgkQuEkLFQpY zJnQZgf9ELhtTEXu3BnrqsVdh/g7j9YX31ZbqiyXBYKwt7yCjdasNA6uXe1XMo8f p8rP+8Dj3r8+KqSo1HlBCemYG1yPZc4RqVe9Vy1SOIeRrG3VNMSkQo5oGgFWDkN/ qSD0sma7hS3SRhrEmzT6O9loVfBHKdRM5NYfdCOiL74gFm9kUTLaXX9ikLYBvxWw laQVKCXqt91pRz3+SmTN9hcOfOhz8p2dh6RTTxJ4AV6P6R+T03kk0/vsS2UY5qVu QM1JuXxQpjFUZL37kQjvmUU9Npa4WGM2EN9cgcABL3s7yPiplnNcFTzHd8EGkeWM IJxIY59p2+/98LISiHAw1Ufbkg54XQ== =RYF9 -----END PGP SIGNATURE----- --Apple-Mail=_C4B2EE3C-8A12-4E3C-B353-D3EADB6850E7-- From nobody Tue Oct 3 10:46:37 2017 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 86852134F0C for ; Tue, 3 Oct 2017 10:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvofjKXaXOTN for ; Tue, 3 Oct 2017 10:46:35 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7A5133044 for ; Tue, 3 Oct 2017 10:46:34 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id n5so6774482qke.11 for ; Tue, 03 Oct 2017 10:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CvUANukN3/yf2GH0whWg5xBUImEJdIpwxshMFOAjKb4=; b=uw07av0v+NerQYds5nagZWc3mP6LLIcjljAR1aBrwXxqR2rYb0QHIrOjj/j/PftoJS 8oFCAof5UEo2PyvpFeoXnEChT1n/t9q39YliFzjBZnuC1/ZJeuY7/4nlR5/hWBR6+Lvz kztsjfH/IiirNRXspeJH3J69dQ3nfiSFHr3710/5+1m4H78r1v7rXNDm5Lh6AhYKAX6/ OuAWKfjJQTgOg18wmsPgcXkniVKIkEWsVLESSczkaRGSUNbLqNvqNAcUZm7Tz3Gthd6y yJI4bRDHOb39XnG4tpp+YlEBVR9+s9x17ialkOCTirk1LrjMwEGchmNkC3L9jLtXAIxq eA8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CvUANukN3/yf2GH0whWg5xBUImEJdIpwxshMFOAjKb4=; b=beT/0aGGAHEd0pxlByCf7MvQRbVgvf72jMuKM2zVu2LvjNUKMleYwu7RacLep7l5gg JjsEzba3DuvakH2BmdrePKZRaC2E9WbFRmUWTU0We4kvehaEfFalazhD9BXbs2USgFvg 6besGpRDbQ4vjhfWbZv8tD6ueogzagoXDoYzG5TCZbQj0oMX32GAmITOT+TcN2gje7cI u5u8pFwk30oKjgZiXMYgJhOI5f3NJVSb8iC1UvlDzsO3eV0ZpxCb2upAqFeukCE67Rqc NL0bcXNYEKBFRe/V5/6qM/Vn6/zKd28JlUO7mZlyQgeZfWnT1e94Q7qdwEB0HCUXVY7D 7cpQ== X-Gm-Message-State: AMCzsaWpDDB07lKCNUHZ15a9CwNg1qNHusjMEoXKRECtNWFHcjlv49ad +ZfFwe8zyfvo/fr1m8NkPlUchpfLRQ55TBrgtuY= X-Google-Smtp-Source: AOwi7QAbyEkJXHKxmbU2E0PmvKXApEGUsiZo/UUa+uNF7v9Eb35JNOBm+dC8lYyUL8VMdZkyJXg7Pi3wbtCeUPnfyW0= X-Received: by 10.55.31.141 with SMTP id n13mr19578696qkh.179.1507052793850; Tue, 03 Oct 2017 10:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.58.97 with HTTP; Tue, 3 Oct 2017 10:46:33 -0700 (PDT) In-Reply-To: <9E9F9413-6A06-4151-8012-5E8CA2AB5397@gmail.com> References: <9E9F9413-6A06-4151-8012-5E8CA2AB5397@gmail.com> From: Peter Alexander Date: Tue, 3 Oct 2017 13:46:33 -0400 Message-ID: To: Yoav Nir Cc: Security Area Advisory Group Content-Type: multipart/alternative; boundary="001a1147da866f6e82055aa81274" Archived-At: Subject: Re: [saag] Guidance for writing Internet-Drafts? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 17:46:36 -0000 --001a1147da866f6e82055aa81274 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yoav, Thank you for this. I will start digging around to see if I can find something similar. Pete On Tue, Oct 3, 2017 at 1:10 PM, Yoav Nir wrote: > Hi, Peter > > 1. Find some draft that looks like what you want. For example, let=E2=80= =99s pick > https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-01 > 2. Click that =E2=80=9CXML=E2=80=9D tag at the top. You=E2=80=99ll get ht= tps://tools.ietf.org/id/ > draft-nir-ipsecme-eddsa-01.xml > 3, Download the file and rename it to something like > draft-alexander-ipsecme-enhanced-security-00.xml > 4. The format is not too complicated. You can edit it to have your conten= t. > 5. Either install the utility xml2rfc or use the online converter at > https://xml2rfc.tools.ietf.org > 6. Repeat until you like what it looks like. > 7. Submit on the draft submission page: https://datatracker. > ietf.org/submit/ > > Then, when there=E2=80=99s a draft, you can start a thread about the cont= ent > either here on on the IPsec mailing list: https://www.ietf.org/ > mailman/listinfo/ipsec > > HTH > > Yoav > > On 3 Oct 2017, at 17:07, Peter Alexander wrote: > > Greetings! > > Some years ago myself, and another individual drafted a patent applicatio= n > for a novel use of IPSec which enhanced security between endpoints. Since > then the application has been rejected, and the company has been > dismantled. My co-author at the time mentioned how cool it would be if we > could turn the idea into an RFC eventually. I have finally decided to beg= in > looking into that. > > Having never written an Internet-Draft I would greatly appreciate some > guidance (beyond the Guidelines to Authors of Internet-Drafts) regarding = a > formal submission. > > I do hope that I have found the correct place for this discussion. > > Cheers, > > Peter Alexander > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > --001a1147da866f6e82055aa81274 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yoav,=C2=A0

Thank you for this.=C2=A0
I will start digging around to see if I can find something similar= .

Pete

<= div class=3D"gmail_quote">On Tue, Oct 3, 2017 at 1:10 PM, Yoav Nir <ynir= .ietf@gmail.com> wrote:
Hi, Peter

1. Find some = draft that looks like what you want.=C2=A0 For example, let=E2=80=99s pick= =C2=A0https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-01
2. Click that =E2=80=9CXML=E2=80=9D tag at the top. You= =E2=80=99ll get=C2=A0https://tools.ietf.org/id/draft-nir-i= psecme-eddsa-01.xml
3, Download the file and rename it to som= ething like draft-alexander-ipsecme-enhanced-security-00.xml
4. The format is not too complicated. You can edit it to have your content= .
5. Either install the utility xml2rfc or use the online convert= er at=C2=A0htt= ps://xml2rfc.tools.ietf.org
6. Repeat until you like wha= t it looks like.
7. Submit on the draft submission page:=C2=A0https://dat= atracker.ietf.org/submit/

Then, when ther= e=E2=80=99s a draft, you can start a thread about the content either here o= n on the IPsec mailing list:=C2=A0https://www.ietf.org/mailman/listinfo= /ipsec

HTH

Yoav

On 3 Oct 2= 017, at 17:07, Peter Alexander <pipnflinx@gmail.com> wrote:

Greetings!

Some years ago mysel= f, and another individual drafted a patent application for a novel use of I= PSec which enhanced security between endpoints. Since then the application = has been rejected, and the company has been dismantled. My co-author at the= time mentioned how cool it would be if we could turn the idea into an RFC = eventually. I have finally decided to begin looking into that.
Having never written an Internet-Draft I would greatly appreci= ate some guidance (beyond the Guidelines to Authors of Internet-Drafts) reg= arding a formal submission.

I do hope that I have = found the correct place for this discussion.

Cheer= s,=C2=A0

Peter Alexander
_______________________________________________
saag mailing listsaag@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/saag" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/saag


--001a1147da866f6e82055aa81274-- From nobody Thu Oct 5 12:18:36 2017 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 787E913263F for ; Thu, 5 Oct 2017 12:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8EvnaqS_B60 for ; Thu, 5 Oct 2017 12:18:33 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 040DB13431D for ; Thu, 5 Oct 2017 12:17:40 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id u12so8406533pfl.4 for ; Thu, 05 Oct 2017 12:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vTy2rR5y6Hn52CwURBt6/rEhuxLmRj4GU6bhjIsVK/o=; b=llokQxqurBvMx6qRag9xVISEowS5pGnsUagguQkEcREOUnO9ONIrywUeL4+QPW9zW2 L2LDk8bqZ2DBL/DESyc3vvtVR0HxJ2QOP/fMrR5UnW6V5+O5G0/6Rn2mg4HbCfVSvQc6 0oRLStyDVTJMjRPo10V5/J8iFUUxHTnw35nxFXOpdV90Pvd+tHf6NbPmCOJAGZ5YLKyH z+Z8vJSyErU3qkRfaSzzw/yd1OVdDQew2qk2Wey7rtUdz5MruwkkgAfZ/Ln5gG5BPFen 3M9gcmsrbdicyDj6CT1nQSUxNds5IvRkcx3StO7jxv3fVk5J4srjVof4NEOAUcfy/0sb kHuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vTy2rR5y6Hn52CwURBt6/rEhuxLmRj4GU6bhjIsVK/o=; b=JViOh9zwBa2Ts1kFUKhCxnoBNJ0M73+dxR0+f9iFQhjHWYsBI4V3HQB2s2ggmVxJtd P7ChNlEmKLCnm6NI/g/kIlz7JNqRs5faHhcqOfWLWzSlSqEVYuFZm6JeHKCGb6puX8Vw PgWo3y+lVQdMTbpaxXmCwaOOj1JwsuDxVHFjam3RiIAAOdkXkjf3M9u4vJV03f0qdHD9 rVWK8AL9kahwKhhaKe++B+BW7p/ZanLKfYsUdXTlvE80/EMtA6grAZT4ObcYDOdFCwH8 /7k23UtHupFx8W/NS9S9K/yi/FQwogXmkNQsB+VRKUqDr7Ee6hCV+kXJ2V+D/0/+Qu+k BPgw== X-Gm-Message-State: AHPjjUj2YFUU2EjWXRA1pI6cQJ+nLEYqa2pc92lfa6UtrLTQUXObqNaR 9vaaBbiVaJVmQ20/3UZ/MjibKbLLQw+jtWQWZCQ= X-Google-Smtp-Source: AOwi7QDE4dgo1YILDxD6vQm7Fjw5C6GlMN6jCugcFcizZkFv5HPyqY4S8RenCsgieOhdZdFrfmv+KPmKxP9iUgPFwRo= X-Received: by 10.84.130.47 with SMTP id 44mr23477387plc.171.1507231060315; Thu, 05 Oct 2017 12:17:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.233 with HTTP; Thu, 5 Oct 2017 12:16:59 -0700 (PDT) From: Kathleen Moriarty Date: Thu, 5 Oct 2017 15:16:59 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Security AD Role X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 19:18:34 -0000 Hello, I have had a few changes surface after I accepted a nomination for Security AD and wanted to let the community know that I am VERY likely to pull my name from consideration. I wanted to let folks know while the nomination period was still open. If you are considering putting your name in the hat and have questions, please reach out to Eric or me (or former ADs). -- Best regards, Kathleen From nobody Sat Oct 7 11:37:27 2017 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 49498134B12; Sat, 7 Oct 2017 11:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uycmojqQWQUt; Sat, 7 Oct 2017 11:37:12 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 A79E01342F1; Sat, 7 Oct 2017 11:37:11 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t69so13641053wmt.2; Sat, 07 Oct 2017 11:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x94bjUdkXDMVmhfXlLTCu4egzpqJb5s7zTtFk52b1YQ=; b=EOZvUU42P0+tY8esykPQSAY9y2rj0TTpR9AOBLFXrBQZCvvFmEmNC9ZDIMCLDxYu/6 30YWiQfRZ+CH9JcVUQaFw1U6EIS4DOKjQCBXG8G9dsIlczbTysJLkHYMBIS7Aw3hjbau hb8+iPVySvPBL9WsFuCUauFPFlqR6lxCUvS5BBcoFXTyz1+fE0p4HddFk789SfaiyNyI +G6jz/oCg1LZslVSsLfxz05SAc2XpVJOocJAArGw7h6fkvDuUOhx0VKsy2CJNygcqAKA iqDC2NfyZfyamRu70UR4hn+DKK2KKPad6ONrv7KUAbfXeKQDjgLozhkgVCMuwN9l0RSB hlHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x94bjUdkXDMVmhfXlLTCu4egzpqJb5s7zTtFk52b1YQ=; b=f/bGsEUDPhV/N5HdDC0FbN4jcYxpvFi5RORPD4iMmy1n3sYfyOrqSuHIRj9nmXxY+m Fx6WMp6Xhw0kA7+HuwCY6IZyYy5k2mbcwJpD0AshI3p/EO3RR0l5fzuo8PcmUGY4WlE2 UxasxuCcnLb3UdUc0V3GS72t38cQCRxbz15s1VIKT5/N7jonmRP9q6ZfuYS6xtSw0tCl MZ1oCrTUVXBVhocNJkNlO2tnrYeSi/PCDOLtuccDBl9AHfz4jYlGr4p49LyJzI582M6b NNXt6tpGxSVf8kWYhxW0cpGhxE/NAf0JQM/YwrqyUAL4AkGkBJ4E/mNgeQybDXtHWPL3 lZsQ== X-Gm-Message-State: AMCzsaXW9gbKkMO97fqfnys77BHwOBM7hCp6iTvvx9Xi6/KuLEEzVI9x FHZ6+JmAIsznx5Hk+0hJ69tzoZ+Nxjnijg3bryo= X-Google-Smtp-Source: AOwi7QBZLFVdLrLWMfNXYEf4+jrxj4diUUwLrBWsBOZWjHBcNTV7tFqxYWA5m6DkLp6JVlFxkRyWdaDFE3a8I25lnSk= X-Received: by 10.80.174.241 with SMTP id f46mr7882561edd.135.1507401430163; Sat, 07 Oct 2017 11:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.220.202 with HTTP; Sat, 7 Oct 2017 11:37:09 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Sat, 7 Oct 2017 21:37:09 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: multipart/alternative; boundary="f403045c18e0c76566055af93e42" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 18:37:14 -0000 --f403045c18e0c76566055af93e42 Content-Type: text/plain; charset="UTF-8" Dear Nicos, Sorry for the delay with my response. On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos wrote: > On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky > wrote: > > Dear Nikos > > > > On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos < > nmav@gnutls.org> > > wrote: > >> > >> > >> 4. How do you handle extensions to this format? > >> > >> Overall, why not use X.509 extensions to store such additional > >> constraints? We already (in the p11-kit trust store in Fedora/RHEL > >> systems) use the notion of stapled extensions to limit certificates > >> [0, 1] and seems quite a flexible approach. Have you considered that > >> path? > >> > >> regards, > >> Nikos > >> > >> [0]. > >> https://p11-glue.freedesktop.org/doc/storing-trust-policy/ > storing-trust-model.html > >> [1]. > >> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca- > certificates.html > > I've looked through the specification. It's OK for me, but I do not get > > whether the attached extensions are crypto-protected. > > No, as these values are inserted by the administrator of the system, > or us (the distributor of the software), we didn't feel we needed the > introduction of additional PKI. > Well, the specification I suggest should allow applying CLPs issued by major vendors (Mozilla etc). For this purposes the CLPs should be validable => signed. > How do you see the infrastructure on the > draft-belyavskiy-certificate-limitation-policy? Who do you envision > signing these structures? (I assume that distribution of data will be > done by software distributors?) > I anticipate some ways to distribute CLPs. 1. Major vendor-issued CLPs are distributed either by vendors or by OS vendors (similar to, e.g., ca-certificates package in Debian). In this case we should have certificates to sign these CLPs distributed together with these bundles. 2. App-specific CLPs may include the key as a part of the application bundle. So CLP is distributed via normal app-distributing channel. 3. Locally created CLPs. This is the case more or less similar to the p11-glue solution, if I understand it correctly. Various protocols, such as TAMP (RFC 5934) can be used for transport the CLPs too. > > >> 4. How do you handle extensions to this format? > >> > > Simillary to CRL. Do you have ideas of the extensions? > > One problem with that is the fact that the existing CRL extensions are > about extending attributes of the CRL, rather than adding/removing > attributes to the certificate in question. > For this purposes I implied that the limitations are provided not by extensions, but as SEQUENCE of limitations related to the certificates. Was I wrong in the ASN1 scheme in the current version of my draft? > To bring the stapled extensions to your proposal, you'd need the > Extensions and Extension fields from RFC5280, and > add into limitedCertificates structure (I'll split it on the example > below for clarity) the following field. > > LimitedCertificates ::= SEQUENCE OF LimitedCertificate > > LimitedCertificate ::= SEQUENCE { > userCertificate CertificateSerialNumber, > certificateIssuer Name, > limitationDate Time, > limitationPropagation Enum, > fingerprint SEQUENCE { > fingerprintAlgorithm AlgorithmIdentifier, > fingerprintValue OCTET STRING > } OPTIONAL, > limitations SEQUENCE, > } OPTIONAL, > }; > > > stapledExtensions Extensions; <----- NEW > } > Sorry, I do not get the difference between the purposes of the field 'limitations' and 'stapledExtensions'. > Another difference between this profile and the p11-kit one, is that > the extensions/revocation here is done on the certificate, while in > p11-kit is done on the public key. Both approaches have pros and cons. > Sure. > > Another question. I also noticed the fingerprint field above. Is that > to distinguish between same CAs with different keys? In that case > using the SubjectPublicKeyIdentifier may be sufficient, and more > natural as this is how certificates with matching DNs/serials are > distinguished. > Do you mean Subject Key Identifier (RFC 5280, 4.2.1.2)? Yes, I agree and I'll update the draft. I introduced the fingerprint field to distinguish bogus certs from the valid ones, but I think the SKI will be OK for this purpose. Thank you! -- SY, Dmitry Belyavsky --f403045c18e0c76566055af93e42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Nicos,

Sorry for the delay with my= response.

On = Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos &l= t;nmav@gnutls.org&= gt; wrote:
On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
> Dear Nikos
>
> On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org>
> wrote:
>>
>>
>> 4. How do you handle extensions to this format?
>>
>> Overall, why not use X.509 extensions to store such additional
>> constraints? We already (in the p11-kit trust store in Fedora/RHEL=
>> systems) use the notion of stapled extensions to limit certificate= s
>> [0, 1] and seems quite a flexible approach. Have you considered th= at
>> path?
>>
>> regards,
>> Nikos
>>
>> [0].
>> https://p= 11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-mo= del.html
>> [1].
>> http://nmav.gnutls.= org/2016/06/restricting-scope-of-ca-certificates.html
> I've looked through the specification. It's OK for me, but I d= o not get
> whether the attached extensions are crypto-protected.

No, as these values are inserted by the administrator of the system,=
or us (the distributor of the software), we didn't feel we needed the introduction of additional PKI.

Well, t= he specification I suggest should allow applying CLPs issued by major vendo= rs (Mozilla etc).
For this purposes the CLPs should be validable = =3D> signed.



How do you see the infrastructure on the
draft-belyavskiy-certificate-limitation-policy? Who do you envision signing these structures? (I assume that distribution of data will be
done by software distributors?)

I antic= ipate some ways to distribute CLPs.

1. Major vendo= r-issued CLPs are distributed either by vendors or by OS vendors=C2=A0
(similar to, e.g., ca-certificates package in Debian). In this case w= e should have=C2=A0
certificates to sign these CLPs distributed t= ogether with these bundles.

2. App-specific CLPs m= ay include the key as a part of the application bundle.=C2=A0
So = CLP is distributed via normal app-distributing channel.

3. Locally created CLPs. This is the case more or less similar to the= p11-glue solution,
if I understand it correctly.

<= /div>
Various protocols, such as TAMP (RFC 5934) can be used for transp= ort the CLPs too.
=C2=A0

>> 4. How do you handle extensions to this format?
>>
> Simillary to CRL. Do you have ideas of t= he extensions?

One problem with that is the fact that the existing CRL extensions a= re
about extending attributes of the CRL, rather than adding/removing
attributes to the certificate in question.

<= div>For this purposes I implied that the limitations are provided not by ex= tensions,
but as SEQUENCE of limitations related to the certifica= tes.

Was I wrong in the ASN1 scheme in the current= version of my draft?



To bring the stapled extensions to your proposal, you'd need the
Extensions and Extension fields from RFC5280, and
add into limitedCertificates structure (I'll split it on the example below for clarity) the following field.

LimitedCertificates=C2=A0 ::=3D=C2=A0 =C2=A0SEQUENCE OF LimitedCertificate<= br>
LimitedCertificate ::=3D SEQUENCE {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 userCertificate=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateSerialNumber,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 certificateIssuer= =C2=A0 =C2=A0 =C2=A0 =C2=A0Name,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitationDate=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Time,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitationPropagati= on=C2=A0 =C2=A0Enum,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fingerprint SEQUENC= E {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 finge= rprintAlgorithm AlgorithmIdentifier,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 finge= rprintValue=C2=A0 =C2=A0 =C2=A0OCTET STRING
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} OPTIONAL,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 limitations=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQUENCE,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} OPTIONAL,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stapledExtensions E= xtensions; <----- NEW
}

Sorry, I do not get the difference be= tween the purposes of the field 'limitations'
and 'st= apledExtensions'.


Another difference between this profile and the p11-kit one, is that
the extensions/revocation here is done on the certificate, while in
p11-kit is done on the public key. Both approaches have pros and cons.
<= /blockquote>

Sure.
=C2=A0

Another question. I also noticed the fingerprint field above. Is that
to distinguish between same CAs with different keys? In that case
using the SubjectPublicKeyIdentifier may be sufficient, and more
natural as this is how certificates with matching DNs/serials are
distinguished.

Do you mean=C2=A0Subject= Key Identifier (RFC 5280, 4.2.1.2)?
Yes, I agree and I'll up= date the draft.

I introduced the fingerprint field= to distinguish bogus certs from the valid ones,
but I think the = SKI will be OK for this purpose.

Thank you!
<= /div>

--
SY, Dmitry Belyav= sky
--f403045c18e0c76566055af93e42-- From nobody Sat Oct 7 20:31:30 2017 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 7C26A13331E; Sat, 7 Oct 2017 20:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEoUoE651Y-u; Sat, 7 Oct 2017 20:31:21 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7E2133078; Sat, 7 Oct 2017 20:31:20 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id c82so20174030lfc.6; Sat, 07 Oct 2017 20:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Prd6OgF7t7YAi6BCUrTaOlcSYcyIAeTLoc4K4V2s8j4=; b=d4my61sYNBVlPOeMxkf+5RIyZgwT+SenU42iKIX7D1gHjHZFjYQ9QbPtdqbYqvdlJK BDbsD6rnVLMismMHxOGKkBxVWzlSuLJElKv+iS3c6saW68gOknjcFdzJByXaMCE9xfmr vv/e3jfJxVjyndkmbUn1/9zLibCFYafV4ELlO1+lrykKrVmFQ9XSSAd/uwklsLUoVi0a Z35N6GbkNVuix1qqcikOz1j/8YJigsbgn0zbw0VCGAFM2vYGO6T6WCdb78T5cG9jRkQV RIm0pNPi1WvNv+MuPLAMGknAJSiIMnAlCz5panmQ7V7R1C4L0KrwcH9HDFLg448MQM0d +dHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Prd6OgF7t7YAi6BCUrTaOlcSYcyIAeTLoc4K4V2s8j4=; b=iBX89SxVt7xHfOsdVYSF1u54w/n4Qp5ETvVTEpArRKIGQAitLyI9W/isAFZmYZQipz k5ENfKnvw9eC3DOcnYtEjiPXgqjjBu9FudubH1oEleJ08BjEo1OjwLmEC4AZGtIHys6M Y57N6v5LeM8+Q4E4vUsjtgkZS0P21gqNMOlrYNsMa6Aft111TQFgHrg577qDHDrS2E6O P9JkMgftyMPLz+yZqAhBBud65eVIsEw9V5FZonesJ70ELxa9t42vLRdr7IZmQc08ouSd 5KxKm3q3xZ1faDrQJ/Mo5/NBY0bSFHlGkXRsW1GsrEisNEC61M7vRaeAMXcf77axsqQS h4zg== X-Gm-Message-State: AMCzsaV5jHLfC2832mFSkaGl4RYaDze9kIivgXxTS5DttKgE3HPVNU0S LPJXyXYke+b4iCIVon4uwQ/oNYxRCoKmq5EsJr8= X-Google-Smtp-Source: AOwi7QAXUoA4L06mmq/nwvpTnFH+Ygyomp3o6mS2ux9w29TjL4W7W19ID59obXswesQhxHJXS6zq1S3rwvNxFbK9/P8= X-Received: by 10.25.143.156 with SMTP id s28mr2521530lfk.236.1507433478938; Sat, 07 Oct 2017 20:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.28.19 with HTTP; Sat, 7 Oct 2017 20:31:18 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Peter Bowen Date: Sat, 7 Oct 2017 20:31:18 -0700 Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , "mozilla-dev-security-policy@lists.mozilla.org" , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 03:31:22 -0000 On Tue, Sep 12, 2017 at 5:59 AM, Dmitry Belyavsky via dev-security-policy wrote: > Here is the new version of the draft updated according to the discussion on > mozilla-dev-security list. Given that RFC 5914 already defines a TrustAnchorList and TrustAnchorInfo object and that the Trust Anchor List object is explicitly contemplated as being included in a signed CMS message, would it not make more sense to start from 5914 and define new extensions encode constraints not currently defined? Thanks, Peter From nobody Sun Oct 8 07:16:17 2017 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 04C391342E0 for ; Sun, 8 Oct 2017 07:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 Gj0CSq34CBU3 for ; Sun, 8 Oct 2017 07:16:03 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA6213463B for ; Sun, 8 Oct 2017 07:16:01 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id b15so19489587qkg.9 for ; Sun, 08 Oct 2017 07:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=hITRZf9hT6t0xdB4JdfHhLm8th9azff/CNVFokXBUJU=; b=J44fNxJnvKrUn0unURpamhOPuLFH83FExa0gTAYERixcweKmZdLib86G/jDUYD5QAa v1XQnJTXJ8591cdX0syPmey+edKEUTqnZJ82nwjRDgym5wsoxaCYM8neRkLr1llqarjM S5RV5UpGk99EbEkSctS8Dxz9vZ2ag9nQS1q2U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=hITRZf9hT6t0xdB4JdfHhLm8th9azff/CNVFokXBUJU=; b=coY9hhpGfV0BrStzvxl4etgaUL9fckBr5VFhHWSeBS69BghJeAIv9CQYBzdrg3c2Db 2iooUs22SpcezZuze7QI3vRvrHqXjvtGLxnyYoNudYrPuLhMg7OfOn8/A4/DhV22PAD1 53trBxMViOwFTmKG9YXvCJqGMOfOhpH5y81ut8hS327wPmJGIFRjHIYUXaiTLS8O3Mbg FirkUUuxn1zhniwdPQ7hGIMNczgUgptx9P/w+dBs+6oImnLBUfh+++k9U684vr53uQ8U JLZwqk7CcSvvMy5NOxlbynd91ngdLVo7NPeyLwLWQ6QkIEsDRZHksuJ6/Rg1+0kcu1D0 x6CA== X-Gm-Message-State: AMCzsaWLgcnB5aIgMbZkiiN38yth9JKjzUYc7foQ8BaUa4G9E0jZOmvh k32DRUqP69HoyPwzns6voZwD6w== X-Google-Smtp-Source: AOwi7QCta0ux/xhB3WHoo64t/jM1QOBHHQ4HNJiyr9MzumkNygno/2cu6IiMLruWKMVQYB8Mg2HPOA== X-Received: by 10.55.18.28 with SMTP id c28mr6029124qkh.297.1507472161100; Sun, 08 Oct 2017 07:16:01 -0700 (PDT) Received: from [192.168.2.246] (pool-173-66-76-215.washdc.fios.verizon.net. [173.66.76.215]) by smtp.googlemail.com with ESMTPSA id n45sm3663687qtf.51.2017.10.08.07.15.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 08 Oct 2017 07:16:00 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Sun, 08 Oct 2017 10:16:00 -0400 From: Carl Wallace To: Peter Bowen , Dmitry Belyavsky CC: LAMPS , "" , "mozilla-dev-security-policy@lists.mozilla.org" , "saag@ietf.org" Message-ID: Thread-Topic: [pkix] New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [saag] [pkix] New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 14:16:05 -0000 Also, RFC 5937 defines how to process the constraints from the 5914 structure. On 10/7/17, 11:31 PM, "pkix on behalf of Peter Bowen" wrote: >On Tue, Sep 12, 2017 at 5:59 AM, Dmitry Belyavsky via >dev-security-policy wrote: >> Here is the new version of the draft updated according to the >>discussion on >> mozilla-dev-security list. > >Given that RFC 5914 already defines a TrustAnchorList and >TrustAnchorInfo object and that the Trust Anchor List object is >explicitly contemplated as being included in a signed CMS message, >would it not make more sense to start from 5914 and define new >extensions encode constraints not currently defined? > >Thanks, >Peter > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From nobody Sun Oct 8 15:33:39 2017 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 60801134964 for ; Sun, 8 Oct 2017 15:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 MUupeb8kgs-m for ; Sun, 8 Oct 2017 15:33:37 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 C4C821345A4 for ; Sun, 8 Oct 2017 15:33:36 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id h200so9877419oib.4 for ; Sun, 08 Oct 2017 15:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xz06sroev7Ngv7x+Dx+1NnnOcITr+BYZ0IiuOQjkf6A=; b=NGEl6qRzZEU8aeXWtKqyPeJ0glClvC4xg+ukfyeIcuQD4VGJTJ3DfBqcUZJRcCKPxB 2m2x8CCCaYMUuMnrSHn4bnn8PIufo4A2+1AC+PvhVx+1UH9XQ9t8eu4ztoBspaurCnMB eczNCJcyMuYK4DdSdu812QFiKIdW1hOmc/8LtpzeiCLud0pITn6G7RBnydaFc4qSgGww PRQa0GP9Vk39nngnAKZSeQxstUBNw9zVyms9VX4aKAgcT+e/97F5YDJv12CoVPDvk+M0 b6IsjapR4abgCRjZAYWW2j4xIfwY7RODRuYz0N/YJVwOOkGCFXPxSPxWE/O97wzljQBU Haeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xz06sroev7Ngv7x+Dx+1NnnOcITr+BYZ0IiuOQjkf6A=; b=r2JcbUoEHJ5+k7QVKAfYsOkcG1N5blEsSnct5U3YjdvII6ZN3CaGBOl3rtRHz4Swie UxtzhhuxV8pZGndiQ7053+lh41J3qBgVbe/DLpgP/uOYgNRwjLDddKOfWmfQXspVrXxQ RC/Isp8K2zI+khCz1Ifq/c7WVgoI7Zh81xq/qbxTLNgoYO6GaICoqNnNczybAvY/YRt+ ve0YLTeXhUIgh4xO+ZiIZGtSG4R2oEOb+9IU/WUSOZYrrSC8XjAzAh9V7RiYQn1TKoSe Oz6qoskHGCazvxvWpPgJGkN4BrkIc6hhB/viC4qieuk8JQTpU001zuXOQppMrUrnn5P3 bO/A== X-Gm-Message-State: AMCzsaXHRzsEuehV8yaylx5YTk+OZdyeIfyItUDI7MwwoS/k1Y8uhblx v1zbCGkWexJ64uM6cyQ8dQVdog14D06aNTinvM6VLA== X-Google-Smtp-Source: AOwi7QA4nmBNwwKB2VpPE6/UyYHBoTJFSP5tGbFTkS3BUvFO4FG7MWv+tIjXOWc5dqU/QgAd6boDOxVco1Y7c2f4X+g= X-Received: by 10.202.104.22 with SMTP id d22mr4787653oic.68.1507502016068; Sun, 08 Oct 2017 15:33:36 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.80.42 with HTTP; Sun, 8 Oct 2017 15:33:35 -0700 (PDT) In-Reply-To: <6ac8feb7-a648-485f-b6d8-3bd97e8f48c5@iang.org> References: <6ac8feb7-a648-485f-b6d8-3bd97e8f48c5@iang.org> From: Phillip Hallam-Baker Date: Sun, 8 Oct 2017 18:33:35 -0400 X-Google-Sender-Auth: oSAHyoyyOluvhWbSLctxAja2wYw Message-ID: To: iang Cc: "saag@ietf.org" Content-Type: multipart/alternative; boundary="001a1140f7b82a872c055b10aadb" Archived-At: Subject: Re: [saag] Blockchained log format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 22:33:38 -0000 --001a1140f7b82a872c055b10aadb Content-Type: text/plain; charset="UTF-8" The container format is described here. It is also submitted as an ID if you like unreadable document formats. http://prismproof.org/Documents/draft-hallambaker-jbcd-container.html The frame format is binary but the metadata descriptions of the frames can be text or binary. JSON-B just uses the upper 128 codes in a byte that are unused in JSON tagging to define a set of tags for binary encoding. So you have a choice of text or binary for encoding. Since JSON-B is a strict superset of JSON, one decoder works for both. The advantage of the double frame pointers is that you can read files just as fast in either direction. So you can append an index to the end of a container when it is complete. Or you can drop out incrementals every n entries. This avoids the need for a second file to maintain an index. Each frame payload is encrypted separately but a frame can reference the key exchange parameters in a prior frame. So if you have an online chat, you might have two different session keys in use at the same time on interleaved frames. The idea is to provide for a range of time/memory access tradeoffs. I get really annoyed when programs take a long time to load because they are reading an index into memory. When files get large, that becomes impossible. This approach allows a server to bind to a data repository and get a 'fast open' with immediate albeit somewhat slower access to any frame in the file. Meanwhile, an indexer thread can compile a fast access index if needed. One tweak I thought about today but have not had time to implement is external payloads. If a file is really large, e.g. a video file and likely to be included in more than one log, it might well be desirable to store it as an external attachment. This might still be wrapped by a frame header with encryption information. Yes, cross linking trees/chains is planned but I have not yet thought through how to do it. I am pretty sure it is a layered feature. Simplest way at this stage is probably to simply define a content type for 'external digest' and log it as any other payload. On Thu, Sep 14, 2017 at 10:34 AM, iang wrote: > On 11/09/2017 15:01, Phillip Hallam-Baker wrote: > > Ideas? Comments? >> > > First comment - I (also would) do it in binary. I used to use text > formats because I could read and confirm the code, but in the end, it was > easier to be confident of a binary I/O code than text code. And when I > added encryption, it made the text a bit useless. > > Second comment - for better generality, make it two files not one, one > being indexes and one being the frames in full. Each index locates its > frame in the frame file by start / length or end. > > This way, you can read the entire index file into memory qiuckly, and then > only pull in the frames on demand. > > I must admit - I never thought about doing the reverse reading. Probably > because I've always read the whole (index) thing into memory for any and > all processing. > > iang > > ps; in my work, both files have the same header, more or less, and the > header has the encryption keys in it. A stream cipher is needed, as we're > picking up at any point in the frame, I use Chacha and poly. > --001a1140f7b82a872c055b10aadb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The container format is descr= ibed here. It is also submitted as an ID if you like unreadable document fo= rmats.

http://prismproof.org/Documents/draft-hallambaker-jbcd-containe= r.html

The frame format is binary but the metadata descriptions of th= e frames can be text or binary. JSON-B just uses the upper 128 codes in a b= yte that are unused in JSON tagging to define a set of tags for binary enco= ding. So you have a choice of text or binary for encoding. Since JSON-B is = a strict superset of JSON, one decoder works for both.


The advantage of the double frame pointers is that you c= an read files just as fast in either direction. So you can append an index = to the end of a container when it is complete. Or you can drop out incremen= tals every n entries. This avoids the need for a second file to maintain an= index.

Each frame payload is encrypted separately but a frame can reference = the key exchange parameters in a prior frame. So if you have an online chat= , you might have two different session keys in use at the same time on inte= rleaved frames.


The idea is to provide= for a range of time/memory access tradeoffs. I get really annoyed when pro= grams take a long time to load because they are reading an index into memor= y. When files get large, that becomes impossible. This approach allows a se= rver to bind to a data repository and get a 'fast open' with immedi= ate albeit somewhat slower access to any frame in the file. Meanwhile, an i= ndexer thread can compile a fast access index if needed.

One tweak I thought = about today but have not had time to implement is external payloads. If a f= ile is really large, e.g. a video file and likely to be included in more th= an one log, it might well be desirable to store it as an external attachmen= t. This might still be wrapped by a frame header with encryption informatio= n.


Yes, cross linking trees/chains is = planned but I have not yet thought through how to do it. I am pretty sure i= t is a layered feature.

Simplest way at this stage is probably to simply defi= ne a content type for 'external digest' and log it as any other pay= load.


On Thu, Sep 14, 2017 at 10:34 AM, ia= ng <iang@iang.org> wrote:
On 1= 1/09/2017 15:01, Phillip Hallam-Baker wrote:

Ideas? Comments?

First comment - I (also would) do it in binary.=C2=A0 I used to use text fo= rmats because I could read and confirm the code, but in the end, it was eas= ier to be confident of a binary I/O code than text code. And when I added e= ncryption, it made the text a bit useless.

Second comment - for better generality, make it two files not one, one bein= g indexes and one being the frames in full.=C2=A0 Each index locates its fr= ame in the frame file by start / length or end.

This way, you can read the entire index file into memory qiuckly, and then = only pull in the frames on demand.

I must admit - I never thought about doing the reverse reading. Probably be= cause I've always read the whole (index) thing into memory for any and = all processing.

iang

ps; in my work, both files have the same header, more or less, and the head= er has the encryption keys in it.=C2=A0 A stream cipher is needed, as we= 9;re picking up at any point in the frame, I use Chacha and poly.

--001a1140f7b82a872c055b10aadb-- From nobody Thu Oct 12 05:04:12 2017 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 A555913449D; Thu, 12 Oct 2017 05:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 63ajlBVraiIq; Thu, 12 Oct 2017 05:04:05 -0700 (PDT) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (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 57FCF1330AD; Thu, 12 Oct 2017 05:04:05 -0700 (PDT) Received: by mail-qk0-x242.google.com with SMTP id k123so918593qke.3; Thu, 12 Oct 2017 05:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=TCqPnYL4yBFTpRdUr7jblVhd2/TZXBoC9g9GpOVcukw=; b=aZXngVJolKmB5qKUZjBFNqxaUs8suE/ETIDub7xnI/rT+nQHZLaUuVVxKauMy15SQl NiayiBih/spKuPqfB5qJOaHmS9GjeJ9HNGgvA37jw8lnBCDk2EbaYvqSA5m0ei7nkOkg sv3NLA+4/haizzyfcGWWp5F81ZFhsbFQ44OENQhZLKOAZs5UKpqRAP8u4JGk2LcAOw8N 9ur5kwX7Gtr6ZxJv/kfwqpXnQoOLLhI7QgfZ1FcgHQtlKFgnIqML57kDMxcH9jQ5zbD0 ta9CNvc65Rvl/gYYcZDoBDyH45yjPQn4cr5FVyO1A6j1yZ7Dww2F4XJe0gGKyE09YSRa fLuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=TCqPnYL4yBFTpRdUr7jblVhd2/TZXBoC9g9GpOVcukw=; b=jtH/xx4PZJeubpu9imObBWTgZWsb4S5rKlKC0PYmGSneDmVgx+UIMzCnx01TuZBO7n IfSO0WXJj/hPQLbCfrQrO+PAHdWfgRPtj9Wje/s3+ZEjog464MPiQG1fBJo3717IqnjX jhv4bvi5DYWIJdFZitlMaSSuqDFCbvqvgmP1du+kO/IATdH0MAD8tvRjHpAc0AqgFond U/wW4yfCB8v9dPtidQCKVykqHH86bBRVHyWY9DQDckM21O51qTubtTE8hSTPW8ogVCm9 xlyu2XgsxnVYyNGKWPsFpuIowgDUkolzfigmQ5eJmXAl93mJup3Fj4SNDKd784nMAhY0 nRLg== X-Gm-Message-State: AMCzsaVahLQ+z/0u6a05EuuukAw9XeywMeKayRxjPiNkajxy6ToIevKM lVJUHXu36Ee81P9ZwQVKWtoVq0j/rWaVaBW5+uA= X-Google-Smtp-Source: ABhQp+S0Ize0DihDopeTfONoJZR2DeYX/5+R4CCzu9p+nsV8RV6f60RHcvV0Rz8eAsTf15MGKkks+OErQseG4cYvesE= X-Received: by 10.55.119.5 with SMTP id s5mr59984qkc.233.1507809844422; Thu, 12 Oct 2017 05:04:04 -0700 (PDT) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.12.148.1 with HTTP; Thu, 12 Oct 2017 05:03:23 -0700 (PDT) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Nikos Mavrogiannopoulos Date: Thu, 12 Oct 2017 14:03:23 +0200 X-Google-Sender-Auth: cN59JnC25PeuqtWEpUsR4t3QJOQ Message-ID: To: Dmitry Belyavsky Cc: "saag@ietf.org" , LAMPS , dev-security-policy@lists.mozilla.org, pkix@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 12:04:11 -0000 On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky wrote: > Dear Nicos, > > Sorry for the delay with my response. > > On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos > wrote: >> >> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky >> wrote: >> > Dear Nikos >> > >> > On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos >> > >> > wrote: >> >> >> >> >> >> 4. How do you handle extensions to this format? >> >> >> >> Overall, why not use X.509 extensions to store such additional >> >> constraints? We already (in the p11-kit trust store in Fedora/RHEL >> >> systems) use the notion of stapled extensions to limit certificates >> >> [0, 1] and seems quite a flexible approach. Have you considered that >> >> path? >> >> >> >> regards, >> >> Nikos >> >> >> >> [0]. >> >> >> >> https://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html >> >> [1]. >> >> >> >> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html >> > I've looked through the specification. It's OK for me, but I do not get >> > whether the attached extensions are crypto-protected. >> >> No, as these values are inserted by the administrator of the system, >> or us (the distributor of the software), we didn't feel we needed the >> introduction of additional PKI. > > > Well, the specification I suggest should allow applying CLPs issued by major > vendors (Mozilla etc). > For this purposes the CLPs should be validable => signed. Hi, If mozilla or any other organization is willing to deploy such PKI, that would be great. However for the majority of software, I'd expect that such files are distributed using the same channel as software, and thus using the same authentication mechanism for it rather than a new PKI. For a software distributor to use that optional signing could work. >> One problem with that is the fact that the existing CRL extensions are >> about extending attributes of the CRL, rather than adding/removing >> attributes to the certificate in question. > For this purposes I implied that the limitations are provided not by > extensions, > but as SEQUENCE of limitations related to the certificates. > > Was I wrong in the ASN1 scheme in the current version of my draft? I do not think that the presented ASN.1 description is valid. The "limitations SEQUENCE," doesn't define anything in ASN.1 (i..e, it is a sequence of what?). > >> >> To bring the stapled extensions to your proposal, you'd need the >> Extensions and Extension fields from RFC5280, and >> add into limitedCertificates structure (I'll split it on the example >> below for clarity) the following field. >> >> LimitedCertificates ::= SEQUENCE OF LimitedCertificate >> >> LimitedCertificate ::= SEQUENCE { >> userCertificate CertificateSerialNumber, >> certificateIssuer Name, >> limitationDate Time, >> limitationPropagation Enum, >> fingerprint SEQUENCE { >> fingerprintAlgorithm AlgorithmIdentifier, >> fingerprintValue OCTET STRING >> } OPTIONAL, >> limitations SEQUENCE, >> } OPTIONAL, >> }; >> >> >> stapledExtensions Extensions; <----- NEW >> } > > > Sorry, I do not get the difference between the purposes of the field > 'limitations' > and 'stapledExtensions'. I cannot answer this as I cannot see the syntax of the limitations field. I thought it was a field intended to spark discussion rather than anything specific. regards, Nikos From nobody Tue Oct 17 06:16:20 2017 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 DFB7C127517 for ; Tue, 17 Oct 2017 06:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuyfrvVGQLXH for ; Tue, 17 Oct 2017 06:16:14 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98BD1321A1 for ; Tue, 17 Oct 2017 06:16:13 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w197so2819293oif.6 for ; Tue, 17 Oct 2017 06:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=4LfPn2tyHp0zijfZumS/D9AtZvjdY3JW9/sP0k//xsY=; b=P/As5vzHkJWK9ZzP6MizDsiyd0rp8NyNJacuoiT7jDBBkLIU8JVP0k9NoSYldTxmSu p/FopY43T/yVqSsEvFz79rro9HddCSjSHA/e8RIYP1RrWQmXW6g7+ijXn3qRAzqGy1KR haZZX57k4PFgD/NlXjQ7avUgsf23AENruO0eVEZRGABl1BTF/rVhBe0wWEKFTGYTXA5q F+bUTIHsmBtsdI9siVRpxHSnrHNSVFZ/vZExpYw8SYaqk/6ZwwFFV5kFoVX9/g+NaHRJ tO0fG1+ujzmRNxbMOeulz9JPUrvY3rk8Jed4etuk8yYC0zQkI4S0Xl+poBX51+Idh4h+ D68A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=4LfPn2tyHp0zijfZumS/D9AtZvjdY3JW9/sP0k//xsY=; b=iNBcghdXIueIaJUS1ZTikWbPuR++YLfhripeLWr6EPPT9ZLgMfwJqHkplxNj0JUk7h in+RmgbQFatCWdb0PxI75dotIBGcI+khga9Gk8vbpjeQtAkQYEAMTYXfzCYJaaePGdCi OnyuzVDFlzQ8Go1TE+tzO3qZhJtsDZ1oyNwJLZt0OjB5TUh4w2MuyBvNl3Y8Hs86qc69 FOodVCjouSJtbqfMp8PCiyjRU2cDr1cfRAgKholBcLi9m3LhVYOgfvJVQSGdnVJkMJsp KJ/8lDeqtqV0hSZ4hoGTJg8G3b0VGg7HjqPnnD4fm5TnwEYZGlbZhSoMlSsILz62O/47 Ftgw== X-Gm-Message-State: AMCzsaUsGigUvP3r9fPJSEVSiwoEvwLlwGWZ55NEQocbDhXVix+FADzb y/Mp6IPRcJvW++qZzGkuZGkgdJHUobkn4dssHP0lDw== X-Google-Smtp-Source: ABhQp+QwfZYDSfrqsZ9RPyF9RgAWWIrXxTLjh14l3HaKOm0zIAW/IKHrStD3Bh9597r6heaz28cYu5lHI4d9geMdjtE= X-Received: by 10.157.18.144 with SMTP id g16mr2122245otg.373.1508246172875; Tue, 17 Oct 2017 06:16:12 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.80.42 with HTTP; Tue, 17 Oct 2017 06:16:12 -0700 (PDT) From: Phillip Hallam-Baker Date: Tue, 17 Oct 2017 09:16:12 -0400 X-Google-Sender-Auth: JXXa99oFIUeZ9JoTFRNowvbiQFk Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Encrypted URI X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 13:16:20 -0000 I would like to have an easy way to make a document available to a party who can scan a QRCode and to nobody else. I proposed a mechanism to do this a few years back but have not got round to implementation until now. I was wondering if anyone had seen similar or had comments. Let M be the document to be disclosed. The document is encrypted using AES under key k, the IV prepended and the result stored at http://example.com/.well-known/phb/ Where hash = Base64url (SHA-2-512(k)) The encoded URL is phb://example.com// Where version = 1 and keydata = base64url (k) We can of course use key stretching to allow a key shorter than the algorithm length to be used. So one could use a 128 bit initial key and stretch it to allow AES-256 with its extra rounds to be used. The application of the idea is to allow a printed document such as an invoice or a tax return to contain a link to a machine readable copy. From nobody Tue Oct 17 12:03:13 2017 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 87F111323F7 for ; Tue, 17 Oct 2017 12:03: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 kyDVVcvSgwy8 for ; Tue, 17 Oct 2017 12:03:11 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 D3B31126B6E for ; Tue, 17 Oct 2017 12:03:10 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t69so5805149wmt.2 for ; Tue, 17 Oct 2017 12:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=2iZuD5QTiLaSvXPd4Chl5adChIGQVDspXIwfupHfi5Q=; b=JAJJqRZojs9cg2q3k9C6R3TgQMmAcgHnvlEQImwJd5HAz5kl9TAZ31n8HpwGpMyxsY oC+7bz9ocQ700wtMMoPKAYwYLGiZKCQodBuhbr24I+90xgMWch+qmp20PWEGCLmGwcyV N86pcAkdy6xZdIomAWP4Dh1yuZfw6s6qF5L5m75CaOmNyx2rgwlcBwGJ9vlAzTgrqXnH lyUf5SC2CpsNAy0Pq8O4/wZ0+mI9I4NuS3PK92rE97MbMyjqimaQOJKGy5DT+UKN8bc1 3lYn1FdMfcqwxoqJCi8n/XL2wGw/424VFTMr3ajXD0v8VUF38BGC5SOm4tin8GJo8vxK 6BZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=2iZuD5QTiLaSvXPd4Chl5adChIGQVDspXIwfupHfi5Q=; b=nEThJUP42HSFrPeytgayeqVh4m8+GWwG9/2z7x5MK0CP7e1C1AU1EBztnVaL9HjD2q Y9q4gNUujLwaO3bjDOmz9mlLjomHvqR3GMm1PncnEeyUt41mKFdyEmjA976TlMwjYgn2 WdURkeTOoBj5unVFm3Z1yF1gVE8Lu1JEJGK4QsNTw6SLFK/5s6jMKjIuoNFQ3XIJbLfL DMPRHIqf8b2jysVCge4cO8i9+mS4KrioAMHZI1SxbeiLJljt5v4XiUh65rKdYtCkml5G pjl6e4woEHPBzqSF5PDldc5RUgS073LJMJok6aU6yc73oXfYqLlPCY/rluz5KQknd7YQ 10Qg== X-Gm-Message-State: AMCzsaXHHa7Zqs9Xx2XsGf25nDTVRbx6Uy2qRXnaQTNszHF7NPeDvNRk vZCezGAZKA4K1a5Sur0PKlwt3gl0 X-Google-Smtp-Source: ABhQp+Rz6Z0ezjPPS16jXW3MmLCBvCDXlGhx0VlTQ2BuZI/NUt0YxzUX1uo6aUQc7YYyFupoy3sGCw== X-Received: by 10.28.48.143 with SMTP id w137mr4633988wmw.3.1508266989111; Tue, 17 Oct 2017 12:03:09 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id h21sm7984353wrf.47.2017.10.17.12.03.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 12:03:08 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_9A58BF1F-4671-47EA-9ECA-F33A283B173F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Message-Id: <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> References: <150809609468.12209.18375712195993239092.idtracker@ietfa.amsl.com> To: Security Area Advisory Group Date: Tue, 17 Oct 2017 22:03:06 +0300 X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: [saag] Using short term certificates (instead of revocation) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 19:03:12 -0000 --Apple-Mail=_9A58BF1F-4671-47EA-9ECA-F33A283B173F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all We=E2=80=99ve submitted this -00 draft for your consideration. It is = still very rough with several sections missing, but we feel it=E2=80=99s = good enough for starting a conversation. There is quite a bit of interest in using short term certificates = recently. There is a draft at ACME, a proposed draft at STIR, and many = use cases in IT, whether these certificates are exchanged with TLS or = with IKE or SSH. Some of these use cases are web, but many others are = not. The purpose of this draft is to list considerations, both = operational and security, for using short term certificates without = revocation. If this effort is successful, the resulting document should guide both = draft writers and IT people in answering two important questions: 1. When is using short term certificates appropriate? 2. What needs to be in place for a functional, reliable and secure = deployment? Any comments will be greatly appreciated. Thanks Yoav on behalf of the authors. > Begin forwarded message: >=20 >=20 > A new version of I-D, draft-nir-saag-star-00.txt > has been successfully submitted by Yoav Nir and posted to the > IETF repository. >=20 > Name: draft-nir-saag-star > Revision: 00 > Title: Considerations For Using Short Term Certificates > Document date: 2017-10-14 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-nir-saag-star-00.txt > Status: https://datatracker.ietf.org/doc/draft-nir-saag-star/ > Htmlized: https://tools.ietf.org/html/draft-nir-saag-star-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-nir-saag-star-00 >=20 >=20 > Abstract: > Recently there has been renewed interest in an old idea: Issue > certificates with short validity periods and forego revocation > processing, reasoning that expiration is a sufficient replacement = for > revocation as long as that expiration is not too far off. >=20 > This document covers considerations, both security and operational, > for using such Short Term Auto Renewed (STAR) certificates for > various scenarios where Using a revocation protocol is considered > inappropriate. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_9A58BF1F-4671-47EA-9ECA-F33A283B173F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlnmU+oACgkQuEkLFQpY zJmYDAgAuCtmlsruvuWmcjpwkTiCqRXsI61DycO+5mpEfnhpxTRBkZ5+1To6b1n3 Q69PceuJ9XTcCQnsMoBF3U2TJM6X23j+P8orpUpyagoSln6+WrBuXcf0V6sS++mh ncYVBqSeN9z71CdDN/xUl0/rBGaKsHIKZZxWLSYO7zvQKqNmkwlATuyGqNBmr4iP vugcBRPYhxxRsxnYGWaXX4Va6E9v0alRHfG3uIWrgGuMKJqA8O5XLTcuyinz967P uGJ6v2TYAUnKYBXCZ8jSngrTwuGeBqGJaOwwbhv/PHDFzkUFdXQJKOP/DtWkWHCQ l+KSqd48UydQ6EXZutqqWtBNDmpQtw== =3nAX -----END PGP SIGNATURE----- --Apple-Mail=_9A58BF1F-4671-47EA-9ECA-F33A283B173F-- From nobody Tue Oct 17 16:52:34 2017 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 14192132620 for ; Tue, 17 Oct 2017 16:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY7cDhKrRFqZ for ; Tue, 17 Oct 2017 16:52:32 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 F09851321D8 for ; Tue, 17 Oct 2017 16:52:31 -0700 (PDT) X-AuditID: 1209190e-d0fff70000002616-d2-59e697be05ab Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 04.B2.09750.EB796E95; Tue, 17 Oct 2017 19:52:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v9HNqTVp031643; Tue, 17 Oct 2017 19:52:30 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9HNqQZF021725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Oct 2017 19:52:28 -0400 Date: Tue, 17 Oct 2017 18:52:26 -0500 From: Benjamin Kaduk To: Yoav Nir Cc: Security Area Advisory Group Message-ID: <20171017235226.GW96685@kduck.kaduk.org> References: <150809609468.12209.18375712195993239092.idtracker@ietfa.amsl.com> <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bvgsfYmVhxWy/2TA" Content-Disposition: inline In-Reply-To: <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixCmqrLtv+rNIg4fPrSym9HcyWSw99oHJ gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mpo6r7PXLBZoOLx2Q9sDYz9fF2MnBwSAiYS 9+bMZuxi5OIQEljMJPF993k2kISQwEZGifdrkyESV5kkvq6YywySYBFQlXjT9wLMZhNQkWjo vgxmiwgoSRy+8hXMZhYwkGhdcY4JxBYW8JS4tWsO2FBeoG3XdmxmgRjayCjx9NI1ZoiEoMTJ mU9YIJrLJI7tXc7axcgBZEtLLP/HARLmFLCV2LXiMCuILSqgLDFv3yq2CYwCs5B0z0LSPQuh GyKsLvFn3iVmDGFtiWULXzND2LYS69a9Z1nAyL6KUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11gv N7NELzWldBMjOAok+XYwTmrwPsQowMGoxMP7Q/FZpBBrYllxZe4hRkkOJiVRXmfDJ5FCfEn5 KZUZicUZ8UWlOanFhxhVgHY92rD6AqMUS15+XqqSCK+eLVArb0piZVVqUT5MmTQHi5I477ag XZFCAumJJanZqakFqUUwWRkODiUJ3uxpQI2CRanpqRVpmTklCGkmDs5DjBIcPEDDTUFqeIsL EnOLM9Mh8qcYFaXEef1BEgIgiYzSPLheUPKSyN5f84pRHOgtYd6lU4CqeICJD677FdBgJqDB 65yegAwuSURISTUwZoeXHZ82zWfWYp4Zc3WfH1eaa/wjb+aVbI9J5as5Vdulpfk731d5Ncw/ F/fb2W2z4olOy5wDNdN4ciYXrOnWXqh3SebQfRtt/6eib+x3/AhKrjnlqaksnbhD3Hp2z5bn k9/r75r9an7PlDPXix4yadz6npHY/5Pf/sKk785/J/w9biSRUp10XImlOCPRUIu5qDgRAN8f oWI5AwAA Archived-At: Subject: Re: [saag] Using short term certificates (instead of revocation) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 23:52:33 -0000 --bvgsfYmVhxWy/2TA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 17, 2017 at 10:03:06PM +0300, Yoav Nir wrote: > Hi all >=20 > We=E2=80=99ve submitted this -00 draft for your consideration. It is stil= l very rough with several sections missing, but we feel it=E2=80=99s good e= nough for starting a conversation. >=20 > There is quite a bit of interest in using short term certificates recentl= y. There is a draft at ACME, a proposed draft at STIR, and many use cases i= n IT, whether these certificates are exchanged with TLS or with IKE or SSH.= Some of these use cases are web, but many others are not. The purpose of = this draft is to list considerations, both operational and security, for us= ing short term certificates without revocation. >=20 > If this effort is successful, the resulting document should guide both dr= aft writers and IT people in answering two important questions: > 1. When is using short term certificates appropriate? > 2. What needs to be in place for a functional, reliable and secure deplo= yment? >=20 > Any comments will be greatly appreciated. A note in passing from skimming the draft: TLS 1.3 will permit OCSP stapling for client certificates. -Ben --bvgsfYmVhxWy/2TA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlnml7IACgkQKNmm82Tr dRJ1Qwwg3nAHfoqzJMb1fQ9pwQ17nWAQC8tnQwnf1APsDQnLvCTky7Vebt/jS/uh uY3fPdHpoOAa6SS51wF770l/pcGZN9KMFAO0h/vH8tOb5cS0emAvVg6govOEo4vd nI/tkXiHPJ/Z7dRS2bWfzbSKs97c2sR/UwtQghFjAwPrxDmqiQLPqFn84L7r11F9 L5OETMIrOwnarZBZxQ0BrVwAqT3tmpudVp8IT5898+JzuKEGJnT4eBP/IP4CreIg ej8WyqWJbI3pM0ezXSKf2REuOitomCbr6ICoggevuMsjyvfDS3Oi7QEl2+qRJ3ES rjjZmi6xY5upjVHFi8Jdp5ZZomKWlqxb7AEHhrUCM2Lz6yEDgMDVpvXTMLzi25Xt ifAV3MfTKqF6JgP1ikHnCBtmDYgFFw/7Lqs7yqvW/gJnIKTPuekqFtfOm6EdgoX2 PX8NhXISa8sLsOlaMEQGP9t0288GohNBbdHbwEIEWd/oQaMMyZ8u5jko4oqAH4S5 fiI5D9jluNHLXA== =TkK+ -----END PGP SIGNATURE----- --bvgsfYmVhxWy/2TA-- From nobody Tue Oct 17 17:46:11 2017 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 1A7B8132397 for ; Tue, 17 Oct 2017 17:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert365.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 qCV22oEPIBgC for ; Tue, 17 Oct 2017 17:46:07 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0125.outbound.protection.outlook.com [104.47.37.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565C51270AE for ; Tue, 17 Oct 2017 17:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert365.onmicrosoft.com; s=selector1-digicert-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fYrUA13rrDYLbk6W8nXHMQMsl7EDetilm3Q7t6shY0A=; b=icMB6kojAfMnavj9ckPiEoPtIC7p9HpFJFs70gqaKKMbb1pATY0UPU2c0T15AES0rNxVPqSC4xZAMejfZJUX7AbN00uiKf2+N2XpdL3t02HBZS4jkZuNQ49P/Bfzj82AGb2OE70OqL6r/ciGnOKudCu1H3svMRzuSHn2Q1n3nT8= Received: from BLUPR14MB0339.namprd14.prod.outlook.com (10.163.213.145) by BLUPR14MB0340.namprd14.prod.outlook.com (10.163.213.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 18 Oct 2017 00:46:05 +0000 Received: from BLUPR14MB0339.namprd14.prod.outlook.com ([10.163.213.145]) by BLUPR14MB0339.namprd14.prod.outlook.com ([10.163.213.145]) with mapi id 15.20.0077.022; Wed, 18 Oct 2017 00:46:04 +0000 From: Jeremy Rowley To: Benjamin Kaduk , Yoav Nir CC: Security Area Advisory Group Thread-Topic: [saag] Using short term certificates (instead of revocation) Thread-Index: AQHTR3qZvAn47KlHWE6gTyQhgD/IlKLotwIAgAAA6QA= Date: Wed, 18 Oct 2017 00:46:04 +0000 Message-ID: References: <150809609468.12209.18375712195993239092.idtracker@ietfa.amsl.com> <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> <20171017235226.GW96685@kduck.kaduk.org> In-Reply-To: <20171017235226.GW96685@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jeremy.rowley@digicert.com; x-originating-ip: [67.137.52.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR14MB0340; 6:AUPPPhu3T/G7qmurHIdPo4CHcJJSnp3dGehpEPOi21ZZX8Jur2jPqzlP6etfV5rQNF5J21OtWbHSGxh44JRl86xqIYSPtq2HSoLKdtvUmn8Z21zAPWOYw9GOoLm210MUplu9orHHheOXnN5opzH80JVE1MVucz55HLiZrdcDyuNYCj4KdGB5RpPjhFbfEXmY2RSlUEVk2F9M3xG8wIqkNbazwduiDC5yjQhGUGDnIrj6w9kgOJtlOpac/wKaaJz2aGrwEMRbSPWYCWSt5nLlxhZzNBkz3mPmT4/wNskpypqb9vy+w6Qbpj8hxGfL/oIkS4t5YGq4cyujDDs9bNrpdQ==; 5:ccfjYyUjwNqklMdYSOCTYjl/RU4HB2BFgtvD+ul5ogq1zadrEG9tdopl4A62eTDbWPR5SPP7kcs0PghbtF5/PII2yUYQ0EGh/8103J2+LHCYLRJGd5lw9jcA00pqwZqL1I1JRCpRzuNLY9advkfRfCC7RhMZ4VPw/IRLcBmhOYw=; 24:cBWzOvem1ImTqPi4hIl75S0A3q8Pof6x3PujIZH7VNkKZ8sSYtl9Tre0Af9Y7tqpPUSts7Wc6YfQOzcM7L7W6xv/jI8IbH+oDd/tf5UNk6A=; 7:no5oTXMB1N6mTY9Uq470i7XkeGayUo3anRk8PXMQUF2CbwkIaE0g95pd+Yz5rr2DSADIkYJfRV2KCs0phvujRQQQczUava7nmfFfu/Df9GswRQHyFyianuwfq4CdQawkJW2GQ5z0odlLayw75B4+5fsgL6wtnLutuYxwIn30fVa4yvtPmLzEUes8IAufmxK1OKHkdoT/Ku1vd0iV9B21NTz0BsZSuwXWjQJOeDaVSFU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d9418666-e712-436d-2149-08d515c19d04 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017082002075)(2017052603199)(49563074)(201703131423075)(201702281549075); SRVR:BLUPR14MB0340; x-ms-traffictypediagnostic: BLUPR14MB0340: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(192374486261705)(228788266533470)(211936372134217); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(920507026)(6041248)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(2016111802025)(20161123558100)(20161123555025)(6043046)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR14MB0340; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR14MB0340; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(199003)(377454003)(189002)(13464003)(24454002)(53754006)(53936002)(39060400002)(316002)(81166006)(99936001)(34040400001)(53546010)(4326008)(77096006)(110136005)(6246003)(7736002)(7696004)(2171002)(966005)(305945005)(99286003)(55016002)(478600001)(76176999)(66066001)(25786009)(74316002)(97736004)(2900100001)(6306002)(2906002)(9686003)(106356001)(229853002)(54356999)(2950100002)(8676002)(3660700001)(3280700002)(101416001)(50986999)(81156014)(8936002)(105586002)(3846002)(33656002)(6506006)(102836003)(6436002)(6116002)(14454004)(86362001)(5660300001)(68736007)(575784001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR14MB0340; H:BLUPR14MB0339.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_01F7_01D34778.2EF76850" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2017 00:46:04.8395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR14MB0340 Archived-At: Subject: Re: [saag] Using short term certificates (instead of revocation) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 00:46:10 -0000 ------=_NextPart_000_01F7_01D34778.2EF76850 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I can capture some of the other discussions around short-lived certs = here. Note that this is a collection of the previous discussion points = and not necessarily my view in all cases. The reasons for it: 1) Unstable regimes. Some users deploy short-lived certificates to = servers operating in unstable regions. They want to shut off the server = more rapidly than current revocation caching permits. Alternatively, = these operators want to protect against government intervention, closing = the certificate account to block additional issuance instead of waiting = until the revocation information updates. This is especially vital where = the government can block access to revocation information. Although = stapling provides similar results, some servers don't want to call out = to a third party for this information. I'm not sure why. 2) Smaller certificate sizes. Everyone loves smaller certs and = handshakes. Cutting out revocation information reduces the size. Cutting = out a signed blob of revocation information from the handshake makes it = even better. Why transmit revocation information if the cert will = expire before its updated? I think almost every CA pre-signs their = revocation responses, meaning that initial revocation response will = always be "good" for clients caching the information. 3) Faster updates to certificate profiles. If something goes wrong, an = entity can shift their entire certificate production to short-lived = certs within days. Say RSA is no long secure. With fast roll-overs, the = entire server farm could shift to ECC within days by updating the = delivered profile. 4) Current support. All UAs (I know of) support certificate expiration. = This means that short-lived certs will effectively work in all UAs, new = or old. Stapling only works with servers and browsers specifically = implementing stapling. Mozilla already supports non-checking of = revocation for short-lived certs. Other UA's do not strictly support = short-lived certificates but currently do not check revocation using = traditional revocation mechanisms. Those that do provide soft-fail when = the revocation response is not returned. Most (or all) fail on expired = certificates. Entities using short-lived certs effectively migrate to = hard-fail instead of soft-fail because of how UAs process expiration = compared to revocation. This also leads to a more consistent user = experience. Stapling may eventually result in hard-fail = (https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-m= ust-staple-and-short-lived-certificates/)? But see = https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/F= 9oHW0u339E for the contrary. 5) Customized certs for dynamically = changing domain names. Devices we've seen use a name like = [random].[identifier].example.com as their DNS identifier. Some of these = identifiers change the random part occasionally. Using short-lived certs = allows the device to update the digital certificates at the identifiers = change, getting a new certificate as necessary to support the connected = device. I'm not sure why the identifiers change. Perhaps whenever it = calls home to whatever monitoring service, such as a subscription = account?=20 Reasons against it: 1) Immediate revocation. Occasionally a CA may mis-issue a certificate = and revoke the certificate prior to distribution to any end-point. In = this case, the CA can revoke the certificate without worrying about UA = caching. The rebuttal is that a CA is mis-issuing certificates is just = as likely to omit the revocation information as make another mistake. 2) No value. Stapling accomplishes similar results, effectively negating = any usefulness of short-lived certificates. Although stapling requires = the server to communicate with the CA, this is no different than what's = already required for short-lived certs. In fact, stapling is better. = Most CAs publish revocation information via CDN, meaning it's highly = available and easy to access. Certificate publication usually happens at = an address controlled and operated by the CA, without use of a CDN. The = availability of these addresses is sometimes questionable.=20 3) Risk Analysis. If OCSP caching and stapled life-cycles are set to a = lower value than the certificate lifecycle, OCSP stapling is superior = because of the immediate revocation advantages. If OCSP responses are = refreshed every 24 hours, short-lived certs will remain valid for a = longer period of time than the OCSP response and require more work = because of installation and configuration requirements on the server = side. Therefore, the solution is to simply lower OCSP responses to a = shorter validity period and eliminate OCSP caching.=20 4) Conflict with CT. Who wants to run a log full of short-lived certs? = Short-lived certs undermine the industry attempts at creating additional = transparency into the CA ecosystem by making logs unmanageable for the = log operators and monitors. Trying to build a log scalable to that = magnitude is hard - our current log couldn't do it. -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Benjamin Kaduk Sent: Tuesday, October 17, 2017 5:52 PM To: Yoav Nir Cc: Security Area Advisory Group Subject: Re: [saag] Using short term certificates (instead of = revocation) On Tue, Oct 17, 2017 at 10:03:06PM +0300, Yoav Nir wrote: > Hi all >=20 > We=E2=80=99ve submitted this -00 draft for your consideration. It is = still very rough with several sections missing, but we feel it=E2=80=99s = good enough for starting a conversation. >=20 > There is quite a bit of interest in using short term certificates = recently. There is a draft at ACME, a proposed draft at STIR, and many = use cases in IT, whether these certificates are exchanged with TLS or = with IKE or SSH. Some of these use cases are web, but many others are = not. The purpose of this draft is to list considerations, both = operational and security, for using short term certificates without = revocation. >=20 > If this effort is successful, the resulting document should guide both = draft writers and IT people in answering two important questions: > 1. When is using short term certificates appropriate? > 2. What needs to be in place for a functional, reliable and secure = deployment? >=20 > Any comments will be greatly appreciated. A note in passing from skimming the draft: TLS 1.3 will permit OCSP = stapling for client certificates. -Ben ------=_NextPart_000_01F7_01D34778.2EF76850 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD3cw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFZjCCBE6gAwIBAgIQ C4B3By87NWBjv2prStoEyDANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTUxMDEzMDAwMDAwWhcNMTkwMTEwMTIwMDAwWjCBgTEL MAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxDTALBgNVBAcTBExlaGkxETAPBgNVBAoTCERpZ2lD ZXJ0MRYwFAYDVQQDEw1KZXJlbXkgUm93bGV5MSkwJwYJKoZIhvcNAQkBFhpqZXJlbXkucm93bGV5 QGRpZ2ljZXJ0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPJD3aoxfpY1uYfF u5kKTI2hpWfWAy2E7VM3EI5e9b0SODOlkomYlH27ngILqbEJ8b5fActAXcFZl5ziAFL6qRas2YTS HPAxhzPrr14E+PmqEL5/aj5bdOAjeYcxPxhVb6rN53loBn5M6dWeR+kYqjaEzs3Q1sq9PUPBs5tY 1vZU6rF9HMaqKGLZNvaKKtdgb21c9CY4LbeBK3adu207YddQmrpSVA0U9/WCywMIkdG8N3jLvAws rlwMFQ+vFMd91G4GFPbr8hcQYSfN0k/tWsNK+BOomE5UJyrWIxKDcJYn4ZMJuMUvpUB7k4q6SRkR VeNoXZfQLVkCkRrglAS+RHcCAwEAAaOCAfMwggHvMB8GA1UdIwQYMBaAFOcCI4AAT9jXvJQL2T90 OUkyPIp5MB0GA1UdDgQWBBTxLS35I9rcAKGmBG/IIsVlfEFvBzAMBgNVHRMBAf8EAjAAMCUGA1Ud EQQeMByBGmplcmVteS5yb3dsZXlAZGlnaWNlcnQuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYB BQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdo dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMD2g O6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEu Y3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t MEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNz dXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCsuDvp30eNIwYCBZWqJl+9t67A7Jz/zE+8 QPcGn/yvyUqpH4ve9/Pax9CF8cHBBv53uuuMA5quLWfRHxZE9nBr9PorW3AgxE3nrvW6jo+vy214 mI/RAc8kRU3GYoeDQSFRKUxHBCGXxXzVp98g6HGOivcGRWjOFCiwKrJzdMWBCgjZEhbFr9Tpf/Cd 6d+twH/j67MMas3ozImL7ItJxWDxVDG8vdNQq5nv5+MaSCee5i1stvGLITRYqfLCDpgnVSXCfSlO uWJYxeQ9HFshZOMbJSoR8+sdyysKkJqXncVht82CVXGqi7k8mUqmnsMyeavKh/rrJ5pJm/rXBf0g xQ+wMIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIwMDAwWhcN MjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRstBYeiEEMx3w7U FRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW8R98Qn4lsCMZ xkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/UPPwFxH/ vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG 2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9 CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0 BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYD VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElE Um9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGq MIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yUC9k/dDlJMjyK eTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEATtSJ J7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb5QKihBLZ FfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82Tq/Bqy09Y D7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh 7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447f ISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCA78wggO7AgEBMHkwZTELMAkGA1UEBhMCVVMxFTAT BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhALgHcHLzs1YGO/amtK2gTIMA0GCWCGSAFlAwQC AQUAoIICFzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEwMTgw MDQ2MDNaMC8GCSqGSIb3DQEJBDEiBCB861sBVp1yoL554IAXCxuMiqoZVqcVKxG//bA/8ArNNjCB iAYJKwYBBAGCNxAEMXsweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkw FwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQg SUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwgYoGCyqGSIb3DQEJEAILMXugeTBlMQswCQYDVQQGEwJV UzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYD VQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEAuAdwcvOzVgY79qa0raBMgwgZMGCSqG SIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCG SAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwCwYJYIZIAWUDBAIBMAsGCWCG SAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA3YgCxmH3i5r+ Zk+eki9wssUCXeYwttkbnxLJqi3znxVrc9p1+NOWLQXb5b5/hCu2vhABjIDZljiQ2Vip4hlAkK4W kvftTOvMx61OB7BLvql+hqnyn6Lwuvc09BSmfR09FTWH9VqRCSNqcGYBL7xCSL+ElrZA3eFmljAY NbB/1geHFPht2W9qheCP5ZnqU/xmpBNATfU8mXpLpT07tkHPgZiNl82nXyrXNWo3LK8MgNRF6lzH ObKVGnv6/qLX1w/YOYt4qlomJ/fWHX4Fo+3fFQECSbYGZxMc+9DaJBf8Q5ycztFnWK+kf60DGMuq xqvp83N2YFZwnSMzlhitGRPgBwAAAAAAAA== ------=_NextPart_000_01F7_01D34778.2EF76850-- From nobody Tue Oct 17 22:20:25 2017 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 3F3D7132941 for ; Tue, 17 Oct 2017 22:20:23 -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 CCIADxOW4x2j for ; Tue, 17 Oct 2017 22:20:21 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34AD13232C for ; Tue, 17 Oct 2017 22:20:18 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id r64so4867150qkc.1 for ; Tue, 17 Oct 2017 22:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=YVyiaAZbci1+CaC75CuAUzfpRKgCPCxu/1+j88pLWP0=; b=mDjiOAWPafpLRSXsnI5ly6K8+DMYTN7mUmmoAkHeghYy8X0hbsqMyRIhRShAFZzF+x jEmfWTgDSLTIn/MsrKsp/0lpv///M8vaMb52DApravFeMa5dgZ9YL88gOavT2Y6qMqDZ FobaG4B/k78cM/zkLF+ZYideN3q7uHeSLN6RWbKH/VfFOBE4JgTDHWnXJyiggoWgZ/iz hBX7EIuyOT0vNY78Bqp0GThHmoLhSlo/fcGMw88HA2vHowDRC56SKzAiwf7d8Z9Fkhyy 07aVQHJktZmGWEkaWL0tdJDMHvnE3ZXMJHpZL9w1Fn+tjhgAgSEf+17hpOcYqnP7R/qw rXNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=YVyiaAZbci1+CaC75CuAUzfpRKgCPCxu/1+j88pLWP0=; b=ZUP6DR+o9U2ylNsiMmPklDjo//cGZR9pnCW7F4N+jb0Gpup4FkCVMdQ+XaJkQC2yzP VBjP101Y4s+Lh6EMckKLm2rsKpwbK5UStSbyu5jNPVKBkvJh9q41l3R4ak2JsqhejRPX VXRzcTW7qLs2sn29KXM4b/YOKbuDhqdAmymdduNylyb+fkm2pKMPx2L8iF4Rq5zkkD2h +7QNY7qp/colGuXBAByyVg+V3iIBOyeN0UVGl+c2wFtWb2pPTz+iyLDCRpHUAse54FxV LZkI+FYygJe/EkqquMtx8zwV41GlcLR/qaBcK3jIWLKKc1UPtzZIHUzlkaexUfOi5x3j Fy2Q== X-Gm-Message-State: AMCzsaUO2nXz8zw8UuTDxXPo9UMFxR78P5kVW548i9Ow41tH8dfoGOsZ eZxd36wahfrd982IBrjZha5jytOa X-Google-Smtp-Source: ABhQp+QbpqlRXVkuAZjjq4SDEZr++PjbCD5j5HrvVXtd5/IdANB5zhWMkIeq45P1Fsq+vQ3jdfB1DQ== X-Received: by 10.55.167.144 with SMTP id q138mr804275qke.160.1508304018060; Tue, 17 Oct 2017 22:20:18 -0700 (PDT) Received: from sio_centos_lt ([147.178.6.131]) by smtp.googlemail.com with ESMTPSA id 12sm4053121qkf.61.2017.10.17.22.20.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Oct 2017 22:20:17 -0700 (PDT) Message-ID: <1508303999.27918.1.camel@gmail.com> From: Yoav Nir To: Benjamin Kaduk Cc: Security Area Advisory Group Date: Wed, 18 Oct 2017 08:19:59 +0300 In-Reply-To: <20171017235226.GW96685@kduck.kaduk.org> References: <150809609468.12209.18375712195993239092.idtracker@ietfa.amsl.com> <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> <20171017235226.GW96685@kduck.kaduk.org> Organization: Dell-EMC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] Using short term certificates (instead of revocation) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 05:20:23 -0000 On Tue, 2017-10-17 at 18:52 -0500, Benjamin Kaduk wrote: > On Tue, Oct 17, 2017 at 10:03:06PM +0300, Yoav Nir wrote: > > Hi all > > > > We’ve submitted this -00 draft for your consideration. It is still > > very rough with several sections missing, but we feel it’s good > > enough for starting a conversation. > > > > There is quite a bit of interest in using short term certificates > > recently. There is a draft at ACME, a proposed draft at STIR, and > > many use cases in IT, whether these certificates are exchanged with > > TLS or with IKE or SSH. Some of these use cases are web, but many > > others are not.  The purpose of this draft is to list > > considerations, both operational and security, for using short term > > certificates without revocation. > > > > If this effort is successful, the resulting document should guide > > both draft writers and IT people in answering two important > > questions: > >  1. When is using short term certificates appropriate? > >  2. What needs to be in place for a functional, reliable and secure > > deployment? > > > > Any comments will be greatly appreciated. > > A note in passing from skimming the draft: TLS 1.3 will permit OCSP > stapling > for client certificates. Hi, Ben. Thanks. I should mention this in the draft.  I guess that in a year or so, when TLS 1.3 is in OpenSSL, Windows and the major Linux distributions (OK, maybe I'm being a bit optimistic) this advantage will be gone. Still it's nice that short term certificates work with everything that's out there now and with what will be considered legacy in the next few years. Yoav From nobody Wed Oct 18 07:18:25 2017 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 1D64F133039 for ; Wed, 18 Oct 2017 07:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w6_p_sLWrK2 for ; Wed, 18 Oct 2017 07:18:21 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1BB1332CA for ; Wed, 18 Oct 2017 07:18:21 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id d9so3606360qtd.7 for ; Wed, 18 Oct 2017 07:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=te+Z1clvZsBmQbm1GQbLhula6lc+QJm+xevdpLIoS5U=; b=dKt5puG/hucnKcCvtEiM1NxD9Ra4j1SsrqQOdd/t/nW/xgEcTwbJKh6tot4XSGqyp8 9rlFKob+2tcUmGEl5QzPGpmK2UPHnuTBbb5OXYytcs4BP2t5QgTzdhUFl5NYaS6zFpPX K6RuQLu/VzFn6z/+1f6M7p3f2QPPtBfdTiZrq1Qbiw1sYOOf4vtmptk4T9fpNVrUF39P 1GsN/M7t8BowlN4EpL+7qEJHCg7sYafWiN1GfZBs9aI57m1qWiniDUouJAwTKEYrDGUW 5wyi40LfUV2pkSxP9up5XAMbUfF/vCKoS+wBTlE9ws17kSX/5XbN4tPZSW/k3rJDEpbr WqUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=te+Z1clvZsBmQbm1GQbLhula6lc+QJm+xevdpLIoS5U=; b=sRgwxEB68iKOkbGJp1NduZzw4FjRXdbG58vNDeo0h8UyXtRH0a/XaKYEcQvwWE9hcM S8sVtHAJZ/rY0uKaGu/R8HlGjgOohQuCJcrE5ZoJE+nMFV+szvi56/c9yEzU1ef+H3JP InrnQVzXP2smlxoKpyPWw1z/9emyNnnknmDaSgLUhsC4R9TmDje4j1Ruy96FlrhFzeNX 5kQ8QEVPxcfhcTLSKoRvM/3XKG4//oL9GofbLJXv4LWBR7GIF/aDPxDo4fjYFcxQXLxN eC7OilteERutb4FSYxCZRgHKCLo9YdLRhNiQYeRefFzBA7pbnRwWoHbGL53pR4RLi1qE Xc0g== X-Gm-Message-State: AMCzsaXVnW4LfqynLu682PbKMUieDB2Mxt18OvirSJKE1QSdCyM0OqbJ X40q5z0be0Z67TPMKczhixMhbLGr X-Google-Smtp-Source: ABhQp+TDCAFWMQmrAeNsMYF4KM5nWhXRkwJrp1XYmJ5umjd8F9GnCh43I84Ph70D4OZwMBykKEZFcg== X-Received: by 10.237.53.137 with SMTP id c9mr3503501qte.125.1508336300347; Wed, 18 Oct 2017 07:18:20 -0700 (PDT) Received: from [192.168.1.114] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id y62sm7402120qkb.92.2017.10.18.07.18.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Oct 2017 07:18:19 -0700 (PDT) To: saag@ietf.org References: <150809609468.12209.18375712195993239092.idtracker@ietfa.amsl.com> <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> From: Michael StJohns Message-ID: <3ca18f12-fe3f-494a-bc19-f9e391037e10@nthpermutation.com> Date: Wed, 18 Oct 2017 10:18:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> Content-Type: multipart/alternative; boundary="------------A89A5A787B44FB0471FED8C3" Content-Language: en-US Archived-At: Subject: Re: [saag] Using short term certificates (instead of revocation) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 14:18:24 -0000 This is a multi-part message in MIME format. --------------A89A5A787B44FB0471FED8C3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 10/17/2017 3:03 PM, Yoav Nir wrote: > Hi all > > We’ve submitted this -00 draft for your consideration. It is still very rough with several sections missing, but we feel it’s good enough for starting a conversation. > > There is quite a bit of interest in using short term certificates recently. There is a draft at ACME, a proposed draft at STIR, and many use cases in IT, whether these certificates are exchanged with TLS or with IKE or SSH. Some of these use cases are web, but many others are not. The purpose of this draft is to list considerations, both operational and security, for using short term certificates without revocation. > > If this effort is successful, the resulting document should guide both draft writers and IT people in answering two important questions: > 1. When is using short term certificates appropriate? > 2. What needs to be in place for a functional, reliable and secure deployment? > > Any comments will be greatly appreciated. > > Thanks > > Yoav on behalf of the authors. Hi Yoav - The clockSkew commentary is useful, but misses the problem that you might not actually have a version of secure time available at all or consistently or different RPs may or may not have the same clocks. Some of the smaller IOT devices can't afford either an RTC or the power for an RTC and trusting mesh time might be problematic.  It would be helpful if you would expand upon your expectations for time domain support either in the intro or somewhere before you get into the discussions with skew. E.g. its OK to exclude IoT usages that depend on reliable time, but best to set expectations. I've been trying to think about how to provide something that allows certs to expire or be validated without dependence on clock time - its not an easy problem. Last - you may want to chat about the fact that - with clock skew - the certificate holder and the relying party may have different ideas about validity for a given cert and the error handling related to this problem. Thanks - Mike > >> Begin forwarded message: >> >> >> A new version of I-D, draft-nir-saag-star-00.txt >> has been successfully submitted by Yoav Nir and posted to the >> IETF repository. >> >> Name: draft-nir-saag-star >> Revision: 00 >> Title: Considerations For Using Short Term Certificates >> Document date: 2017-10-14 >> Group: Individual Submission >> Pages: 14 >> URL: https://www.ietf.org/internet-drafts/draft-nir-saag-star-00.txt >> Status: https://datatracker.ietf.org/doc/draft-nir-saag-star/ >> Htmlized: https://tools.ietf.org/html/draft-nir-saag-star-00 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-nir-saag-star-00 >> >> >> Abstract: >> Recently there has been renewed interest in an old idea: Issue >> certificates with short validity periods and forego revocation >> processing, reasoning that expiration is a sufficient replacement for >> revocation as long as that expiration is not too far off. >> >> This document covers considerations, both security and operational, >> for using such Short Term Auto Renewed (STAR) certificates for >> various scenarios where Using a revocation protocol is considered >> inappropriate. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------A89A5A787B44FB0471FED8C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 10/17/2017 3:03 PM, Yoav Nir wrote:
Hi all

We’ve submitted this -00 draft for your consideration. It is still very rough with several sections missing, but we feel it’s good enough for starting a conversation.

There is quite a bit of interest in using short term certificates recently. There is a draft at ACME, a proposed draft at STIR, and many use cases in IT, whether these certificates are exchanged with TLS or with IKE or SSH. Some of these use cases are web, but many others are not.  The purpose of this draft is to list considerations, both operational and security, for using short term certificates without revocation.

If this effort is successful, the resulting document should guide both draft writers and IT people in answering two important questions:
 1. When is using short term certificates appropriate?
 2. What needs to be in place for a functional, reliable and secure deployment?

Any comments will be greatly appreciated.

Thanks

Yoav on behalf of the authors.

Hi Yoav -


The clockSkew commentary is useful, but misses the problem that you might not actually have a version of secure time available at all or consistently or different RPs may or may not have the same clocks.  Some of the smaller IOT devices can't afford either an RTC or the power for an RTC and trusting mesh time might be problematic.  It would be helpful if you would expand upon your expectations for time domain support either in the intro or somewhere before you get into the discussions with skew. E.g. its OK to exclude IoT usages that depend on reliable time, but best to set expectations.

I've been trying to think about how to provide something that allows certs to expire or be validated without dependence on clock time - its not an easy problem. 

Last - you may want to chat about the fact that - with clock skew - the certificate holder and the relying party may have different ideas about validity for a given cert and the error handling related to this problem.

Thanks - Mike




Begin forwarded message:


A new version of I-D, draft-nir-saag-star-00.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.

Name:		draft-nir-saag-star
Revision:	00
Title:		Considerations For Using Short Term Certificates
Document date:	2017-10-14
Group:		Individual Submission
Pages:		14
URL:            https://www.ietf.org/internet-drafts/draft-nir-saag-star-00.txt
Status:         https://datatracker.ietf.org/doc/draft-nir-saag-star/
Htmlized:       https://tools.ietf.org/html/draft-nir-saag-star-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-nir-saag-star-00


Abstract:
  Recently there has been renewed interest in an old idea: Issue
  certificates with short validity periods and forego revocation
  processing, reasoning that expiration is a sufficient replacement for
  revocation as long as that expiration is not too far off.

  This document covers considerations, both security and operational,
  for using such Short Term Auto Renewed (STAR) certificates for
  various scenarios where Using a revocation protocol is considered
  inappropriate.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



      

      

      

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


    

    


    

  


--------------A89A5A787B44FB0471FED8C3--


From yakov@nightwatchcybersecurity.com  Sun Oct 15 19:00:12 2017
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 4174E1332DA for ; Sun, 15 Oct 2017 19:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeaAmZTAUdyO for ; Sun, 15 Oct 2017 19:00:10 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B241332E1 for ; Sun, 15 Oct 2017 19:00:10 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id v132so23010676oie.1 for ; Sun, 15 Oct 2017 19:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=dOnOSl0rHLf8IxFmzdpdGjzM8rfN8B+6d/7rfxYTZwo=; b=a6zoBTEyX46Qy3sgnQCm0jrHPfFpELuwkBFUMqk3oMPeYideDDYE2FHrT94l+jzCI2 AKcZHnvbAU40KGMc0A0GbjdqttxIliUnq7paBug5pVU9v70ffE6Uuz2mcjtYBtB4WMd/ R8K4LBKnv1M13Ee4xVCP1a1puY9LhzCnHWZgKxHnedFsUc7QfiET0gixHUS8khksgDfC EBTJQno3fqPLiN9vuntMV1bTszp7+Xq/PhB6f5BqduSwh8tl90Aa80mTeykM9rIjMqFl 1h8fksQVy4jOa03tklgfXCaU/MgIByLM5SYEnS5JidtH0v34s0A0y2S90jga5T4+TKd8 gtug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=dOnOSl0rHLf8IxFmzdpdGjzM8rfN8B+6d/7rfxYTZwo=; b=oBxD35VoechSkLhOgXiX9A9ugiwBPW1OWLBn+QGEZvVw2kEJsNOBukhlqtrIb9fZ0q /+nPvHRego+YlOo7ZkE70/bOKjl4VXZUIshnbVeT7CCIcVgJe7q5eiAigE0ccK3HRHyf oX2meKJmhJBrwkyOo1db5KI6iTSE6jcvfw/+f12Mjet1azX5gieyM3r83shtz8EzVsG1 mBjuYMvApaloRVtV0KJ9vZUmhoAdyYM5WAbhH4IapkH7Wl0Xi4KVp15bOzg6Kj0UPIm8 FF8O+IvzOkcKFsCRzwPiQCYeCo5mx77fegNLFHl5+u83C89uuS5fGfi1LkPkFTbFHqY/ fKZw==
X-Gm-Message-State: AMCzsaViDlWVW6T0vnB5bsHazDrdKEdYNQ8ZQ45rLKKSm8q3U6JtKz9X PYt48X4vrw8LjOdeYEOwE7KeRpB2Zay/gT9er+zB1gG8RVE=
X-Google-Smtp-Source: AOwi7QDhctIKRLIap/MGQXAALCz1fRBxrtGXfS1eGMOoeGiA4iCuJI84YeoaZbSMKpsvgf6lcOWSLiLOMwVqW4OArDE=
X-Received: by 10.157.81.145 with SMTP id y17mr5857711otg.113.1508119209414; Sun, 15 Oct 2017 19:00:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.84.27 with HTTP; Sun, 15 Oct 2017 18:59:29 -0700 (PDT)
From: Yakov Shafranovich 
Date: Sun, 15 Oct 2017 21:59:29 -0400
Message-ID: 
To: saag@ietf.org
Cc: Ed Overflow , Russ Housley ,  Nancy Cam-Winget 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-Mailman-Approved-At: Wed, 18 Oct 2017 14:02:02 -0700
Subject: [saag] Proposal for "security.txt"
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Oct 2017 02:07:13 -0000

[I am posting this as per my emails with the sec ADs]

Ed Foudil and others within the security community are working on an
Internet draft proposing a new standard for providing security contact
information via a standard file, similar to robots.txt. The draft can
be found here:
https://tools.ietf.org/html/draft-foudil-securitytxt-00

Additional resources here:
https://securitytxt.org/
https://github.com/securitytxt/security-txt

Nevil Brownlee (the Independent Submissions Editor) has indicated that
this document is not a good candidate for the independent stream, so
the question now is whether this can be something that fall under the
security area.

EKR has suggested that this may be a good topic to add to the upcoming
SEC-DISPATCH meeting at IETF 100 in Singapore.

Thanks,
Yakov


From nobody Wed Oct 18 14:05:15 2017
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 CD78A132620 for ; Wed, 18 Oct 2017 14:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9GB05kwJVEm for ; Wed, 18 Oct 2017 14:05:07 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D433132193 for ; Wed, 18 Oct 2017 14:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v9IL4v1C020386; Wed, 18 Oct 2017 23:04:57 +0200 (CEST)
Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yHPhT4hQTzDXL9; Wed, 18 Oct 2017 23:04:57 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: 
Date: Wed, 18 Oct 2017 23:04:55 +0200
Cc: saag@ietf.org, Ed Overflow 
X-Mao-Original-Outgoing-Id: 530053495.001448-aa82541aaea463c43ffe27cfe20563d8
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A8D136E-D99D-4944-B9AA-BAA4D1765514@tzi.org>
References: 
To: Yakov Shafranovich 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [saag] Proposal for "security.txt"
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 21:05:14 -0000

Surely, this needs to be under /.well-known?
(RFC 5785)

Gr=C3=BC=C3=9Fe, Carsten

> On Oct 16, 2017, at 03:59, Yakov Shafranovich =
 wrote:
>=20
> [I am posting this as per my emails with the sec ADs]
>=20
> Ed Foudil and others within the security community are working on an
> Internet draft proposing a new standard for providing security contact
> information via a standard file, similar to robots.txt. The draft can
> be found here:
> https://tools.ietf.org/html/draft-foudil-securitytxt-00
>=20
> Additional resources here:
> https://securitytxt.org/
> https://github.com/securitytxt/security-txt
>=20
> Nevil Brownlee (the Independent Submissions Editor) has indicated that
> this document is not a good candidate for the independent stream, so
> the question now is whether this can be something that fall under the
> security area.
>=20
> EKR has suggested that this may be a good topic to add to the upcoming
> SEC-DISPATCH meeting at IETF 100 in Singapore.
>=20
> Thanks,
> Yakov
>=20
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>=20


From nobody Wed Oct 18 14:15:08 2017
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 D385F132705 for ; Wed, 18 Oct 2017 14:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=HWrd3kHN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=R/mHceBU
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 W7pn8spaQeaT for ; Wed, 18 Oct 2017 14:15:05 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4620A1320DC for ; Wed, 18 Oct 2017 14:15:05 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9116A20D7A; Wed, 18 Oct 2017 17:15:04 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 18 Oct 2017 17:15:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=QduxerhJEofBRQkDv+Wz4L5rwvCtICPFa8KEvU0NvY0=; b=HWrd3kHN vWC59M12hPWJjFqT7Tz4HWG7W6pL8G4gCMDZz3OwEZ8dokMiXZrKDiRvDd+AZJ7r 3r0PG+ohqyot2B0yZ8tahVepem214Vi5HfXUxizKeKnAuTs1Gxm5ajAukxYN3ecv kliIuTXiiuOEMZE70z34qF1qg1M2X7rjERiBMl8Ncu72Do12Ofr6yzk0laFnxYWI Xhof8LyQYiDqjxCWgjGvDxGNPY9WFGasXJHdKoe2r4g8zOT//Tmcqj/fdDBN11mz I55N+qreqb4gH55xf4QNCr2UQtiNwwYNkbrsASVVE+GLN0LlEspSwnhgU8W34XUm KOlloZGFKruBsw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=QduxerhJEofBRQkDv+Wz4L5rwvCtI CPFa8KEvU0NvY0=; b=R/mHceBUOA0EKrV/W2rFa+rGyX9Dg4cjIZSwaHWmJ4MF9 9OIoLYR2tAjpZZBCu5tq80Lg9XcF+0gHbPNA5MX9NMYig9Ji+M/Jk3ze4uGa7zrc cLEaKqn9sIll8rLZU4Ra+XvMQyYXDUZJrFNtVw4zxQT/FJ5eR9SBH/BdGCk574P7 bUbm8PWAWA/eLlIUej3d0I6/ALuB5Lzaim7jUg4XU6F79Kac/Yg8zaZQaZCRQUkm QZ6/7nwXAppRiAHqt5K1JjluWrrqq1Pa5j80tcRgYJGRl5ECYUmGzxKTsLiy7UB+ OLhgxzg8cmMi2ebvdD4ShuylPM2ueGbC+061qtqSg==
X-ME-Sender: 
Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id E821D7FA80; Wed, 18 Oct 2017 17:15:03 -0400 (EDT)
To: Yakov Shafranovich , saag@ietf.org
Cc: Ed Overflow 
References: 
From: Peter Saint-Andre 
Message-ID: <9dd8a85f-4ea1-eb2f-84c3-932566e76841@stpeter.im>
Date: Wed, 18 Oct 2017 15:15:01 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l8ioCuLGnBxHvuTFFUs3NffOTq27vGN9b"
Archived-At: 
Subject: Re: [saag] Proposal for "security.txt"
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 21:15:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--l8ioCuLGnBxHvuTFFUs3NffOTq27vGN9b
Content-Type: multipart/mixed; boundary="BMkuDos58vvNjsGm6JH3AhH9qhL6eRncc";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Yakov Shafranovich , saag@ietf.org
Cc: Ed Overflow 
Message-ID: <9dd8a85f-4ea1-eb2f-84c3-932566e76841@stpeter.im>
Subject: Re: [saag] Proposal for "security.txt"
References: 
In-Reply-To: 

--BMkuDos58vvNjsGm6JH3AhH9qhL6eRncc
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 10/15/17 7:59 PM, Yakov Shafranovich wrote:
> [I am posting this as per my emails with the sec ADs]
>=20
> Ed Foudil and others within the security community are working on an
> Internet draft proposing a new standard for providing security contact
> information via a standard file, similar to robots.txt. The draft can
> be found here:
> https://tools.ietf.org/html/draft-foudil-securitytxt-00
>=20
> Additional resources here:
> https://securitytxt.org/
> https://github.com/securitytxt/security-txt

Related:

https://blog.liftsecurity.io/2013/06/02/security-md-improved-security-dis=
closure/

Peter



--BMkuDos58vvNjsGm6JH3AhH9qhL6eRncc--

--l8ioCuLGnBxHvuTFFUs3NffOTq27vGN9b
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlnnxFUACgkQ6gakkSvF
raniHQ//fajfuqlI/EQRJUdA0CiVRmHz1uFieNV5jJIK7KusMa3i8UrpxRfq7Zhl
W4yA7i/KylWfPKKiiARcGeFPuHNq9ezwPUDx+bUkkV/mSiQFo7x4OdkrSvT/uDsd
XG515n2pmrN8Pn3RuZmlHwz1QjwSFq4sngAjQgd2dMk3xZ6ginM2m0khDNyxbd7o
RdyWfR1QhbRulToRZzSdlDM7J0xOiZV3G6+ePwwOL3SwkIRSBbo/MGB+J0P+szrG
4PC3E/G25Q2urW1jfwm+aVpY1tAJzbZpXK+uoz1ICcYx8cExnHj0lQmJ4Ipn/kuv
lLBIQ3KU41FaXrDBiQNlU1LPu6iD99MtaFGio8UPgZ81X3TnvxKSOLdBXJtwkARj
bmcKxRiPBYkWNoW3bE8pbwzSOc6pGK1j/190MmAXX1iiO9Cd/ue6WAOrYfMpc/8+
0q/t12Pyd/rwRMjs4M7r+Yk/EoTuyYuSazOp65TelON1LxsOAo2X+VG8FMlzBFe1
LuhasXC/X5dpcVXb8mkMMrPCEGObU3sCtsjgT9ZI6L8rn4fGq4Oy6dQbj0kTIIHn
uFbu5X2aH5Y50bml1MVAXU9i+6QMCkIp1rWXlBncDLKec6kEmnTVnF64j+V/sOTj
p47RPPWiuWH6QzGyN20NiDswN3+E0plMij5dW+KkxZ+Wl+MxB54=
=8ESD
-----END PGP SIGNATURE-----

--l8ioCuLGnBxHvuTFFUs3NffOTq27vGN9b--


From nobody Wed Oct 18 14:55:51 2017
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 3D9C613308D for ; Wed, 18 Oct 2017 14:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEZNImdECmE7 for ; Wed, 18 Oct 2017 14:55:48 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 959CF13292A for ; Wed, 18 Oct 2017 14:55:48 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id h6so11462680oia.10 for ; Wed, 18 Oct 2017 14:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Q0eqSlfTCG9R0hYn8viQRFI6BAuQ+vwrHyK2xLQJdN0=; b=lLMkrMUZjMF4yYXs+GC7QdonHKwCrqNcoEFnYkK3DCq40LTtLaExfIdvwY7Jwz8j1I 2yQLjNGvHIzAvpCON0zHjFX1If6f05NmcQNp7iQc2QPM/WF/sq/QlLJYHsiD34zurrkI wbftvYqaRRPGfStuSomS4ftZwd9eEIWB5jn8bBqpIm4fBdUn6oCvNI7uk3P9OHywMmLY VbgFhLhRm+dWdmSjyylqTWUiIbPuE4OXh/SRA5kYS62NyGAXG+BdCrPsIhqjKP1nePE3 N9X7itF4sim2ENpA3wFTCRaDLtIvnrBO7IRsuGA0rS1yJrsxj2kHdquxFqPyD/7HCE4d BsBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=Q0eqSlfTCG9R0hYn8viQRFI6BAuQ+vwrHyK2xLQJdN0=; b=PSk4HauRgzYQPTvsDV9B7iTyZCSFNo9TNi9SLSfI0D4rvrw8xxSRWigpS4lXqe9pmr 3IuIkZ9WmcRG7YJ8tNB3xo3iAJM3QuL4IJMXVunhM4amsMSuCrvDDmVZGWse1AMAt+YN wQQYSKmiQcH7cHNSEmj4HrfcBDtI/53eHBGEbWyiQcliaNhiF+q4+4HAzhJus+klbdZ7 UJXPeKTc3f/EBItxDKgYmU0F6uG7TPTTeZ51Io5ixQzBQwEAvgoIIKpFuLozAxYVxXFc j+MHw6ESNTKEzQtnSf2XLUh/uVLQq0uA1PKALzR2rNczkWgIjSS1B/P2RlM0GLZrLqjF 5anw==
X-Gm-Message-State: AMCzsaUiMfOVSn7Q5on1pp8j0fkkurhw4NyxUsd3VpkihSPbbzd1se+x ygqvYyypwm8iaJjPj8DAP0bdIQylSxjznwdHl2g=
X-Google-Smtp-Source: ABhQp+Soefnt0ul/oZha9/QKIUNacSG+eA4jretSktvhLm8raCsaBRso0S2uOsH0wD4Nq6IFWDOubkPbXb0YyuPVyB4=
X-Received: by 10.157.25.2 with SMTP id j2mr5597604ota.319.1508363748006; Wed, 18 Oct 2017 14:55:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.19.87 with HTTP; Wed, 18 Oct 2017 14:55:47 -0700 (PDT)
Reply-To: noloader@gmail.com
In-Reply-To: 
References: 
From: Jeffrey Walton 
Date: Wed, 18 Oct 2017 17:55:47 -0400
Message-ID: 
To: Yakov Shafranovich 
Cc: "saag@ietf.org" , Ed Overflow 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [saag] Proposal for "security.txt"
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 21:55:50 -0000

On Sun, Oct 15, 2017 at 9:59 PM, Yakov Shafranovich
 wrote:
> [I am posting this as per my emails with the sec ADs]
>
> Ed Foudil and others within the security community are working on an
> Internet draft proposing a new standard for providing security contact
> information via a standard file, similar to robots.txt. The draft can
> be found here:
> https://tools.ietf.org/html/draft-foudil-securitytxt-00
>
> Additional resources here:
> https://securitytxt.org/
> https://github.com/securitytxt/security-txt
>
> Nevil Brownlee (the Independent Submissions Editor) has indicated that
> this document is not a good candidate for the independent stream, so
> the question now is whether this can be something that fall under the
> security area.
>
> EKR has suggested that this may be a good topic to add to the upcoming
> SEC-DISPATCH meeting at IETF 100 in Singapore.

We already have RFC 2142, MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS. It provides a security@ address.

But it would be nice to have have something simple, like a robots.txt,
to establish domain boundaries. That is, a subdomain can indicate
*.example.com does not apply to the subdomain for the purposes of a
security context used in PKIX.

Jeff


From nobody Wed Oct 18 15:45:40 2017
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 8C8BF1321A1 for ; Wed, 18 Oct 2017 15:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFLwnM4BOQpm for ; Wed, 18 Oct 2017 15:45:38 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 613821320B5 for ; Wed, 18 Oct 2017 15:45:38 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id n82so11683602oig.3 for ; Wed, 18 Oct 2017 15:45:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j1t4tP67qfNlT4VsVJxD4cOrEfrLszjB9bxPkQElfkw=; b=lX2hcuZme82fLJzRqgY8ldIEU+fQ/UOHTRgElSaL/bzovUurM5hOcDCD+sDD/j+bwP KDMXT58ie8Smc3/wtS6Z0C60jv9xfHXiwau2sHEjQxAJzhezN/PupP3rQszLqh7JV+RH l48aq5oF5yjErgfM1Y7rpYe58SjI7pOeJX3xcbMGb7xvacXXZgYzigGtTJjyeZa55HEZ SMqsL/jvZiQ/4eEsGNJIK1NJLwsbxopb2Q5WDVHHjW7+wcqnuq9ru3OlUeETRf3rYRYx 0ffTUNUNtOdyEjKs6Fh82iTfHuUEXVGO+Gs/sdvQYpd9JQeAK0l4/G5opN/IW+EqhoAD jI+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j1t4tP67qfNlT4VsVJxD4cOrEfrLszjB9bxPkQElfkw=; b=pkrYWN/nJHKXq3HHWZycIj7qHmiMBpC7coZ/BGihjggfMT+ojufs82eiKYUitir3p7 SOKLalaHrspY/Qfk3wXuPBIN718GARcnd7tTYHl4Nnhtt/RQRQzkQASvV4wnrTnOr04v L3BRl6IwggGkgUuaAZ49Prd4P8/ThZC/VSg/gtAUSKyeBDszLwEewD3NzytaVpK+TtWP t6pOs35IzJ3xpMkdBChqLvxxZfQC9aMWYOhBQLkTzC5pBLNy1G/kHjXdzYBlhKyya1LH aL17bGcWE0oyZNj7gkDqOMLsTq731oOsGhgH/96mmoYRqyD5yhbyJX/+gSNvGT/nZHHV XIgw==
X-Gm-Message-State: AMCzsaU2Djq6W0c1tZbMdR6v71GY1aMax1jRIx23f87BDvYlcGGWvgG+ yQMNckSl04Gsc/6gik2DJDh0SA0mrox40gnk9XDpTg==
X-Google-Smtp-Source: ABhQp+T3A/zwIF+TRgNu/WMpq6gXCalR4K5jt8tbrwDAv7fyuXKP4UruNgpTw4XwkZhtQ1o4kF2Z4xsM23kpTbcXMY4=
X-Received: by 10.157.87.75 with SMTP id x11mr5518286oti.112.1508366737725; Wed, 18 Oct 2017 15:45:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.72.178 with HTTP; Wed, 18 Oct 2017 15:45:37 -0700 (PDT)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Thu, 19 Oct 2017 09:45:37 +1100
Message-ID: 
To: Yakov Shafranovich 
Cc: saag , Ed Overflow 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [saag] Proposal for "security.txt"
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 22:45:39 -0000

On Mon, Oct 16, 2017 at 12:59 PM, Yakov Shafranovich
 wrote:
> EKR has suggested that this may be a good topic to add to the upcoming
> SEC-DISPATCH meeting at IETF 100 in Singapore.

Yes, this seems appropriate.  Going through this process will ensure
that comments like Carsten's - a view I share - are considered and
addressed.


From nobody Mon Oct 23 10:58:52 2017
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 5362F1398CF for ; Mon, 23 Oct 2017 10:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level: 
X-Spam-Status: No, score=-4.801 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3mjVzPiG1cn for ; Mon, 23 Oct 2017 10:58:48 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0138.outbound.protection.outlook.com [104.47.38.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF50138AEE for ; Mon, 23 Oct 2017 10:58:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zfRrzvsD4DivCdlPklYtMZ080CEmbRXv60u5lbGlpgQ=; b=gbLw6jmZqt197KJQfdZ7yFXQaZEZ29DlW06kIz9jM3317K4gOvUL2FtmIHjMH0mGrATVoPCl0x/Lo3GWlWVrEGJUhKq+mfb52Y9aW72w0UltxAaXfnZ9e1bbFGGDmk/vskYndIYMkdcKBYbrW12HPGeBrAbS/zO+XQOElLg30mA=
Received: from BN1PR05MB280.namprd05.prod.outlook.com (10.141.64.153) by BN1PR05MB278.namprd05.prod.outlook.com (10.141.64.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.3; Mon, 23 Oct 2017 17:58:45 +0000
Received: from BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497]) by BN1PR05MB280.namprd05.prod.outlook.com ([fe80::2501:f69b:d3d5:1497%14]) with mapi id 15.20.0178.003; Mon, 23 Oct 2017 17:58:45 +0000
From: Kent Watsen 
To: Yoav Nir , Security Area Advisory Group 
Thread-Topic: [saag] Using short term certificates (instead of revocation)
Thread-Index: AQHTR3qYup42yNiMeUuaiQCzlD3TDaLxfySA
Date: Mon, 23 Oct 2017 17:58:45 +0000
Message-ID: <40F22633-EB28-43AE-9F05-39833F9B7F1C@juniper.net>
References: <150809609468.12209.18375712195993239092.idtracker@ietfa.amsl.com> <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com>
In-Reply-To: <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN1PR05MB278; 6:HOiSiqkoX8b4zoWYZuxONsaE8VC1C4VRCSA2qdRFzpQmJbbPfvERLQOI5FfcA9PdOV75jz6PIDfjGL7Vfg08KvdltNiXnoZ1O4V1MCUC4RHtXGs5MRQ///3Iw5osbuHLGRz61FjTyDOOn2Q21sW28r20tbfe0yEDxPEogRTReq0dV3lXITaiow6FgjfPZRvNPrFeS3wIdb9wtOncQ2K73W7J6T0N6TOvBse7jBa6M4PtVdgXEz5Mc0KLx4sVr6kX5FE0noVBBD0CeQVvxLcNR1OFNNF3cKYni8dhFXoeSY334eh5nbO867IEELkNabKd5TOnDhMOg7jYh9pfPYrEV3TjGJi3HN/ElWXxI/sQSwM=; 5:17cxUwiNF03JqJPkwDYoal6ZAHz5AAQyBLeNzKEPK7QMkvMyA9XxDYK+OeLMhJ/uboh+BS6vpHxRMZtBDnhEfF8ZLHXoXOwms+kPlb0vgthsivC1w0WQCt+zO+97GOt4iFN5CdaApAWAxmc3KaPajBQ00DKIt+FruLZjiE1rPRI=; 24:3jAF5KnSprgKOH4mFZoM7kbFd46oDUwi4lNRqLl13y8EP3VNjzQL5nInU2I0sAdTdDR+ob8LBim4aLVhILooDWhAQEn0+61kqhXoFQV2Fvg=; 7:7pjAfD2JKnx9bWfOa2lr+Yb6snSBM6fnZWGz21J5Pv243+IaCEYKPtKRAZpsNtBkPN3X4IGZiaBwJEVh5PNx8yOeOvxVSn301wRuBaDidxcQVneeXkThXBVjdiQAgqhwyR1PLASymlVMXz4mWO61/LCh0B2ICTdo/R5PUWrf81HcBSnGJtBkwhwBFbcoji1tJx4+ES0HsEnQC18JYRkI+rIa6KD5n4UH+1j2U/4DaLyJiZQAl8QGXbYuDttexlly
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 669fb55b-e7a6-4761-2f02-08d51a3fb47c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:BN1PR05MB278; 
x-ms-traffictypediagnostic: BN1PR05MB278:
x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231020)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB278; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB278; 
x-forefront-prvs: 046985391D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(53754006)(199003)(189002)(377424004)(966005)(2900100001)(3846002)(66066001)(101416001)(6116002)(102836003)(50986999)(76176999)(54356999)(2950100002)(33656002)(105586002)(68736007)(106356001)(3660700001)(81156014)(7736002)(305945005)(8676002)(81166006)(3280700002)(8936002)(189998001)(478600001)(2906002)(5660300001)(99286003)(4001150100001)(6246003)(83506002)(58126008)(36756003)(110136005)(6486002)(53936002)(6436002)(6306002)(5250100002)(97736004)(83716003)(6506006)(39060400002)(25786009)(14454004)(82746002)(229853002)(316002)(6512007)(86362001)(367364002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB278; H:BN1PR05MB280.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1D4768E73689254A8E897F760A04F2AB@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 669fb55b-e7a6-4761-2f02-08d51a3fb47c
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 17:58:45.4529 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB278
Archived-At: 
Subject: Re: [saag] Using short term certificates (instead of revocation)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Oct 2017 17:58:50 -0000

SG8gWW9hdiwNCg0KWW91IG1pZ2h0IGJlIGludGVyZXN0ZWQgaW4gdGhpcyBhcyB3ZWxsOg0KDQog
IFJlbmV3YWxzIGluc3RlYWQgb2YgUmV2b2NhdGlvbnM6DQogIGh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLWFuaW1hLXZvdWNoZXItMDUjc2VjdGlvbi03LjENCg0KVGhhbmtz
LA0KS2VudA0KDQoNCkhpIGFsbA0KDQpXZeKAmXZlIHN1Ym1pdHRlZCB0aGlzIC0wMCBkcmFmdCBm
b3IgeW91ciBjb25zaWRlcmF0aW9uLiBJdCBpcyBzdGlsbCB2ZXJ5IHJvdWdoIHdpdGggc2V2ZXJh
bCBzZWN0aW9ucyBtaXNzaW5nLCBidXQgd2UgZmVlbCBpdOKAmXMgZ29vZCBlbm91Z2ggZm9yIHN0
YXJ0aW5nIGEgY29udmVyc2F0aW9uLg0KDQpUaGVyZSBpcyBxdWl0ZSBhIGJpdCBvZiBpbnRlcmVz
dCBpbiB1c2luZyBzaG9ydCB0ZXJtIGNlcnRpZmljYXRlcyByZWNlbnRseS4gVGhlcmUgaXMgYSBk
cmFmdCBhdCBBQ01FLCBhIHByb3Bvc2VkIGRyYWZ0IGF0IFNUSVIsIGFuZCBtYW55IHVzZSBjYXNl
cyBpbiBJVCwgd2hldGhlciB0aGVzZSBjZXJ0aWZpY2F0ZXMgYXJlIGV4Y2hhbmdlZCB3aXRoIFRM
UyBvciB3aXRoIElLRSBvciBTU0guIFNvbWUgb2YgdGhlc2UgdXNlIGNhc2VzIGFyZSB3ZWIsIGJ1
dCBtYW55IG90aGVycyBhcmUgbm90LiAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFmdCBpcyB0byBs
aXN0IGNvbnNpZGVyYXRpb25zLCBib3RoIG9wZXJhdGlvbmFsIGFuZCBzZWN1cml0eSwgZm9yIHVz
aW5nIHNob3J0IHRlcm0gY2VydGlmaWNhdGVzIHdpdGhvdXQgcmV2b2NhdGlvbi4NCg0KSWYgdGhp
cyBlZmZvcnQgaXMgc3VjY2Vzc2Z1bCwgdGhlIHJlc3VsdGluZyBkb2N1bWVudCBzaG91bGQgZ3Vp
ZGUgYm90aCBkcmFmdCB3cml0ZXJzIGFuZCBJVCBwZW9wbGUgaW4gYW5zd2VyaW5nIHR3byBpbXBv
cnRhbnQgcXVlc3Rpb25zOg0KIDEuIFdoZW4gaXMgdXNpbmcgc2hvcnQgdGVybSBjZXJ0aWZpY2F0
ZXMgYXBwcm9wcmlhdGU/DQogMi4gV2hhdCBuZWVkcyB0byBiZSBpbiBwbGFjZSBmb3IgYSBmdW5j
dGlvbmFsLCByZWxpYWJsZSBhbmQgc2VjdXJlIGRlcGxveW1lbnQ/DQoNCkFueSBjb21tZW50cyB3
aWxsIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQoNClRoYW5rcw0KDQpZb2F2IG9uIGJlaGFsZiBv
ZiB0aGUgYXV0aG9ycy4NCg0KPiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4gDQo+IA0KPiBB
IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbmlyLXNhYWctc3Rhci0wMC50eHQNCj4gaGFzIGJl
ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBZb2F2IE5pciBhbmQgcG9zdGVkIHRvIHRoZQ0K
PiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtbmlyLXNhYWctc3Rhcg0KPiBS
ZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlDb25zaWRlcmF0aW9ucyBGb3IgVXNpbmcgU2hvcnQgVGVy
bSBDZXJ0aWZpY2F0ZXMNCj4gRG9jdW1lbnQgZGF0ZToJMjAxNy0xMC0xNA0KPiBHcm91cDoJCUlu
ZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczoJCTE0DQo+IFVSTDogICAgICAgICAgICBodHRw
czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbmlyLXNhYWctc3Rhci0wMC50
eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LW5pci1zYWFnLXN0YXIvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtbmlyLXNhYWctc3Rhci0wMA0KPiBIdG1saXplZDogICAgICAgaHR0cHM6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1uaXItc2FhZy1zdGFyLTAwDQo+
IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgUmVjZW50bHkgdGhlcmUgaGFzIGJlZW4gcmVuZXdlZCBp
bnRlcmVzdCBpbiBhbiBvbGQgaWRlYTogSXNzdWUNCj4gICBjZXJ0aWZpY2F0ZXMgd2l0aCBzaG9y
dCB2YWxpZGl0eSBwZXJpb2RzIGFuZCBmb3JlZ28gcmV2b2NhdGlvbg0KPiAgIHByb2Nlc3Npbmcs
IHJlYXNvbmluZyB0aGF0IGV4cGlyYXRpb24gaXMgYSBzdWZmaWNpZW50IHJlcGxhY2VtZW50IGZv
cg0KPiAgIHJldm9jYXRpb24gYXMgbG9uZyBhcyB0aGF0IGV4cGlyYXRpb24gaXMgbm90IHRvbyBm
YXIgb2ZmLg0KPiANCj4gICBUaGlzIGRvY3VtZW50IGNvdmVycyBjb25zaWRlcmF0aW9ucywgYm90
aCBzZWN1cml0eSBhbmQgb3BlcmF0aW9uYWwsDQo+ICAgZm9yIHVzaW5nIHN1Y2ggU2hvcnQgVGVy
bSBBdXRvIFJlbmV3ZWQgKFNUQVIpIGNlcnRpZmljYXRlcyBmb3INCj4gICB2YXJpb3VzIHNjZW5h
cmlvcyB3aGVyZSBVc2luZyBhIHJldm9jYXRpb24gcHJvdG9jb2wgaXMgY29uc2lkZXJlZA0KPiAg
IGluYXBwcm9wcmlhdGUuDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h
eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+
IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v
bHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCg0KDQoNCg==


From nobody Mon Oct 23 12:01:24 2017
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 6B6CB138351 for ; Mon, 23 Oct 2017 12:01:23 -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 3Di9PzG2x2fb for ; Mon, 23 Oct 2017 12:01:21 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB28139B9F for ; Mon, 23 Oct 2017 12:01:08 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id p75so11423736wmg.3 for ; Mon, 23 Oct 2017 12:01:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6OIhK6zARMwlBWAtSByqIuEccX3XJU5oeZnT2mj9qm8=; b=fx0/40TsxguskHmbLVI+WN0Br04mKYMO/FJsMhUSBzMMKAjmhp+akZ1JH+9tX5YiTP GRcE9Brex8xekhFwF/QCNEMd6+Zpb/WybVVoxIKypnfrE01rKviDnwc9v9K+MBJoY8z9 FAJKVRZaTt2WhiLDPpPy57Dwpj9daK8tb5axXr2jEyRA3bDX3YtKfAz4udUuobI9+sQL l1cVQ4IfR3zrBXoH17T0oSh8r5ajy/X2wuqCfduSAFIShZ0Um9hgJsEju2Yil3wb30Ia 7n0Su4ByAJhK39HNeCJpcmSdVXjfkZtT4MU3BC086G6UvpoNWRBfrb94IwDvExuw51JO zfVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6OIhK6zARMwlBWAtSByqIuEccX3XJU5oeZnT2mj9qm8=; b=BmfxQYEJHK2YGfMO6l0/QKjZGy6/Xdw1YYYVnHXhsANUWP8ZphLERW6NTqaTr1BiUC 0pLyIUmgEmtJpXrKaRGYm9Q2yyTSxi5jI5b6C0zXZmIM2OMImgV8PrGbhGc4c6nmCyWH 6HjENLdvG1DxPurckqVjXPy2+irsmbYPwh8RVmcULb6BTlqQVvon0rwenHmAPa4Tr1Gh XfBx69Y28XrVDdrJcrnIcFkkPbelGe3cJqKUyEblip3PBCQ8Yun3I3yIwGOvNk2h9mf8 /r7C+bjF+ys9PTEXykHSQLO+gBrqDk1Hz0LaRrfZCB7c3M6HrgqaO4CF/JQlQDZ92ZWq pJxg==
X-Gm-Message-State: AMCzsaVPcPQndPyUEGqDAdZEdOWKx595jjNkZIxyUokPhxqnWgMlSmAQ JSRYd4AcCb43hSKF+u6aUNw=
X-Google-Smtp-Source: ABhQp+QmD/ZGMRp1WWoY7e6A4ViCu/GbVtgb1kxTPSWiH2Gp1noqp3SGcLWnBGOwTrHINcRBtVgfDQ==
X-Received: by 10.80.155.27 with SMTP id o27mr18154648edi.39.1508785267229; Mon, 23 Oct 2017 12:01:07 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m23sm3773777edc.53.2017.10.23.12.01.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 12:01:06 -0700 (PDT)
From: Yoav Nir 
Message-Id: <3636D5EA-E1DD-46AA-A2D3-0B5DA1B6B6DF@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_5849D3F9-253F-4BB5-AD3C-0A9327C7CAF4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Date: Mon, 23 Oct 2017 22:01:04 +0300
In-Reply-To: <40F22633-EB28-43AE-9F05-39833F9B7F1C@juniper.net>
Cc: Security Area Advisory Group 
To: Kent Watsen 
References: <150809609468.12209.18375712195993239092.idtracker@ietfa.amsl.com> <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> <40F22633-EB28-43AE-9F05-39833F9B7F1C@juniper.net>
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [saag] Using short term certificates (instead of revocation)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Oct 2017 19:01:23 -0000

--Apple-Mail=_5849D3F9-253F-4BB5-AD3C-0A9327C7CAF4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Kent

Thanks for that.

One argument I=E2=80=99ve heard from people not associated with the IETF =
and PKIX tradition is that it seems to them redundant to have both a =
signed assertion (the certificate) and then another assertion (CRL or =
OCSP response) saying that the first assertion is valid. If you take =
revocation seriously you have to wonder how do we know the second =
assertion is valid. Quis custodiet ipsos custodes?

So it makes sense to make them just one assertion. It simplifies things. =
At least it should be an acceptable option.

Yoav


> On 23 Oct 2017, at 20:58, Kent Watsen  wrote:
>=20
> Ho Yoav,
>=20
> You might be interested in this as well:
>=20
>  Renewals instead of Revocations:
>  https://tools.ietf.org/html/draft-ietf-anima-voucher-05#section-7.1
>=20
> Thanks,
> Kent
>=20
>=20
> Hi all
>=20
> We=E2=80=99ve submitted this -00 draft for your consideration. It is =
still very rough with several sections missing, but we feel it=E2=80=99s =
good enough for starting a conversation.
>=20
> There is quite a bit of interest in using short term certificates =
recently. There is a draft at ACME, a proposed draft at STIR, and many =
use cases in IT, whether these certificates are exchanged with TLS or =
with IKE or SSH. Some of these use cases are web, but many others are =
not.  The purpose of this draft is to list considerations, both =
operational and security, for using short term certificates without =
revocation.
>=20
> If this effort is successful, the resulting document should guide both =
draft writers and IT people in answering two important questions:
> 1. When is using short term certificates appropriate?
> 2. What needs to be in place for a functional, reliable and secure =
deployment?
>=20
> Any comments will be greatly appreciated.
>=20
> Thanks
>=20
> Yoav on behalf of the authors.
>=20
>> Begin forwarded message:
>>=20
>>=20
>> A new version of I-D, draft-nir-saag-star-00.txt
>> has been successfully submitted by Yoav Nir and posted to the
>> IETF repository.
>>=20
>> Name:		draft-nir-saag-star
>> Revision:	00
>> Title:		Considerations For Using Short Term Certificates
>> Document date:	2017-10-14
>> Group:		Individual Submission
>> Pages:		14
>> URL:            =
https://www.ietf.org/internet-drafts/draft-nir-saag-star-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-nir-saag-star/
>> Htmlized:       https://tools.ietf.org/html/draft-nir-saag-star-00
>> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-nir-saag-star-00
>>=20
>>=20
>> Abstract:
>>  Recently there has been renewed interest in an old idea: Issue
>>  certificates with short validity periods and forego revocation
>>  processing, reasoning that expiration is a sufficient replacement =
for
>>  revocation as long as that expiration is not too far off.
>>=20
>>  This document covers considerations, both security and operational,
>>  for using such Short Term Auto Renewed (STAR) certificates for
>>  various scenarios where Using a revocation protocol is considered
>>  inappropriate.
>>=20
>>=20
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> The IETF Secretariat
>>=20
>=20
>=20
>=20


--Apple-Mail=_5849D3F9-253F-4BB5-AD3C-0A9327C7CAF4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlnuPHAACgkQuEkLFQpY
zJk4RQgAyfDe5aG8r2LZL/BBr40fZzvR0FljyWlOe5blVqhH0SY1w4h+/oi1qmp/
nW0nGnMx64YMHeTl9Zq+f4ml4aos1bCfcvC6Ey+nvHVGOLwobDjpCmCLS0hqqMnE
2FyulTrgb9jKwqnugWIR+31HLuWC4E1qykAySq6Gow4PrHCuXK7nZm3/vrvkDKAA
SQ2o9u1641yT6FL3NPeJTtjrVH3mirDiUj7zSrQT/NuYWsKr6YqcEQfANgoAO0fW
9bRtSM00vfdhHMVwEEdrCWRhY3ivGBqEaCUv4TDNihADDBE+6thP6E0WQ5u28T2+
ifbzWt+B8GI0wAB0DONjZWqVKXfRvw==
=QPvl
-----END PGP SIGNATURE-----

--Apple-Mail=_5849D3F9-253F-4BB5-AD3C-0A9327C7CAF4--


From nobody Mon Oct 23 13:54:41 2017
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 4CAAF13A296 for ; Mon, 23 Oct 2017 13:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.056
X-Spam-Level: *
X-Spam-Status: No, score=1.056 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 7B33rHmeonSw for ; Mon, 23 Oct 2017 13:54:38 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id D0F7813A273 for ; Mon, 23 Oct 2017 13:54:37 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id A83463740FCA for ; Mon, 23 Oct 2017 20:54:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qmyy4WfEUVp3 for ; Mon, 23 Oct 2017 16:54:30 -0400 (EDT)
Received: from maxs-mbp.cablelabs.com (host221-111.cablelabs.com [192.160.73.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 75A863740E7A for ; Mon, 23 Oct 2017 16:54:30 -0400 (EDT)
To: "saag@ietf.org" 
From: "Dr. Pala" 
Organization: OpenCA Labs
Message-ID: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org>
Date: Mon, 23 Oct 2017 14:54:29 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000702010206080005040205"
Archived-At: 
Subject: [saag] Proposal for OCSP over DNS
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Oct 2017 20:54:40 -0000

This is a cryptographically signed message in MIME format.

--------------ms000702010206080005040205
Content-Type: multipart/alternative;
 boundary="------------E781460F1B0CC2B2C045A501"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------E781460F1B0CC2B2C045A501
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi all,

we are currently working on specifying how to use DNS as a transport=20
protocol for revocation information for X509 certificates. In=20
particular, we are working on how to leverage the distributed nature of=20
DNS to efficiently (and at lower operational costs) distribute OCSP=20
responses to applications/devices/etc.

We started this work sometime ago but never really had the time to=20
finish it. Now it seems we can focus more on the topic and would like to =

discuss this work in a more public venue.

We currently have two similar I-D submitted (that should probably be=20
re-edited and merged):

  * https://datatracker.ietf.org/doc/draft-pala-odin/
  * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/

EKR suggested that this may be another topic for the SEC-DISPATCH=20
meeting. Can we have 5-10 minutes for this @IETF100 ?

Cheers,
Max

--=20
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

--------------E781460F1B0CC2B2C045A501
Content-Type: multipart/related;
 boundary="------------581F37EECF7DE973AD0F9148"


--------------581F37EECF7DE973AD0F9148
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
Hi all,

    
we are currently working on specifying how to use DNS as a
      transport protocol for revocation information for X509
      certificates. In particular, we are working on how to leverage the
      distributed nature of DNS to efficiently (and at lower operational
      costs) distribute OCSP responses to applications/devices/etc. 

    

    
We started this work sometime ago but never really had the time
      to finish it. Now it seems we can focus more on the topic and
      would like to discuss this work in a more public venue.

    
We currently have two similar I-D submitted (that should probably
      be re-edited and merged):

    
    
EKR suggested that this may be another topic for the SEC-DISPATCH
      meeting. Can we have 5-10 minutes for this @IETF100 ?

    

    
Cheers,

      Max

    

    
-- 

      

        Best Regards,
        

          Massimiliano Pala, Ph.D.

          OpenCA Labs Director

        

        3D"OpenCA

      

    

  


--------------581F37EECF7DE973AD0F9148
Content-Type: image/png;
 name="lpmpliemokppgomm.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="lpmpliemokppgomm.png"

iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX
BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq
MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1
SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27
PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae
VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV
WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq
aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv
cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7
gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl
eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5
giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e
o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw
tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc
zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y
ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF
sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g
EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp
lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE
y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U
jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/
85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf
70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc
AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N
puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq
1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO
cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM
9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb
juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9
wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX
3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme
gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco
9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy
Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C
Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf
b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f
fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu
BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW
hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d
Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R
grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH
dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu
aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm
GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC
BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY
IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q
KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv
JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh
mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/
JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM
VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC
N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl
gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv
Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3
+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT
Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59
qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd
XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a
8XoAAAAASUVORK5CYII=
--------------581F37EECF7DE973AD0F9148--

--------------E781460F1B0CC2B2C045A501--

--------------ms000702010206080005040205
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
CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq
hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV
BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ
ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF
CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi
wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV
afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT
zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt
MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1
PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM
KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv
Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI
QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF
BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T
SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF
BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl
bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL
O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4
A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+
NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa
DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck
RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC
AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEw
MjMyMDU0MjlaMC8GCSqGSIb3DQEJBDEiBCBuOFQBZ6kCVO8iTAWyiVHE4EysVOJL5v2Zb4Fa
ymOjvzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3
DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD
QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp
b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ
EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAH5kMjxPVKf3lE27
Q2Ege1TK6Noj0np7up+WNneJ9Wwp7hUOBYEUrA6Dc2mSLXJnaxbJzDvQw1G4vpqhOT7leFTE
P8P6QWV6zowAaTge2iWrfnvzXwVeSMDuh6iWIOoXVhWtGgrZofq40RSpZ8l25BVt7Rmb00g9
WHCpiuEv8Cel+iwH06TVzn1pwwS/Me22WsJvI8goA/XoArV1R56+8rZfZlcMzr+1oypkg1/6
eVVQPBiIs8xSuMfZ3P6MY4yUty2Mvl9S0KgbFh8g0a5qddUPGqURCyjYaMJjsN3VwLmZvYzC
pnWU6r/2SDF9WIB0dm+ymfa0hi50wWsTmLThNF0AAAAAAAA=
--------------ms000702010206080005040205--


From nobody Mon Oct 23 14:13:57 2017
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 5090C13A2B8 for ; Mon, 23 Oct 2017 14:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih9h9xdYiugb for ; Mon, 23 Oct 2017 14:13:55 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 485131394F8 for ; Mon, 23 Oct 2017 14:13:55 -0700 (PDT)
Received: from [169.254.132.122] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9NLCVG8073173 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Oct 2017 14:12:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.132.122]
From: "Paul Hoffman" 
To: "Dr. Pala" 
Cc: "saag@ietf.org" 
Date: Mon, 23 Oct 2017 14:13:51 -0700
Message-ID: <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org>
In-Reply-To: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org>
References: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.7r5425)
Archived-At: 
Subject: Re: [saag] Proposal for OCSP over DNS
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Oct 2017 21:13:56 -0000

On 23 Oct 2017, at 13:54, Dr. Pala wrote:

> we are currently working on specifying how to use DNS as a transport 
> protocol for revocation information for X509 certificates. In 
> particular, we are working on how to leverage the distributed nature 
> of DNS to efficiently (and at lower operational costs) distribute OCSP 
> responses to applications/devices/etc.
>
> We started this work sometime ago but never really had the time to 
> finish it. Now it seems we can focus more on the topic and would like 
> to discuss this work in a more public venue.
>
> We currently have two similar I-D submitted (that should probably be 
> re-edited and merged):
>
>  * https://datatracker.ietf.org/doc/draft-pala-odin/
>  * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/
>
> EKR suggested that this may be another topic for the SEC-DISPATCH 
> meeting. Can we have 5-10 minutes for this @IETF100 ?

These sound like "we want HTTP over UDP to save latency, so we'll just 
substitute DNS". That's certainly an option, but it hasn't been a 
popular route in the IETF. Are the busy CAs asking for this? Is there a 
reason why they can't just beef up their web infrastructure (like their 
customers are)?

--Paul Hoffman


From nobody Mon Oct 23 14:38:55 2017
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 3108B139605 for ; Mon, 23 Oct 2017 14:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZd9XJpeYe-H for ; Mon, 23 Oct 2017 14:38:51 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 3B507138351 for ; Mon, 23 Oct 2017 14:38:51 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 02FDC3740FCB; Mon, 23 Oct 2017 21:38:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ePBeAgBvTnIa; Mon, 23 Oct 2017 17:38:43 -0400 (EDT)
Received: from maxs-mbp.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id AFB843740E7A; Mon, 23 Oct 2017 17:38:43 -0400 (EDT)
To: Paul Hoffman 
Cc: "saag@ietf.org" 
References: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org> <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org>
From: "Dr. Pala" 
Organization: OpenCA Labs
Message-ID: <58937108-5f04-5be8-bfe8-948dd4ea13dc@openca.org>
Date: Mon, 23 Oct 2017 15:38:43 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040704050304010504020308"
Archived-At: 
Subject: Re: [saag] Proposal for OCSP over DNS
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Oct 2017 21:38:53 -0000

This is a cryptographically signed message in MIME format.

--------------ms040704050304010504020308
Content-Type: multipart/alternative;
 boundary="------------A1078D5FD3F6C61929858BA6"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------A1078D5FD3F6C61929858BA6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Paul, all,

the way I personally see this is not only related to Internet CAs /=20
website-oriented TLS, but also as a way to distribute the revocation=20
information in environments where entities (devices, software, etc.)=20
might be restricted from accessing the global Internet but still allowed =

to query the DNS. Entities leveraging specific trust environments (e.g., =

OCF, CMI, etc. ) might especially benefit from this additional=20
distribution mechanism (which is not in competition with existing=20
solutions :D)

Beefing up CAs web infrastructures is what CAs have been doing so far -=20
AFAIK, however that comes at high operational costs that have to be=20
covered somehow :D I think that it will be useful to have an alternative =

that can be as efficient (if not even more efficient), distributed (info =

get closer to the client), and that comes at (potentially) lower=20
operational costs.

Just my 2 cents...

Cheers,
Max


On 10/23/17 3:13 PM, Paul Hoffman wrote:
> On 23 Oct 2017, at 13:54, Dr. Pala wrote:
>
>> we are currently working on specifying how to use DNS as a transport=20
>> protocol for revocation information for X509 certificates. In=20
>> particular, we are working on how to leverage the distributed nature=20
>> of DNS to efficiently (and at lower operational costs) distribute=20
>> OCSP responses to applications/devices/etc.
>>
>> We started this work sometime ago but never really had the time to=20
>> finish it. Now it seems we can focus more on the topic and would like =

>> to discuss this work in a more public venue.
>>
>> We currently have two similar I-D submitted (that should probably be=20
>> re-edited and merged):
>>
>> =C2=A0* https://datatracker.ietf.org/doc/draft-pala-odin/
>> =C2=A0* https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/=

>>
>> EKR suggested that this may be another topic for the SEC-DISPATCH=20
>> meeting. Can we have 5-10 minutes for this @IETF100 ?
>
> These sound like "we want HTTP over UDP to save latency, so we'll just =

> substitute DNS". That's certainly an option, but it hasn't been a=20
> popular route in the IETF. Are the busy CAs asking for this? Is there=20
> a reason why they can't just beef up their web infrastructure (like=20
> their customers are)?
>
> --Paul Hoffman

--=20
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

--------------A1078D5FD3F6C61929858BA6
Content-Type: multipart/related;
 boundary="------------CA25C0C453F340B94F9100B3"


--------------CA25C0C453F340B94F9100B3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Paul, all,

    

    
the way I personally see this is not only related to Internet CAs
      / website-oriented TLS, but also as a way to distribute the
      revocation information in environments where entities (devices,
      software, etc.) might be restricted from accessing the global
      Internet but still allowed to query the DNS. Entities leveraging
      specific trust environments (e.g., OCF, CMI, etc. ) might
      especially benefit from this additional distribution mechanism
      (which is not in competition with existing solutions :D)

    

    
Beefing up CAs web infrastructures is what CAs have been doing so
      far - AFAIK, however that comes at high operational costs that
      have to be covered somehow :D I think that it will be useful to
      have an alternative that can be as efficient (if not even more
      efficient), distributed (info get closer to the client), and that
      comes at (potentially) lower operational costs.

    
Just my 2 cents...

    
Cheers,

      Max

    

    

    
On 10/23/17 3:13 PM, Paul Hoffman
      wrote:

    

    
On 23 Oc=
t
      2017, at 13:54, Dr. Pala wrote:
      

      

      
we are currently working on specifying ho=
w
        to use DNS as a transport protocol for revocation information
        for X509 certificates. In particular, we are working on how to
        leverage the distributed nature of DNS to efficiently (and at
        lower operational costs) distribute OCSP responses to
        applications/devices/etc.
        

        

        We started this work sometime ago but never really had the time
        to finish it. Now it seems we can focus more on the topic and
        would like to discuss this work in a more public venue.
        

        

        We currently have two similar I-D submitted (that should
        probably be re-edited and merged):
        

        

        =C2=A0* https://datatracker.ietf.org/doc/dra=
ft-pala-odin/
        

        =C2=A0*
        https://datatracker.ietf.org/do=
c/draft-pala-rea-ocsp-over-dns/
        

        

        EKR suggested that this may be another topic for the
        SEC-DISPATCH meeting. Can we have 5-10 minutes for this @IETF100
        ?
        

      

      

      These sound like "we want HTTP over UDP to save latency, so we'll
      just substitute DNS". That's certainly an option, but it hasn't
      been a popular route in the IETF. Are the busy CAs asking for
      this? Is there a reason why they can't just beef up their web
      infrastructure (like their customers are)?
      

      

      --Paul Hoffman
      

    

    

    
-- 

      

        Best Regards,
        

          Massimiliano Pala, Ph.D.

          OpenCA Labs Director

        

        3D"OpenCA

      

    

  


--------------CA25C0C453F340B94F9100B3
Content-Type: image/png;
 name="ddffjiojeijcccop.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="ddffjiojeijcccop.png"

iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX
BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq
MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1
SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27
PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae
VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV
WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq
aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv
cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7
gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl
eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5
giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e
o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw
tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc
zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y
ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF
sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g
EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp
lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE
y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U
jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/
85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf
70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc
AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N
puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq
1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO
cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM
9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb
juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9
wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX
3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme
gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco
9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy
Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C
Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf
b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f
fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu
BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW
hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d
Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R
grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH
dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu
aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm
GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC
BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY
IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q
KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv
JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh
mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/
JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM
VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC
N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl
gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv
Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3
+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT
Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59
qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd
XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a
8XoAAAAASUVORK5CYII=
--------------CA25C0C453F340B94F9100B3--

--------------A1078D5FD3F6C61929858BA6--

--------------ms040704050304010504020308
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
CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq
hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV
BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ
ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF
CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi
wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV
afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT
zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt
MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1
PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr
BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM
KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv
Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI
QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF
BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T
SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF
BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl
bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL
O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4
A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+
NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa
DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck
RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC
AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEw
MjMyMTM4NDNaMC8GCSqGSIb3DQEJBDEiBCCvkyQ1e/agdWFVdYP4os4TDHrxYRnpuijt+kKm
erkN5DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3
DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD
QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp
b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ
EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAJxPpthDTThWCneu
0+b8re8N0QpmXDNi6/GFVdJsjAd3gC0HjWWna9zact8NauUm2LrX26rdRdlsOB5DO2GxUkFx
fYGlkwd/xw+NACIgOccPWIChpOU0dVO262EusCejy0NfK/cQQPfBvT0DRpqor0uIQ43mifRm
6bY/beGMT+vdZ2rW6HRo1B39vaeNFNihWXIytrJpDWSMd0COP09CdzWa77BnkhHDSh7fE0L0
7fVmtPQbpGG2a5HNkOyQsAWSgtU+dMTQgjMMHrQxNVXkVmTw7X8rILBH/2ZYzTJ1QsGrjAAK
XlaYPi6xaY5BJD13Is0cg4TXo+U4+2Ehwl3iTFQAAAAAAAA=
--------------ms040704050304010504020308--


From nobody Thu Oct 26 06:03:27 2017
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 5297E13F588; Thu, 26 Oct 2017 06:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET-kS_4g7D3v; Thu, 26 Oct 2017 06:03:13 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5710A13F58C; Thu, 26 Oct 2017 06:03:13 -0700 (PDT)
X-AuditID: c1b4fb25-1b7d19c000000c94-83-59f1dd0fd0c1
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8E.E3.03220.F0DD1F95; Thu, 26 Oct 2017 15:03:11 +0200 (CEST)
Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.352.0; Thu, 26 Oct 2017 15:02:49 +0200
Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1])	by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 7E9CB4EDA2;	Thu, 26 Oct 2017 16:04:50 +0300 (EEST)
Received: from [127.0.0.1] (localhost [127.0.0.1])	by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 1A5724E689;	Thu, 26 Oct 2017 16:04:50 +0300 (EEST)
To: "saag@ietf.org" , 
From: Mohit Sethi 
Message-ID: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>
Date: Thu, 26 Oct 2017 16:02:48 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM2K7ky7/3Y+RBveey1mcW3mcxWJKfyeT A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy7sxrZC+4z16xeo1TA+MGti5GTg4JAROJCxv2s3cx cnEICRxhlDh7YCeUs4NRov/HRiYIZxOjxPpNKxkhnIWMEj97pwL1c3CIAPW/WJMIMopNQE+i 89xxZhBbWMBSYsfK+WA2r4C9xMRpTawgNouAqsS3iXvAVosKREg8b37PClEjKHFy5hMWEJtZ wEJi5vzzjBC2vMT2t3OYIWxxiVtP5jNBnK0mcfXcJrC4kIC6xNaOA4wTGAVnIRk1C8moWUhG zUIyagEjyypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwPA9uOW36g7Gy28cDzEKcDAq8fDa n/8YKcSaWFZcmXuIUYKDWUmE1+oaUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6Ykl qdmpqQWpRTBZJg5OqQbGAm+WrB0bOhxn10tIeEgKqnyQj10SZVQ0Z8+GgzZ/dLifHrkzMSjr jHXLI1XLNoP3nU6rZB2Wuj/aX+G+Njd8+86Kh+lJJ/q43z91jPptr/DXMHduKsvWLCP1xJM9 /hFpuit6gxRnzXl7YfamTzp35t7dZPh9k3uPaVru0chr4dtEpiYUP7ysxFKckWioxVxUnAgA e6DILFsCAAA=
Archived-At: 
Subject: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Oct 2017 13:03:15 -0000

Dear all,

We have started a mailing list for discussing new EAP related work that 
currently has no obvious home. The mailing list is called REAP (Renew 
EAP) reap@ietf.org and you can subscribe here:
https://www.ietf.org/mailman/listinfo/reap

Recently several new EAP methods have been proposed. These include for 
example:

EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00

EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02

EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00

The list serves as a venue for discussion of these and other EAP related 
drafts that will be submitted in the near future. As courtesy, we will 
post any new draft to SAAG, but we plan to continue the discussion only 
on the REAP mailing list. We have also asked for a short presentation 
slot during SECDISPATCH at IETF 100 in Singapore.

Comments, early feedback, and discussion on existing or new work is more 
than welcome.

--Mohit


From nobody Thu Oct 26 08:52:25 2017
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 354AD13F56B; Thu, 26 Oct 2017 08:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZE3N-7BYtsD; Thu, 26 Oct 2017 08:52:17 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 6A25013F551; Thu, 26 Oct 2017 08:52:16 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id t184so2432535vka.6; Thu, 26 Oct 2017 08:52:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pNtIUAui3gGKuj7B0WykiVtgNLObTea6aex25gyN+Hg=; b=bMLEiSmOAxe4gC3btWCDQODHqyL2qWXHVw9r6pR9kAjtbFXK+MR100B4AYkeBT/6y6 wbP7EOet7MqhkAis0LO3An1yx0Z5VFI4resUXmQlHwPS9newhuqbGUqnuKwsNANmXgFT XNv17fr/Xe9hOW59vjm5Rb9JDil46255V9fgAxzijjuZROLJqqxI76z+zZ4M8Yl1DPmh Wz4lsIEaaiuKZR4CNYDEAwlWEud+IXBnbNx93mrdgiPINaUVp66Yt5PtZek0ZV25tz+Y caCCMv2aDSWo2ZkmaUesHIfkTMUIEPLRhATYpCkHQcgZf0g32NVJwS1pz0BwZO1u2ErK aqLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pNtIUAui3gGKuj7B0WykiVtgNLObTea6aex25gyN+Hg=; b=QqiDQez5AQbMjqtmPCkWUAAEGMmtXIjHJ5D6XGcw+6eiWnoahotGrYsdSA0n3dEyjV 76DpgbWZpOVqewRuVcow41yRd3yh54a5LdIITCSFvDUMpzeUD8Vq2UHVFFvPkULX0UxI Si1SMHzctk70subJjXFqBLYHqa/FiqYb8MTFv2/9u6rOixZjdRsRk/+DuDaYmOHpsp5m T+4oXkTcrZJJkbyYqipXCnWxZQw/1MClE/ZGbSbCWz6YBxabOTKVXNtQMeTakP1rG/3o 1YM9GilueMaHz2Ac97Gy1vGD4gDG2z7GwIQRXtEZ78/N+qYa8S1A95Qb3Zea4jklWLAA vY9g==
X-Gm-Message-State: AMCzsaVbhfVDQOTLwtXb7TIrUJOO3ag+uQOmHtTPaU+qXFknqnyon1Lu ILImHKCjS7xYZOlBy3nOuO8odVPaDu5lgkwDeN71yQ==
X-Google-Smtp-Source: ABhQp+ReN6iujY0r23bTkgeiOz8V/fjpET8moe3Putesa2G1sMc5FC1IeWnPNGBrY4na7+qZzRtaQ3qjOPGbc+EmTNI=
X-Received: by 10.31.63.144 with SMTP id m138mr3933349vka.5.1509033135305; Thu, 26 Oct 2017 08:52:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Thu, 26 Oct 2017 08:51:54 -0700 (PDT)
In-Reply-To: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>
From: Bernard Aboba 
Date: Thu, 26 Oct 2017 08:51:54 -0700
Message-ID: 
To: Mohit Sethi 
Cc: "saag@ietf.org" , reap@ietf.org
Content-Type: multipart/alternative; boundary="001a114dbff4fbfaf3055c752792"
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Oct 2017 15:52:19 -0000

--001a114dbff4fbfaf3055c752792
Content-Type: text/plain; charset="UTF-8"

There are existing functioning IETF mailing lists relating to EAP.

Why are you starting yet another one?

>From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5216
(with no acknowledgement to the original authors) stating that EAP-TLS
implementations must support TLS 1.3.

This is ridiculous because there are 1+ Billion existing implementations
out there that


On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi 
wrote:

> Dear all,
>
> We have started a mailing list for discussing new EAP related work that
> currently has no obvious home. The mailing list is called REAP (Renew EAP)
> reap@ietf.org and you can subscribe here:
> https://www.ietf.org/mailman/listinfo/reap
>
> Recently several new EAP methods have been proposed. These include for
> example:
>
> EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>
> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>
> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>
> The list serves as a venue for discussion of these and other EAP related
> drafts that will be submitted in the near future. As courtesy, we will post
> any new draft to SAAG, but we plan to continue the discussion only on the
> REAP mailing list. We have also asked for a short presentation slot during
> SECDISPATCH at IETF 100 in Singapore.
>
> Comments, early feedback, and discussion on existing or new work is more
> than welcome.
>
> --Mohit
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>

--001a114dbff4fbfaf3055c752792
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


There are existing functioning IETF mailing lists relating=
 to EAP.=C2=A0

Why are you starting yet another one?=C2=
=A0

From what I can tell, the EAP-TLS 1.3 draft is=
 merely a copy of RFC 5216 (with no acknowledgement to the original authors=
) stating that EAP-TLS implementations must support TLS 1.3.=C2=A0

This is ridiculous because there are 1+ Billion existing i=
mplementations out there that=C2=A0


On Thu, Oct 26, 2017 at 6:02 A=
M, Mohit Sethi <mohit.m.sethi@ericsson.com> wrote:<=
br>
Dear all,



We have started a mailing list for discussing new EAP related work that cur=
rently has no obvious home. The mailing list is called REAP (Renew EAP) reap@ietf.org and you c=
an subscribe here:

https://www.ietf.org/mailman/listinfo/reap



Recently several new EAP methods have been proposed. These include for exam=
ple:



EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00



EAP-NOOB: https://tools.ietf.org/html/draft-a=
ura-eap-noob-02



EAP-SASL: https://tools.ietf.org/html/draf=
t-vanrein-eap-sasl-00



The list serves as a venue for discussion of these and other EAP related dr=
afts that will be submitted in the near future. As courtesy, we will post a=
ny new draft to SAAG, but we plan to continue the discussion only on the RE=
AP mailing list. We have also asked for a short presentation slot during SE=
CDISPATCH at IETF 100 in Singapore.



Comments, early feedback, and discussion on existing or new work is more th=
an welcome.



--Mohit



_______________________________________________

saag mailing list

saag@ietf.org

https://www.ietf.org/mailman/listinfo/saag





--001a114dbff4fbfaf3055c752792--


From nobody Thu Oct 26 10:16:33 2017
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 80CC013F3B8; Thu, 26 Oct 2017 10:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZc1cVyqkwWC; Thu, 26 Oct 2017 10:16:30 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E12139059; Thu, 26 Oct 2017 10:16:29 -0700 (PDT)
X-AuditID: c1b4fb2d-bf5ff7000000268d-55-59f2186b35f5
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.7A.09869.B6812F95; Thu, 26 Oct 2017 19:16:28 +0200 (CEST)
Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.352.0; Thu, 26 Oct 2017 19:16:27 +0200
Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1])	by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 005744EDA2;	Thu, 26 Oct 2017 20:18:28 +0300 (EEST)
Received: from [127.0.0.1] (localhost [127.0.0.1])	by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 1901D4E689;	Thu, 26 Oct 2017 20:18:27 +0300 (EEST)
To: Bernard Aboba , Mohit Sethi 
CC: , "saag@ietf.org" 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> 
From: Mohit Sethi 
Message-ID: <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>
Date: Thu, 26 Oct 2017 20:16:25 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------058350CA33B59DC857667733"
Content-Language: en-US
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2J7iG6OxKdIg6lvWC027PvPbHFu5XEW iyn9nUwOzB47Z91l91iy5CdTAFMUl01Kak5mWWqRvl0CV8aBLXPZCma4VUzZspq9gfGjSRcj J4eEgInE+q5PLF2MXBxCAkcYJY7t/8gM4exglFi1YiMTSJWQwCZGiUdPuSESCxkl5q2fAZYQ FnCReP+xnR3EFhEIl9h65AUjiM0MNLbp0y12iIY2Rokth2eCFbEJ6El0njvODGLzCthLLP5x H2wQi4CqxOUTS8DiogIREs+b37NC1AhKnJz5hAXE5hQIlDj/pgtqQZjE8i+9ULa4xK0n85kg /lGTuHpuEzPE1eoSWzsOME5gFJ6FZNQsJO2zkLRD2BYSM+efh4rLS2x/O4cZwtaQaJ0zlx0m 3rx1NvMCRvZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIHxdHDLb90djKtfOx5iFOBgVOLh vcr5KVKINbGsuDL3EKMEB7OSCG+UMFCINyWxsiq1KD++qDQntfgQozQHi5I4r8O+CxFCAumJ JanZqakFqUUwWSYOTqkGRq7S/Wp+c+2fbXozebv+Up11vz/lK+w7tfhhXLLf3rLbjuyV0lpp +9/ukfp/3cDcfVVq7oSP9rdO7mq7LJQi33hHOrR8etquyBNzuBc6Pa279YNbzGpn77KFRt/P JcTm2h3TjDFpnmplZV59OdZOn6nHK3i+kvKCHO16OcfJIlsaeqbvXNw7SYmlOCPRUIu5qDgR AN+mNN+jAgAA
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Oct 2017 17:16:32 -0000

--------------058350CA33B59DC857667733
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Bernard,

The EAP-TLS 1.3 document is a very rough drafty version that was 
submitted before the cut-off for the last IETF. As you rightly point 
out, it has the skeleton and a lot of material from RFC5216, and still 
many important details are missing.

The purpose of this list is to exactly receive these kind of comments. 
Should RFC5216 be updated or obsoleted by this draft. And it would be 
great if we can have your contributions to the document. We will 
definitely add an acknowledgement section and contact the authors of 
RFC5216 to see if they can contribute and comment. We plan to have more 
EAP related contributions in the near future. We discussed this with the 
Security ADs and thought that a separate list would be appropriate to 
get feedback/criticism and contributions from the folks interested.

--Mohit


On 10/26/2017 06:51 PM, Bernard Aboba wrote:
> There are existing functioning IETF mailing lists relating to EAP.
>
> Why are you starting yet another one?
>
> From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 
> 5216 (with no acknowledgement to the original authors) stating that 
> EAP-TLS implementations must support TLS 1.3.
>
> This is ridiculous because there are 1+ Billion existing 
> implementations out there that
>
>
> On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi 
> > wrote:
>
>     Dear all,
>
>     We have started a mailing list for discussing new EAP related work
>     that currently has no obvious home. The mailing list is called
>     REAP (Renew EAP) reap@ietf.org  and you can
>     subscribe here:
>     https://www.ietf.org/mailman/listinfo/reap
>     
>
>     Recently several new EAP methods have been proposed. These include
>     for example:
>
>     EAP-TLS 1.3:
>     https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>     
>
>     EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>     
>
>     EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>     
>
>     The list serves as a venue for discussion of these and other EAP
>     related drafts that will be submitted in the near future. As
>     courtesy, we will post any new draft to SAAG, but we plan to
>     continue the discussion only on the REAP mailing list. We have
>     also asked for a short presentation slot during SECDISPATCH at
>     IETF 100 in Singapore.
>
>     Comments, early feedback, and discussion on existing or new work
>     is more than welcome.
>
>     --Mohit
>
>     _______________________________________________
>     saag mailing list
>     saag@ietf.org 
>     https://www.ietf.org/mailman/listinfo/saag
>     
>
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag


--------------058350CA33B59DC857667733
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Bernard,

    
The EAP-TLS 1.3 document is a very rough drafty version that was
      submitted before the cut-off for the last IETF. As you rightly
      point out, it has the skeleton and a lot of material from RFC5216,
      and still many important details are missing.

    
 The purpose of this list is to exactly receive these kind of
      comments. Should RFC5216 be updated or obsoleted by this draft.
      And it would be great if we can have your contributions to the
      document. We will definitely add an acknowledgement section and
      contact the authors of RFC5216 to see if they can contribute and
      comment. We plan to have more EAP related contributions in the
      near future. We discussed this with the Security ADs and thought
      that a separate list would be appropriate to get
      feedback/criticism and contributions from the folks interested.

    

    
--Mohit

    

    

    
On 10/26/2017 06:51 PM, Bernard Aboba
      wrote:

    

    

      
There are existing functioning IETF mailing lists
        relating to EAP. 
        


        

        
Why are you starting yet another one? 

        


        

        
From what I can tell, the EAP-TLS 1.3 draft is merely a
          copy of RFC 5216 (with no acknowledgement to the original
          authors) stating that EAP-TLS implementations must support TLS
          1.3. 

        


        

        
This is ridiculous because there are 1+ Billion existing
          implementations out there that 

        


        

      

      


        
On Thu, Oct 26, 2017 at 6:02 AM, Mohit
          Sethi <mohit.m.sethi@ericsson.com>
          wrote:

          
Dear all,

            

            We have started a mailing list for discussing new EAP
            related work that currently has no obvious home. The mailing
            list is called REAP (Renew EAP) reap@ietf.org and you can
            subscribe here:

            https://www.ietf.org/mailman/listinfo/reap

            

            Recently several new EAP methods have been proposed. These
            include for example:

            

            EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00

            

            EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02

            

            EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00

            

            The list serves as a venue for discussion of these and other
            EAP related drafts that will be submitted in the near
            future. As courtesy, we will post any new draft to SAAG, but
            we plan to continue the discussion only on the REAP mailing
            list. We have also asked for a short presentation slot
            during SECDISPATCH at IETF 100 in Singapore.

            

            Comments, early feedback, and discussion on existing or new
            work is more than welcome.

            

            --Mohit

            

            _______________________________________________

            saag mailing list

            saag@ietf.org

            https://www.ietf.org/mailman/listinfo/saag

          

        

        

      

      

      

      

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


    

    

  


--------------058350CA33B59DC857667733--


From nobody Thu Oct 26 10:55:43 2017
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 4F39913F5D2; Thu, 26 Oct 2017 10:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nROSNQDHf1Ck; Thu, 26 Oct 2017 10:55:29 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D0A13F5D0; Thu, 26 Oct 2017 10:55:29 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id t139so9927863wmt.1; Thu, 26 Oct 2017 10:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1K8iPlcxL+A//uQl0MNTmipU+zQvaXDNDgCIXG0R0KA=; b=RjEDjGZwpOLJTxNd8ZCbGa+ZDrv4M5LDdwmvSYPTcoKTaucl/sMxkmkJR5T3dbc64b 3ft7jZpamdZLHsxcWJmdqhINMVyEfTjpBF7xLn/pdDrFmyyOqHEqtSUuwYw/aCK9/wEv WNGCBBBeq+R49mPn3yoOv0mQO5ntTka2OxtAGGOo1arQwSZPHFdXYfX7ANH/ln2S+8Cy pDS9E5uend7+xcSyrVQF5GNWZGBOouHpet5WeB+GHsH/BO47F3+hXBAU6H17GtFATylj Tv1nhA2THfq5o5MV9/8Takyku96oRFSN03rA7NyO+jd4f+afNpwOxgEE0HHNgmUWYZVj rCOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1K8iPlcxL+A//uQl0MNTmipU+zQvaXDNDgCIXG0R0KA=; b=nFD7KPIFkfsBshOKjzeyZ8oNIHTS3r4wY7Jy0L+sjij4f3NMLz4bBSZAb/OJ97SHSW GeNxNw5pi/1lbYJwNaV0IcAoVp+QKDVY9LcfcTD4IfifsbP2xS/s3gJ7++VYsih+b46+ wzWH8OiPxPYhDpWKzIVJXyDjGVme2+eDM8HyFoLVg0Q5740t1J6lPP8Dwo1oBYreSY7J OpEZ+UIW0TLomkur2DZBfZY6czC03t83z7Y2OTOg1zIQ2iYjcqBFglCLaTXEl9Rc8OlJ oqTz4ldMo5xlkfq65iXPuhYdD4ossi5v5HiYRsfQQFCN/alj4mW6Hh+J0EOL6poA3Q43 BfyA==
X-Gm-Message-State: AMCzsaVsxFAyD7Z3kJKJxzdApwLG57F+svgj9lhJZBU013mJix6wqcbZ aQW0NhQBwermkNnusSEbcpQ=
X-Google-Smtp-Source: ABhQp+QqV+pqMRqTyBIRCn3qMF/Z/7OvJEy6f3MGB1Lb+B60wCafbd9KAcIniuRbUrYEgt6ahVnC1g==
X-Received: by 10.28.72.8 with SMTP id v8mr2045743wma.38.1509040527766; Thu, 26 Oct 2017 10:55:27 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y187sm1093641wmy.13.2017.10.26.10.55.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 10:55:27 -0700 (PDT)
From: Yoav Nir 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_127CC89A-36EE-4E42-8003-FEC308D701E1"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Date: Thu, 26 Oct 2017 20:55:24 +0300
In-Reply-To: 
Cc: Mohit Sethi , reap@ietf.org, Security Area Advisory Group 
To: Bernard Aboba 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Oct 2017 17:55:31 -0000

--Apple-Mail=_127CC89A-36EE-4E42-8003-FEC308D701E1
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E6015445-0E03-4A9A-9B2B-FC004162D1BA"


--Apple-Mail=_E6015445-0E03-4A9A-9B2B-FC004162D1BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 26 Oct 2017, at 18:51, Bernard Aboba  =
wrote:
>=20
> There are existing functioning IETF mailing lists relating to EAP.
>=20
> Why are you starting yet another one?

+1

The EMU mailing list seems appropriate.

Yoav

https://tools.ietf.org/wg/emu/ 
https://www.ietf.org/mail-archive/web/emu/current/maillist.html =



--Apple-Mail=_E6015445-0E03-4A9A-9B2B-FC004162D1BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On 26 Oct 2017, at 18:51, Bernard Aboba <bernard.aboba@gmail.com> wrote:

There are existing functioning IETF mailing lists relating to =
EAP. 

Why are =
you starting yet another =
one? 

+1

The EMU mailing list seems appropriate.

Yoav

https://tools.ietf.org/wg/emu/
https://www.ietf.org/mail-archive/web/emu/current/maillist.html=


=

--Apple-Mail=_E6015445-0E03-4A9A-9B2B-FC004162D1BA--

--Apple-Mail=_127CC89A-36EE-4E42-8003-FEC308D701E1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlnyIYwACgkQuEkLFQpY
zJnZ9wf8CRVZlfrmtkxh5W18fhtw/hRvRdtnK9SZB3MJGWT59YGjyemW0g51RD0P
698wAUVumUmeOxTPkgKTEip7iNqxU0sFmtVjgunTCRYg5ldlc7NrH+ASdfue9Aug
YZC0jfJDwRwWJFOFH4ImB/CxAnLr7JE8xSZWsvB3lnVH9PDFc4kYPj7EjRo11d+D
7fQa9hK6cp0rrMGVctlN1yr7RuQDjQaQnoQ+6D3VuAHYzk5daxNVM1OSTqulDI+T
VVlm/6PDC/FnyflNYEZc0VSLmGRu0CIXmrkbKF5eIhRUb1E9GkXBuTBgHRttW1DB
wF17CZ763/Ff7BpGG1my/5q9/yyNWA==
=3pNP
-----END PGP SIGNATURE-----

--Apple-Mail=_127CC89A-36EE-4E42-8003-FEC308D701E1--


From nobody Thu Oct 26 11:43:55 2017
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 7BEC913942C; Thu, 26 Oct 2017 11:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixgLWC-pgnxv; Thu, 26 Oct 2017 11:43:46 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A3783139553; Thu, 26 Oct 2017 11:43:46 -0700 (PDT)
Received: from [192.168.2.9] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id 19B0A506; Thu, 26 Oct 2017 18:43:44 +0000 (UTC)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Alan DeKok 
X-Priority: 3
In-Reply-To: <20171026144512.519DD12A5FD@relay.mailchannels.net>
Date: Thu, 26 Oct 2017 14:43:43 -0400
Cc: Mohit Sethi , "saag@ietf.org" ,  "reap@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D4AC5B7-4F4E-4E28-B6AC-205824386D10@deployingradius.com>
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <20171026144512.519DD12A5FD@relay.mailchannels.net>
To: David Mitton 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Oct 2017 18:43:48 -0000

> On Oct 26, 2017, at 10:45 AM, David Mitton =
 wrote:
>=20
> I=E2=80=99m sorry, it=E2=80=99s been a while since I paid attention.
> So EMU has been closed, and you didn=E2=80=99t want to recycle the =
acronym?
> It might be useful to review the progress of the methods that came out =
of EMU.

  The main output of EMU was TEAP.  While it may be implemented =
somewhere, I'm now aware of it's existence in any popular OS, or any =
wide-spread use of it.

  Alan DeKok.


From nobody Thu Oct 26 11:54:21 2017
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 0A29713F442; Thu, 26 Oct 2017 11:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqcuwA1g0TPf; Thu, 26 Oct 2017 11:54:17 -0700 (PDT)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA1913942C; Thu, 26 Oct 2017 11:54:17 -0700 (PDT)
Received: by mail-pg0-x229.google.com with SMTP id a192so3391733pge.9; Thu, 26 Oct 2017 11:54:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=13mn0BAYaGa/4VJjztteIkV69s2qxIIZtitzpGcDEuY=; b=CJjj7Yj8wTN7qRe/nV8AV7LYyyuIGOHVVd4zBdekavMfC0Zgf8ZLB+LEFKIE+X6+CC FRmxFNjt2W1C7dkrsueAF3Wx2OJJ4npgn4+t3CNuI7kqOUcfD/8Dim/EfUxtEO2KRxpr MNnRe+WgERJSzzsQ36p5JVtDYrS8Hgw1QdHQNY8LjBElASho3AYw/Qhpofmj9wvDbmpF fjpLVfu8tg5niD5oiaScrBcrAywp30GnMOdSMlJsi7X3onI9UTTii6LX+8HcP4dwY1kn GjiacYoFoE+z3Zb389SYhBQJEi2TMRhW6FgFFuzyhKGSdcr2vLHgpHwxZBVKvZPOV383 jzBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=13mn0BAYaGa/4VJjztteIkV69s2qxIIZtitzpGcDEuY=; b=Vaj0PS0pSpSQdzucbqiV92Ge5ah3WPKxlOEFMCEmOi3Y5pETUcGAsNORwunIEO1rzX XT/UkiSj/yzBVjrAihiLfNIxmZ8FReMDy+EqjXslsvMXM3zn2BjFqI8YZiv5BPOCEHas UN344OVL4bk3McvIc56v7xQbAlkBQzg/uzfAz+elX8USQPPBSEbTH+MBftdbk5cVdHnv 57tspwGAhSO96w63h8A2Djh592lM6BKV4bY9UCx4brM/hqKxv3VBm+DmZGrUW8V2nEqD P+1PDSPPi1Qvv9fli7xUKZySouDETZVWnNvp17FsKSxm3JqfHe1ZiwnUxjPsjN5ja1PC wRyQ==
X-Gm-Message-State: AMCzsaUOCHjalp/IrD/2KHl/SrjLuEB0DH+FLYuxNjIBLyHGwmgSFTox h3iqZVwJcn0J9uSMBrm1otTPcwlx8bTNweuOnIU=
X-Google-Smtp-Source: ABhQp+Sc7EizZrEDR6ttng7dEkdx2CFPlVikI8Svdo2OzKjBbKY3EUVz4x2a7XKEOlnDqwle42xiPysBOoMCAAHNXnc=
X-Received: by 10.98.214.76 with SMTP id r73mr6198747pfg.261.1509044056806; Thu, 26 Oct 2017 11:54:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.194 with HTTP; Thu, 26 Oct 2017 11:53:36 -0700 (PDT)
In-Reply-To: <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>
From: Kathleen Moriarty 
Date: Thu, 26 Oct 2017 14:53:36 -0400
Message-ID: 
To: Mohit Sethi 
Cc: Bernard Aboba , reap@ietf.org, "saag@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Oct 2017 18:54:20 -0000

On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi  wrote:
> Hi Bernard,
>
> The EAP-TLS 1.3 document is a very rough drafty version that was submitted
> before the cut-off for the last IETF. As you rightly point out, it has the
> skeleton and a lot of material from RFC5216, and still many important
> details are missing.
>
> The purpose of this list is to exactly receive these kind of comments.
> Should RFC5216 be updated or obsoleted by this draft. And it would be great
> if we can have your contributions to the document. We will definitely add an
> acknowledgement section and contact the authors of RFC5216 to see if they
> can contribute and comment. We plan to have more EAP related contributions
> in the near future. We discussed this with the Security ADs and thought that
> a separate list would be appropriate to get feedback/criticism and
> contributions from the folks interested.

I'm sorry, I didn't realize that a revision of 5216 was involved and
that the authors were not notified at the onset as is normal practice
in case they want to continue as authors.  Thank you for spotting this
issue Bernard.

Is there an existing list that should be used?  Is there adequate
overlap in objectives and personnel?

Thank you,
Kathleen

>
> --Mohit
>
>
> On 10/26/2017 06:51 PM, Bernard Aboba wrote:
>
> There are existing functioning IETF mailing lists relating to EAP.
>
> Why are you starting yet another one?
>
> From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5216
> (with no acknowledgement to the original authors) stating that EAP-TLS
> implementations must support TLS 1.3.
>
> This is ridiculous because there are 1+ Billion existing implementations out
> there that
>
>
> On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi 
> wrote:
>>
>> Dear all,
>>
>> We have started a mailing list for discussing new EAP related work that
>> currently has no obvious home. The mailing list is called REAP (Renew EAP)
>> reap@ietf.org and you can subscribe here:
>> https://www.ietf.org/mailman/listinfo/reap
>>
>> Recently several new EAP methods have been proposed. These include for
>> example:
>>
>> EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>>
>> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>>
>> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>>
>> The list serves as a venue for discussion of these and other EAP related
>> drafts that will be submitted in the near future. As courtesy, we will post
>> any new draft to SAAG, but we plan to continue the discussion only on the
>> REAP mailing list. We have also asked for a short presentation slot during
>> SECDISPATCH at IETF 100 in Singapore.
>>
>> Comments, early feedback, and discussion on existing or new work is more
>> than welcome.
>>
>> --Mohit
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>



-- 

Best regards,
Kathleen


From nobody Thu Oct 26 12:51:43 2017
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 D80A513899A; Thu, 26 Oct 2017 12:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH-NskncIu2i; Thu, 26 Oct 2017 12:51:35 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81E713836A; Thu, 26 Oct 2017 12:51:34 -0700 (PDT)
X-AuditID: c1b4fb25-debff70000000c94-61-59f23cc42b8a
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 87.54.03220.4CC32F95; Thu, 26 Oct 2017 21:51:33 +0200 (CEST)
Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.352.0; Thu, 26 Oct 2017 21:51:32 +0200
Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1])	by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 54AC44EDA2;	Thu, 26 Oct 2017 22:53:34 +0300 (EEST)
Received: from [127.0.0.1] (localhost [127.0.0.1])	by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id ACDE14E689;	Thu, 26 Oct 2017 22:53:33 +0300 (EEST)
To: Yoav Nir , Bernard Aboba 
CC: , Mohit Sethi , Security Area Advisory Group 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  
From: Mohit Sethi 
Message-ID: <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com>
Date: Thu, 26 Oct 2017 22:51:31 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------EC2C00B0E247F0D0B57097A4"
Content-Language: en-US
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7pe5Rm0+RBg8ncVts2Pef2eLcyuMs FlP6O5kslh77wOTA4rFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZSy9PZW54JpKxfdDh9gb GI/IdDFyckgImEjcXnSbtYuRi0NI4AijxLQLW9khnB2MEm+ffWUFqRIS2MQosekcD0RiIaPE xH8r2UASwgLeEsf/z2EBsUWA7CnN58BsZoFcif5Da6DG7mSUmHVgJTNIgk1AT6Lz3HEwm1fA XuLjgQdgg1gEVCUe9T4Cs0UFIiSeN79nhagRlDg58wnYUE4BW4lli3YyQSwIk3g84SKULS5x 68l8Joh/1CSuntvEDHG1usTWjgOMExiFZyEZNQtJ+ywk7bMYOYBse4kHW8sgwtoSyxa+Zoaw 9SWu37nPCmHLSzRvnc28gJF9FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgXB3c8lt1B+Pl N46HGAU4GJV4eAv1P0UKsSaWFVfmHmKU4GBWEuFlsgQK8aYkVlalFuXHF5XmpBYfYpTmYFES 53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwOgSsKva/p6ndMm+2N1qD67xqX45NvWHx+OEAO45 S5VudBiJvn+8h2P25CQ5vei9RZOvLS/+tP7rupKaN/FbUy7/O+h7ZOlWRqGFepOS39nwdukz Zvmu2Z1p+a7Jcsur4y8d5eecnvPVc+4L4cwbldHtO0smPMjp8n8zb4Yt6xTuv/P4Ph/Rj69R YinOSDTUYi4qTgQAqeN2bacCAAA=
Archived-At: 
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Oct 2017 19:51:37 -0000

--------------EC2C00B0E247F0D0B57097A4
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Yoav,

Thanks for the feedback. This issue about the list had come up a short=20
while back when Rick posted his draft on EAP-SASL to SAAG:=20
https://mailarchive.ietf.org/arch/msg/saag/stEf0BxTPKGEJq-2RDrlKj1rxRc

We thought that it would make sense to have a separate mailing list on=20
all new EAP related work. This would also allow us to gauge the=20
community interest in the new work.

At the end of the day, I believe our objectives are the same: we want to =

work on things that the IETF as a community is interested in, and make=20
sure that the work progresses at an acceptable pace.

--Mohit

On 10/26/2017 08:55 PM, Yoav Nir wrote:
>
>
>> On 26 Oct 2017, at 18:51, Bernard Aboba > > wrote:
>>
>> There are existing functioning IETF mailing lists relating to EAP.
>>
>> Why are you starting yet another one?
>
> +1
>
> The EMU mailing list seems appropriate.
>
> Yoav
>
> https://tools.ietf.org/wg/emu/
> https://www.ietf.org/mail-archive/web/emu/current/maillist.html
>
>
>
> _______________________________________________
> REAP mailing list
> REAP@ietf.org
> https://www.ietf.org/mailman/listinfo/reap


--------------EC2C00B0E247F0D0B57097A4
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Yoav,

    
Thanks for the feedback. This issue about the list had come up a
      short while back when Rick posted his draft on EAP-SASL to SAAG: https://mailarchive.ietf.org/arch/msg/saag/stEf0BxTPKGEJq-2RDrlKj1rxRc

    
We thought that it would make sense to have a separate mailing
      list on all new EAP related work. This would also allow us to
      gauge the community interest in the new work.   

    

    At the end of the day, I believe our objectives are the same: we
    want to work on things that the IETF as a community is interested
    in, and make sure that the work progresses at an acceptable pace.

    

    --Mohit

    

    
On 10/26/2017 08:55 PM, Yoav Nir wrote:

    

    

      
      

      


        

          
On 26 Oct 2017, at 18:51, Bernard Aboba <bernard.aboba@gmail.com>
            wrote:

          

          

            
There are existing functioning IETF
              mailing lists relating to EAP. 
              


              

              
Why are you starting yet another one? 

            

          

        

        


        

      

      +1
      


      

      
The EMU mailing list seems appropriate.

      


      

      
Yoav

      


      

      
      
      


      

      

      

      

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


    

    

  


--------------EC2C00B0E247F0D0B57097A4--


From nobody Thu Oct 26 14:59:18 2017
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 B915413F60D; Thu, 26 Oct 2017 14:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHnptkKB9M5l; Thu, 26 Oct 2017 14:59:14 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6213F46E; Thu, 26 Oct 2017 14:59:14 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 509C43741015; Thu, 26 Oct 2017 21:59:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lzoytQTzIki7; Thu, 26 Oct 2017 17:59:07 -0400 (EDT)
Received: from maxs-mbp.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 04D913740E16; Thu, 26 Oct 2017 17:59:06 -0400 (EDT)
To: saag@ietf.org, LAMPS 
References: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org> <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org> <58937108-5f04-5be8-bfe8-948dd4ea13dc@openca.org>
From: "Dr. Pala" 
Message-ID: 
Date: Thu, 26 Oct 2017 15:59:06 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <58937108-5f04-5be8-bfe8-948dd4ea13dc@openca.org>
Content-Type: multipart/alternative; boundary="------------08F6701D51A17113189BBF61"
Content-Language: en-US
Archived-At: 
Subject: [saag] Draft New Version (was Re:  Proposal for OCSP over DNS)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Oct 2017 21:59:17 -0000

This is a multi-part message in MIME format.
--------------08F6701D51A17113189BBF61
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi all,

I just want to let everybody know that we manage to send in the latest 
version of the draft that better organizes the text and incorporates the 
previous work / I-Ds into one:

    https://datatracker.ietf.org/doc/draft-pala-odin

comments, feedback, etc. always welcome :D

Cheers,
Max


On 10/23/17 3:38 PM, Dr. Pala wrote:
>
> Hi Paul, all,
>
> the way I personally see this is not only related to Internet CAs / 
> website-oriented TLS, but also as a way to distribute the revocation 
> information in environments where entities (devices, software, etc.) 
> might be restricted from accessing the global Internet but still 
> allowed to query the DNS. Entities leveraging specific trust 
> environments (e.g., OCF, CMI, etc. ) might especially benefit from 
> this additional distribution mechanism (which is not in competition 
> with existing solutions :D)
>
> Beefing up CAs web infrastructures is what CAs have been doing so far 
> - AFAIK, however that comes at high operational costs that have to be 
> covered somehow :D I think that it will be useful to have an 
> alternative that can be as efficient (if not even more efficient), 
> distributed (info get closer to the client), and that comes at 
> (potentially) lower operational costs.
>
> Just my 2 cents...
>
> Cheers,
> Max
>
>
> On 10/23/17 3:13 PM, Paul Hoffman wrote:
>> On 23 Oct 2017, at 13:54, Dr. Pala wrote:
>>
>>> we are currently working on specifying how to use DNS as a transport 
>>> protocol for revocation information for X509 certificates. In 
>>> particular, we are working on how to leverage the distributed nature 
>>> of DNS to efficiently (and at lower operational costs) distribute 
>>> OCSP responses to applications/devices/etc.
>>>
>>> We started this work sometime ago but never really had the time to 
>>> finish it. Now it seems we can focus more on the topic and would 
>>> like to discuss this work in a more public venue.
>>>
>>> We currently have two similar I-D submitted (that should probably be 
>>> re-edited and merged):
>>>
>>>  * https://datatracker.ietf.org/doc/draft-pala-odin/
>>>  * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/
>>>
>>> EKR suggested that this may be another topic for the SEC-DISPATCH 
>>> meeting. Can we have 5-10 minutes for this @IETF100 ?
>>
>> These sound like "we want HTTP over UDP to save latency, so we'll 
>> just substitute DNS". That's certainly an option, but it hasn't been 
>> a popular route in the IETF. Are the busy CAs asking for this? Is 
>> there a reason why they can't just beef up their web infrastructure 
>> (like their customers are)?
>>
>> --Paul Hoffman
>
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag


--------------08F6701D51A17113189BBF61
Content-Type: multipart/related;
 boundary="------------7521D1A940D3FDEE1E02516E"


--------------7521D1A940D3FDEE1E02516E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi all,

    
I just want to let everybody know that we manage to send in the
      latest version of the draft that better organizes the text and
      incorporates the previous work / I-Ds into one:

    

      
https://datatracker.ietf.org/doc/draft-pala-odin

    

    
comments, feedback, etc. always welcome :D

    

    
Cheers,

      Max

    

    

    
On 10/23/17 3:38 PM, Dr. Pala wrote:

    

    

      
      
Hi Paul, all,

      

      
the way I personally see this is not only related to Internet
        CAs / website-oriented TLS, but also as a way to distribute the
        revocation information in environments where entities (devices,
        software, etc.) might be restricted from accessing the global
        Internet but still allowed to query the DNS. Entities leveraging
        specific trust environments (e.g., OCF, CMI, etc. ) might
        especially benefit from this additional distribution mechanism
        (which is not in competition with existing solutions :D)

      

      
Beefing up CAs web infrastructures is what CAs have been doing
        so far - AFAIK, however that comes at high operational costs
        that have to be covered somehow :D I think that it will be
        useful to have an alternative that can be as efficient (if not
        even more efficient), distributed (info get closer to the
        client), and that comes at (potentially) lower operational
        costs.

      
Just my 2 cents...

      
Cheers,

        Max

      

      

      
On 10/23/17 3:13 PM, Paul Hoffman
        wrote:

      

      
On 23
        Oct 2017, at 13:54, Dr. Pala wrote: 

        

        
we are currently working on specifying
          how to use DNS as a transport protocol for revocation
          information for X509 certificates. In particular, we are
          working on how to leverage the distributed nature of DNS to
          efficiently (and at lower operational costs) distribute OCSP
          responses to applications/devices/etc. 

          

          We started this work sometime ago but never really had the
          time to finish it. Now it seems we can focus more on the topic
          and would like to discuss this work in a more public venue. 

          

          We currently have two similar I-D submitted (that should
          probably be re-edited and merged): 

          

           * https://datatracker.ietf.org/doc/draft-pala-odin/
          

           * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/
          

          

          EKR suggested that this may be another topic for the
          SEC-DISPATCH meeting. Can we have 5-10 minutes for this
          @IETF100 ? 

        

        

        These sound like "we want HTTP over UDP to save latency, so
        we'll just substitute DNS". That's certainly an option, but it
        hasn't been a popular route in the IETF. Are the busy CAs asking
        for this? Is there a reason why they can't just beef up their
        web infrastructure (like their customers are)? 

        

        --Paul Hoffman 

      

      

      
-- 

        
 Best Regards,
          
 Massimiliano
            Pala, Ph.D.

            OpenCA Labs Director

          

          OpenCA Logo

        

      

      

      

      

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


    

    

  


--------------7521D1A940D3FDEE1E02516E
Content-Type: image/png;
 name="ddffjiojeijcccop.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="ddffjiojeijcccop.png"

iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX
BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq
MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1
SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27
PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae
VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV
WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq
aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv
cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7
gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl
eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5
giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e
o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw
tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc
zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y
ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF
sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g
EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp
lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE
y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U
jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/
85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf
70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc
AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N
puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq
1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO
cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM
9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb
juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9
wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX
3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme
gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco
9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy
Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C
Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf
b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f
fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu
BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW
hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d
Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R
grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH
dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu
aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm
GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC
BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY
IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q
KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv
JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh
mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/
JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM
VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC
N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl
gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv
Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3
+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT
Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59
qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd
XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a
8XoAAAAASUVORK5CYII=
--------------7521D1A940D3FDEE1E02516E--

--------------08F6701D51A17113189BBF61--


From nobody Thu Oct 26 18:03:20 2017
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 2F4FF13F415; Thu, 26 Oct 2017 18:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LflqhgjX0K1x; Thu, 26 Oct 2017 18:03:09 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 23EC613B1A9; Thu, 26 Oct 2017 18:03:09 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id k123so3274508vkb.3; Thu, 26 Oct 2017 18:03:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QIBA5VZZfftWvy6UxNXhmEz4hpMXVzpnXEwl7PqYZ5c=; b=O50qrm3M671nBDu1sWaabCXg9aFDRspomQajOo8NPUjGjW2ydYqYDOM5jfXX9Ji1X4 qbAbDsMRKqNGG3IhOwtgpbKcN5jsXmhon6QOdzGsSykYUuTea4qxDBMqSWEUnS2AduVx SioKHIWMlLPBEZ7HVw5MNAX6vMRGVv9it1OPwtJI5RlyUOjGfihTop3T3q5P7ZjG8Aev 1Qu3PNZQpm7xSnRuR+0WB0C8SCxcRzQCojOus78TyJgvU/UcqsEaDelj/7q9reE5BtSP Gl4ok4Bu08Hj57eHD/QCfOWgG0xgFyBa+k7o9v/yvVfkmXF9UEHzBSNURASTDCnJLYpZ 2FXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QIBA5VZZfftWvy6UxNXhmEz4hpMXVzpnXEwl7PqYZ5c=; b=S2h8NGwhn2nCTzPLjAHKlSTtllk9ObQgIDte8RHphPN+DH5W3+paxkLz0anA589Van 3oHg5vB+LQ6cG9Xt77fYN4c9UOUqwm1LcLVKnrBzWa++rGXufMTqMSfVSTYEFhIdQxd6 q+nNAe8+QojumeMDBc0ztjtr+cu8+/meIOGXlLS+cgMkAkfZ3XLyhKt/7Wor6RXd/HlM lPdz2evUaSR2dzVCAKi4FwA8uD658E/O4cE8I3K+QAvUv4TnKeEsnq1IugVFaJ+K4rAk BKNDXl3S2MTcTlII1NT7VWJmSiLANvWWgrQe9ixqrGb6n/dLlYvSsnHcL4UP2hZuW4AE o4tw==
X-Gm-Message-State: AMCzsaU6PbO6CE9v6phBXaF/SPCUMz9fWJfTqvocU6bTbmLuw84idJVT kgMFYnpTnkwFdjA6IEJ+4QkCVvGZ4Kf1/gwtUjY=
X-Google-Smtp-Source: ABhQp+TmvnaGzP3t5oWz4Ksu/4/FEcOhaPP4OvfQSS2DoEwTuqQajkPoXfdnJ9hXVrX3bugO7I1pHUDavIFy+JqpXug=
X-Received: by 10.31.64.199 with SMTP id n190mr4843573vka.26.1509066187988; Thu, 26 Oct 2017 18:03:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Thu, 26 Oct 2017 18:02:47 -0700 (PDT)
In-Reply-To: <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>
From: Bernard Aboba 
Date: Thu, 26 Oct 2017 18:02:47 -0700
Message-ID: 
To: Mohit Sethi 
Cc: reap@ietf.org, "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1144737813e527055c7cdace"
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Oct 2017 01:03:12 -0000

--001a1144737813e527055c7cdace
Content-Type: text/plain; charset="UTF-8"

I have nothing against TLS 1.3, but it was not necessary to obsolete RFC
5216 to support TLS 1.2 and there are a number of implementations of TLS
1.3 already in progress with no issues as far as I am aware. So I don't
understand why a new document is needed - and the downside is very
substantial.

Given the prevalence of EAP-TLS in open source, there is great concern over
the introduction of encumbrance into a protocol that is widely required in
high security environments.  Were this to happen, it would in effect impose
a "tax" on each of the 2+ billion devices implementing EAP-TLS.

A cursory search of the IETF IPR database indicates that your draft could
potentially encumber EAP-TLS with a vast number of TLS-related IPR
declarations that would not necessarily apply to an RFC 5216
implementation. While there are  many installations that wish to take on
the costs (and benefits) of TLS 1.3 as well as support for additional
ciphersuites, there are also installations that would not be willing to pay
for the costs of a "forklift" upgrade for every device and server,
particularly if they were forced to migrate off of open-source due to IPR
encumbrance.  Such a migration should be up to the organization deploying
EAP-TLS, not imposed by the IETF without extra-ordinary justification (such
as an unpatcheable vulnerability found in previous versions of TLS).

In addition, the introduction of support for new authentication modes such
as PSK was explicitly rejected by for RFC 5216 in EMU because it
complicated the security analysis and would invalidate existing EAP-TLS
security proofs that were considered critical to deployment in the highest
security installations.  When an organization deploys EAP-TLS today they
know what they are getting - a protocol focused on certificate
authentication that does not attempt to be a "swiss army knife".  Such a
protocol isn't for everyone (indeed, only a small fraction of all EAP
deployments use EAP-TLS), but those that mandate its use have very specific
needs.

On Thu, Oct 26, 2017 at 10:16 AM, Mohit Sethi 
wrote:

> Hi Bernard,
>
> The EAP-TLS 1.3 document is a very rough drafty version that was submitted
> before the cut-off for the last IETF. As you rightly point out, it has the
> skeleton and a lot of material from RFC5216, and still many important
> details are missing.
>
> The purpose of this list is to exactly receive these kind of comments.
> Should RFC5216 be updated or obsoleted by this draft. And it would be great
> if we can have your contributions to the document. We will definitely add
> an acknowledgement section and contact the authors of RFC5216 to see if
> they can contribute and comment. We plan to have more EAP related
> contributions in the near future. We discussed this with the Security ADs
> and thought that a separate list would be appropriate to get
> feedback/criticism and contributions from the folks interested.
>
> --Mohit
>
> On 10/26/2017 06:51 PM, Bernard Aboba wrote:
>
> There are existing functioning IETF mailing lists relating to EAP.
>
> Why are you starting yet another one?
>
> From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5216
> (with no acknowledgement to the original authors) stating that EAP-TLS
> implementations must support TLS 1.3.
>
> This is ridiculous because there are 1+ Billion existing implementations
> out there that
>
>
> On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi 
> wrote:
>
>> Dear all,
>>
>> We have started a mailing list for discussing new EAP related work that
>> currently has no obvious home. The mailing list is called REAP (Renew EAP)
>> reap@ietf.org and you can subscribe here:
>> https://www.ietf.org/mailman/listinfo/reap
>>
>> Recently several new EAP methods have been proposed. These include for
>> example:
>>
>> EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>>
>> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>>
>> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>>
>> The list serves as a venue for discussion of these and other EAP related
>> drafts that will be submitted in the near future. As courtesy, we will post
>> any new draft to SAAG, but we plan to continue the discussion only on the
>> REAP mailing list. We have also asked for a short presentation slot during
>> SECDISPATCH at IETF 100 in Singapore.
>>
>> Comments, early feedback, and discussion on existing or new work is more
>> than welcome.
>>
>> --Mohit
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>
>
>
>
> _______________________________________________
> saag mailing listsaag@ietf.orghttps://www.ietf.org/mailman/listinfo/saag
>
>
>

--001a1144737813e527055c7cdace
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have nothing against TLS=
 1.3, but it was not necessary to obsolete RFC 5216 to support TLS 1.2 and =
there are a number of implementations of TLS 1.3 already in progress with n=
o issues as far as I am aware. So I don't understand why a new document=
 is needed - and the downside is very substantial.=C2=A0=C2=A0

Given th=
e prevalence of EAP-TLS in open source, there is great concern over the int=
roduction of encumbrance into a protocol that is widely required in high se=
curity environments.=C2=A0 Were this to happen, it would in effect impose a=
 "tax" on each of the 2+ billion devices implementing EAP-TLS.

A cursory search of the IETF IPR database indicates that your draft could=
 potentially encumber EAP-TLS with a vast number of TLS-related IPR declara=
tions that would not necessarily apply to an RFC 5216 implementation. While=
 there are=C2=A0 many installations that wish to take on the costs (and ben=
efits) of TLS 1.3 as well as support for additional ciphersuites, there are=
 also installations that would not be willing to pay for the costs of a &qu=
ot;forklift" upgrade for every device and server, particularly if they=
 were forced to migrate off of open-source due to IPR encumbrance.=C2=A0 Su=
ch a migration should be up to the organization deploying EAP-TLS, not impo=
sed by the IETF without extra-ordinary justification (such as an unpatcheab=
le vulnerability found in previous versions of TLS).=C2=A0=C2=A0

In add=
ition, the introduction of support for new authentication modes such as PSK=
 was explicitly rejected by for RFC 5216 in EMU because it complicated the security analysis and would invalidate exi=
sting EAP-TLS security proofs that were considered critical to deployment i=
n the highest security installations.=C2=A0 When an organization deploys EA=
P-TLS today they know what they are getting - a protocol focused on certifi=
cate authentication that does not attempt to be a "swiss army knife&qu=
ot;.=C2=A0 Such a protocol isn't for everyone (indeed, only a small fra=
ction of all EAP deployments use EAP-TLS), but those that mandate its use h=
ave very specific needs.=C2=A0

On Thu, Oct 26, 2017 at 10:16 AM, Mohit Set=
hi <mohit.m.sethi@ericsson.com> wrote:

 =20
   =20
 =20
  

    
Hi Bernard,

    
The EAP-TLS 1.3 document is a very rough drafty version that was
      submitted before the cut-off for the last IETF. As you rightly
      point out, it has the skeleton and a lot of material from RFC5216,
      and still many important details are missing.

    
 The purpose of this list is to exactly receive these kind of
      comments. Should RFC5216 be updated or obsoleted by this draft.
      And it would be great if we can have your contributions to the
      document. We will definitely add an acknowledgement section and
      contact the authors of RFC5216 to see if they can contribute and
      comment. We plan to have more EAP related contributions in the
      near future. We discussed this with the Security ADs and thought
      that a separate list would be appropriate to get
      feedback/criticism and contributions from the folks interested.

    

    
--Mohit

    

    

    
On 10/26/2017 06:5=
1 PM, Bernard Aboba
      wrote:

    

    

      
There are existing functioning IETF mailing lists
        relating to EAP.=C2=A0
        


        

        
Why are you starting yet another one?=C2=A0

        


        

        
From what I can tell, the EAP-TLS 1.3 draft is merely a
          copy of RFC 5216 (with no acknowledgement to the original
          authors) stating that EAP-TLS implementations must support TLS
          1.3.=C2=A0

        


        

        
This is ridiculous because there are 1+ Billion existing
          implementations out there that=C2=A0

        


        

      

      


        
On Thu, Oct 26, 2017 at 6:02 AM, Mohit
          Sethi <mohit.m.sethi@ericsson.com>
          wrote:

          
Dear all,

            

            We have started a mailing list for discussing new EAP
            related work that currently has no obvious home. The mailing
            list is called REAP (Renew EAP) reap@ietf.org and you can
            subscribe here:

            https://www.ietf.org/mailman/listinfo/rea=
p

            

            Recently several new EAP methods have been proposed. These
            include for example:

            

            EAP-TLS 1.3: https://tools.ietf.o=
rg/html/draft-mattsson-eap-tls13-00

            

            EAP-NOOB: https://tools.ietf.org/html/=
draft-aura-eap-noob-02

            

            EAP-SASL: https://tools.ietf.org/ht=
ml/draft-vanrein-eap-sasl-00

            

            The list serves as a venue for discussion of these and other
            EAP related drafts that will be submitted in the near
            future. As courtesy, we will post any new draft to SAAG, but
            we plan to continue the discussion only on the REAP mailing
            list. We have also asked for a short presentation slot
            during SECDISPATCH at IETF 100 in Singapore.

            

            Comments, early feedback, and discussion on existing or new
            work is more than welcome.

            

            --Mohit

            

            _______________________________________________

            saag mailing list

            saag@ietf.or=
g

            https://www.ietf.org/mailman/listinfo/saa=
g

          

        

        

      

      

      

      

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


    

    

  






--001a1144737813e527055c7cdace--


From nobody Thu Oct 26 18:07:57 2017
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 5BE9A13F415; Thu, 26 Oct 2017 18:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1oOMAE51T4m; Thu, 26 Oct 2017 18:07:47 -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 4F176138BD2; Thu, 26 Oct 2017 18:07:47 -0700 (PDT)
Received: by mail-vk0-x231.google.com with SMTP id i133so3268093vke.9; Thu, 26 Oct 2017 18:07:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7xscIoFwlMC67u0AA3Ulx2NzYi/JbjgEbyiahTdRJ3Q=; b=W26h6xSFa7m5qhMgUxkrvOSmToyTyiJ/gHc1xpqC+3bBWNUoka/LdL2iW+JoXo65sK 1EDlUIOyVXbWDLvZD6b8VchWBfxDZGv8ucd5pdF7jr26KdOIa2xjTv9aRMrswNEPPyet 3zBy1XeVHriMlTpA7ahwdDsKETfzfMrWleE2DNVuYbVwG8jgR5ZixN4fM6sk/FFIuOfQ HX6OSM0SFQ8MCQ6LTMHFWT1BIyDcEE/kIJCQAhuvEkVBfMU98WlIw17Typ8ZRwXtsP4V GANfx086/h0FCQhrn2XBfUgT3j0pGJf18P7cqp01yaBpMItvJ+AtvBfqgYOP8Ls4mwa1 1/eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7xscIoFwlMC67u0AA3Ulx2NzYi/JbjgEbyiahTdRJ3Q=; b=d3Rim0duW6NfSJxT1vNJeIUyWngdCe64GdGFvwbA1ep7lTkyJW+XiqhgI7ML1kax55 3IgmBntuX7tB7U74VpicWCUwVNIO49+yZw3v/1l6vyaimvhVqHRigVw4iHze/3w9LvIn GcRVQOu5jqHcc10AREQetU9/MNmMU4OYO8rsJ39n97AgT1obIFb/sF7LZsNXOOpgWWXb gytUt/iRRG1gTVm9DMIG/EICMPx9XJs5pKJQzxeyVQMCNwKhQudhSAfmD7MXlcoWWmUj aCCayW0gtK+4vImLz+cRCIUmrRnaubQe/acZelzq0QcK+clyc5Ri4esrG6LKtKD2H/n2 A43w==
X-Gm-Message-State: AMCzsaVWllnUW9+TECWJVFoIiXaYmYEjQjqR7JzMSD8mmNiKFTpyS2tG PPdyGZ9jYlVrw1kwIt6+ppvVqg7Hbgu2yKRl3bc=
X-Google-Smtp-Source: ABhQp+R9D7zwTalHeqYbMa5tdpp4xMDx7b0UpkG0SPq5vHdWO7SfcPySkirK2ymrOOJU/SJChPNiHfPKqAvT/OWemR4=
X-Received: by 10.31.157.7 with SMTP id g7mr5599537vke.130.1509066466115; Thu, 26 Oct 2017 18:07:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Thu, 26 Oct 2017 18:07:25 -0700 (PDT)
In-Reply-To: <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com>
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>   <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com>
From: Bernard Aboba 
Date: Thu, 26 Oct 2017 18:07:25 -0700
Message-ID: 
To: Mohit Sethi 
Cc: Yoav Nir , reap@ietf.org,  Security Area Advisory Group 
Content-Type: multipart/alternative; boundary="001a1142d8d2a7c521055c7ceaf2"
Archived-At: 
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Oct 2017 01:07:49 -0000

--001a1142d8d2a7c521055c7ceaf2
Content-Type: text/plain; charset="UTF-8"

Creating a separate list has real drawbacks and very little in the way of
benefits.

If your desire is to get feedback from EAP implementers, why not post on a
list they already subscribe to (such as EMU)?

Creating a new list is in effect requiring those people to actively decide
to pay attention to your work, rather than you bringing the work to them.

For a protocol that is more than 20 years old, with dozens of
implementations and billions of existing devices, this is not a sound way
to move forward.



On Thu, Oct 26, 2017 at 12:51 PM, Mohit Sethi 
wrote:

> Hi Yoav,
>
> Thanks for the feedback. This issue about the list had come up a short
> while back when Rick posted his draft on EAP-SASL to SAAG:
> https://mailarchive.ietf.org/arch/msg/saag/stEf0BxTPKGEJq-2RDrlKj1rxRc
>
> We thought that it would make sense to have a separate mailing list on all
> new EAP related work. This would also allow us to gauge the community
> interest in the new work.
> At the end of the day, I believe our objectives are the same: we want to
> work on things that the IETF as a community is interested in, and make sure
> that the work progresses at an acceptable pace.
>
> --Mohit
>
>
> On 10/26/2017 08:55 PM, Yoav Nir wrote:
>
>
>
> On 26 Oct 2017, at 18:51, Bernard Aboba  wrote:
>
> There are existing functioning IETF mailing lists relating to EAP.
>
> Why are you starting yet another one?
>
>
> +1
>
> The EMU mailing list seems appropriate.
>
> Yoav
>
> https://tools.ietf.org/wg/emu/
> https://www.ietf.org/mail-archive/web/emu/current/maillist.html
>
>
>
> _______________________________________________
> REAP mailing listREAP@ietf.orghttps://www.ietf.org/mailman/listinfo/reap
>
>
>

--001a1142d8d2a7c521055c7ceaf2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Creating a separate list has real drawbacks and very littl=
e in the way of benefits.=C2=A0

If your desire is to get=
 feedback from EAP implementers, why not post on a list they already subscr=
ibe to (such as EMU)?

Creating a new list is in ef=
fect requiring those people to actively decide to pay attention to your wor=
k, rather than you bringing the work to them.=C2=A0

For a protocol that is more than 20 years old, with dozens of implementat=
ions and billions of existing devices, this is not a sound way to move forw=
ard.=C2=A0



On Thu, Oct 26, 2017 at 12:51 PM, Mohit =
Sethi <mohit.m.sethi@ericsson.com> wrote:

 =20
   =20
 =20
  

    
Hi Yoav,

    
Thanks for the feedback. This issue about the list had come up a
      short while back when Rick posted his draft on EAP-SASL to SAAG: https://mailarchive.ietf.org/arch/msg/saag/stEf0=
BxTPKGEJq-2RDrlKj1rxRc

    
We thought that it would make sense to have a separate mailing
      list on all new EAP related work. This would also allow us to
      gauge the community interest in the new work.=C2=A0=C2=A0 

    

    At the end of the day, I believe our objectives are the same: we
    want to work on things that the IETF as a community is interested
    in, and make sure that the work progresses at an acceptable pace.

    

    --Mohit


    

    
On 10/26/2017 08:55 =
PM, Yoav Nir wrote:

    

    

     =20
      

      


        

          
On 26 Oct 2017, at 18:51, Bernard Aboba <bernard.aboba@gmail.com>=
;
            wrote:

          

          

            
There are existing functioning IETF
              mailing lists relating to EAP.=C2=A0
              


              

              
Why are you starting yet another one?=C2=A0

            

          

        

        


        

      

      +1
      


      

      
The EMU mailing list seems appropriate.

      


      

      
Yoav

      


      

      
      
      


      

      

      

      

      
_______________________________________________
REAP mailing list
REAP@ietf.org
https://www.ietf.org/mail=
man/listinfo/reap


    

    

  






--001a1142d8d2a7c521055c7ceaf2--


From nobody Thu Oct 26 18:16:29 2017
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 A5E3F13B1A9; Thu, 26 Oct 2017 18:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6UInMo_u_4w; Thu, 26 Oct 2017 18:16:26 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C1A138BD2; Thu, 26 Oct 2017 18:16:26 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id w45so3805124uac.3; Thu, 26 Oct 2017 18:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1uwYbky3C/SRVCqquB9ZdxcbJCEalXgawNhznVOkDig=; b=JtU7D29YdU83zRB8ghOKaA6HQfewsmhJ2SXVtSi6ffpuXON6YmZAd8/R22GzkE0clR XvXN2vnec+CACACYy/fWUNlE9PNN5pUYD8xkSWOpZvqBv4aFBGCTROhVrB6X1cy7LHvR lL9M5mCWlHEp6v5pT0QsriB0N8LY34+kq3apU24W7zjq59xAEJ/+ABufHjpUgSdnOrNa tvYXsBMoL5FaIIHDli8b+IdDAcenGBrxHujNZahTb9/p5nyug1atUOR4MhepPJ6iw3Qe mFk7+pdMv69gFFEu71Wg9MgNHSkyy7zncDKkh5fwYeMQePJRkr0qtdtGBv2kmoNPJVLy RQ6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1uwYbky3C/SRVCqquB9ZdxcbJCEalXgawNhznVOkDig=; b=bl3TGwyaUqpQIVLJ+MI74EBCyEAzDheqp7pJ4yyuy8TL6oncjRi0H0iNFSHn+IXTes W4P30Rh3Ekc0BarmHMKCyqGC7MJDkn7Fz6Co9Lp2WDuqQFkkyw/Z3mc8ejTdfbqxuzC6 3bHtx8Ss4DNcmqmXz49TByJuNIrdxdfwIcVl9l0YEi8zEVKExehU2gyRKxkp3MAV3pGp zq2P6JQKB+WkTDgsq4yBiOqJmZmuWKoQ48nDMdfTwONeG38crMwcUPgZoY4zDu6+2MWL hIdsc1xHXUHdcJBSJiLoaozdL2YtkNNldS8xSkTk/BdWwcuqLyjWq+nyJficBsEbYVXU gY7w==
X-Gm-Message-State: AMCzsaW/87Or0rkf31OG6fmm+4IgOHHMv2TbZpoLW4gS/6L99pLoIJOZ w1qsfvtu2rQ27OJ3x9O43y0ALSRMTzNbQYnn0j9oXA==
X-Google-Smtp-Source: ABhQp+Rg/46M2g6qGsX6aK9J2eg/maF9ne8Ar+JaBpXwA2Xs7wRtye/3MXRIlrpVYgSUNHF+yrdro1H0YTzI8oRj7Qo=
X-Received: by 10.176.20.225 with SMTP id f30mr5965780uae.66.1509066985064; Thu, 26 Oct 2017 18:16:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Thu, 26 Oct 2017 18:16:04 -0700 (PDT)
In-Reply-To: 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com> 
From: Bernard Aboba 
Date: Thu, 26 Oct 2017 18:16:04 -0700
Message-ID: 
To: Kathleen Moriarty 
Cc: Mohit Sethi , reap@ietf.org,  "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1145ab00964e7f055c7d0901"
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Oct 2017 01:16:28 -0000

--001a1145ab00964e7f055c7d0901
Content-Type: text/plain; charset="UTF-8"

Yes, the EMU WG  list has been used for discussion of EAP methods since the
WG closed.

That list is a better venue for discussion of EAP  methods than a new REAP
list, so as to ensure that proper attention is paid to backward
compatibility, IPR, security properties and other critical aspects of EAP
method design.

After all, we are talking about a protocol that is 20+ years old that is
implemented on billions of devices, many of which utilize open-source.








On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

> On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi 
> wrote:
> > Hi Bernard,
> >
> > The EAP-TLS 1.3 document is a very rough drafty version that was
> submitted
> > before the cut-off for the last IETF. As you rightly point out, it has
> the
> > skeleton and a lot of material from RFC5216, and still many important
> > details are missing.
> >
> > The purpose of this list is to exactly receive these kind of comments.
> > Should RFC5216 be updated or obsoleted by this draft. And it would be
> great
> > if we can have your contributions to the document. We will definitely
> add an
> > acknowledgement section and contact the authors of RFC5216 to see if they
> > can contribute and comment. We plan to have more EAP related
> contributions
> > in the near future. We discussed this with the Security ADs and thought
> that
> > a separate list would be appropriate to get feedback/criticism and
> > contributions from the folks interested.
>
> I'm sorry, I didn't realize that a revision of 5216 was involved and
> that the authors were not notified at the onset as is normal practice
> in case they want to continue as authors.  Thank you for spotting this
> issue Bernard.
>
> Is there an existing list that should be used?  Is there adequate
> overlap in objectives and personnel?
>
> Thank you,
> Kathleen
>
> >
> > --Mohit
> >
> >
> > On 10/26/2017 06:51 PM, Bernard Aboba wrote:
> >
> > There are existing functioning IETF mailing lists relating to EAP.
> >
> > Why are you starting yet another one?
> >
> > From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5216
> > (with no acknowledgement to the original authors) stating that EAP-TLS
> > implementations must support TLS 1.3.
> >
> > This is ridiculous because there are 1+ Billion existing implementations
> out
> > there that
> >
> >
> > On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi  >
> > wrote:
> >>
> >> Dear all,
> >>
> >> We have started a mailing list for discussing new EAP related work that
> >> currently has no obvious home. The mailing list is called REAP (Renew
> EAP)
> >> reap@ietf.org and you can subscribe here:
> >> https://www.ietf.org/mailman/listinfo/reap
> >>
> >> Recently several new EAP methods have been proposed. These include for
> >> example:
> >>
> >> EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
> >>
> >> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
> >>
> >> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
> >>
> >> The list serves as a venue for discussion of these and other EAP related
> >> drafts that will be submitted in the near future. As courtesy, we will
> post
> >> any new draft to SAAG, but we plan to continue the discussion only on
> the
> >> REAP mailing list. We have also asked for a short presentation slot
> during
> >> SECDISPATCH at IETF 100 in Singapore.
> >>
> >> Comments, early feedback, and discussion on existing or new work is more
> >> than welcome.
> >>
> >> --Mohit
> >>
> >> _______________________________________________
> >> saag mailing list
> >> saag@ietf.org
> >> https://www.ietf.org/mailman/listinfo/saag
> >
> >
> >
> >
> > _______________________________________________
> > saag mailing list
> > saag@ietf.org
> > https://www.ietf.org/mailman/listinfo/saag
> >
> >
> >
> > _______________________________________________
> > saag mailing list
> > saag@ietf.org
> > https://www.ietf.org/mailman/listinfo/saag
> >
>
>
>
> --
>
> Best regards,
> Kathleen
>

--001a1145ab00964e7f055c7d0901
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes, the EMU WG=C2=A0 list has been used for discussion of=
 EAP methods since the WG closed.=C2=A0

That list is a b=
etter venue for discussion of EAP=C2=A0 methods than a new REAP list, so as=
 to ensure that proper attention is paid to backward compatibility, IPR, se=
curity properties and other critical aspects of EAP method design.=C2=A0

After all, we are talking about a protocol that is 2=
0+ years old that is implemented on billions of devices, many of which util=
ize open-source.=C2=A0=C2=A0








On Thu, Oct 26, 2017 a=
t 11:53 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail=
.com> wrote:
On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi <mohit.m.sethi@ericsson.com> wrote:

> Hi Bernard,

>

> The EAP-TLS 1.3 document is a very rough drafty version that was submi=
tted

> before the cut-off for the last IETF. As you rightly point out, it has=
 the

> skeleton and a lot of material from RFC5216, and still many important<=
br>
> details are missing.

>

> The purpose of this list is to exactly receive these kind of comments.=


> Should RFC5216 be updated or obsoleted by this draft. And it would be =
great

> if we can have your contributions to the document. We will definitely =
add an

> acknowledgement section and contact the authors of RFC5216 to see if t=
hey

> can contribute and comment. We plan to have more EAP related contribut=
ions

> in the near future. We discussed this with the Security ADs and though=
t that

> a separate list would be appropriate to get feedback/criticism and

> contributions from the folks interested.



I'm sorry, I didn't realize that a revision of 5216 was invo=
lved and

that the authors were not notified at the onset as is normal practice

in case they want to continue as authors.=C2=A0 Thank you for spotting this=


issue Bernard.



Is there an existing list that should be used?=C2=A0 Is there adequate

overlap in objectives and personnel?



Thank you,

Kathleen




>

> --Mohit

>

>

> On 10/26/2017 06:51 PM, Bernard Aboba wrote:

>

> There are existing functioning IETF mailing lists relating to EAP.

>

> Why are you starting yet another one?

>

> From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 52=
16

> (with no acknowledgement to the original authors) stating that EAP-TLS=


> implementations must support TLS 1.3.

>

> This is ridiculous because there are 1+ Billion existing implementatio=
ns out

> there that

>

>

> On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi <mohit.m.sethi@ericsson.com>

> wrote:

>>

>> Dear all,

>>

>> We have started a mailing list for discussing new EAP related work=
 that

>> currently has no obvious home. The mailing list is called REAP (Re=
new EAP)

>> reap@ietf.org and you can sub=
scribe here:

>> https://www.ietf.org/mailman/listinfo/reap

>>

>> Recently several new EAP methods have been proposed. These include=
 for

>> example:

>>

>> EAP-TLS 1.3: https://tools.ietf.org/=
html/draft-mattsson-eap-tls13-00

>>

>> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02

>>

>> EAP-SASL: https://tools.ietf.org/html/=
draft-vanrein-eap-sasl-00

>>

>> The list serves as a venue for discussion of these and other EAP r=
elated

>> drafts that will be submitted in the near future. As courtesy, we =
will post

>> any new draft to SAAG, but we plan to continue the discussion only=
 on the

>> REAP mailing list. We have also asked for a short presentation slo=
t during

>> SECDISPATCH at IETF 100 in Singapore.

>>

>> Comments, early feedback, and discussion on existing or new work i=
s more

>> than welcome.

>>

>> --Mohit

>>

>> _______________________________________________

>> saag mailing list

>> saag@ietf.org

>> https://www.ietf.org/mailman/listinfo/saag

>

>

>

>

> _______________________________________________

> saag mailing list

> saag@ietf.org

> https://www.ietf.org/mailman/listinfo/saag
>

>

>

> _______________________________________________

> saag mailing list

> saag@ietf.org

> https://www.ietf.org/mailman/listinfo/saag
>








--



Best regards,

Kathleen





--001a1145ab00964e7f055c7d0901--


From nobody Thu Oct 26 18:43:39 2017
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 4C02613A41F; Thu, 26 Oct 2017 18:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLs4HUtkbAML; Thu, 26 Oct 2017 18:43:34 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 A992013F4CB; Thu, 26 Oct 2017 18:43:34 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id 31so6685974qtz.9; Thu, 26 Oct 2017 18:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vybTILVLThz2X/6QS0SVHs/owRIsuBvQ3Emi6X2zfeg=; b=r+UcSx8eWWoHgkzYa0ycah9SJ+xrVNGgSaUQuPlqlRGxMYO3J3gYK++rimoTkOqWIm hXkO7CfmZC7ou2xWossVqA0w58Hdk4Upaof4SURAcG1F4bxodde2elooicstRh2CxyGs VvvBHr3oPv984O/3spPfQTPfiiKFfzrLpUDnIQP1oc7LElqXdQfqVwoGwjZIO3zdEDLH YoEtGmyJ0rMeGd0I6HBDnhAtodwQ1D+ZyaXq+D8Dh2veCaqquvE8rI0AxEKKkDLLudta 5kF5EJWXKgvmjnVQYo5FwppX9flFfgS6eJKh6Icsj0x6dmnFCzqI+zR42j7W+89uQGe4 mNvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vybTILVLThz2X/6QS0SVHs/owRIsuBvQ3Emi6X2zfeg=; b=oUK5ifdW6qlvodoilgC+pVHghuuyVk7u8ncK19YmXO+xXcJKEluTNbS50rbHeSi1bO d1BDQM1RVAhncxfWx+rCbTLTBbQJaxHq/3uX1ElkWFD1B718Uzs3QsJcP/8t1gGd8+mp fQwaA0dRrhceoaQVO3TKwsB463SNKa8/SqA4tMLVdNoKBGQVct/KUDXDkAhLRwHe+vRA kZBtmwGFdtmJfyyksMu0HEicweX7yN/KUA4BCN7neZlBzt1J+9/+WlVPQ40m9oTM0v93 vws6oaeeS2IHFwZmzbfdpToN7oZmnhjwQ8sXYgq6kYg9t08I/44nz6LcwqjqZbKOye5j Fn4g==
X-Gm-Message-State: AMCzsaWNiD1qLYkm0pr+74IkLt3roUXimDVKc0qby3HEmgCiT/BUZ4uk YDOBRYiwLoi0kaT7xHkBPc6TIwO4
X-Google-Smtp-Source: ABhQp+SLoTVxssoa3Va6svRBoU12ahmiw2XRQGk8RO856Jknfdcmt0lYIKwHY62GnSY3wKJaMal43A==
X-Received: by 10.237.34.201 with SMTP id q9mr38829872qtc.198.1509068613406; Thu, 26 Oct 2017 18:43:33 -0700 (PDT)
Received: from [192.168.1.6] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id e62sm4277328qkb.11.2017.10.26.18.43.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 18:43:32 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-2A7FD865-AA95-4AF5-B368-2F44CD914C8B
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty 
X-Mailer: iPhone Mail (14F89)
In-Reply-To: 
Date: Thu, 26 Oct 2017 21:43:31 -0400
Cc: Mohit Sethi , reap@ietf.org, "saag@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: <112200E8-0E1D-4A38-800D-54892BFF67F6@gmail.com>
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>  
To: Bernard Aboba 
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Oct 2017 01:43:37 -0000

--Apple-Mail-2A7FD865-AA95-4AF5-B368-2F44CD914C8B
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

That sounds like the best plan.

Thank you,
Kathleen=20

Sent from my iPhone

> On Oct 26, 2017, at 9:16 PM, Bernard Aboba  wrote=
:
>=20
> Yes, the EMU WG  list has been used for discussion of EAP methods since th=
e WG closed.=20
>=20
> That list is a better venue for discussion of EAP  methods than a new REAP=
 list, so as to ensure that proper attention is paid to backward compatibili=
ty, IPR, security properties and other critical aspects of EAP method design=
.=20
>=20
> After all, we are talking about a protocol that is 20+ years old that is i=
mplemented on billions of devices, many of which utilize open-source. =20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>> On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty  wrote:
>> On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi =
 wrote:
>> > Hi Bernard,
>> >
>> > The EAP-TLS 1.3 document is a very rough drafty version that was submit=
ted
>> > before the cut-off for the last IETF. As you rightly point out, it has t=
he
>> > skeleton and a lot of material from RFC5216, and still many important
>> > details are missing.
>> >
>> > The purpose of this list is to exactly receive these kind of comments.
>> > Should RFC5216 be updated or obsoleted by this draft. And it would be g=
reat
>> > if we can have your contributions to the document. We will definitely a=
dd an
>> > acknowledgement section and contact the authors of RFC5216 to see if th=
ey
>> > can contribute and comment. We plan to have more EAP related contributi=
ons
>> > in the near future. We discussed this with the Security ADs and thought=
 that
>> > a separate list would be appropriate to get feedback/criticism and
>> > contributions from the folks interested.
>>=20
>> I'm sorry, I didn't realize that a revision of 5216 was involved and
>> that the authors were not notified at the onset as is normal practice
>> in case they want to continue as authors.  Thank you for spotting this
>> issue Bernard.
>>=20
>> Is there an existing list that should be used?  Is there adequate
>> overlap in objectives and personnel?
>>=20
>> Thank you,
>> Kathleen
>>=20
>> >
>> > --Mohit
>> >
>> >
>> > On 10/26/2017 06:51 PM, Bernard Aboba wrote:
>> >
>> > There are existing functioning IETF mailing lists relating to EAP.
>> >
>> > Why are you starting yet another one?
>> >
>> > =46rom what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5=
216
>> > (with no acknowledgement to the original authors) stating that EAP-TLS
>> > implementations must support TLS 1.3.
>> >
>> > This is ridiculous because there are 1+ Billion existing implementation=
s out
>> > there that
>> >
>> >
>> > On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi 
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> We have started a mailing list for discussing new EAP related work tha=
t
>> >> currently has no obvious home. The mailing list is called REAP (Renew E=
AP)
>> >> reap@ietf.org and you can subscribe here:
>> >> https://www.ietf.org/mailman/listinfo/reap
>> >>
>> >> Recently several new EAP methods have been proposed. These include for=

>> >> example:
>> >>
>> >> EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>> >>
>> >> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>> >>
>> >> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>> >>
>> >> The list serves as a venue for discussion of these and other EAP relat=
ed
>> >> drafts that will be submitted in the near future. As courtesy, we will=
 post
>> >> any new draft to SAAG, but we plan to continue the discussion only on t=
he
>> >> REAP mailing list. We have also asked for a short presentation slot du=
ring
>> >> SECDISPATCH at IETF 100 in Singapore.
>> >>
>> >> Comments, early feedback, and discussion on existing or new work is mo=
re
>> >> than welcome.
>> >>
>> >> --Mohit
>> >>
>> >> _______________________________________________
>> >> saag mailing list
>> >> saag@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/saag
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > saag mailing list
>> > saag@ietf.org
>> > https://www.ietf.org/mailman/listinfo/saag
>> >
>> >
>> >
>> > _______________________________________________
>> > saag mailing list
>> > saag@ietf.org
>> > https://www.ietf.org/mailman/listinfo/saag
>> >
>>=20
>>=20
>>=20
>> --
>>=20
>> Best regards,
>> Kathleen
>=20

--Apple-Mail-2A7FD865-AA95-4AF5-B368-2F44CD914C8B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


That sounds like the best plan.
<=
div id=3D"AppleMailSignature">
Thank=
 you,
Kathleen 

Sent from my=
 iPhone

On Oct 26, 2017, at 9:16 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Yes, the EMU WG&=
nbsp; list has been used for discussion of EAP methods since the WG closed.&=
nbsp;

That list is a better venue for discussion of EAP&n=
bsp; methods than a new REAP list, so as to ensure that proper attention is p=
aid to backward compatibility, IPR, security properties and other critical a=
spects of EAP method design. 

After all, we ar=
e talking about a protocol that is 20+ years old that is implemented on bill=
ions of devices, many of which utilize open-source.  







On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi &=
lt;mohit.m.sethi@ericsson.com<=
/a>> wrote:

> Hi Bernard,

>

> The EAP-TLS 1.3 document is a very rough drafty version that was submit=
ted

> before the cut-off for the last IETF. As you rightly point out, it has t=
he

> skeleton and a lot of material from RFC5216, and still many important
> details are missing.

>

> The purpose of this list is to exactly receive these kind of comments.<=
br>
> Should RFC5216 be updated or obsoleted by this draft. And it would be g=
reat

> if we can have your contributions to the document. We will definitely a=
dd an

> acknowledgement section and contact the authors of RFC5216 to see if th=
ey

> can contribute and comment. We plan to have more EAP related contributi=
ons

> in the near future. We discussed this with the Security ADs and thought=
 that

> a separate list would be appropriate to get feedback/criticism and

> contributions from the folks interested.



I'm sorry, I didn't realize that a revision of 5216 was involved and<=
br>
that the authors were not notified at the onset as is normal practice

in case they want to continue as authors.  Thank you for spotting this<=
br>
issue Bernard.



Is there an existing list that should be used?  Is there adequate

overlap in objectives and personnel?



Thank you,

Kathleen




>

> --Mohit

>

>

> On 10/26/2017 06:51 PM, Bernard Aboba wrote:

>

> There are existing functioning IETF mailing lists relating to EAP.

>

> Why are you starting yet another one?

>

> =46rom what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5=
216

> (with no acknowledgement to the original authors) stating that EAP-TLS<=
br>
> implementations must support TLS 1.3.

>

> This is ridiculous because there are 1+ Billion existing implementation=
s out

> there that

>

>

> On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi <mohit.m.sethi@ericsson.com>

> wrote:

>>

>> Dear all,

>>

>> We have started a mailing list for discussing new EAP related work t=
hat

>> currently has no obvious home. The mailing list is called REAP (Ren=
ew EAP)

>> reap@ietf.org and you can subs=
cribe here:

>> https://www.ietf.org/mailman/listinfo/reap=


>>

>> Recently several new EAP methods have been proposed. These include f=
or

>> example:

>>

>> EAP-TLS 1.3: https://tools.ietf.org/ht=
ml/draft-mattsson-eap-tls13-00

>>

>> EAP-NOOB: https://tools.ietf.org/html/=
draft-aura-eap-noob-02

>>

>> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00

>>

>> The list serves as a venue for discussion of these and other EAP re=
lated

>> drafts that will be submitted in the near future. As courtesy, we w=
ill post

>> any new draft to SAAG, but we plan to continue the discussion only o=
n the

>> REAP mailing list. We have also asked for a short presentation slot=
 during

>> SECDISPATCH at IETF 100 in Singapore.

>>

>> Comments, early feedback, and discussion on existing or new work is=
 more

>> than welcome.

>>

>> --Mohit

>>

>> _______________________________________________

>> saag mailing list

>> saag@ietf.org

>> https://www.ietf.org/mailman/listinfo/saag=


>

>

>

>

> _______________________________________________

> saag mailing list

> saag@ietf.org

> https://www.ietf.org/mailman/listinfo/saag
=

>

>

>

> _______________________________________________

> saag mailing list

> saag@ietf.org

> https://www.ietf.org/mailman/listinfo/saag
=

>








--



Best regards,

Kathleen





=

--Apple-Mail-2A7FD865-AA95-4AF5-B368-2F44CD914C8B--


From nobody Thu Oct 26 18:57:40 2017
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 94251139F18; Thu, 26 Oct 2017 18:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByL5ShYTT6wz; Thu, 26 Oct 2017 18:57:31 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F8A13968C; Thu, 26 Oct 2017 18:57:31 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id n22so3849184uaj.13; Thu, 26 Oct 2017 18:57:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JnFaB6yrqfYxxvJU15GPaY+TSRtHt2dAzJ3U3CY6bnA=; b=fZP4DOlAZWSxGB1/++REsMRQskX7HHzfxs7MXAELz8y/M3nSxK/S7Eg4zFgK+WZPb+ mahvgi3xHr18yf3/2MszlYjjbRa5U4jCgIKkZ7D6uMSyryaJBQesGTUC9bsH8TrBW3bz VQdoqP0Psn1n4eaxM9+gwujwrF+fqHAJBgIvy3680+vO3E6rDbGxDkCWUnnSbOsRf+YX D1FvUt7oVVOxX1ylgXYSixI82fmaYMszsZluxOKQh8LnIg+TGZrF7jBgkWd3+e/cBA7v VKo3NnlqQ63OLWCBC5TjC0FtvHFYTpGmRJtDLkXVfMTAVcF1jgDtYqTZng70C5Dk89uW Rb/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JnFaB6yrqfYxxvJU15GPaY+TSRtHt2dAzJ3U3CY6bnA=; b=qhDOFMH7oDSPL4dxOb+45p+XSv9ybBhz5fkLY+KVQrriRHjS9zZtucltywxfIVNfuY 3E/uU0HqOBBmtsvuUmRr+repTHb80M0cDgflcpMrpuT1MI/KlaWXKDq4Fq7dcmFrtvhN pjfFw7mvRzfyT/gPn8a/4/oVjUUcCTzshyah5Y6IP/VXNLAqDQdb2PR/o/65eA7AuQ6P mQypot+7eVXs8CTXoQcHaDkBjKl70yBSSWEXnvshczQTcZw1c54ZNZs4C88kywRdfXTW k78lAjqay1ZAcOqx1Rl6VWx/+ktsyTRiAtCdqia9Wwt7epLfIBHNGKeScgGHLyBITkrO iROA==
X-Gm-Message-State: AMCzsaWHtFUel5RNhnWi2/IyB07lyto5imOJ+4s5ftftZm91VNQ9lkYZ OIJ55MstKn4fs602GkXMYM9B5uYkJDq0cUQZYQE=
X-Google-Smtp-Source: ABhQp+S9pJDQDmc7QIgNwd5bjMduvtK6JFD8RF9fwzJ5fgb59sSrU0DTB9shD9OKP3JuysxSih7mtYSbTpii41Lqf4A=
X-Received: by 10.176.81.68 with SMTP id f4mr5203676uaa.52.1509069450106; Thu, 26 Oct 2017 18:57:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Thu, 26 Oct 2017 18:57:09 -0700 (PDT)
In-Reply-To: <06C83B1E-3330-4DE7-9F98-CA7D133CFDB5@deployingradius.com>
References:  <06C83B1E-3330-4DE7-9F98-CA7D133CFDB5@deployingradius.com>
From: Bernard Aboba 
Date: Thu, 26 Oct 2017 18:57:09 -0700
Message-ID: 
To: Alan DeKok , saag 
Cc: emu@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c19131883dc85055c7d9cfb"
Archived-At: 
Subject: Re: [saag] [Emu] RFC 5216 updates, backwards compatibility and open source
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Oct 2017 01:57:33 -0000

--94eb2c19131883dc85055c7d9cfb
Content-Type: text/plain; charset="UTF-8"

Alan said:

"Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic.  Not
because TLS1.2 is bad, but because in some cases, the upgrade was
*mandated* by the OS vendor.  This forced upgrade caused massive
incompatibilities.  Which led the OS vendors to back off on their
requirements.

  i.e. with billions of devices supporting EAP-TLS, there are hundreds of
millions which support only old versions of TLS.  Devices which cannot
realistically be upgraded."

[BA] Yes, in practice, the upgrade from EAP-TLS with TLS 1.0 to EAP-TLS
with TLS 1.1 or 1.2 had to be very carefully orchestrated, both because of
protocol and ciphersuite issues.

"Moving to newer versions of TLS is a decision best left to site
administrators.  They should be *strongly recommended* to use the best
available crypto.  But mandating it is counter-productive.  Such mandates
cause administrators to stick with older server software that is compatible
with older systems."

[BA] Fully agree. In practice those decisions often need to take into
account guidance from regulators or organizations that seek to summarize
industry "best practices".  Organizations (such as NIST) think through the
migration issues very carefully in order to balance the costs and benefits,
and minimize disruptions.

On Thu, Oct 26, 2017 at 5:57 PM, Alan DeKok 
wrote:

> On Oct 26, 2017, at 8:24 PM, Bernard Aboba 
> wrote:
> > To provide backwards as well as forwards compatibility, EAP-TLS was
> designed to to support new versions of TLS, including versions introducing
> new ciphersuites.
> > So while RFC 5216 mandates support for TLS 1.0 to preserve backwards
> compatibility, it does not mandate the use of TLS 1.0 or any other version
> in a given installation.  This allows organizations to manage their
> deployments (and required ciphersuites) as they see fit.  For example, an
> organization wiling to take on the costs of migrating all of their devices
> and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated
> ciphersuites is fully able to do so within the framework laid out by RFC
> 5216. \
>
>   Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic.  Not
> because TLS1.2 is bad, but because in some cases, the upgrade was
> *mandated* by the OS vendor.  This forced upgrade caused massive
> incompatibilities.  Which led the OS vendors to back off on their
> requirements.
>
>   i.e. with billions of devices supporting EAP-TLS, there are hundreds of
> millions which support only old versions of TLS.  Devices which cannot
> realistically be upgraded.
>
>   Moving to newer versions of TLS is a decision best left to site
> administrators.  They should be *strongly recommended* to use the best
> available crypto.  But mandating it is counter-productive.  Such mandates
> cause administrators to stick with older server software that is compatible
> with older systems.
>
> > However, what RFC 5216 does NOT attempt to do is to mandate a world-wide
> non-backward compatible "forklift" upgrade for TLS versions of
> ciphersuites.  Such a non-backward compatible "forklift" update would be
> extra-ordinarily costly, requiring the upgrading of every device
> implementing EAP-TLS, including devices that do not use the protocol
> regularly, if ever.
> >
> > Despite this lack of "central management" imposed by the IETF, the
> record of EAP-TLS forward compatibility appears to be pretty good. At this
> point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and I am
> aware of several implementations of EAP-TLS now testing support for TLS
> 1.3, without any changes to the protocol.
>
>   That has been my experience, too.
>
> > I was therefore surprised to come across draft-mattsson-eap-tls13 which:
> >
> > 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS.  As
> noted earlier, organizations requiring support for TLS 1.3 can easily
> impose such a requirement on their EAP-TLS devices, if the cost and
> security benefits justify it.  However, since RFC 5216 is referenced in
> many RFPs, obsoleting it merely to impose a TLS 1.3 requirement without
> extraordinary justification (such as discovery of a critical security flaw
> that cannot be patched in previous versions) would impose enormous costs.
> >
> > 2. Invalidates the existing security proofs of EAP-TLS by introducing
> new authentication modes (such as EAP PSK) that were specifically rejected
> by the EMU WG so to ensure that high-security installations could ensure
> that certificate-based authentication, and only cert-based authentication
> was provided by their EAP-TLS implementations.
> >
> > This reversal of an EMU WG decision is very unwise since it has the
> potential to introduce new security vulnerabilities into the systems
> protecting some of the world's most sensitive data.
> >
> > 3. Removes much of the security guidance of RFC 5216 addressing known
> interoperability and security issues.
> >
> > 4. Does not discuss the potential IPR implications of introducing a TLS
> 1.3 requirement into a protocol that is widely implemented in open source.
>
>   I concur.
>
>   Not only because I'm an open source implementor.  But also because that
> software supports networks encompassing hundreds of millions of devices.
> Software which is used by all network equipment vendors.
>
>   It is just infeasible to mandate that all devices upgrade to TLS 1.3.
>
>   For me, it's 2017.  Any proposal that does not address existing
> deployments is one that should be ignored, as being out of touch with
> real-world use-cases.
>
>   Alan DeKok.
>
>

--94eb2c19131883dc85055c7d9cfb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Alan said:

"Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic=
.=C2=A0 Not because TLS1.2 is bad, but because in some cases, the upgrade w=
as *mandated* by the OS vendor.=C2=A0 This forced upgrade caused massive in=
compatibilities.=C2=A0 Which led the OS vendors to back off on their requir=
ements.

=C2=A0 i.e. with billions of devices supporting EAP-TLS, there are=
 hundreds of millions which support only old versions of TLS.=C2=A0 Devices=
 which cannot realistically be upgraded."

[B=
A] Yes, in practice, the upgrade from EAP-TLS with TLS 1.0 to EAP-TLS with =
TLS 1.1 or 1.2 had to be very carefully orchestrated, both because of proto=
col and ciphersuite issues.=C2=A0

"Moving to newer versions of TLS is a decision b=
est left to site administrators.=C2=A0 They should be *strongly recommended=
* to use the best available crypto.=C2=A0 But mandating it is counter-produ=
ctive.=C2=A0 Such mandates cause administrators to stick with older server =
software that is compatible with older systems."

=

[BA] Fully agree. In practice those decisions often need to take=
 into account guidance from regulators or organizations that seek to summar=
ize industry "best practices".=C2=A0 Organizations (such as NIST)=
 think through the migration issues very carefully in order to balance the =
costs and benefits, and minimize disruptions.

On Thu, Oct 26, 2017 at 5:5=
7 PM, Alan DeKok <aland@deployingradius.com> wrote:<=
br>
On Oct 26, 2017, at 8:24=
 PM, Bernard Aboba <bernard.a=
boba@gmail.com> wrote:

> To provide backwards as well as forwards compatibility, EAP-TLS was de=
signed to to support new versions of TLS, including versions introducing ne=
w ciphersuites.

> So while RFC 5216 mandates support for TLS 1.0 to preserve back=
wards compatibility, it does not mandate the use of TLS 1.0 or any other ve=
rsion in a given installation.=C2=A0 This allows organizations to manage th=
eir deployments (and required ciphersuites) as they see fit.=C2=A0 For exam=
ple, an organization wiling to take on the costs of migrating all of their =
devices and servers to TLS 1.3 and requiring the use of TLS 1.3 mandated ci=
phersuites is fully able to do so within the framework laid out by RFC 5216=
. \



=C2=A0 Upgrading from TLS1.0 to TLS1.2 has been shown to be problematic.=C2=
=A0 Not because TLS1.2 is bad, but because in some cases, the upgrade was *=
mandated* by the OS vendor.=C2=A0 This forced upgrade caused massive incomp=
atibilities.=C2=A0 Which led the OS vendors to back off on their requiremen=
ts.



=C2=A0 i.e. with billions of devices supporting EAP-TLS, there are hundreds=
 of millions which support only old versions of TLS.=C2=A0 Devices which ca=
nnot realistically be upgraded.



=C2=A0 Moving to newer versions of TLS is a decision best left to site admi=
nistrators.=C2=A0 They should be *strongly recommended* to use the best ava=
ilable crypto.=C2=A0 But mandating it is counter-productive.=C2=A0 Such man=
dates cause administrators to stick with older server software that is comp=
atible with older systems.



> However, what RFC 5216 does NOT attempt to do is to mandate a world-wi=
de non-backward compatible "forklift" upgrade for TLS versions of=
 ciphersuites.=C2=A0 Such a non-backward compatible "forklift" up=
date would be extra-ordinarily costly, requiring the upgrading of every dev=
ice implementing EAP-TLS, including devices that do not use the protocol re=
gularly, if ever.

>

> Despite this lack of "central management" imposed by the IET=
F, the record of EAP-TLS forward compatibility appears to be pretty good. A=
t this point support for TLS 1.1 and 1.2 in EAP-TLS has widely deployed and=
 I am aware of several implementations of EAP-TLS now testing support for T=
LS 1.3, without any changes to the protocol.



=C2=A0 That has been my experience, too.



> I was therefore surprised to come across draft-mattsson-eap-tls13 whic=
h:

>

> 1. Mandates support for TLS 1.3 in all implementations of EAP-TLS.=C2=
=A0 As noted earlier, organizations requiring support for TLS 1.3 can easil=
y impose such a requirement on their EAP-TLS devices, if the cost and secur=
ity benefits justify it.=C2=A0 However, since RFC 5216 is referenced in man=
y RFPs, obsoleting it merely to impose a TLS 1.3 requirement without extrao=
rdinary justification (such as discovery of a critical security flaw that c=
annot be patched in previous versions) would impose enormous costs.

>

> 2. Invalidates the existing security proofs of EAP-TLS by introducing =
new authentication modes (such as EAP PSK) that were specifically rejected =
by the EMU WG so to ensure that high-security installations could ensure th=
at certificate-based authentication, and only cert-based authentication was=
 provided by their EAP-TLS implementations.

>

> This reversal of an EMU WG decision is very unwise since it has the po=
tential to introduce new security vulnerabilities into the systems protecti=
ng some of the world's most sensitive data.

>

> 3. Removes much of the security guidance of RFC 5216 addressing known =
interoperability and security issues.

>

> 4. Does not discuss the potential IPR implications of introducing a TL=
S 1.3 requirement into a protocol that is widely implemented in open source=
.



=C2=A0 I concur.



=C2=A0 Not only because I'm an open source implementor.=C2=A0 But also =
because that software supports networks encompassing hundreds of millions o=
f devices.=C2=A0 Software which is used by all network equipment vendors.


=C2=A0 It is just infeasible to mandate that all devices upgrade to TLS 1.3=
.



=C2=A0 For me, it's 2017.=C2=A0 Any proposal that does not address exis=
ting deployments is one that should be ignored, as being out of touch with =
real-world use-cases.



=C2=A0 Alan DeKok.







--94eb2c19131883dc85055c7d9cfb--


From nobody Fri Oct 27 04:55:42 2017
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 DC7EA13F507; Fri, 27 Oct 2017 04:55:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq-8UehXMp7Q; Fri, 27 Oct 2017 04:55:32 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED78113F511; Fri, 27 Oct 2017 04:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20655; q=dns/txt; s=iport; t=1509105329; x=1510314929; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=/W6IwO0pwDlTEJLT4EutdpzB4s/0WB8qBFCMNNUNyug=; b=Wpb+Ex6NfXAZgrmPsHegCLOEa6nlZiWqUpf2cNNgGZYiyB7Fp/Kj2VX3 t5/kl58BDI+KC9WogvgXSKM/aZLK30QeVfc3Vz/GP4ypu5bq4vuZ7r+4d qc6vJmUuDrnc6hPZ9XUGSH7sAPOoDa+66VtEWzYfWaa3+bC/OUBQUr3Py I=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAQDZHfNZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzGBEm4ng3qLE49yJohPiC6FRRCCAQcDGAEKhRgChQoWAQIBAQE?= =?us-ascii?q?BAQEBayiFHgEBAQMBASFLCxALGAwbAwICIQYfEQYBDAYCAQGKBwMVEKkRgicmh?= =?us-ascii?q?xgNgyMBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWDLoVAKQuBaYENgl6Bb4NNgmE?= =?us-ascii?q?Fh1WRLIhFPIRCgiOBAYdMUIR5i3SHOYxeOYh3gTkmCSiBaDQhCB0VSYJkgiM5H?= =?us-ascii?q?IFpPzYBi2sBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,304,1505779200";  d="asc'?scan'208,217";a="698279204"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2017 11:55:26 +0000
Received: from [10.61.96.63] (dhcp-10-61-96-63.cisco.com [10.61.96.63]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9RBtPkk030225; Fri, 27 Oct 2017 11:55:25 GMT
To: Kathleen Moriarty , Bernard Aboba 
Cc: reap@ietf.org, Mohit Sethi , "saag@ietf.org" 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>   <112200E8-0E1D-4A38-800D-54892BFF67F6@gmail.com>
From: Eliot Lear 
Message-ID: 
Date: Fri, 27 Oct 2017 13:55:08 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <112200E8-0E1D-4A38-800D-54892BFF67F6@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TVqle0GMKRf7OxwCq5whJ0CgU3iw7iVM1"
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Oct 2017 11:55:35 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--TVqle0GMKRf7OxwCq5whJ0CgU3iw7iVM1
Content-Type: multipart/mixed; boundary="K3cjR6hn7OsvQHlghiKN58MaWJNL7SfDI";
 protected-headers="v1"
From: Eliot Lear 
To: Kathleen Moriarty ,
 Bernard Aboba 
Cc: reap@ietf.org, Mohit Sethi ,
 "saag@ietf.org" 
Message-ID: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>
 
 <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>
 
 
 <112200E8-0E1D-4A38-800D-54892BFF67F6@gmail.com>
In-Reply-To: <112200E8-0E1D-4A38-800D-54892BFF67F6@gmail.com>

--K3cjR6hn7OsvQHlghiKN58MaWJNL7SfDI
Content-Type: multipart/alternative;
 boundary="------------7EB59F17637EB9AE94300361"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------7EB59F17637EB9AE94300361
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Kathleen,

So the plan is to close reap and use emu?

Eliot


On 10/27/17 3:43 AM, Kathleen Moriarty wrote:
> That sounds like the best plan.
>
> Thank you,
> Kathleen=C2=A0
>
> Sent from my iPhone
>
> On Oct 26, 2017, at 9:16 PM, Bernard Aboba  > wrote:
>
>> Yes, the EMU WG=C2=A0 list has been used for discussion of EAP methods=

>> since the WG closed.=C2=A0
>>
>> That list is a better venue for discussion of EAP=C2=A0 methods than a=
 new
>> REAP list, so as to ensure that proper attention is paid to backward
>> compatibility, IPR, security properties and other critical aspects of
>> EAP method design.=C2=A0
>>
>> After all, we are talking about a protocol that is 20+ years old that
>> is implemented on billions of devices, many of which utilize
>> open-source.=C2=A0=C2=A0
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty
>> > > wrote:
>>
>>     On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi
>>     >
>>     wrote:
>>     > Hi Bernard,
>>     >
>>     > The EAP-TLS 1.3 document is a very rough drafty version that
>>     was submitted
>>     > before the cut-off for the last IETF. As you rightly point out,
>>     it has the
>>     > skeleton and a lot of material from RFC5216, and still many
>>     important
>>     > details are missing.
>>     >
>>     > The purpose of this list is to exactly receive these kind of
>>     comments.
>>     > Should RFC5216 be updated or obsoleted by this draft. And it
>>     would be great
>>     > if we can have your contributions to the document. We will
>>     definitely add an
>>     > acknowledgement section and contact the authors of RFC5216 to
>>     see if they
>>     > can contribute and comment. We plan to have more EAP related
>>     contributions
>>     > in the near future. We discussed this with the Security ADs and
>>     thought that
>>     > a separate list would be appropriate to get feedback/criticism a=
nd
>>     > contributions from the folks interested.
>>
>>     I'm sorry, I didn't realize that a revision of 5216 was involved a=
nd
>>     that the authors were not notified at the onset as is normal pract=
ice
>>     in case they want to continue as authors.=C2=A0 Thank you for spot=
ting
>>     this
>>     issue Bernard.
>>
>>     Is there an existing list that should be used?=C2=A0 Is there adeq=
uate
>>     overlap in objectives and personnel?
>>
>>     Thank you,
>>     Kathleen
>>
>>     >
>>     > --Mohit
>>     >
>>     >
>>     > On 10/26/2017 06:51 PM, Bernard Aboba wrote:
>>     >
>>     > There are existing functioning IETF mailing lists relating to EA=
P.
>>     >
>>     > Why are you starting yet another one?
>>     >
>>     > From what I can tell, the EAP-TLS 1.3 draft is merely a copy of
>>     RFC 5216
>>     > (with no acknowledgement to the original authors) stating that
>>     EAP-TLS
>>     > implementations must support TLS 1.3.
>>     >
>>     > This is ridiculous because there are 1+ Billion existing
>>     implementations out
>>     > there that
>>     >
>>     >
>>     > On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi
>>     >
>>     > wrote:
>>     >>
>>     >> Dear all,
>>     >>
>>     >> We have started a mailing list for discussing new EAP related
>>     work that
>>     >> currently has no obvious home. The mailing list is called REAP
>>     (Renew EAP)
>>     >> reap@ietf.org  and you can subscribe here=
:
>>     >> https://www.ietf.org/mailman/listinfo/reap
>>     
>>     >>
>>     >> Recently several new EAP methods have been proposed. These
>>     include for
>>     >> example:
>>     >>
>>     >> EAP-TLS 1.3:
>>     https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>>     
>>     >>
>>     >> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>>     
>>     >>
>>     >> EAP-SASL:
>>     https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>>     
>>     >>
>>     >> The list serves as a venue for discussion of these and other
>>     EAP related
>>     >> drafts that will be submitted in the near future. As courtesy,
>>     we will post
>>     >> any new draft to SAAG, but we plan to continue the discussion
>>     only on the
>>     >> REAP mailing list. We have also asked for a short presentation
>>     slot during
>>     >> SECDISPATCH at IETF 100 in Singapore.
>>     >>
>>     >> Comments, early feedback, and discussion on existing or new
>>     work is more
>>     >> than welcome.
>>     >>
>>     >> --Mohit
>>     >>
>>     >> _______________________________________________
>>     >> saag mailing list
>>     >> saag@ietf.org 
>>     >> https://www.ietf.org/mailman/listinfo/saag
>>     
>>     >
>>     >
>>     >
>>     >
>>     > _______________________________________________
>>     > saag mailing list
>>     > saag@ietf.org 
>>     > https://www.ietf.org/mailman/listinfo/saag
>>     
>>     >
>>     >
>>     >
>>     > _______________________________________________
>>     > saag mailing list
>>     > saag@ietf.org 
>>     > https://www.ietf.org/mailman/listinfo/saag
>>     
>>     >
>>
>>
>>
>>     --
>>
>>     Best regards,
>>     Kathleen
>>
>>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag


--------------7EB59F17637EB9AE94300361
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Kathleen,

    
So the plan is to close reap and use emu?

    
Eliot

    

    

    
On 10/27/17 3:43 AM, Kathleen Moriarty=

      wrote:

    

    

      
      
That sounds like the best plan.

      


      

      
Thank you,

      
Kathleen=C2=A0

        

        Sent from my iPhone

      


        On Oct 26, 2017, at 9:16 PM, Bernard Aboba <bernard.aboba@gmail.com>
        wrote:

        

      

      

        

          
Yes, the EMU WG=C2=A0 list has been used for
            discussion of EAP methods since the WG closed.=C2=A0
            


            

            
That list is a better venue for discussion of EAP=C2=A0
              methods than a new REAP list, so as to ensure that proper
              attention is paid to backward compatibility, IPR, security
              properties and other critical aspects of EAP method
              design.=C2=A0

            


            

            
After all, we are talking about a protocol that is 20+
              years old that is implemented on billions of devices, many
              of which utilize open-source.=C2=A0=C2=A0

            


            

            


            

            


            

            


            

            


              


              

              


              

            

          

          


            
On Thu, Oct 26, 2017 at 11:53 AM,
              Kathleen Moriarty <kathleen.mor=
iarty.ietf@gmail.com>
              wrote:

              
On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi=

                  <mohit.m.sethi@ericsson.com>
                  wrote:

                  > Hi Bernard,

                  >

                  > The EAP-TLS 1.3 document is a very rough drafty
                  version that was submitted

                  > before the cut-off for the last IETF. As you
                  rightly point out, it has the

                  > skeleton and a lot of material from RFC5216, and
                  still many important

                  > details are missing.

                  >

                  > The purpose of this list is to exactly receive
                  these kind of comments.

                  > Should RFC5216 be updated or obsoleted by this
                  draft. And it would be great

                  > if we can have your contributions to the
                  document. We will definitely add an

                  > acknowledgement section and contact the authors
                  of RFC5216 to see if they

                  > can contribute and comment. We plan to have more
                  EAP related contributions

                  > in the near future. We discussed this with the
                  Security ADs and thought that

                  > a separate list would be appropriate to get
                  feedback/criticism and

                  > contributions from the folks interested.

                  

                I'm sorry, I didn't realize that a revision of
                5216 was involved and

                that the authors were not notified at the onset as is
                normal practice

                in case they want to continue as authors.=C2=A0 Thank you=
 for
                spotting this

                issue Bernard.

                

                Is there an existing list that should be used?=C2=A0 Is t=
here
                adequate

                overlap in objectives and personnel?

                

                Thank you,

                Kathleen

                

                  


                    >

                    > --Mohit

                    >

                    >

                    > On 10/26/2017 06:51 PM, Bernard Aboba wrote:
=

                    >

                    > There are existing functioning IETF mailing
                    lists relating to EAP.

                    >

                    > Why are you starting yet another one?

                    >

                    > From what I can tell, the EAP-TLS 1.3 draft is
                    merely a copy of RFC 5216

                    > (with no acknowledgement to the original
                    authors) stating that EAP-TLS

                    > implementations must support TLS 1.3.

                    >

                    > This is ridiculous because there are 1+ Billion
                    existing implementations out

                    > there that

                    >

                    >

                    > On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi
                    <mohit.m.sethi@ericsson.com=
>

                    > wrote:

                    >>

                    >> Dear all,

                    >>

                    >> We have started a mailing list for
                    discussing new EAP related work that

                    >> currently has no obvious home. The mailing
                    list is called REAP (Renew EAP)

                    >> reap@ietf.org and you
                    can subscribe here:

                    >> https://www.ietf.org/mailm=
an/listinfo/reap

                    >>

                    >> Recently several new EAP methods have been
                    proposed. These include for

                    >> example:

                    >>

                    >> EAP-TLS 1.3: https://tools.ietf.org/htm=
l/draft-mattsson-eap-tls13-00

                    >>

                    >> EAP-NOOB: https://tools.ietf.org/htm=
l/draft-aura-eap-noob-02

                    >>

                    >> EAP-SASL: https://tools.ietf.org/htm=
l/draft-vanrein-eap-sasl-00

                    >>

                    >> The list serves as a venue for discussion
                    of these and other EAP related

                    >> drafts that will be submitted in the near
                    future. As courtesy, we will post

                    >> any new draft to SAAG, but we plan to
                    continue the discussion only on the

                    >> REAP mailing list. We have also asked for a
                    short presentation slot during

                    >> SECDISPATCH at IETF 100 in Singapore.

                    >>

                    >> Comments, early feedback, and discussion on
                    existing or new work is more

                    >> than welcome.

                    >>

                    >> --Mohit

                    >>

                    >> _______________________________________=
________

                    >> saag mailing list

                    >> saag@ietf.org

                    >> https://www.ietf.org/mailm=
an/listinfo/saag

                    >

                    >

                    >

                    >

                    > ___________________________________________=
____

                    > saag mailing list

                    > saag@ietf.org

                    > https://www.ietf.org/mailm=
an/listinfo/saag

                    >

                    >

                    >

                    > ___________________________________________=
____

                    > saag mailing list

                    > saag@ietf.org

                    > https://www.ietf.org/mailm=
an/listinfo/saag

                    >

                    

                    

                    

                  

                

                --

                    

                    Best regards,

                    Kathleen

                  

            

            

          

        

      

      

      

      

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


    

    

  


--------------7EB59F17637EB9AE94300361--

--K3cjR6hn7OsvQHlghiKN58MaWJNL7SfDI--

--TVqle0GMKRf7OxwCq5whJ0CgU3iw7iVM1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ8x6cAAoJEIe2a0bZ0noz5fwH/1sppW7lDrShjLE2wZua9YUI
msGrFTVz+nvKG+SLXMyVZblCUTg/WckyYCthZ3btIQPjPAppeVVXS1HkhFz+/p6D
L0obIvnUqtpRVyJyh1qapzMRQRXq4ubXI/CcGyQbmCBbzBkUy78v+z/whnhM0r/7
j9yviks73AVWkP+WLd6v3tq6C00IFcwd/JZF9E8QGtbbIvNJltw7v2mPHl9hiN3w
khSH7asECzh4rluEhihF1RAqybxeqqtwsdsZLAyCvhY27NQF+tsS9U3FDJXX0gn1
71DPr9bdMXznecRru8OisUaE8abyD4JlcWq7kNcw94NZoDKj0jljVKtHJlJO5s8=
=eP9o
-----END PGP SIGNATURE-----

--TVqle0GMKRf7OxwCq5whJ0CgU3iw7iVM1--


From nobody Fri Oct 27 05:16:55 2017
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 BD93713B13E; Fri, 27 Oct 2017 05:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level: 
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYXRqJSfWO92; Fri, 27 Oct 2017 05:16:46 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 CF253138BD8; Fri, 27 Oct 2017 05:16:46 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id j126so10544494oib.8; Fri, 27 Oct 2017 05:16:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Yc0YEwQg9Ae/vBs3D1SCwAE5yYQ0JqzP5ERo9QcvGm0=; b=OMHQdhH0hFTZ4DYGu5qXIc/Bp/GuE7LO/AxVGyqMbyIp1VUQXrKMV2i+UJoInxqs8I KM2/62pVi/haQ9sYDH7f+IJm0H4jeqKgzX8MZtYFQbG/7JWyHEtvJiDIJ8u5mG2Dg9lv xxrfWxTEgXcOI1Q0ESWbjbeXdLMQcbgpzowzdcfuFH7kc6QXR7brhCSlg9F9oN71/ucn LOIHKi1xPClDRXyNxNglmypRn7FsrfGM9zUwCE5Sdf/mlXTO8FVFiOg5T5D87LojR06M CAB8Mbw+attn/PFcK0Qjb/1HbdBwfCBeD3EmvOwuSvERJKNUVUAZ0GzBod1SWdxjlvLQ T/SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Yc0YEwQg9Ae/vBs3D1SCwAE5yYQ0JqzP5ERo9QcvGm0=; b=q5ZuOabZSd4cT+GxKT9aU6Lbg93vw/1aAcLR6JUFNQZAPA65Y11CzTULDyIH5mmBds y+OBEl7emO5f/NIoplOmIE6e6MoltFChqN78c0sTdykF+fx6S2U16wQ84j5vVrb+ZZwF czXQVncwFqRTCyVIuRv6IhCVWzITHGfASbZ0UYEk29Bm1RD7vMSNQRaGs57XWrp2VF+V jHLaSWwtILt4Xmz3wJHu5LbJRu8MiAdycuVC8nptigEQxpud/FgjhywHBU/AqG4idNtI AHLJ7PV/3YdnXLtpgb7IQg3ztswPr7nCLe7T2W2ION4q0EMpKYkK/HM5nrKrk0X3YR6s rIfA==
X-Gm-Message-State: AMCzsaVe9iKr2GBxCs2d+xJ6hUSu7qtzuZEpTW/DvhnMscCq54DMaQD6 rIFm6ljV8eRLxf8Z108KGHl4ycIW7w8UP6Fmmpk=
X-Google-Smtp-Source: ABhQp+Smc5xV3bKf038wf3vDSsYZ3oxaF3JG85DIbyGnH+mB2QO1amOQwf1qWjYvKfEJGS+5Pr3zZvUVJfGbzgyK9/0=
X-Received: by 10.157.17.72 with SMTP id p8mr163963otp.305.1509106606078; Fri, 27 Oct 2017 05:16:46 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.80.42 with HTTP; Fri, 27 Oct 2017 05:16:45 -0700 (PDT)
In-Reply-To: <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org>
References: <10f5c653-e2b7-9332-02b0-5528e6693582@openca.org> <3D9CC81C-404A-48D0-9F45-14829FADC646@vpnc.org>
From: Phillip Hallam-Baker 
Date: Fri, 27 Oct 2017 08:16:45 -0400
X-Google-Sender-Auth: VtwmmqA_KcMJ1rv_AjrzLhtJlxE
Message-ID: 
To: Paul Hoffman 
Cc: "Dr. Pala" , "saag@ietf.org" , SPASM 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [saag] Proposal for OCSP over DNS
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Oct 2017 12:16:49 -0000

On Mon, Oct 23, 2017 at 5:13 PM, Paul Hoffman  wrote:
> On 23 Oct 2017, at 13:54, Dr. Pala wrote:
>
>> we are currently working on specifying how to use DNS as a transport
>> protocol for revocation information for X509 certificates. In particular, we
>> are working on how to leverage the distributed nature of DNS to efficiently
>> (and at lower operational costs) distribute OCSP responses to
>> applications/devices/etc.
>>
>> We started this work sometime ago but never really had the time to finish
>> it. Now it seems we can focus more on the topic and would like to discuss
>> this work in a more public venue.
>>
>> We currently have two similar I-D submitted (that should probably be
>> re-edited and merged):
>>
>>  * https://datatracker.ietf.org/doc/draft-pala-odin/
>>  * https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dns/
>>
>> EKR suggested that this may be another topic for the SEC-DISPATCH meeting.
>> Can we have 5-10 minutes for this @IETF100 ?
>
>
> These sound like "we want HTTP over UDP to save latency, so we'll just
> substitute DNS". That's certainly an option, but it hasn't been a popular
> route in the IETF. Are the busy CAs asking for this? Is there a reason why
> they can't just beef up their web infrastructure (like their customers are)?

Since QUIC is 'TCP++ over UDP' and flavor of the month, OCSP over QUIC
is probably a more viable route.

The expiry of the Micali and Kocher efficient revocation patents mean
that we now have options beyond OCSP which is what we are currently
focused on at Comodo.


I have proposed OCSP over DNS several times in the past. The problem I
ran into was that the chief concern of the browser providers is
latency. And some are unwilling to accept any proposal that increases
latency in any way for the sake of public safety.

Attempting to use DNS as transport is highly problematic. Many
networks block unknown RRs for a start. It is hard enough to get
DNSSEC to work right.

That led me to an approach where the OCSP and DNS lookups were
combined into one UDP transaction to a trusted discovery service
combining DNS lookup, OCSP and certificate fetch, aka 'omnibroker'.
That is an approach I will probably be revisiting in the near future.


From nobody Fri Oct 27 11:08:39 2017
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 A369413F088; Fri, 27 Oct 2017 11:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TUXVOjBGOAu; Fri, 27 Oct 2017 11:08:30 -0700 (PDT)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 C34E913F3AC; Fri, 27 Oct 2017 11:08:29 -0700 (PDT)
Received: by mail-pg0-x236.google.com with SMTP id y5so5856124pgq.7; Fri, 27 Oct 2017 11:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mfLuGKQymS9Pve+iWDqSwLU/XAqvuuWAL12NUZs79G0=; b=it3+p7qq+tMWWu24Y/lXtbqNbyWlsYlhks9/BN45T40MjVbPzIMmJkvWIk1z5bYoNW Pk2oPLbxaQzIAbQO5UpuN0nzm30jZtiyN4hqCKAxgWBo+LlD6ZyCvUgTIXSrv0YM7K2H Q4TmmQjf3CMgtM+qil7CmS2yc7fGoelopfXTielJFDnLhOGKunckQkNWwfwSAPQyasxQ T/Rju/CEMTzSra4GAwhwvE9MN46hSI9FJx5QQixPJIR/9q6heMa231DHCsrPqUqwVUah xlwgKhDlMK4VOwQOTgJf1L4CQpYcQ+KMrGPMQzy/5pli4w+U1RQ0tefYNr7JncHBZ7i5 Sipg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mfLuGKQymS9Pve+iWDqSwLU/XAqvuuWAL12NUZs79G0=; b=OkgBrotfqyVANY+5tTTf+0bluDN17DAfwJktDfvHNcWPaaJzrB0OugXrYCW1YJ3Xgi f979Y0OMzrWCGhAiF1gtj/Pl6l0Loi87q/YUzXvEB74H/F5z8MKK7PunIMf1lGgOXzA5 cRrVHbJnQ5ojhSPjICVRBqCMRSBwI7f6ryzL9kio69mz3klliuYYmmTfa9fxR3ee+hgg E+dMjWv+CjyTjGKAFqNDN0NWDgLpHox1RXGmORT/uQEOcwVk6PEgdUKerW5sfKpufWWs of1HNPTiwLC0g3zT3KsVtc/WNBm0GpgVH0HxTW9rORep+fY1Kwdv4bEBk9PCUdum2vqS zG9Q==
X-Gm-Message-State: AMCzsaWxgmprggTPlozZBGTQlZv1FI1m64lC3bEWW+K5uYOM7mYk+TMM POawfna2VqM5HAprZjTWcBh0nFpFsAVcZE1FpBk=
X-Google-Smtp-Source: ABhQp+TJw88MYEwrb3/WH/vr73KxRatVu52bcF93PJKkDVnO9VaeD8ryS0f2nffXeiafHytAsHNTuM9vL92znxUh9os=
X-Received: by 10.98.201.87 with SMTP id k84mr1225147pfg.109.1509127709345; Fri, 27 Oct 2017 11:08:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.194 with HTTP; Fri, 27 Oct 2017 11:07:48 -0700 (PDT)
In-Reply-To: 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>   <112200E8-0E1D-4A38-800D-54892BFF67F6@gmail.com> 
From: Kathleen Moriarty 
Date: Fri, 27 Oct 2017 14:07:48 -0400
Message-ID: 
To: Eliot Lear 
Cc: Bernard Aboba , reap@ietf.org,  Mohit Sethi , "saag@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Oct 2017 18:08:33 -0000

EKR and I chatted and agree using EMU is the best go forward plan.
Thank you for raising the issue that slipped by us.

Best regards,
Kathleen

On Fri, Oct 27, 2017 at 7:55 AM, Eliot Lear  wrote:
> Kathleen,
>
> So the plan is to close reap and use emu?
>
> Eliot
>
>
> On 10/27/17 3:43 AM, Kathleen Moriarty wrote:
>
> That sounds like the best plan.
>
> Thank you,
> Kathleen
>
> Sent from my iPhone
>
> On Oct 26, 2017, at 9:16 PM, Bernard Aboba  wrote:
>
> Yes, the EMU WG  list has been used for discussion of EAP methods since the
> WG closed.
>
> That list is a better venue for discussion of EAP  methods than a new REAP
> list, so as to ensure that proper attention is paid to backward
> compatibility, IPR, security properties and other critical aspects of EAP
> method design.
>
> After all, we are talking about a protocol that is 20+ years old that is
> implemented on billions of devices, many of which utilize open-source.
>
>
>
>
>
>
>
>
> On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty
>  wrote:
>>
>> On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi 
>> wrote:
>> > Hi Bernard,
>> >
>> > The EAP-TLS 1.3 document is a very rough drafty version that was
>> > submitted
>> > before the cut-off for the last IETF. As you rightly point out, it has
>> > the
>> > skeleton and a lot of material from RFC5216, and still many important
>> > details are missing.
>> >
>> > The purpose of this list is to exactly receive these kind of comments.
>> > Should RFC5216 be updated or obsoleted by this draft. And it would be
>> > great
>> > if we can have your contributions to the document. We will definitely
>> > add an
>> > acknowledgement section and contact the authors of RFC5216 to see if
>> > they
>> > can contribute and comment. We plan to have more EAP related
>> > contributions
>> > in the near future. We discussed this with the Security ADs and thought
>> > that
>> > a separate list would be appropriate to get feedback/criticism and
>> > contributions from the folks interested.
>>
>> I'm sorry, I didn't realize that a revision of 5216 was involved and
>> that the authors were not notified at the onset as is normal practice
>> in case they want to continue as authors.  Thank you for spotting this
>> issue Bernard.
>>
>> Is there an existing list that should be used?  Is there adequate
>> overlap in objectives and personnel?
>>
>> Thank you,
>> Kathleen
>>
>> >
>> > --Mohit
>> >
>> >
>> > On 10/26/2017 06:51 PM, Bernard Aboba wrote:
>> >
>> > There are existing functioning IETF mailing lists relating to EAP.
>> >
>> > Why are you starting yet another one?
>> >
>> > From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5216
>> > (with no acknowledgement to the original authors) stating that EAP-TLS
>> > implementations must support TLS 1.3.
>> >
>> > This is ridiculous because there are 1+ Billion existing implementations
>> > out
>> > there that
>> >
>> >
>> > On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi
>> > 
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> We have started a mailing list for discussing new EAP related work that
>> >> currently has no obvious home. The mailing list is called REAP (Renew
>> >> EAP)
>> >> reap@ietf.org and you can subscribe here:
>> >> https://www.ietf.org/mailman/listinfo/reap
>> >>
>> >> Recently several new EAP methods have been proposed. These include for
>> >> example:
>> >>
>> >> EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>> >>
>> >> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>> >>
>> >> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>> >>
>> >> The list serves as a venue for discussion of these and other EAP
>> >> related
>> >> drafts that will be submitted in the near future. As courtesy, we will
>> >> post
>> >> any new draft to SAAG, but we plan to continue the discussion only on
>> >> the
>> >> REAP mailing list. We have also asked for a short presentation slot
>> >> during
>> >> SECDISPATCH at IETF 100 in Singapore.
>> >>
>> >> Comments, early feedback, and discussion on existing or new work is
>> >> more
>> >> than welcome.
>> >>
>> >> --Mohit
>> >>
>> >> _______________________________________________
>> >> saag mailing list
>> >> saag@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/saag
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > saag mailing list
>> > saag@ietf.org
>> > https://www.ietf.org/mailman/listinfo/saag
>> >
>> >
>> >
>> > _______________________________________________
>> > saag mailing list
>> > saag@ietf.org
>> > https://www.ietf.org/mailman/listinfo/saag
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>



-- 

Best regards,
Kathleen


From nobody Sat Oct 28 02:01:11 2017
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 14B6013AB36; Sat, 28 Oct 2017 02:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVX38joHEYBv; Sat, 28 Oct 2017 02:01:01 -0700 (PDT)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194CD1395ED; Sat, 28 Oct 2017 02:01:01 -0700 (PDT)
Received: by mail-vk0-x22a.google.com with SMTP id h142so2076805vkf.7; Sat, 28 Oct 2017 02:01:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GQPVS9z3WKVynxCRTm4otDRR2eRsFMWgbwy4vWA7o8U=; b=D1fFb0sGFJ10CLihI+Q1ybwCS9XDhQmD1oq6gEY2rPzdSct7+HHY2wKpMsrd6u4M7t PmNY29JObWUO5GtmwKNLBeD9E8wIkb6Rfn/5YbrbGXfQi6domI3Z+ESqkR4DTGySxJtO aiEeCYCR7Szpe+k3wAE9vKEiCnhEQeUvMYJ0SltmjFGQwbuOIzIk0lF2fHvHPgFpGbI4 dYlOkPa91iDM3MEgp289emR/ps/Q/bAY0m75kc6MeqSGAetOkxEFad03TeLJ7+gMwkA4 GwbaLojGMivWBwqrLQR+pwhEYCH9+iHmLusgYUazGlj413od2lJJbVJDSsFQZ2soPUIp jDQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GQPVS9z3WKVynxCRTm4otDRR2eRsFMWgbwy4vWA7o8U=; b=nmd/WV9ExnpiJSnZQxEd9/7RuGoDZyOh94MGvM8l+vD3eHG85Nwn7g2CmZNZ1eEGUk Y2HhliwX/iJkMWpHXw8NOpKPuTzb2KABKjrQjlso3lbY9vp5r0VF5TAiTS2LsfKxpS2j Or2SAr+7EGrYNgNDvp5Glt0NJtGsEoyUOrcyIO1vQW4rV3kret9K0lsv/QzVKu2oMAU/ 1G6tKXZIwqWeUz9KaDYqnssXi256TQo/VhyysgPTfa0xO1TWCbcQMU8LJtUldswF60ay R9vasHE60sQE2nwxPBofX5MGyhwRukOjl784BqWmBIgsX7umb9uoDgPwX3bzGfDWgRlB DlAw==
X-Gm-Message-State: AMCzsaV05aDA1yvcFf0I6rYssbJUDSFK5p5q8xPWQt11j8LchegiTHnl PsysD18ndxkDS+Fu24ZTy9kEFXMEyK/57JpCs/E=
X-Google-Smtp-Source: ABhQp+SSWnDZeBWfM97aTgh189/7IMuUbtdCb7dnDOVk80GNXgL6R1cMAt7pxGeJu5TaOBsJj9YfQPQbFGBHuQCaNnc=
X-Received: by 10.31.70.133 with SMTP id t127mr2691863vka.100.1509181260169; Sat, 28 Oct 2017 02:01:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.84.143 with HTTP; Sat, 28 Oct 2017 02:00:59 -0700 (PDT)
In-Reply-To: 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>  
From: Zhen Cao 
Date: Sat, 28 Oct 2017 17:00:59 +0800
Message-ID: 
To: Bernard Aboba 
Cc: Kathleen Moriarty , reap@ietf.org,  Mohit Sethi , "saag@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Oct 2017 09:01:03 -0000

Thanks Bernard for pointing out this, at least new to me. I check the
emu wg conclusion email, not formally stating that emu will be the
only place for eap-related discussion.

The emu list has been quite silent since the wg conclusion, less than
20 messages for three years.  There were occasionally some drafts
posted for comments, but not any follow-up responses.  This leaves an
impression that either the list members are not interested in new
topics or the emu list is not actually adequately subscribed (who has
the ground truth?).    I believe this is not only a motive for Mohit
and I to request a new mailing list, but may also confuse upcoming
people who seek for a place to have discussion.

Regards,
-Zhen
On Fri, Oct 27, 2017 at 9:16 AM, Bernard Aboba  wrote:
> Yes, the EMU WG  list has been used for discussion of EAP methods since the
> WG closed.
>
> That list is a better venue for discussion of EAP  methods than a new REAP
> list, so as to ensure that proper attention is paid to backward
> compatibility, IPR, security properties and other critical aspects of EAP
> method design.
>
> After all, we are talking about a protocol that is 20+ years old that is
> implemented on billions of devices, many of which utilize open-source.
>
>
>
>
>
>
>
>
> On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty
>  wrote:
>>
>> On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi 
>> wrote:
>> > Hi Bernard,
>> >
>> > The EAP-TLS 1.3 document is a very rough drafty version that was
>> > submitted
>> > before the cut-off for the last IETF. As you rightly point out, it has
>> > the
>> > skeleton and a lot of material from RFC5216, and still many important
>> > details are missing.
>> >
>> > The purpose of this list is to exactly receive these kind of comments.
>> > Should RFC5216 be updated or obsoleted by this draft. And it would be
>> > great
>> > if we can have your contributions to the document. We will definitely
>> > add an
>> > acknowledgement section and contact the authors of RFC5216 to see if
>> > they
>> > can contribute and comment. We plan to have more EAP related
>> > contributions
>> > in the near future. We discussed this with the Security ADs and thought
>> > that
>> > a separate list would be appropriate to get feedback/criticism and
>> > contributions from the folks interested.
>>
>> I'm sorry, I didn't realize that a revision of 5216 was involved and
>> that the authors were not notified at the onset as is normal practice
>> in case they want to continue as authors.  Thank you for spotting this
>> issue Bernard.
>>
>> Is there an existing list that should be used?  Is there adequate
>> overlap in objectives and personnel?
>>
>> Thank you,
>> Kathleen
>>
>> >
>> > --Mohit
>> >
>> >
>> > On 10/26/2017 06:51 PM, Bernard Aboba wrote:
>> >
>> > There are existing functioning IETF mailing lists relating to EAP.
>> >
>> > Why are you starting yet another one?
>> >
>> > From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5216
>> > (with no acknowledgement to the original authors) stating that EAP-TLS
>> > implementations must support TLS 1.3.
>> >
>> > This is ridiculous because there are 1+ Billion existing implementations
>> > out
>> > there that
>> >
>> >
>> > On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi
>> > 
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> We have started a mailing list for discussing new EAP related work that
>> >> currently has no obvious home. The mailing list is called REAP (Renew
>> >> EAP)
>> >> reap@ietf.org and you can subscribe here:
>> >> https://www.ietf.org/mailman/listinfo/reap
>> >>
>> >> Recently several new EAP methods have been proposed. These include for
>> >> example:
>> >>
>> >> EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>> >>
>> >> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>> >>
>> >> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>> >>
>> >> The list serves as a venue for discussion of these and other EAP
>> >> related
>> >> drafts that will be submitted in the near future. As courtesy, we will
>> >> post
>> >> any new draft to SAAG, but we plan to continue the discussion only on
>> >> the
>> >> REAP mailing list. We have also asked for a short presentation slot
>> >> during
>> >> SECDISPATCH at IETF 100 in Singapore.
>> >>
>> >> Comments, early feedback, and discussion on existing or new work is
>> >> more
>> >> than welcome.
>> >>
>> >> --Mohit
>> >>
>> >> _______________________________________________
>> >> saag mailing list
>> >> saag@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/saag
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > saag mailing list
>> > saag@ietf.org
>> > https://www.ietf.org/mailman/listinfo/saag
>> >
>> >
>> >
>> > _______________________________________________
>> > saag mailing list
>> > saag@ietf.org
>> > https://www.ietf.org/mailman/listinfo/saag
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>


From nobody Sat Oct 28 12:16:56 2017
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 D151B13FD3A; Sat, 28 Oct 2017 12:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZjB1skyPNpu; Sat, 28 Oct 2017 12:16:47 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 7EF091380DB; Sat, 28 Oct 2017 12:16:47 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id x7so7457761pfa.1; Sat, 28 Oct 2017 12:16:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FKa29m46l6F9SHCIM33T1NIKaZE60XVhkZzlk8SXVa8=; b=tdxm49HAy2ZiyITjarl9N5lSDp32ybY9lMvuY2RcRtRhdcmx03QMWKLRNPpJGe61Tt X0aA3yQ2/zaKEBay7/t6r90zoG0SVe4R+LIRHOOcKc8necT/PpRmJ+DhRzy7WHhko/+2 0VSZBkMWSvAyVmyOFkF8NnbZIt646GP9VGffhcjOJhn2OtGKO3/TpMKLEaTXwOyaLJzc YWph9KgyRkipPYqSdHIQhB3IhRilODY3BNuVvUPoyL24TE/1YS42GCJvSBGrXOqBwfYT jz1JFlgbPDrteZ5eVrWghGUmcM+wtSg3+iwf5POXFzeKZRnTJtPIDohY5JpouC96buh/ D8DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FKa29m46l6F9SHCIM33T1NIKaZE60XVhkZzlk8SXVa8=; b=QcrI//KlQ53op0VplsK2PnGZ8Fgonq3CR1UjzDFLqJxgPgpxHIN6As3KKPlPeek5tY CmI1Q/CyX/cHl5c2R8RV4Y37X+Q5J58F3vdWmzT8XLK7JXmiAB/eB0HoEWJc1Lg3yhi2 Wqt/d9tyJ9KNP6agk5pMhHO1Hy8kDsgKckClbGbBfWXX5r5mWL4anpxJDi85YQdvyzWN DNYHFc+JeReOJmjvdOt3n8Uru5iZ/Gw+XbRl+zzVQoLJrO6IYOO9jsCdpA4hywcxC1kX FutBBZapp8bMwk3PpVPL8DLjL3zenTG/4hAVH5kgYCpsJ5ge3i7PhId0F8jrFn8bE7M1 OwHw==
X-Gm-Message-State: AMCzsaW1sOPGjOSngI4btCyxK+aqCg26JUo4kxwriiMNqsHWMtP1kaCs rCaPMkKmg21gXBkw4hUISk1gBWNY
X-Google-Smtp-Source: ABhQp+T9romOCHyDIbdixrMSPJWl81KC+KynK8rZr4wkPKXrR6uuSVT+f5W3qTf5Lu4c7McMYYTglg==
X-Received: by 10.98.161.24 with SMTP id b24mr4211025pff.297.1509218206518; Sat, 28 Oct 2017 12:16:46 -0700 (PDT)
Received: from [192.168.1.104] (c-24-17-217-136.hsd1.wa.comcast.net. [24.17.217.136]) by smtp.gmail.com with ESMTPSA id 76sm21088014pfq.4.2017.10.28.12.16.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Oct 2017 12:16:45 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Bernard Aboba 
X-Mailer: iPhone Mail (15A432)
In-Reply-To: 
Date: Sat, 28 Oct 2017 12:16:44 -0700
Cc: Kathleen Moriarty , reap@ietf.org, Mohit Sethi , "saag@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>   
To: Zhen Cao 
Archived-At: 
Subject: Re: [saag] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Oct 2017 19:16:50 -0000

The IANA EAP page lists the policies for EAP code point allocations and poin=
ts to RFC 3748 as the document relevant to method type allocations.

RFC 3748 Section 6 describes the EAP method type registration and review pro=
cess, requiring method reviews to be posted to a designated list. Originally=
 the EAP mailing list was designated, and then EMU was subsequently designat=
ed as the successor list.=20

> On Oct 28, 2017, at 2:00 AM, Zhen Cao  wrote:
>=20
> Thanks Bernard for pointing out this, at least new to me. I check the
> emu wg conclusion email, not formally stating that emu will be the
> only place for eap-related discussion.
>=20
> The emu list has been quite silent since the wg conclusion, less than
> 20 messages for three years.  There were occasionally some drafts
> posted for comments, but not any follow-up responses.  This leaves an
> impression that either the list members are not interested in new
> topics or the emu list is not actually adequately subscribed (who has
> the ground truth?).    I believe this is not only a motive for Mohit
> and I to request a new mailing list, but may also confuse upcoming
> people who seek for a place to have discussion.
>=20
> Regards,
> -Zhen
>> On Fri, Oct 27, 2017 at 9:16 AM, Bernard Aboba  w=
rote:
>> Yes, the EMU WG  list has been used for discussion of EAP methods since t=
he
>> WG closed.
>>=20
>> That list is a better venue for discussion of EAP  methods than a new REA=
P
>> list, so as to ensure that proper attention is paid to backward
>> compatibility, IPR, security properties and other critical aspects of EAP=

>> method design.
>>=20
>> After all, we are talking about a protocol that is 20+ years old that is
>> implemented on billions of devices, many of which utilize open-source.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty
>>  wrote:
>>>=20
>>> On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi 
>>> wrote:
>>>> Hi Bernard,
>>>>=20
>>>> The EAP-TLS 1.3 document is a very rough drafty version that was
>>>> submitted
>>>> before the cut-off for the last IETF. As you rightly point out, it has
>>>> the
>>>> skeleton and a lot of material from RFC5216, and still many important
>>>> details are missing.
>>>>=20
>>>> The purpose of this list is to exactly receive these kind of comments.
>>>> Should RFC5216 be updated or obsoleted by this draft. And it would be
>>>> great
>>>> if we can have your contributions to the document. We will definitely
>>>> add an
>>>> acknowledgement section and contact the authors of RFC5216 to see if
>>>> they
>>>> can contribute and comment. We plan to have more EAP related
>>>> contributions
>>>> in the near future. We discussed this with the Security ADs and thought=

>>>> that
>>>> a separate list would be appropriate to get feedback/criticism and
>>>> contributions from the folks interested.
>>>=20
>>> I'm sorry, I didn't realize that a revision of 5216 was involved and
>>> that the authors were not notified at the onset as is normal practice
>>> in case they want to continue as authors.  Thank you for spotting this
>>> issue Bernard.
>>>=20
>>> Is there an existing list that should be used?  Is there adequate
>>> overlap in objectives and personnel?
>>>=20
>>> Thank you,
>>> Kathleen
>>>=20
>>>>=20
>>>> --Mohit
>>>>=20
>>>>=20
>>>> On 10/26/2017 06:51 PM, Bernard Aboba wrote:
>>>>=20
>>>> There are existing functioning IETF mailing lists relating to EAP.
>>>>=20
>>>> Why are you starting yet another one?
>>>>=20
>>>> =46rom what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5=
216
>>>> (with no acknowledgement to the original authors) stating that EAP-TLS
>>>> implementations must support TLS 1.3.
>>>>=20
>>>> This is ridiculous because there are 1+ Billion existing implementation=
s
>>>> out
>>>> there that
>>>>=20
>>>>=20
>>>> On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi
>>>> 
>>>> wrote:
>>>>>=20
>>>>> Dear all,
>>>>>=20
>>>>> We have started a mailing list for discussing new EAP related work tha=
t
>>>>> currently has no obvious home. The mailing list is called REAP (Renew
>>>>> EAP)
>>>>> reap@ietf.org and you can subscribe here:
>>>>> https://www.ietf.org/mailman/listinfo/reap
>>>>>=20
>>>>> Recently several new EAP methods have been proposed. These include for=

>>>>> example:
>>>>>=20
>>>>> EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>>>>>=20
>>>>> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>>>>>=20
>>>>> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>>>>>=20
>>>>> The list serves as a venue for discussion of these and other EAP
>>>>> related
>>>>> drafts that will be submitted in the near future. As courtesy, we will=

>>>>> post
>>>>> any new draft to SAAG, but we plan to continue the discussion only on
>>>>> the
>>>>> REAP mailing list. We have also asked for a short presentation slot
>>>>> during
>>>>> SECDISPATCH at IETF 100 in Singapore.
>>>>>=20
>>>>> Comments, early feedback, and discussion on existing or new work is
>>>>> more
>>>>> than welcome.
>>>>>=20
>>>>> --Mohit
>>>>>=20
>>>>> _______________________________________________
>>>>> saag mailing list
>>>>> saag@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/saag
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> saag mailing list
>>>> saag@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/saag
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> saag mailing list
>>>> saag@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/saag
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>>=20
>>> Best regards,
>>> Kathleen
>>=20
>>=20
>>=20
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>=20


From nobody Sun Oct 29 10:46:38 2017
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 242CE1388A9; Sun, 29 Oct 2017 10:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvHtfVXJpBVz; Sun, 29 Oct 2017 10:46:35 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 53E4F1389AC; Sun, 29 Oct 2017 10:46:30 -0700 (PDT)
X-AuditID: c1b4fb3a-de7ff70000006897-a6-59f613f47be4
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1A.5D.26775.4F316F95; Sun, 29 Oct 2017 18:46:28 +0100 (CET)
Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.352.0; Sun, 29 Oct 2017 18:46:27 +0100
Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1])	by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 81E9D4EE5E;	Sun, 29 Oct 2017 19:48:33 +0200 (EET)
Received: from [127.0.0.1] (localhost [127.0.0.1])	by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id DC5514E689;	Sun, 29 Oct 2017 19:48:32 +0200 (EET)
To: Bernard Aboba , Zhen Cao 
CC: , Kathleen Moriarty , Mohit Sethi , "saag@ietf.org" 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>  <6b3dcad6-f00c-1fb9-4df6-19f3dc744371@ericsson.com>    
From: Mohit Sethi 
Message-ID: <0f175e1a-6bed-7fd1-b44f-04ef2acc694e@ericsson.com>
Date: Sun, 29 Oct 2017 19:46:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbHdVfeL8LdIg0+b1C027PvPbNGwM9/i 3MrjLBZT+juZLKbv/cPowOqxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGWc7uMv2G1aceD3 f5YGxivaXYycHBICJhLvjjezdTFycQgJHGaUeDj/KiuEs4NRou/VWyhnI6PEx64TLBDOAkaJ H0dvs4H0Cwt4Sxz/P4cFxBYR8JNYfHUuK4jNLDCNUaJtaxpEwxFmiZ1X5rCDJNgE9CQ6zx1n BrF5BewlXn27AWazCKhKvLqyAswWFYiQeN78nhWiRlDi5MwnYAs4BWwlbl7/yAaxwEJi5vzz jBC2vMT2t3OYIWxxiVtP5jNBPKcmcfXcJrC4kIC6xNaOA4wTGEVmIRk7C8moWUhGzUIyagEj yypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwIg5uOW31Q7Gg88dDzEKcDAq8fAu5v4WKcSa WFZcmXuIUYKDWUmEt/rZ10gh3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQICaQnlqRmp6YW pBbBZJk4OKUaGB0uqUR1l/EnqMiu3OpnuE790fwP/3JOKqtc6Qrve878RXK33ax0taOWf8J9 ToWutrFIFdUVqvyiuXbCW+c7oZ93LN1md/3pvFz2W4rcs6YzvLAsb0ut3nvwiMSJxKui3mvv pe13cLt597Hw1NvuuUl1Hi+2L3z3N/iq9RNWd5Z5qWHHNr4XmqbEUpyRaKjFXFScCAAe8Pfk lAIAAA==
Archived-At: 
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Oct 2017 17:46:37 -0000

Hi Bernard,

Thanks for pointing this out. Somehow this did not come up earlier when 
Zhen and I discussed with the Security ADs.

I am happy to keep the discussion on EMU. I think our goals are 
ultimately the same: we want the interested people to get engaged in the 
new work and make sure that there is enough review from experts.

We let the security ADs decide on what to do with REAP list. It might be 
better to shut it down now when there hasn't been much discussion. We 
would also encourage others who are not on EMU to join the list to stay 
updated.

--Mohit


On 10/28/2017 10:16 PM, Bernard Aboba wrote:
> The IANA EAP page lists the policies for EAP code point allocations and points to RFC 3748 as the document relevant to method type allocations.
>
> RFC 3748 Section 6 describes the EAP method type registration and review process, requiring method reviews to be posted to a designated list. Originally the EAP mailing list was designated, and then EMU was subsequently designated as the successor list.
>
>> On Oct 28, 2017, at 2:00 AM, Zhen Cao  wrote:
>>
>> Thanks Bernard for pointing out this, at least new to me. I check the
>> emu wg conclusion email, not formally stating that emu will be the
>> only place for eap-related discussion.
>>
>> The emu list has been quite silent since the wg conclusion, less than
>> 20 messages for three years.  There were occasionally some drafts
>> posted for comments, but not any follow-up responses.  This leaves an
>> impression that either the list members are not interested in new
>> topics or the emu list is not actually adequately subscribed (who has
>> the ground truth?).    I believe this is not only a motive for Mohit
>> and I to request a new mailing list, but may also confuse upcoming
>> people who seek for a place to have discussion.
>>
>> Regards,
>> -Zhen
>>> On Fri, Oct 27, 2017 at 9:16 AM, Bernard Aboba  wrote:
>>> Yes, the EMU WG  list has been used for discussion of EAP methods since the
>>> WG closed.
>>>
>>> That list is a better venue for discussion of EAP  methods than a new REAP
>>> list, so as to ensure that proper attention is paid to backward
>>> compatibility, IPR, security properties and other critical aspects of EAP
>>> method design.
>>>
>>> After all, we are talking about a protocol that is 20+ years old that is
>>> implemented on billions of devices, many of which utilize open-source.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Oct 26, 2017 at 11:53 AM, Kathleen Moriarty
>>>  wrote:
>>>> On Thu, Oct 26, 2017 at 1:16 PM, Mohit Sethi 
>>>> wrote:
>>>>> Hi Bernard,
>>>>>
>>>>> The EAP-TLS 1.3 document is a very rough drafty version that was
>>>>> submitted
>>>>> before the cut-off for the last IETF. As you rightly point out, it has
>>>>> the
>>>>> skeleton and a lot of material from RFC5216, and still many important
>>>>> details are missing.
>>>>>
>>>>> The purpose of this list is to exactly receive these kind of comments.
>>>>> Should RFC5216 be updated or obsoleted by this draft. And it would be
>>>>> great
>>>>> if we can have your contributions to the document. We will definitely
>>>>> add an
>>>>> acknowledgement section and contact the authors of RFC5216 to see if
>>>>> they
>>>>> can contribute and comment. We plan to have more EAP related
>>>>> contributions
>>>>> in the near future. We discussed this with the Security ADs and thought
>>>>> that
>>>>> a separate list would be appropriate to get feedback/criticism and
>>>>> contributions from the folks interested.
>>>> I'm sorry, I didn't realize that a revision of 5216 was involved and
>>>> that the authors were not notified at the onset as is normal practice
>>>> in case they want to continue as authors.  Thank you for spotting this
>>>> issue Bernard.
>>>>
>>>> Is there an existing list that should be used?  Is there adequate
>>>> overlap in objectives and personnel?
>>>>
>>>> Thank you,
>>>> Kathleen
>>>>
>>>>> --Mohit
>>>>>
>>>>>
>>>>> On 10/26/2017 06:51 PM, Bernard Aboba wrote:
>>>>>
>>>>> There are existing functioning IETF mailing lists relating to EAP.
>>>>>
>>>>> Why are you starting yet another one?
>>>>>
>>>>>  From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5216
>>>>> (with no acknowledgement to the original authors) stating that EAP-TLS
>>>>> implementations must support TLS 1.3.
>>>>>
>>>>> This is ridiculous because there are 1+ Billion existing implementations
>>>>> out
>>>>> there that
>>>>>
>>>>>
>>>>> On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi
>>>>> 
>>>>> wrote:
>>>>>> Dear all,
>>>>>>
>>>>>> We have started a mailing list for discussing new EAP related work that
>>>>>> currently has no obvious home. The mailing list is called REAP (Renew
>>>>>> EAP)
>>>>>> reap@ietf.org and you can subscribe here:
>>>>>> https://www.ietf.org/mailman/listinfo/reap
>>>>>>
>>>>>> Recently several new EAP methods have been proposed. These include for
>>>>>> example:
>>>>>>
>>>>>> EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00
>>>>>>
>>>>>> EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02
>>>>>>
>>>>>> EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00
>>>>>>
>>>>>> The list serves as a venue for discussion of these and other EAP
>>>>>> related
>>>>>> drafts that will be submitted in the near future. As courtesy, we will
>>>>>> post
>>>>>> any new draft to SAAG, but we plan to continue the discussion only on
>>>>>> the
>>>>>> REAP mailing list. We have also asked for a short presentation slot
>>>>>> during
>>>>>> SECDISPATCH at IETF 100 in Singapore.
>>>>>>
>>>>>> Comments, early feedback, and discussion on existing or new work is
>>>>>> more
>>>>>> than welcome.
>>>>>>
>>>>>> --Mohit
>>>>>>
>>>>>> _______________________________________________
>>>>>> saag mailing list
>>>>>> saag@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/saag
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> saag mailing list
>>>>> saag@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/saag
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> saag mailing list
>>>>> saag@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/saag
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>> Kathleen
>>>
>>>
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org
>>> https://www.ietf.org/mailman/listinfo/saag
>>>
> _______________________________________________
> REAP mailing list
> REAP@ietf.org
> https://www.ietf.org/mailman/listinfo/reap


From nobody Sun Oct 29 14:07:38 2017
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 D5FB513FC2E for ; Sun, 29 Oct 2017 14:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level: 
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, 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 Q0_MYHo86cZe for ; Sun, 29 Oct 2017 14:07:37 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCE313FC0D for ; Sun, 29 Oct 2017 14:07:36 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1e8unu-0003zb-A4; Sun, 29 Oct 2017 21:07:34 +0000
Date: Sun, 29 Oct 2017 21:07:33 +0000
Message-ID: 
From: Randy Bush 
To: Bernard Aboba 
Cc: Mohit Sethi , Security Area Advisory Group 
In-Reply-To: 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>   <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> 
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Oct 2017 21:07:38 -0000

> Creating a separate list has real drawbacks and very little in the way of
> benefits.

bernard, for the clueless here, what change is needed for tls 1.3?

randy


From nobody Sun Oct 29 15:59:38 2017
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 7ADA013FBC7 for ; Sun, 29 Oct 2017 15:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcODbiKxlc2q for ; Sun, 29 Oct 2017 15:59:35 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FEC13F501 for ; Sun, 29 Oct 2017 15:59:35 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id b7so7019637vkh.12 for ; Sun, 29 Oct 2017 15:59:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TtPvSePKWzfbdHF/WXxZWwqDuOS1bsNTGSLznlLm9Ls=; b=TUoKiRJokZlmAP5wYttzYRW66exirszGraBrpm7n6V1qUKxfA6E3/UUWrIj1ph4PgH jN17ZKzoJFEPkSEuSYlm0p+o2lEjTQaYVOsTqzO0nmwdka+kjUyTQ0TxPq25xJeS9r02 Qje8Hozykklf5tGCVwR3mZalaMWChs1Shj2FQA2mH0FazG4xVOhkS09IgyaExkoT+mSN y+9oQ/liLRA1FHP12+04+HlGFH+zIzkxEp+v2q/E1KVps/6DBcypHnqKin2LaEb4tQ9N zI939mm5oFYnjT3t5eWLYfd1o/cLAhAYv1s9XqUzdwLfB4xDQaKGgHoVRSaPjMoCMksN VrIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TtPvSePKWzfbdHF/WXxZWwqDuOS1bsNTGSLznlLm9Ls=; b=dcORVGxFwv1SheE95DbgAchhGKn77ykiHtI1UFl+WnpxntJed0usHl7YcfYjQak3J0 OCl4lWcAttPpmhSeHK0ZYKDpltyGGSeUJVzYOegSIZVD2SCr9X3MtbRU6V5vw/dOOuEe 5rGjgqna34gPe8lK0APhCDo2udtaVoWc1gUuQGqzCDwZF4hbrlgg4fFAx1DqO3ce869d 9PC/XUV/bOAyeqq+1gYRkK7KUwGYT7S6F2hX/7WRfixThHzcMXdb97Ji/1kywYD1hImT IK59DQSktsmYirNpYv7YadvxbXTKUSJLM5YPV1kI3kunQqjpWCMjdTiNaoQQj/Zche6w aQdQ==
X-Gm-Message-State: AMCzsaUR5kOJY8pZNn7QgRl9xA+fULykyDuVFwAL/qNJBefnvcdPqDgz 2lrbgxwphPh2aTqrNuvCNZELKQnOzi3T/3Ti4do=
X-Google-Smtp-Source: ABhQp+ToqzQ5RXTEPv2CUInMvrCt3fMp4DGIILSyXQXwr0zJGz5xoKo+XhkFQnRvgE44cAGnhp5aWAyMtJvYepuRAy8=
X-Received: by 10.31.64.199 with SMTP id n190mr5328785vka.26.1509317973723; Sun, 29 Oct 2017 15:59:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Sun, 29 Oct 2017 15:59:13 -0700 (PDT)
In-Reply-To: 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>   <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com>  
From: Bernard Aboba 
Date: Sun, 29 Oct 2017 15:59:13 -0700
Message-ID: 
To: Randy Bush 
Cc: Mohit Sethi ,  Security Area Advisory Group 
Content-Type: multipart/alternative; boundary="001a11447378ad4fec055cb779ad"
Archived-At: 
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Oct 2017 22:59:36 -0000

--001a11447378ad4fec055cb779ad
Content-Type: text/plain; charset="UTF-8"

Randy asked:

"bernard, for the clueless here, what change is needed for tls 1.3?"
and

[BA] None as far as I know. EAP-TLS makes use of TLS version negotiation so
it is both forward and backward compatible. So far, implementations of RFC
5216 based on TLS 1.3 have not demonstrated any EAP-related issues, as far
as I am aware.

In general, EAP-TLS can leverage TLS policies the administrator chooses to
impose.  So  if the administrator wants to impose a version policy (e.g.
TLS versions 1.2 or later) or a ciphersuite policy (e.g. no RC4),  there
are a number of EAP servers that can be configured to support this.

So rather than attempting to impose an Internet-wide TLS version or
ciphersuite policy (which would impose a huge cost on everyone, given that
there are 2+ billion devices supporting EAP-TLS), it makes a lot more sense
to let the administrators decide, possibly based on guidance from
organizations they trust, such as NIST.  This is how things have been
working for more than a decade.









On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush  wrote:

> > Creating a separate list has real drawbacks and very little in the way of
> > benefits.
>
> bernard, for the clueless here, what change is needed for tls 1.3?
>
> randy
>

--001a11447378ad4fec055cb779ad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Randy asked:=C2=A0

"bernard, for the clueless here, what change is needed fo=
r tls 1.3?"
and=C2=A0

[BA] N=
one as far as I know. EAP-TLS makes use of TLS version negotiation so it is=
 both forward and backward compatible. So far, implementations of RFC 5216 =
based on TLS 1.3 have not demonstrated any EAP-related issues, as far as I =
am aware.

In general, EAP-TLS can leverage TLS pol=
icies the administrator chooses to impose.=C2=A0 So=C2=A0 if the administra=
tor wants to impose a version policy (e.g. TLS versions 1.2 or later) or a =
ciphersuite policy (e.g. no RC4),=C2=A0 there are a number of EAP servers t=
hat can be configured to support this.

So rather t=
han attempting to impose an Internet-wide TLS version or ciphersuite policy=
 (which would impose a huge cost on everyone, given that there are 2+ billi=
on devices supporting EAP-TLS), it makes a lot more sense to let the admini=
strators decide, possibly based on guidance from organizations they trust, =
such as NIST.=C2=A0 This is how things have been working for more than a de=
cade.









On Sun, Oct 29, 2017 at 2:07 P=
M, Randy Bush <randy@psg.com> wrote:
> Creating a separate list has real drawbacks an=
d very little in the way of

> benefits.



bernard, for the clueless here, what change is needed for tls 1.3?


randy





--001a11447378ad4fec055cb779ad--


From nobody Sun Oct 29 17:20:30 2017
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 3BF9713FCC9 for ; Sun, 29 Oct 2017 17:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 gKE7GYCrWoDB for ; Sun, 29 Oct 2017 17:20:26 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177D013F5F4 for ; Sun, 29 Oct 2017 17:20:26 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D5_01D350DA.31FB1EF0"
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509322818; h=from:subject:to:date:message-id; bh=R0F4JqlPQLZolF9onRQfvxRA9i0hQF38LuQSeLnXCJE=; b=CeJmP+/KQkHjobQ0NAL5QTDj12S2m47uuJWiWOGHSAyIrWvirztvwfw2b/ADbrOIQSXKDSp4JGY cZxn+RUlx1u8fUitn0r1sr6PKncoq3kAnEdjUQ7YuPnq3Xt+BmPGZngVeaKTQ5neUJhf9+BvBw6Uo uSI4BZm8Atn6GtblhanMD/vWsAdpJQog6hnRz9n8Fj5/HSMqua2Eahgt/3YjZuxI1YmiwiaSlM8P5 xSvz+bPhjF/9yQr41ObWEF4/80irkbwL0TCGTG5MV+zCbeSoDfgCKD2mxAGLq4/Zv8oyWamta5APk JkDAhcrUHQ0sCqDDduUTAzwWDHq+my+4n9Dw==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 29 Oct 2017 17:20:18 -0700
Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 29 Oct 2017 17:19:20 -0700
From: Jim Schaad 
To: 'Bernard Aboba' , 'Randy Bush' 
CC: 'Mohit Sethi' , 'Security Area Advisory Group' 
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>   <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com>   
In-Reply-To: 
Date: Sun, 29 Oct 2017 17:20:14 -0700
Message-ID: <00d401d35114$de589760$9b09c620$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFN48COdYi+JBd+QK9oHlddhMxUOgKr0/GcAmooxAwB08BivQIidOSsAXKooE8BLiA+3KOo+bOQ
X-Originating-IP: [192.168.1.162]
Archived-At: 
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Oct 2017 00:20:28 -0000

------=_NextPart_000_00D5_01D350DA.31FB1EF0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

There is one advantage that can be obtained by using TLS 1.3, if you =
want to hide the client name then it is no longer necessary to do an =
anonymous connection followed immediately by a re-negotiation with the =
proper client certificate.  But that and perhaps mandatory algorithms is =
the only think I can think of right off the bat.

=20

Jim

=20

=20

From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 29, 2017 3:59 PM
To: Randy Bush 
Cc: Mohit Sethi ; Security Area Advisory =
Group 
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related =
methods

=20

Randy asked:=20

=20

"bernard, for the clueless here, what change is needed for tls 1.3?"

and=20

=20

[BA] None as far as I know. EAP-TLS makes use of TLS version negotiation =
so it is both forward and backward compatible. So far, implementations =
of RFC 5216 based on TLS 1.3 have not demonstrated any EAP-related =
issues, as far as I am aware.

=20

In general, EAP-TLS can leverage TLS policies the administrator chooses =
to impose.  So  if the administrator wants to impose a version policy =
(e.g. TLS versions 1.2 or later) or a ciphersuite policy (e.g. no RC4),  =
there are a number of EAP servers that can be configured to support =
this.

=20

So rather than attempting to impose an Internet-wide TLS version or =
ciphersuite policy (which would impose a huge cost on everyone, given =
that there are 2+ billion devices supporting EAP-TLS), it makes a lot =
more sense to let the administrators decide, possibly based on guidance =
from organizations they trust, such as NIST.  This is how things have =
been working for more than a decade.

=20

=20

=20

=20

=20

=20

=20

=20

=20

On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush  > wrote:

> Creating a separate list has real drawbacks and very little in the way =
of
> benefits.

bernard, for the clueless here, what change is needed for tls 1.3?

randy

=20


------=_NextPart_000_00D5_01D350DA.31FB1EF0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


There is =
one advantage that can be obtained by using TLS 1.3, if you want to hide =
the client name then it is no longer necessary to do an anonymous =
connection followed immediately by a re-negotiation with the proper =
client certificate.=C2=A0 But that and perhaps mandatory algorithms is =
the only think I can think of right off the bat.
 
Jim
 
 
From: saag =
[mailto:saag-bounces@ietf.org] On Behalf Of Bernard =
Aboba
Sent: Sunday, October 29, 2017 3:59 PM
To: =
Randy Bush <randy@psg.com>
Cc: Mohit Sethi =
<mohit.m.sethi@ericsson.com>; Security Area Advisory Group =
<saag@ietf.org>
Subject: Re: [saag] [Reap] PSA: New list =
for discussing EAP related methods
 
Randy =
asked: 
 
"bernard, for the =
clueless here, what change is needed for tls =
1.3?"
and 
 
[BA] None as far as I know. EAP-TLS makes use of TLS =
version negotiation so it is both forward and backward compatible. So =
far, implementations of RFC 5216 based on TLS 1.3 have not demonstrated =
any EAP-related issues, as far as I am =
aware.
 
In general, EAP-TLS can leverage TLS policies the =
administrator chooses to impose.  So  if the administrator =
wants to impose a version policy (e.g. TLS versions 1.2 or later) or a =
ciphersuite policy (e.g. no RC4),  there are a number of EAP =
servers that can be configured to support =
this.
 
So rather than attempting to impose an Internet-wide =
TLS version or ciphersuite policy (which would impose a huge cost on =
everyone, given that there are 2+ billion devices supporting EAP-TLS), =
it makes a lot more sense to let the administrators decide, possibly =
based on guidance from organizations they trust, such as NIST.  =
This is how things have been working for more than a =
decade.
 
 
 
 
 
 
 
 
 
On Sun, =
Oct 29, 2017 at 2:07 PM, Randy Bush <randy@psg.com> wrote:
> =
Creating a separate list has real drawbacks and very little in the way =
of
> benefits.

bernard, for the clueless here, what change =
is needed for tls 1.3?

randy
 

------=_NextPart_000_00D5_01D350DA.31FB1EF0--


From nobody Sun Oct 29 19:37:24 2017
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 C522E13FAA8 for ; Sun, 29 Oct 2017 19:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSveOi986tmj for ; Sun, 29 Oct 2017 19:37:20 -0700 (PDT)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B420013F45D for ; Sun, 29 Oct 2017 19:37:20 -0700 (PDT)
Received: by mail-pg0-x232.google.com with SMTP id s2so10202586pge.10 for ; Sun, 29 Oct 2017 19:37:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LolBjdHZyouVXUNyac4VksF0mXoOPTgvZPOta7SUKag=; b=DfU5Ky2p51uBsydIof/3rV5do3TfznOX7a8VosfJMHu0lKBll+yxKOLjo98EU6ooxI IjxIfmFb6Ih2VXp8h+rdLkFvCSn9rRh58dhgNsEXI0IqEpNB2CCFL3555edtW0/R8h91 Lh9KSa0KJz/qsLpp3BlcnDu9QpBPSGDOVUc56BN5FKKOxfICxUCYAlTVrx63BzlSJ5KN ogvROcv86SKM105TeUikiUEjXhnSBcC0QiuozM1VYVF71CUToxDjhuIsVJ50sd/qPm83 nEXpHoDo5RJqTGiQoRMrzsNpme2ucBPwPrZtKVJOIHAeOZuG4hp1YGDZ4IWZKOgLOW2R TrNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LolBjdHZyouVXUNyac4VksF0mXoOPTgvZPOta7SUKag=; b=Mw1+/6S6WsPq40uESRdj2M+9hU6TQ1RaOQSfU2fndW029ceud9rbmN6prqc/yp5CaC BxeSOoi6NeLsrnnavtg1KD/txJo+Y8RH/BQOTGxHIukWmZ5pDJIkBgayKTw/bWBztjNp p5zp7fVDP844TPRgusu2p5a1fVVHjd3nblwJpbsCL51oFKQm5KXTP4YRKpkWrCM1Hsaw pYppEixXvSKUuMfkWwt2wLv6xAg1A8vamPNw0KNh7/3tVyeetuniKnruytiw0JASvf4q i7m+VngvnZdE5qhTBmFoeS0lQToQerUatBp5yn6M8V7Rb2ixMabk9CU6Fw4Qh8g1J2Pd yMvA==
X-Gm-Message-State: AMCzsaXOMtUe8jRPfyPkg3D/ngxXfJSXrwpiQgd+vQmuKr5gbHL9SMAV 8hNUtHnS1Bma49ThzfFr3Ii3AMWR
X-Google-Smtp-Source: ABhQp+RSVNuUFxd5kXwtIwzmZQ+WMWnkQEFVuGXkd2d40FyaLSH7hih2ZaOZLZbBmHWLDQiodiM86Q==
X-Received: by 10.98.192.6 with SMTP id x6mr7189962pff.170.1509331039806; Sun, 29 Oct 2017 19:37:19 -0700 (PDT)
Received: from [192.168.1.104] (c-24-17-217-136.hsd1.wa.comcast.net. [24.17.217.136]) by smtp.gmail.com with ESMTPSA id a13sm8105752pgq.10.2017.10.29.19.37.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Oct 2017 19:37:18 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-1C41D04A-E6D2-4D73-BBA6-2F70BA65C9D0
Mime-Version: 1.0 (1.0)
From: Bernard Aboba 
X-Mailer: iPhone Mail (15A432)
In-Reply-To: <00d401d35114$de589760$9b09c620$@augustcellars.com>
Date: Sun, 29 Oct 2017 19:37:17 -0700
Cc: Randy Bush , Mohit Sethi , Security Area Advisory Group 
Content-Transfer-Encoding: 7bit
Message-Id: <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com>
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com>   <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com>    <00d401d35114$de589760$9b09c620$@augustcellars.com>
To: Jim Schaad 
Archived-At: 
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Oct 2017 02:37:23 -0000

--Apple-Mail-1C41D04A-E6D2-4D73-BBA6-2F70BA65C9D0
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

RFC 5216 only insists on support (not use) of TLS 1.0 and its mandatory ciph=
ersuites in order to ensure interoperability with legacy implementations and=
 avoid an Internet-wide =E2=80=9Cflag day=E2=80=9D requiring millions of har=
dware devices to be replaced. But if a site wants to impose a TLS version (a=
nd ciphersuite) policy, it can.

Mandatory to support algorithms apply to a TLS version, so EAP-TLS inherits t=
hem when that version is negotiated. Similarly, EAP-TLS inherits features of=
 each TLS version - all it does is tunnel TLS.

Given this, I am puzzled as to why it is being proposed that RFC 5216 be rec=
ycled at Proposed in a non-backward compatible manner with vast new IPR encu=
mbrance, completely new authors, and nearly identical text, rather than bein=
g left alone or moving to the next standards level.=20







> On Oct 29, 2017, at 5:20 PM, Jim Schaad  wrote:
>=20
> There is one advantage that can be obtained by using TLS 1.3, if you want t=
o hide the client name then it is no longer necessary to do an anonymous con=
nection followed immediately by a re-negotiation with the proper client cert=
ificate.  But that and perhaps mandatory algorithms is the only think I can t=
hink of right off the bat.
> =20
> Jim
> =20
> =20
> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Bernard Aboba
> Sent: Sunday, October 29, 2017 3:59 PM
> To: Randy Bush 
> Cc: Mohit Sethi ; Security Area Advisory Group=
 
> Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related method=
s
> =20
> Randy asked:=20
> =20
> "bernard, for the clueless here, what change is needed for tls 1.3?"
> and=20
> =20
> [BA] None as far as I know. EAP-TLS makes use of TLS version negotiation s=
o it is both forward and backward compatible. So far, implementations of RFC=
 5216 based on TLS 1.3 have not demonstrated any EAP-related issues, as far a=
s I am aware.
> =20
> In general, EAP-TLS can leverage TLS policies the administrator chooses to=
 impose.  So  if the administrator wants to impose a version policy (e.g. TL=
S versions 1.2 or later) or a ciphersuite policy (e.g. no RC4),  there are a=
 number of EAP servers that can be configured to support this.
> =20
> So rather than attempting to impose an Internet-wide TLS version or cipher=
suite policy (which would impose a huge cost on everyone, given that there a=
re 2+ billion devices supporting EAP-TLS), it makes a lot more sense to let t=
he administrators decide, possibly based on guidance from organizations they=
 trust, such as NIST.  This is how things have been working for more than a d=
ecade.
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> =20
> On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush  wrote:
> > Creating a separate list has real drawbacks and very little in the way o=
f
> > benefits.
>=20
> bernard, for the clueless here, what change is needed for tls 1.3?
>=20
> randy
> =20

--Apple-Mail-1C41D04A-E6D2-4D73-BBA6-2F70BA65C9D0
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


RFC 5216 only insists on su=
pport (not use) of TLS 1.0 and its mandatory ciphersuites in order to ensure=
 interoperability with legacy implementations and avoid an Internet-wide =E2=
=80=9Cflag day=E2=80=9D requiring millions of hardware devices to be replace=
d. But if a site wants to impose a TLS version (and ciphersuite) policy, it c=
an.

Mandatory to support algorithms apply to a TLS version, so EAP-TL=
S inherits them when that version is negotiated. Similarly, EAP-TLS inherits=
 features of each TLS version - all it does is tunnel TLS.
=

<=
div>Given this, I am puzzled as to why it is being proposed that RFC 5216 be=
 recycled at Proposed in a non-backward compatible manner with vast new IPR e=
ncumbrance, completely new authors, and nearly identical text, rather than b=
eing left alone or moving to the next standards level. 

<=
br>

=





On Oct 29, 2017, at 5:20 PM, Jim=
 Schaad <ietf@augustcellars.com=
> wrote:

There is one advantage that can be obtained by using TLS 1.3, if yo=
u want to hide the client name then it is no longer necessary to do an anony=
mous connection followed immediately by a re-negotiation with the proper cli=
ent certificate.  But that and perhaps mandatory algorithms is the only=
 think I can think of right off the bat.
 
Jim
 
 
=

From: saag [mailto:saag-bounces@ietf.org] On Behalf Of <=
/b>Bernard Aboba
Sent: Sunday, October 29, 2017 3:59 PM
To:<=
/b> Randy Bush <randy@psg.com>Cc: Mohit Sethi <mo=
hit.m.sethi@ericsson.com>; Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] [=
Reap] PSA: New list for discussing EAP related methods
<=
/div>
 
Randy asked: 
 
"be=
rnard, for the clueless here, what change is needed for tls 1.3?"
and 
<=
div>
 
[BA] None as far as I know. EAP-TLS makes use of TLS version negotiati=
on so it is both forward and backward compatible. So far, implementations of=
 RFC 5216 based on TLS 1.3 have not demonstrated any EAP-related issues, as f=
ar as I am aware.
 =
;
In general, EAP-TLS can leverag=
e TLS policies the administrator chooses to impose.  So  if the ad=
ministrator wants to impose a version policy (e.g. TLS versions 1.2 or later=
) or a ciphersuite policy (e.g. no RC4),  there are a number of EAP ser=
vers that can be configured to support this.
 
So r=
ather than attempting to impose an Internet-wide TLS version or ciphersuite p=
olicy (which would impose a huge cost on everyone, given that there are 2+ b=
illion devices supporting EAP-TLS), it makes a lot more sense to let the adm=
inistrators decide, possibly based on guidance from organizations they trust=
, such as NIST.  This is how things have been working for more than a d=
ecade.
 
=

 
 
&nbs=
p;
 
 
 
 =

 
On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush <randy@psg.com> wrote:
> Creating a separate list has real drawbacks and very little in the=
 way of
> benefits.

bernard, for the clueless here, what change=
 is needed for tls 1.3?

randy
 
=

--Apple-Mail-1C41D04A-E6D2-4D73-BBA6-2F70BA65C9D0--