From nobody Tue Jan 2 16:05:49 2018 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 9A687120721 for ; Tue, 2 Jan 2018 16:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 Kqej2nxGa5XE for ; Tue, 2 Jan 2018 16:05:45 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 B57231200F3 for ; Tue, 2 Jan 2018 16:05:45 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id t78so41575oie.8 for ; Tue, 02 Jan 2018 16:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=SjTRrc6XnrKxSe7NtsHdvL60Qnngk2ICpzVBKxWgb7Y=; b=MX/u6Z/95yD6ipJExbhxe/QWgzppUDW44hqdseVjGgFosUOCbfeNw+phYTbjlxp2+6 ECWW9MmL3l6h9Trf9EiGAC4lvcqid6P1LCr+II75FlT21JFLirf0fQpAOhS8T7RUsp28 vB6ZMZ9jgu8/P/GgMztUqX/gjb/Za3ftjTjrZ0D4phWbWlwFGqY1LdCSjBOhFddzZy3S FTvZ1Wiiqsn09wJFwk1sr8RfnF/fP3ca+3pls/uEMpwX+D6FJRITM9XXjTNG/HYTp6RR Ck5+0nD95bfBmNaJynNNlcaq74wLsy6Vn2NW1VbrpCU3gNf4X/oq/KnoxRTPdGXCSR47 NcyA== 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; bh=SjTRrc6XnrKxSe7NtsHdvL60Qnngk2ICpzVBKxWgb7Y=; b=NT2QIo2atEWl5lt+1i0yuE12ewNGaAcV5vS9hAjn+r2lz99Jf3FDXxptb6sBSla/0e KshXPOHe9O16WC4cLUCccFdPdxeLLySPb2ZlmdVlWSi9fJZ6KYZUuSae169V7UpGok/0 HdglLIvwbf8TK9EsH/09JZRl7PYeNS605rFzfa6611qEZQ8j1rtb9RHYjzebUIAblg4t SRxEq20kV435ZRZucpKjecym95gF7koYn8SERMGb/4YyHMOwrdxO0rNc71gXG1G7ACss 5NCYguRX7ZboIds1w0Z5OkGe3/Jwh11BHu4gYYeKHGn3yhRSkcZDkBN3SkzvDwpzmkDE cLWQ== X-Gm-Message-State: AKGB3mKq/4mmDlgpoXUg/vXNN94vCZL2r3jYuWlKEc+6vzoFeVvHxIJK dbLQ10VRL+zOTVbqMQa2mIsCgfoCnjsGnjlyPBK3uFha X-Google-Smtp-Source: ACJfBoshp32muFs/gpigBxBAAkqGSB8EEN2GtJAvWPl/IWv0XhiIQXl/MYusZuN4Qb2rULR8fCKCu2vzRvES0Ox8/N0= X-Received: by 10.202.81.193 with SMTP id f184mr29569151oib.220.1514937944960; Tue, 02 Jan 2018 16:05:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.40.243 with HTTP; Tue, 2 Jan 2018 16:05:04 -0800 (PST) In-Reply-To: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> From: Yakov Shafranovich Date: Tue, 2 Jan 2018 19:05:04 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Fwd: New Version Notification for draft-foudil-securitytxt-02.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, 03 Jan 2018 00:05:48 -0000 FYI - apologies for not post this earlier. ---------- Forwarded message ---------- From: Date: Wed, Dec 27, 2017 at 11:38 AM Subject: New Version Notification for draft-foudil-securitytxt-02.txt To: Edwin Foudil , Yakov Shafranovich A new version of I-D, draft-foudil-securitytxt-02.txt has been successfully submitted by Edwin Foudil and posted to the IETF repository. Name: draft-foudil-securitytxt Revision: 02 Title: A Method for Web Security Policies Document date: 2017-12-27 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-foudil-securitytxt-02.txt Status: https://datatracker.ietf.org/doc/draft-foudil-securitytxt/ Htmlized: https://tools.ietf.org/html/draft-foudil-securitytxt-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-foudil-securitytxt-02 Abstract: When security risks in web services are discovered by independent security researchers who understand the severity of the risk, they often lack the channels to properly disclose them. As a result, security issues may be left unreported. security.txt defines a standard to help organizations define the process for security researchers to securely disclose security vulnerabilities. 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 From nobody Tue Jan 2 23:40:43 2018 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 27FE5127369 for ; Tue, 2 Jan 2018 23:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 u4ACYGY6D6EI for ; Tue, 2 Jan 2018 23:40:40 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 D715F120227 for ; Tue, 2 Jan 2018 23:40:39 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 57FA931D2E; Wed, 3 Jan 2018 08:40:37 +0100 (CET) Received: by godin (Postfix, from userid 1000) id B3FD8EC0BB6; Wed, 3 Jan 2018 08:35:06 +0100 (CET) Date: Wed, 3 Jan 2018 08:35:06 +0100 From: Stephane Bortzmeyer To: saag@ietf.org Message-ID: <20180103073506.GA31821@laperouse.bortzmeyer.org> References: <151439268386.29864.3964469823970181131.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [saag] New Version Notification for draft-foudil-securitytxt-02.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, 03 Jan 2018 07:40:42 -0000 On Tue, Jan 02, 2018 at 07:05:04PM -0500, Yakov Shafranovich wrote a message of 46 lines which said: > Name: draft-foudil-securitytxt > Revision: 02 > Title: A Method for Web Security Policies Note that several points of discussion are recorded as issues on Github and it may be a good idea to read them before discussing the draft. From nobody Wed Jan 3 13:07:56 2018 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 7A44C129C6C for ; Wed, 3 Jan 2018 13:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 HS_QUHYe6ssO for ; Wed, 3 Jan 2018 13:07:53 -0800 (PST) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::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 02AE7126C83 for ; Wed, 3 Jan 2018 13:07:52 -0800 (PST) Received: by mail-ot0-x242.google.com with SMTP id 37so2339798otv.6 for ; Wed, 03 Jan 2018 13:07:52 -0800 (PST) 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=3Bp0NMQTDI287Q5A3411kARn2NBvC7k9sqErk2GG0VI=; b=a7yDA1TsOgnh1SRJ5cjMFleGzGkZgTABLjEXUveoCAFGDhm7KBNLLMKXpGICxryh/o 7Cmdb1Uqc473IksO+tUuBXbKWI/TWsIeXNhmsB2w/4rjuVoCnK2jG6X7wCMEGtGcbr3f i+CpugARnR4sUU4QqZD6MjgWaGdw2hO8VN2R4yDIAnCC+xmN2lIUJes+1zyhq+MJYl3Y PQTpktVGoDswEMAdAS69HIH/FJIvPZssv2ddoex2DvyQ2V2uzCXJFz7GWRNteR2F7NGy xu3kUZXS/IGSYw4nGaDzqUEdeCbLwqs9Nh9US5iM4kvG3R7vFdU89i9J5zBWuGZmRfjz d0lg== 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=3Bp0NMQTDI287Q5A3411kARn2NBvC7k9sqErk2GG0VI=; b=axVO4FejxeBkCVxzrAwwFEnHWxVjR/Q5jxlfHClYL4SvLgN2cKDZdu48IPSbSM3ebh NpYUIy6341ysu3CxOvENSPGUV/HGPJe9FvVnSG1IFYw3K2UmJ5fnYCU8vqBT2lgYADD8 bmMDHe68vnTsuNNRu/35fvnFqeQZEhBCPaThCAmJ1whuO3UoVgwJIZvH3cXfwf6MQQiF V0m2M+rVickDwgDetMypzMnVWcffaG0UN9br9qffxggSmqBW3BzUZiUlPMNWxkV+BwJH 2GYQAmqZK0vZC8cPLQgm1WizJ5hJI09/0jnzDE8bTJRIyR1wTas2g1PPEtQZjCy7pBxI 9yGw== X-Gm-Message-State: AKGB3mJe00gmM8kso3pi5Oun7fwO3Nxc8T2ORdK4tsFqEdy1GVbng/0c InVbVVTSAdgYEWOiQ2Q4cA820TpangOXPmZaxbU= X-Google-Smtp-Source: ACJfBou+qSL4tCnaiuuF9BdcoCTsJxGTvBgzeJ+FhSPAd1L2xU/+vtZe6NxbUoc+/5BFNJJA3ZnEe9j6rzhlSGIXqYg= X-Received: by 10.157.24.116 with SMTP id t49mr1499823ott.60.1515013672190; Wed, 03 Jan 2018 13:07:52 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.49.87 with HTTP; Wed, 3 Jan 2018 13:07:51 -0800 (PST) From: Phillip Hallam-Baker Date: Wed, 3 Jan 2018 16:07:51 -0500 X-Google-Sender-Auth: RNt8tw5hYLuWRbNnO7E_hQ6o1v4 Message-ID: To: DNS Operations List , saag@ietf.org Content-Type: multipart/alternative; boundary="001a1142e598c2c6010561e59bee" Archived-At: Subject: [saag] Use of TSIG 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, 03 Jan 2018 21:07:54 -0000 --001a1142e598c2c6010561e59bee Content-Type: text/plain; charset="UTF-8" As folk who are following a certain FB page know, I am configuring a BIND server direct for the first time in a while and so just for the heck of it, I decided to configure using only sources that I find on the Web that are not actual manuals. This has turned into an audit of the 'advice' out there. Some of the best is n how to generate TSIG keys. Take this for example: $echo $(date) | openssl base64 Because 2^20 is a huge key space for any attacker to brute force. And then there was this gem: The public key, *kprod.tsigkey.+157+57861.key* contains: prod.tsigkey. IN KEY 512 3 157 wzs+I/9e6CthD0BT3Uh00w== While the private key, *Kprod.tsigkey.+157+57861.private*contains: Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: wzs+I/9e6CthD0BT3Uh00w== Bits: AAA= Now that we have generated the DNSSEC keys, we need to put them to use and incorporate them into our configuration. This is the sort of explanation where a little bit of knowledge hinders rather than helps. And I hadn't spotted the reference to 'DNSSEC' until I cam to cut and paste. This is really not acceptable. In 2018 we have to set a different standard for security: A protocol is not secure unless the typical administrator following the line of least resistance to do their job is likely to configure it correctly. This is essentially the old orange book criteria 'secure by default'. OK so how do we get from where we are to where we should be? In the short term we need a set of instructions on how to configure DNS securely that has had some expert review. And by 'secure' I mean, conforms to a high level of security best practice not 'we haven't had issues with this'. Whether ICANN/IETF/OTA is best for this, I don't know but it needs to come into being. Another thing we should do is to remove as many prat-falls from the process as possible. TSIG is an adequate approach to authenticating zone transfers, it is not an adequate approach to managing authentication secrets. These should always be public key pairs. --001a1142e598c2c6010561e59bee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As = folk who are following a certain FB page know, I am configuring a BIND serv= er direct for the first time in a while and so just for the heck of it, I d= ecided to configure using only sources that I find on the Web that are not = actual manuals.

This has = turned into an audit of the 'advice' out there. Some of the best is= n how to generate TSIG keys. Take this for example:

$echo $(date) | openssl base64

Because 2^20 is a huge key space for any attacker to = brute force.

And then there was this gem:

The public key,=C2=A0kprod.tsigkey.+157= +57861.key=C2=A0contains:

prod.=
tsigkey. IN KEY 512 3 157 wzs+I/9e6CthD0BT3Uh00w=3D=3D

While the private key,=C2=A0K= prod.tsigkey.+157+57861.privatecontains:

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: wzs=
+I/9e6CthD0BT3Uh00w=3D=3D
Bits: AAA=3D

Now that we have generated the DNSSEC keys, we nee= d to put them to use and incorporate them into our configuration.=C2=A0=C2= =A0

This is the sort of explanation whe= re a little bit of knowledge hinders rather than helps. And I hadn't sp= otted the reference to 'DNSSEC' until I cam to cut and paste.


Thi= s is really not acceptable. In 2018 we have to set a different standard for= security:=C2=A0

A protocol is not secu= re unless the typical administrator following the line of least resistance = to do their job is likely to configure it correctly.

This is essentially the old orange book criteria 'secure = by default'.


OK so how do we get from where we are to where we should= be?

In the short term we need a set of= instructions on how to configure DNS securely that has had some expert rev= iew. And by 'secure' I mean, conforms to a high level of security b= est practice not 'we haven't had issues with this'. Whether ICA= NN/IETF/OTA is best for this, I don't know but it needs to come into be= ing.

Another thing we should do is to r= emove as many prat-falls from the process as possible. TSIG is an adequate = approach to authenticating zone transfers, it is not an adequate approach t= o managing authentication secrets. These should always be public key pairs.=


--001a1142e598c2c6010561e59bee-- From nobody Wed Jan 3 13:17:59 2018 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 07E0B128C0A for ; Wed, 3 Jan 2018 13:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=NuIbxj2a; dkim=pass (1024-bit key) header.d=yitter.info header.b=aJZOns78 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 DdnHm1F_1sW0 for ; Wed, 3 Jan 2018 13:17:56 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F59D126C83 for ; Wed, 3 Jan 2018 13:17:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id B1896C1969 for ; Wed, 3 Jan 2018 21:17:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1515014245; bh=aKdBYuvbGeO5R8QRu89xBtmh0exTjsUG+p1KHEoRDSM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NuIbxj2aL0oF0lAnLjpFQhB2EEtI2ky/9JmFUVZP2hCNqwiSNqHftohyPrPvfSRJi WpA5jqzQKA2iHYiDkL85MsgXdPE1fP7jCLyc3ZIb6SvxtvZhjJsHB1OkTNqqLCNBlC chZFFQATmB4SCjNWTaIMjhmq8rVbtsFkLrd4XwYs= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5I3CP-j1wOml for ; Wed, 3 Jan 2018 21:17:24 +0000 (UTC) Date: Wed, 3 Jan 2018 16:17:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1515014244; bh=aKdBYuvbGeO5R8QRu89xBtmh0exTjsUG+p1KHEoRDSM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aJZOns78jK1Ic1ijQX5PgmAq/t5p57QNtOtPpaY5AKIbMOCqM/merLOfzgCmYwfDu 7Poi5wDjnxKbz2mEaB80sbJfySrxxe9IycRpMR/eAVWlgSfp604EpzRTOwspYDGVXO W2D/rQ+5jA1IoIPhNd50yCuf4BC1tGZbZG1u2wE4= From: Andrew Sullivan To: saag@ietf.org Message-ID: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [saag] Use of TSIG 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, 03 Jan 2018 21:17:58 -0000 Hi, On Wed, Jan 03, 2018 at 04:07:51PM -0500, Phillip Hallam-Baker wrote: > I decided to configure using only sources that I find on the Web that are > not actual manuals. I don't understand this plan. You're saying that you have forsaken the manual for your software in favour of random things you find on the Internet? I mean, whatever floats your boat, but I often find that a comprehensive manual for my software contains better information than things I learned in the virtual schoolyard. > Some of the best > is n how to generate TSIG keys. In that manual you forsook, you might have discovered the command tsig-keygen. > rather than helps. And I hadn't spotted the reference to 'DNSSEC' until I > cam to cut and paste. For reasons I don't fully understand, TSIG and the DNS Security Extensions are occasionally treated together somehow as "DNSSEC". They have little to do with one another. TSIG is a shared secret approach. > In the short term we need a set of instructions on how to configure DNS > securely that has had some expert review. And by 'secure' I mean, conforms > to a high level of security best practice not 'we haven't had issues with > this'. Whether ICANN/IETF/OTA is best for this, I don't know but it needs > to come into being. It seems to me that the bind-users list is what you're after. This isn't a DNS protocol problem, it's an implementation issue, since every implementation does it differently. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Jan 3 13:28:57 2018 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 D1E91128C0A for ; Wed, 3 Jan 2018 13:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gl4Au0bz7icd for ; Wed, 3 Jan 2018 13:28:46 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFEF129C6C for ; Wed, 3 Jan 2018 13:28:46 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9C3CE7A3309 for ; Wed, 3 Jan 2018 21:28:45 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 Jan 2018 16:28:43 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: saag@ietf.org Message-Id: <9426D822-58C7-424F-B0DA-E4C3790ECB91@dukhovni.org> References: To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] Use of TSIG 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, 03 Jan 2018 21:28:49 -0000 > On Jan 3, 2018, at 4:07 PM, Phillip Hallam-Baker = wrote: >=20 > Another thing we should do is to remove as many prat-falls from the = process as possible. TSIG is an adequate approach to authenticating zone = transfers, it is not an adequate approach to managing authentication = secrets. These should always be public key pairs. PK is not actually more secure when the verifier and relying party are = compute resources operated by the same entity. Indeed symmetric crypto does not = suffer from the potential failure of current PK algorithms if/when scalable = quantum computers show up. That said, a PK alternative to TSIG is available: https://tools.ietf.org/html/rfc2931 You are of course right that there's lots of bad advice on the Internet, = and that giving too much rope to users is liable to reduce security when = they make poor choices (and don't know the difference). This means that administration tools should make it easy to choose = sensible settings, and (more) difficult to choose "exotic" settings. When tools = are completely neutral on parameter choices, the resulting diversity is = generally counter-productive. See for example: = https://lists.dns-oarc.net/pipermail/dns-operations/2017-December/017125.h= tml =20 --=20 Viktor. From nobody Wed Jan 3 13:39:27 2018 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 498F712D77E for ; Wed, 3 Jan 2018 13:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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=digicert.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 C2PL3cQJMYal for ; Wed, 3 Jan 2018 13:39:23 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.209]) (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 25371120726 for ; Wed, 3 Jan 2018 13:39:23 -0800 (PST) Received: from [216.82.242.46] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-17.bemta-8.messagelabs.com id FD/CF-19660-A8D4D4A5; Wed, 03 Jan 2018 21:39:22 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSbUhTYRTee+8+ruLiOqc7jUSbFSZsKFmJRR8 QmOQg7EewJL3qbRttU3ZXLipaMROtrMzwq5iYGZpKWZHkB6mFaaFZ5g8lwTJLh6b0YcnKdnev Vv+e9zzPeZ5zXg6By4bESoK222irhTKpxP7Cfs2NWHW+VquLHh0JjSu+mI/tQLurq39ie5FOZ LSkZ9nTRIa5vpcou2qb/cKPNAeq2FqA/Akh+RmD0w1OjH3IyCIMKm++4B9dCO5NFKIC5EeIyW gYauvGWCwnI+CW56OExUFkGJSfL8K5ejg0tHSLORwPDxbZOuGNWAN1o7FsWUqmQMvtNgnnn4u gpuKJkCX8yB3wurvb54PIEJjvrfdl4aQChsddPgykHMYGnos5HAyT73+LOH0KXP/SyddVMNLw A3E4FF65ziE2DMj7GHhcXACQGnhweZoXaeFb37yIEzUjWKiq4okoqJpv4xsOQ17lVT4hCZ6fd fGufTg8czj5hlWQN1jKE6Mi6G8c8O0mIzOhuG5pvuPwdnwQ5/5OCW8H89EltL78n1XLvf046U JQt/hBUu77tEDoKRsXciI1PGp/jHM4DB5OX+PxFihd6BBzeDUUnxuTcHgjuJ/OoUpE1KFIhrY epa3q2BhNutWoN9jMlNGkjomO05hphqH0tIlKZzQZWeYm5L2oUwIBakbumgOdaCWBqYKlJnqP TrYiPSvzmIFiDKnWIyaa6USRBEE6B3o6MKXQkmWhVSDdkqTVyQKttJ62HzKavCe6JAUiQCWX5 rC0lMmmzIxRz1G9aAPhaR32YMREmduBy3xOSoU0ipWSrNRwxLJstHTur1CoMkiKBAKBLCCbtp qNtv/5KaQgkCpIup91CTBabMt5U95RMO8onv5EdhQb9ZdSOtBhfVlH4ZrkN0XakPymQy8WnJt re2bjRz/Efn2397Y8NXd7a6PClvNJP0U5Z/Ul1RMnMnbaBv2otevOPCmcmVG29xcJEnIj7mxP bHC/v5hQXP9QfmnXwFitSHQ+ypxQUFiz6I5WK+0rI66UjE2uOnjX8b0rT6E+aU+W/NoUnjK7r 1klZAxUTBRuZag/oxN1yOkDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-8.tower-96.messagelabs.com!1515015560!105991968!1 X-Originating-IP: [207.46.163.52] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27068 invoked from network); 3 Jan 2018 21:39:21 -0000 Received: from mail-cys01nam02lp0052.outbound.protection.outlook.com (HELO NAM02-CY1-obe.outbound.protection.outlook.com) (207.46.163.52) by server-8.tower-96.messagelabs.com with AES256-SHA256 encrypted SMTP; 3 Jan 2018 21:39:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BtyCYVqNz6wrV6iagDfjGD5Osw224fFT1fVKCMIl2YI=; b=XMFjzhwJaxlYDpNSNlbWncOg3aOzIftqWWFa22VV7krwcAn7DIy6WAI2C380gRmbL2OUkHkh68eoMR1x//a7T/Sag6biod1CzSroyOoeP6QuUd+75tFqp7IYh/8bAp021AHlK/Nt629h49/kcWs7Xkm2e+vRX6NUSOYIOxfT9dw= Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1291.namprd14.prod.outlook.com (10.173.132.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Wed, 3 Jan 2018 21:39:19 +0000 Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0386.005; Wed, 3 Jan 2018 21:39:19 +0000 From: Tim Hollebeek To: "saag@ietf.org" Thread-Topic: [saag] Use of TSIG Thread-Index: AQHThNbxcnuRbfHheEuoq4Tm3f9zRKNiqfqAgAABtmA= Date: Wed, 3 Jan 2018 21:39:19 +0000 Message-ID: References: <9426D822-58C7-424F-B0DA-E4C3790ECB91@dukhovni.org> In-Reply-To: <9426D822-58C7-424F-B0DA-E4C3790ECB91@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [74.111.107.128] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1291; 7:seTmeAIOIoxbegIc4xsdXu31/ZKW27+xR7vH/kh8cdAJAHtIfHX5rE+UPb1lk6TYZ86DF8cmGFwKDlHWUw5IWIg0WKc56X6a5/jhiqVAge5m8JyoorMmWXzVYA3PTAGdSMB/Ep3TvN6RkzEZGmSGSfuW40x2cXGdH5y4iLMjZk54w8fE7Bo/beFvW4uhGAhYO94O2LOnDPm+e+owBirOhN0bR6lTj/m0CT1DzL7l8amdl2ZbRG/qIzHz9Ihn9JWX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c8422ec9-08dc-4491-7724-08d552f27220 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(3008032)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603307)(7153060)(49563074); SRVR:DM5PR14MB1291; x-ms-traffictypediagnostic: DM5PR14MB1291: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040470)(2401047)(5005006)(8121501046)(3231023)(944501075)(93006095)(93001095)(3002001)(10201501046)(6041268)(2016111802025)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6043046)(6072148)(201708071742011); SRVR:DM5PR14MB1291; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1291; x-forefront-prvs: 0541031FF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39380400002)(39850400004)(346002)(366004)(199004)(189003)(106356001)(105586002)(9686003)(6246003)(6306002)(966005)(76176011)(7736002)(81156014)(1730700003)(102836004)(81166006)(59450400001)(86362001)(305945005)(97736004)(3280700002)(8676002)(6506007)(2351001)(8936002)(68736007)(99286004)(5640700003)(74316002)(6436002)(2906002)(33656002)(53936002)(5660300001)(3660700001)(99936001)(7696005)(77096006)(55016002)(14454004)(6116002)(3846002)(25786009)(2501003)(316002)(2950100002)(2900100001)(6916009)(478600001)(66066001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1291; H:DM5PR14MB1289.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) x-microsoft-antispam-message-info: VpZpfNjhgqyZ2+U1ROtsHy6m53K9XJGTXm6oTzK+xL3Gb10q9hQKDbM8Db1gRIkWHeH3xo0d5n0J4W+WW0/e7g== 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_026B_01D384A0.9A61F0A0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: c8422ec9-08dc-4491-7724-08d552f27220 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2018 21:39:19.1836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1291 Archived-At: Subject: Re: [saag] Use of TSIG 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, 03 Jan 2018 21:39:26 -0000 ------=_NextPart_000_026B_01D384A0.9A61F0A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > This means that administration tools should make it easy to choose sensible > settings, and (more) difficult to choose "exotic" settings. When tools are > completely neutral on parameter choices, the resulting diversity is generally > counter-productive. See for example: > > https://lists.dns-oarc.net/pipermail/dns-operations/2017- > December/017125.html Unfortunately, of course, the proper sensible settings change with time. I'm all for sane defaults, but it doesn't fix the problem of a server that was configured 20+ years ago with sensible settings. It really would be nice if I could set my security to MEDIUM and my device could reconfigure itself appropriately over time as things change. Heck, it'd be nice if it could alert me that my recommended settings are no longer recommended. I do think there's lots of room for better software in this area, especially for long lived servers and devices ... -Tim ------=_NextPart_000_026B_01D384A0.9A61F0A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw 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+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwMTAzMjEzOTA0WjAvBgkqhkiG9w0BCQQxIgQgVk7klEO1Q7AcqNJ/RESpTiq4YciP biSmajdUzZfV7oMwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAMFqAGiJ8jLOoA3Rmzt74aIh6TKPWea2K10IJcger8y86y2NOdTTdBnvUgvwwrUvt4zLADGf HbEM859gE21v8DtevSgSjSE02a+7p2qgTY35LdDwF34eexez0Ggv/PDuNF+C+EPFE7UoqTcWu56O mbnlKO+SVMHv5xtTeeaGd6zr6tYj/c99f/hZoS6waobUXZoe0OAKrt6xl6lvgLNH3k69l1+TdEmL 0WQzgXm+tibwIX1zVFFzp3984NwoNe6V5dr/6RuZ+NJ47Gjge+2UAP7dGjF1LOawt1tOuDVSUY+Y PGyOZoxCy27U6L9YjEw3enYcQ+0PKUSbLef9AbKXKJUAAAAAAAA= ------=_NextPart_000_026B_01D384A0.9A61F0A0-- From nobody Wed Jan 3 13:42:54 2018 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 7286A12D77C for ; Wed, 3 Jan 2018 13:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 hi-X9seObhfQ for ; Wed, 3 Jan 2018 13:42:50 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 6DA40129C6C for ; Wed, 3 Jan 2018 13:42:50 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id t63so142705iod.0 for ; Wed, 03 Jan 2018 13:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R1kkxMXvX73GBFCzM4m3KwlWe0RfxVAwZ+4BLRzrt5I=; b=BjKinCN2Gf7YT3ad++60ZL+zh8OjqhIOD+KEio63p5sj3waz2RqcatCQLH+cRUYHh1 wPt1xROAjwxy1ju2WfuZd75AascN+0+Evao8CA6aZHtP9vhMlCkTX2/lkzO4k4HqSqhp vRNbSfVHZt5jbMUalmR9ecpI6yshuCvMMYSc3XanamlWeCSZgpocs5BqILZmLf1x+iD8 fPfnRKy/eamqgzlg7vGPeKcgwIXwZ4x6bPAjpWt52KlIxQv5OeR1xoDxjF1n2GUBneh3 T23V5mz1pFeSwuQ3tW4/RNHH97wQ4c9KMA2H19XupVQthk+wRWSo6FLPjM+iEEYLIEfc 6wLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R1kkxMXvX73GBFCzM4m3KwlWe0RfxVAwZ+4BLRzrt5I=; b=HGqNL+3ptE1mvntw/ZkxQSasHvuUw/U7yAaM07rWS/iH86QFN9GZWfmEGeIpKRzCQ6 gQJ8u+584Gw0FhH6Ip8PV0U5coXkSPZ7EX++mpseuyl+lTajz2xY9nZiu9QWR1LQuPeZ c0oNRTcRrxWXHuecKq2rIHqzli5DSDc7MrfPOSJu2nMmnp0PT5jyb+vKLDbtXRROkiu8 1P34krgn1Sx2GHHexP1UUMkPMju0UGuOaPxjLOLLSKGKasbJ2a0mIZjLCs1vCxBsjOd8 T5eLh3tsUcj5RbUNYHPmAlrtIuazii/v1uOnDU5AQVi7aFiCBWlmjE1I27CkWSFnWmhg eWaQ== X-Gm-Message-State: AKGB3mIOWlbz/sFvL48/24ht0VraLcjJizsfKM1dBCTi8wY96kL5mhWv AiQsPdEH/+xOyDbc7lquu/1/xG3NIsPDhEqro3s= X-Google-Smtp-Source: ACJfBosziYNbjEKI90WrRaaj2yQASPYpnEzWAGhXtKpWYXScTJcI/TfcuOTsDLOcy6m83sm+oA5awuuy3K1ZHcYJp0g= X-Received: by 10.107.141.210 with SMTP id p201mr3088031iod.272.1515015769590; Wed, 03 Jan 2018 13:42:49 -0800 (PST) MIME-Version: 1.0 References: <9426D822-58C7-424F-B0DA-E4C3790ECB91@dukhovni.org> In-Reply-To: From: Adam Montville Date: Wed, 03 Jan 2018 21:42:38 +0000 Message-ID: To: Tim Hollebeek Cc: "saag@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05f2b2c68fb50561e618d1" Archived-At: Subject: Re: [saag] Use of TSIG 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, 03 Jan 2018 21:42:52 -0000 --94eb2c05f2b2c68fb50561e618d1 Content-Type: text/plain; charset="UTF-8" There are venues that exist to define secure configurations for technologies, including implementation-specific DNS services. https://www.cisecurity.org/benchmark/bind/ Kind regards, Adam On Wed, Jan 3, 2018 at 3:39 PM Tim Hollebeek wrote: > > This means that administration tools should make it easy to choose > sensible > > settings, and (more) difficult to choose "exotic" settings. When tools > are > > completely neutral on parameter choices, the resulting diversity is > generally > > counter-productive. See for example: > > > > https://lists.dns-oarc.net/pipermail/dns-operations/2017- > > December/017125.html > > Unfortunately, of course, the proper sensible settings change with time. > I'm all for sane defaults, but it doesn't fix the problem of a server that > was > configured 20+ years ago with sensible settings. > > It really would be nice if I could set my security to MEDIUM and my device > could reconfigure itself appropriately over time as things change. > > Heck, it'd be nice if it could alert me that my recommended settings are no > longer recommended. I do think there's lots of room for better software > in this area, especially for long lived servers and devices ... > > -Tim > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --94eb2c05f2b2c68fb50561e618d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are venues that exist to define secure configuration= s for technologies, including implementation-specific DNS services.=C2=A0https://www.cisecurity= .org/benchmark/bind/

Kind regards,

Adam

On = Wed, Jan 3, 2018 at 3:39 PM Tim Hollebeek <tim.hollebeek@digicert.com> wrote:
> This means that administration tools should ma= ke it easy to choose
sensible
> settings, and (more) difficult to choose "exotic" settings.= =C2=A0 When tools
are
> completely neutral on parameter choices, the resulting diversity is generally
> counter-productive.=C2=A0 See for example:
>
>=C2=A0 =C2=A0 https://lists.dns-oarc.ne= t/pipermail/dns-operations/2017-
> December/017125.html

Unfortunately, of course, the proper sensible settings change with time. I'm all for sane defaults, but it doesn't fix the problem of a serv= er that
was
configured 20+ years ago with sensible settings.

It really would be nice if I could set my security to MEDIUM and my device<= br> could reconfigure itself appropriately over time as things change.

Heck, it'd be nice if it could alert me that my recommended settings ar= e no
longer recommended.=C2=A0 I do think there's lots of room for better so= ftware
in this area, especially for long lived servers and devices ...

-Tim

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--94eb2c05f2b2c68fb50561e618d1-- From nobody Wed Jan 3 13:51:04 2018 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 E16AF12422F for ; Wed, 3 Jan 2018 13:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 O5lORpdpw3pn for ; Wed, 3 Jan 2018 13:51:02 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B41B120726 for ; Wed, 3 Jan 2018 13:51:02 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A69377A3309 for ; Wed, 3 Jan 2018 21:51:01 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 Jan 2018 16:51:00 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: saag@ietf.org Message-Id: References: <9426D822-58C7-424F-B0DA-E4C3790ECB91@dukhovni.org> To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] Use of TSIG 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, 03 Jan 2018 21:51:04 -0000 > On Jan 3, 2018, at 4:39 PM, Tim Hollebeek = wrote: >=20 > Unfortunately, of course, the proper sensible settings change with = time. > I'm all for sane defaults, but it doesn't fix the problem of a server = that > was configured 20+ years ago with sensible settings. Yes, that's difficult, but not a reason to give up. > It really would be nice if I could set my security to MEDIUM and my = device > could reconfigure itself appropriately over time as things change. Postfix TLS cipher selection does essentially this. The interface for the general user is: smtp_tls_ciphers =3D medium smtpd_tls_ciphers =3D medim however, an advanced interface is available, but users are warned away from tinkering with it. This enables future modification of the meaning of "medium". tls_medium_cipherlist =3D ... The default value of that setting changes as needed with new releases = and also the underlying OpenSSL library also modifies MEDIUM from time to = time when algorithms lose their shine. So security is maintained either when users upgrade, or if that's not an option by following authoritative advice to update the underlying = low-level parameters. Presenting simple interfaces to most users and warning them away from getting in over their head by tinkering with parameters they don't understand is IMHO a fundamental part of delivering usable security. --=20 Viktor. From nobody Wed Jan 3 14:09:19 2018 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 14AE912420B for ; Wed, 3 Jan 2018 14:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 MXFvWrQeGMwz for ; Wed, 3 Jan 2018 14:09:17 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 26C9D120726 for ; Wed, 3 Jan 2018 14:09:17 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B0B843B7652; Wed, 3 Jan 2018 22:08:28 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 50805216C1C; Wed, 3 Jan 2018 22:08:28 +0000 (UTC) Date: Wed, 3 Jan 2018 22:08:28 +0000 From: Evan Hunt To: Phillip Hallam-Baker Cc: DNS Operations List , saag@ietf.org Message-ID: <20180103220828.GA73259@isc.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [saag] [dns-operations] Use of TSIG 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, 03 Jan 2018 22:09:18 -0000 On Wed, Jan 03, 2018 at 04:07:51PM -0500, Phillip Hallam-Baker wrote: > As folk who are following a certain FB page know, I am configuring a BIND > server direct for the first time in a while and so just for the heck of it, > I decided to configure using only sources that I find on the Web that are > not actual manuals. I'm not sure why you decided to do that, but I can tell you that what you're reading is massively out of date. If you want to generate a TSIG key, use "tsig-keygen". It uses an appropriate source of randomness and produces output in a format suitable for use in named.conf. What was the source of the information you found? -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From nobody Wed Jan 3 14:51:41 2018 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 47FB4129C6A for ; Wed, 3 Jan 2018 14:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 69hjuwlOXnPz for ; Wed, 3 Jan 2018 14:51:38 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 B2452120046 for ; Wed, 3 Jan 2018 14:51:38 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id x20so1952004oix.12 for ; Wed, 03 Jan 2018 14:51:38 -0800 (PST) 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=62gUe/K1E00YScDe4c3U8vh3OkPs2A/lbAlCLCZ65E0=; b=CDiA/FC3bXIopOoHCGs/QvHOHfcQnzCjnuebh3Md1DLNrh+XR4knBU+e6CukHz000r 7xF9/QcwuWFh+cKJk2yh59BZKWdqvXv/U9DT1MDB9kxUe7q+4P/VdrD8W64N4U61is1S cMqbDgQmNDU3AVBK7/S4GkDy9dGLxHv7zTsGECYpR13cQiUIocCGmQMzicdCbmXP+f7I jxSchJiYwN9whBL2XzgaTvk88YE6FoQATt+j7t2VS7rDTeYUHTveLQO/7pX/pFnjIQ3v /5fE1+2DOqNRheYymgt+3yddHdQOYjRKUzOqZyy+dAfB/QJunzWQCT+S2gws0grlbaK7 QnXg== 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=62gUe/K1E00YScDe4c3U8vh3OkPs2A/lbAlCLCZ65E0=; b=a2L0r15Ces8Ctmhael6i4cw6rc0UkaQ6AL7sltUebh3b+NXeL9pnOgVU6aXsRb1PHd 8yix1XtXpvbdZUk8CCbxw+BQLbcDejVjhskv9Ra7WcxNMl16i+KbwKA+oUm2LYcBC5g6 5PrXw7WGD+BwmMlQsPzc4A+SGaxaGqgqnBlT6y/wnd06CJfa67o73gJCT2lRU8Z7UNag 7o0bvuBrUxCwfh3vpQ4Wzc8hjKLpGZbnfpAoP1r3n6KBRKOlv0xsav4JmX+DDEfmuoMR xpM+BT93d9gV12xhxbhUevgGv3uFZ+QDjTGC2ocLdsp9OKRtVumCAoLU8mEtAbC6jAD9 xN5A== X-Gm-Message-State: AKGB3mJa9IJfi/MWUz0k0o5M+NdvM7EeHK7KbXHBD3OvHszTi2xtv4l+ j7Mj/9INGLMf5usluvx+ndqQRfZp6NblDGj3H28= X-Google-Smtp-Source: ACJfBosXLgyqqRzBF91Tv8mxWc1Gi+J9Xx86QsgiG8ADErhwgPjn+Ex0CuuIye4AwqpSFOVrexK+zhKELrYHAlCB5Cs= X-Received: by 10.202.245.216 with SMTP id t207mr1357766oih.265.1515019898122; Wed, 03 Jan 2018 14:51:38 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.49.87 with HTTP; Wed, 3 Jan 2018 14:51:37 -0800 (PST) In-Reply-To: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> References: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> From: Phillip Hallam-Baker Date: Wed, 3 Jan 2018 17:51:37 -0500 X-Google-Sender-Auth: bpf_wB7Y_tKiadelhSBgibo1ZfI Message-ID: To: Andrew Sullivan Cc: saag@ietf.org Content-Type: multipart/alternative; boundary="001a113df248daf8980561e70e4b" Archived-At: Subject: Re: [saag] Use of TSIG 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, 03 Jan 2018 22:51:40 -0000 --001a113df248daf8980561e70e4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 3, 2018 at 4:17 PM, Andrew Sullivan wrote: > Hi, > > On Wed, Jan 03, 2018 at 04:07:51PM -0500, Phillip Hallam-Baker wrote: > > I decided to configure using only sources that I find on the Web that a= re > > not actual manuals. > > I don't understand this plan. You're saying that you have forsaken > the manual for your software in favour of random things you find on > the Internet? I mean, whatever floats your boat, but I often find > that a comprehensive manual for my software contains better > information than things I learned in the virtual schoolyard. =E2=80=8BI am saying I am following what I believe to be the approach follo= wed by 90% of network admins.=E2=80=8B =E2=80=8BMy interest is to find out why things are going wrong. Wishing tha= t people will read manuals is like wishing for a unicorn.=E2=80=8B --001a113df248daf8980561e70e4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Ja= n 3, 2018 at 4:17 PM, Andrew Sullivan <ajs@anvilwalrusden.com>= wrote:
Hi,

On Wed, Jan 03, 2018 at 04:07:51PM -0500, Phillip Hallam-Baker wrote:
> I decided to configure using only sources that I find on the Web that = are
> not actual manuals.

I don't understand this plan.=C2=A0 You're saying that you h= ave forsaken
the manual for your software in favour of random things you find on
the Internet?=C2=A0 I mean, whatever floats your boat, but I often find
that a comprehensive manual for my software contains better
information than things I learned in the virtual schoolyard.

= =E2=80=8BI am saying I am following what I believe to be the approach follo= wed by 90% of network admins.=E2=80=8B

=E2=80=8BMy interest is to find out = why things are going wrong. Wishing that people will read manuals is like w= ishing for a unicorn.=E2=80=8B



--001a113df248daf8980561e70e4b-- From nobody Wed Jan 3 15:11:38 2018 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 C20DD12D77B for ; Wed, 3 Jan 2018 15:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUeYPJmpOCeO for ; Wed, 3 Jan 2018 15:11:35 -0800 (PST) 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 A17D4120046 for ; Wed, 3 Jan 2018 15:11:35 -0800 (PST) Received: from [169.254.18.95] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w03NBNEa020782 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Jan 2018 16:11:24 -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.18.95] From: "Paul Hoffman" To: "Phillip Hallam-Baker" Cc: saag@ietf.org Date: Wed, 03 Jan 2018 15:11:30 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: In-Reply-To: References: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] Use of TSIG 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, 03 Jan 2018 23:11:37 -0000 On 3 Jan 2018, at 14:51, Phillip Hallam-Baker wrote: > ​I am saying I am following what I believe to be the approach > followed by > 90% of network admins.​ > > ​My interest is to find out why things are going wrong. Wishing that > people > will read manuals is like wishing for a unicorn.​ Is there anything any of us can do about what you found? Short of someone going and removing links to web pages that have wrong information, I don't see how we can make the situation better. --Paul From nobody Wed Jan 3 15:20:01 2018 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 7C95412D7E6 for ; Wed, 3 Jan 2018 15:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BHZIhMykz-GS for ; Wed, 3 Jan 2018 15:19:59 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DEC51241F8 for ; Wed, 3 Jan 2018 15:19:59 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 4A0147A3309 for ; Wed, 3 Jan 2018 23:19:58 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 3 Jan 2018 18:19:57 -0500 Content-Transfer-Encoding: 7bit Reply-To: saag@ietf.org Message-Id: <7FECBEF1-5152-41D0-8AE9-171847FA95FE@dukhovni.org> References: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] Use of TSIG 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, 03 Jan 2018 23:20:00 -0000 > On Jan 3, 2018, at 6:11 PM, Paul Hoffman wrote: > > Is there anything any of us can do about what you found? Short of someone > going and removing links to web pages that have wrong information, I don't > see how we can make the situation better. Yes. Software should offer an overlay of simplified (mostly idiot-proof) interfaces that will be obviously the right ones to use for most users, and advanced interfaces for unanticipated mitigations for future issues should not also be the routine day to day configuration interfaces. That's my favourite mitigation, there are of course others. -- Viktor. From nobody Wed Jan 3 15:22:51 2018 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 2EE9912D7E6 for ; Wed, 3 Jan 2018 15:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eJx1Xo-ZW1z for ; Wed, 3 Jan 2018 15:22:47 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25F91241F8 for ; Wed, 3 Jan 2018 15:22:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CDEACBE3E; Wed, 3 Jan 2018 23:22:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-KtAMxtU8Ja; Wed, 3 Jan 2018 23:22:43 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 13945BE49; Wed, 3 Jan 2018 23:22:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1515021763; bh=0jc3IhmTFBR2ruYxX3h8NZtNOo62nYa1t6Bvq1VB9y4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VQwfew0ngtD6VY+zWt+MxHwRVmdeWgbWMqPXK5dkkxz+DN9nrbhHgGHjRxU+xhN4N 8AU2hOxSX6p0PZiWQUi8e61jCP6VizVAicG+K4o9MGuVy3IFz2j0pOwTpMd/FqoWLO 7uBfvpQK++YZOBaK2qA81834DOY8zT8csXnVxRZY= To: Paul Hoffman , Phillip Hallam-Baker Cc: saag@ietf.org References: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <4a03140e-05ee-f3a5-3dbd-3b7e0f967e63@cs.tcd.ie> Date: Wed, 3 Jan 2018 23:22:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CGtVBFmpCt1X6J4jTOhS6HqewCwUFM23r" Archived-At: Subject: Re: [saag] Use of TSIG 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, 03 Jan 2018 23:22:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CGtVBFmpCt1X6J4jTOhS6HqewCwUFM23r Content-Type: multipart/mixed; boundary="D0hWcmXhvb5FCGWAkeNj5ZE4APlRJTZkA"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman , Phillip Hallam-Baker Cc: saag@ietf.org Message-ID: <4a03140e-05ee-f3a5-3dbd-3b7e0f967e63@cs.tcd.ie> Subject: Re: [saag] Use of TSIG References: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> In-Reply-To: --D0hWcmXhvb5FCGWAkeNj5ZE4APlRJTZkA Content-Type: multipart/mixed; boundary="------------81338BC9E20A6A988687CB97" Content-Language: en-GB This is a multi-part message in MIME format. --------------81338BC9E20A6A988687CB97 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/01/18 23:11, Paul Hoffman wrote: >=20 > Is there anything any of us can do about what you found? Yeah, not much really. We could include more appendices in RFCs that show how to get started with some widely used implementation, e.g. for crypto things I like RFCs that show how to get started and generate/check test vectors using the openssl command line. Other than that it comes down to the person reading the RFC/manual/stackexchange/blog to know what's crap and what isn't. Educating the general system user/admin about that seems beyond the IETF's remit to me too. S --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------81338BC9E20A6A988687CB97 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------81338BC9E20A6A988687CB97-- --D0hWcmXhvb5FCGWAkeNj5ZE4APlRJTZkA-- --CGtVBFmpCt1X6J4jTOhS6HqewCwUFM23r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaTWXBAAoJEFqy+vF7FyvqCFEQAKUH3a4pGDH6OkqDlmFPvsu4 UcDHHVLCl6zP0Php5lGQGQXnCkUnvy0O/GGF++VgESUYnloZ+zYJLM/Mc27iO5wK 4DebmI6VBn6kDyaQuN3v7p3Ugish44/Z5M2Tf6zh48eGZCosRR43E+o58Jxzgl59 Vv600Y0Q0WUSeePHj1En+sk5u38gtTzkID2ZdzwTqIlxMe9zmh7ScD+B+XTj7vk7 3fXo9+h+KMReeLUzTQWJgRSl3Y0eh6r10Kb9+Pon4KWhFwZRsiGaa0ydjhdKOA9x PHoa9zsnWHV44TJq8Itk7ddWvJDKYHNq/RFo4eQFoeLoMyz35C0LPydKIfB42mZ6 otYqqsOLTAMf0db19+MuSbl6u/7fV2NFh0gDu9505IbCPhlovNnW0wpBXF9o5NwJ p8cLV/S4vvwcqh8wyTDfUpyvDzsOFUBKk07bbQHCGZgBXjTjIKVasxaL/kvwi1h1 0wRXgQW5NnSYEY4QzuZJSJMAnsojUBKxWEJr90W4bKdNiEq49Ql4ZY1Exk2AluYb 7Pinl+KAd2MwV5U2ZqDVL5l5djkvRfz/Nu5BNV8/bCom2c9odekvmSLFYz1PO3mK N3gj0I/AQDRoppojoVsPn+wnyazN3VT2e0nPnjfsDpILqJN3aeQ83bFcC0rPqaPk 8kaKChAnP9p3fNOHD3/p =swpK -----END PGP SIGNATURE----- --CGtVBFmpCt1X6J4jTOhS6HqewCwUFM23r-- From nobody Wed Jan 3 16:09:49 2018 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 6E07112D7FC for ; Wed, 3 Jan 2018 16:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PV7WD5bziOJv for ; Wed, 3 Jan 2018 16:09:45 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46503126BF6 for ; Wed, 3 Jan 2018 16:09:45 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3E441F99B; Wed, 3 Jan 2018 19:09:43 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 37F3520780; Wed, 3 Jan 2018 19:09:35 -0500 (EST) From: Daniel Kahn Gillmor To: Stephen Farrell , Paul Hoffman , Phillip Hallam-Baker Cc: saag@ietf.org In-Reply-To: <4a03140e-05ee-f3a5-3dbd-3b7e0f967e63@cs.tcd.ie> References: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> <4a03140e-05ee-f3a5-3dbd-3b7e0f967e63@cs.tcd.ie> Date: Wed, 03 Jan 2018 19:09:32 -0500 Message-ID: <87mv1ucwn7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [saag] Use of TSIG 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, 04 Jan 2018 00:09:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed 2018-01-03 23:22:41 +0000, Stephen Farrell wrote: > On 03/01/18 23:11, Paul Hoffman wrote: >>=20 >> Is there anything any of us can do about what you found? > > Yeah, not much really. > > We could include more appendices in RFCs that show how to > get started with some widely used implementation, e.g. for > crypto things I like RFCs that show how to get started and > generate/check test vectors using the openssl command line. > > Other than that it comes down to the person reading the > RFC/manual/stackexchange/blog to know what's crap and what > isn't. Educating the general system user/admin about that > seems beyond the IETF's remit to me too. As long as the IETF keeps user interface and user experience (even of system administrators) outside of its scope of work, we will continue to encourage the production of footguns. I don't particularly want to have lengthy IETF-style discussions about UI/UX, but our guidance is usually aimed at technical exhaustiveness (if not exhaustion), and we rarely provide guidance on minimal, simplistic profiles. I'm guilty of this too, in IETF contexts. :( For example, In retrospect, i think our DPRIVE authentication profiles draft should not have outlined quite so many options. i think we would do well to encourage the writing of knowledgable, highly-opinionated informational drafts that set forth narrow "best practices" for software implementers. When i compare the user (administrator) experience with wireguard [0] against the user (administrator) experience of any of the range of IPSec implementations i've worked with [1], it's night and day. It's not surprising to me that the design-by-committee and curse-of-the-deployed-base that produced today's IPSec doesn't have the same clarity of vision and ease of use as Donenfeld's singleminded focus. But it's pretty depressing to me that even skilled implementors can't pull together a "default install" setup that Just Works based on IETF standards. I understand that we nerds love power and flexibility and expansive toolkits, but if we want our tools to have a positive impact on people, we need to spend a lot more time thinking about the shortest path to installation, and make sure our implementations optimize for it. --dkg [0] https://wireguard.com/ [1] https://strongswan.org/ https://libreswan.org/ http://www.kame.net/ http://www.unix-ag.uni-kl.de/~massar/vpnc/ etc=E2=80=A6 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEDuW+l5KC2AufdUDxzNLtlNIXOekFAlpNcLwACgkQzNLtlNIX OekfmhAAnb7DlTCPq/RPkPyfLfSVOCAOiocf3+DPZFCFsc13m4OCWswb9s1An0uW /pBkwNJOx4HYO96buLuReP/1WIMKk768nB/UvVFGxYIgP13ezNfBUqheM+Metywu meH+f9bO3rXXmuk289KjirGUPwcURishe8OCiCUTCgzohBz2lMUm2AZYrXqOfwU5 NcNUDq0bfluCkPKiIL4voRGuUo8h6kPHUkV6Kvong/MJSKUffDy97VQ8l1q2VsUc sTjMn9y/yybUL5MHqNoAjWrDPYUL4ldEbR73j+QUh0KZZDO10aAgp2hp6pSVO6r7 cWsLBrLPn0qDzUjcj/ruf7I2y5F1JFwENcdwE0kIUS4+WlIHG0tOm14W3Dyk9iqP Nu1HTO6jdbX7c+1Md6a+szI3IBoAgF4BD0W5QkxH9trhZho4VaDUcEMMuay07DyJ ypUn05YmzrGHDTLE0hcNQOsui/2at1XYGD9T7Bti5vNwUE1FmekGZHHRcHnlLxYa kns0kpSJFszsGMpF4qfekqmKDoAH9jqAhcViQio9qqmtGThM4lqTYtSOIsMS34v6 H9z6o5LeqEjsSV1vII41LTKgob3csPfGVQmUX5DebtRXpmGmbHlJ7Dx2c2RKjiFq UY0sO75EloNIyEWYwBu9Pza0KTWdKvUAEq1gbvwMPD6QdvN72EY= =9Vyv -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 3 16:26:31 2018 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 6EF0A12D810 for ; Wed, 3 Jan 2018 16:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=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 nhMtcfpB4V2H for ; Wed, 3 Jan 2018 16:26:28 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 3C54D12D7F7 for ; Wed, 3 Jan 2018 16:26:28 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id q39so75621otb.8 for ; Wed, 03 Jan 2018 16:26:28 -0800 (PST) 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=IAmoXyFAjwNfy1k+d+AtIqLvfhuHLDUfM3ajnvgTv6s=; b=LsaFyucG/66d41VzEFAgT1+nwPiMnqe1D5MhlH2MYaOKqMdD2L4AmTw28bofzGM+va Ls/zHIqLzb6DLMDeFwqxvE8w1TOVW3HzDHw4NHKQ+e97/Ly5kqcLh/FozeMj9yPMgPHW 3GuPREjij8Z2yC6v811sO8X/mEtOB0Yr86OoQgJLtNajb9Q49HJeWuy0NwGOuQpvv82h RVvaYQDY4Jt5dqW/FMosAwvNNE+ya353kEODSfMxAAySw9vfxy7i2Guylk1hmmuG1F1Z n+pzIO2TubRb7SlD2T6PCLt11+ATvOqw5oNBRf3st00xUor8+ZpKZgcBoof/rW5S8C8C nDeg== 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=IAmoXyFAjwNfy1k+d+AtIqLvfhuHLDUfM3ajnvgTv6s=; b=oka1oJYwJAFmPYM9uuc73qL4MISRA2uVmPdft8DTkhJt3qzSu2q5pO8TDfNPrAY79u Nxh9Eer89tCQRZl6yG17jcEYf31F1SOsDxszGqNQ8sCgnbk+fGTP0W6oE0oQIR/MT7v+ 3cHJwaZeXBn1yhiyZgISLONo2EwopLOvM5Kiw4Hah+ikIDlefOE8qQLAA6RryqOYGPW6 JUj6btQaOCb8+M78a0TrBUH6tRp8TKSjmfLdNicnR0t0MBR7FAbqmaWpHVKYfX3VXl/O IhqZ2DNqsez+DvrRrIoE9rY7hP5V+ai0KH8+0RbDttGlEPmBmMd2UFnhRfohuYifRs5B Y5/A== X-Gm-Message-State: AKGB3mJ5fEk21PU6vsvTppgHT4lfUR3prL8YDwvOc+goZ5dGiOX6pf9X jyIR6d65i9YVMhFO21QSUydK+jtCU8ab2feLtzs= X-Google-Smtp-Source: ACJfBosKn7rbZnXIs66sSCVdSHgAQ6Wpyg3T9wf/0y+3ljveBCfNBTcuVGGasiB3wfhD1KLXcbauTYOVgmpueDkt0XY= X-Received: by 10.157.24.116 with SMTP id t49mr1747319ott.60.1515025587487; Wed, 03 Jan 2018 16:26:27 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.49.87 with HTTP; Wed, 3 Jan 2018 16:26:26 -0800 (PST) In-Reply-To: <87mv1ucwn7.fsf@fifthhorseman.net> References: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> <4a03140e-05ee-f3a5-3dbd-3b7e0f967e63@cs.tcd.ie> <87mv1ucwn7.fsf@fifthhorseman.net> From: Phillip Hallam-Baker Date: Wed, 3 Jan 2018 19:26:26 -0500 X-Google-Sender-Auth: qWw_ZdD_8f8yCY87Em-pwKei7Vw Message-ID: To: Daniel Kahn Gillmor Cc: Stephen Farrell , Paul Hoffman , saag@ietf.org Content-Type: multipart/alternative; boundary="001a1142e598f7c94d0561e861f2" Archived-At: Subject: Re: [saag] Use of TSIG 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, 04 Jan 2018 00:26:30 -0000 --001a1142e598f7c94d0561e861f2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BIn addition to the points DKG makes, a requirement to describe how= to configure a system properly entails a requirement for such a configuration to 1) exist and 2) be capable of being described clearly. I am pretty sure the Kaminsky bug would have been recognized much earlier if the design of glue records wasn't so bjorked in the first place. The mindset of the typical engineer is 'make it work'. That is not at all the same as the security engineering mindset of 'make it safe'. I agree that getting people to listen is a problem. But there are two groups corporations are generally forced to listen to: their insurers and politicians. On Wed, Jan 3, 2018 at 7:09 PM, Daniel Kahn Gillmor wrote: > On Wed 2018-01-03 23:22:41 +0000, Stephen Farrell wrote: > > On 03/01/18 23:11, Paul Hoffman wrote: > >> > >> Is there anything any of us can do about what you found? > > > > Yeah, not much really. > > > > We could include more appendices in RFCs that show how to > > get started with some widely used implementation, e.g. for > > crypto things I like RFCs that show how to get started and > > generate/check test vectors using the openssl command line. > > > > Other than that it comes down to the person reading the > > RFC/manual/stackexchange/blog to know what's crap and what > > isn't. Educating the general system user/admin about that > > seems beyond the IETF's remit to me too. > > As long as the IETF keeps user interface and user experience (even of > system administrators) outside of its scope of work, we will continue to > encourage the production of footguns. > > I don't particularly want to have lengthy IETF-style discussions about > UI/UX, but our guidance is usually aimed at technical exhaustiveness (if > not exhaustion), and we rarely provide guidance on minimal, simplistic > profiles. > > I'm guilty of this too, in IETF contexts. :( For example, In > retrospect, i think our DPRIVE authentication profiles draft should not > have outlined quite so many options. > > i think we would do well to encourage the writing of knowledgable, > highly-opinionated informational drafts that set forth narrow "best > practices" for software implementers. > > When i compare the user (administrator) experience with wireguard [0] > against the user (administrator) experience of any of the range of IPSec > implementations i've worked with [1], it's night and day. It's not > surprising to me that the design-by-committee and > curse-of-the-deployed-base that produced today's IPSec doesn't have the > same clarity of vision and ease of use as Donenfeld's singleminded > focus. But it's pretty depressing to me that even skilled implementors > can't pull together a "default install" setup that Just Works based on > IETF standards. > > I understand that we nerds love power and flexibility and expansive > toolkits, but if we want our tools to have a positive impact on people, > we need to spend a lot more time thinking about the shortest path to > installation, and make sure our implementations optimize for it. > > --dkg > > [0] https://wireguard.com/ > [1] https://strongswan.org/ > https://libreswan.org/ > http://www.kame.net/ > http://www.unix-ag.uni-kl.de/~massar/vpnc/ > etc=E2=80=A6 > --001a1142e598f7c94d0561e861f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2= =80=8BIn addition to the points DKG makes, a requirement to describe how to= configure a system properly entails a requirement for such a configuration= to 1) exist and 2) be capable of being described clearly. I am pretty sure= the Kaminsky bug would have been recognized much earlier if the design of = glue records wasn't so bjorked in the first place.

The mindset of the typical engineer is 'm= ake it work'. That is not at all the same as the security engineering m= indset of 'make it safe'.

I agree that getting people to listen is a problem. But there ar= e two groups corporations are generally forced to listen to: their insurers= and politicians.=C2=A0


On Wed, Jan 3, 2018 at 7:09 PM, Daniel Kahn Gillmor <dkg@fifth= horseman.net> wrote:
On Wed 2018-01-03 23:22:41 +0000, Stephen Farrell wrote:
> On 03/01/18 23:11, Paul Hoffman wrote:
>>
>> Is there anything any of us can do about what you found?
>
> Yeah, not much really.
>
> We could include more appendices in RFCs that show how to
> get started with some widely used implementation, e.g. for
> crypto things I like RFCs that show how to get started and
> generate/check test vectors using the openssl command line.
>
> Other than that it comes down to the person reading the
> RFC/manual/stackexchange/blog to know what's crap and what
> isn't. Educating the general system user/admin about that
> seems beyond the IETF's remit to me too.

As long as the IETF keeps user interface and user experience (even o= f
system administrators) outside of its scope of work, we will continue to encourage the production of footguns.

I don't particularly want to have lengthy IETF-style discussions about<= br> UI/UX, but our guidance is usually aimed at technical exhaustiveness (if not exhaustion), and we rarely provide guidance on minimal, simplistic
profiles.

I'm guilty of this too, in IETF contexts.=C2=A0 :( For example, In
retrospect, i think our DPRIVE authentication profiles draft should not
have outlined quite so many options.

i think we would do well to encourage the writing of knowledgable,
highly-opinionated informational drafts that set forth narrow "best practices" for software implementers.

When i compare the user (administrator) experience with wireguard [0]
against the user (administrator) experience of any of the range of IPSec implementations i've worked with [1], it's night and day.=C2=A0 It&= #39;s not
surprising to me that the design-by-committee and
curse-of-the-deployed-base that produced today's IPSec doesn't have= the
same clarity of vision and ease of use as Donenfeld's singleminded
focus.=C2=A0 But it's pretty depressing to me that even skilled impleme= ntors
can't pull together a "default install" setup that Just Works= based on
IETF standards.

I understand that we nerds love power and flexibility and expansive
toolkits, but if we want our tools to have a positive impact on people,
we need to spend a lot more time thinking about the shortest path to
installation, and make sure our implementations optimize for it.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg

[0] https://wireguard.com/
[1] https://strongswan.org/
=C2=A0 =C2=A0 https://libreswan.org/
=C2=A0 =C2=A0 http://www.kame.net/
=C2=A0 =C2=A0 http://www.unix-ag.uni-kl.de/~massar/vp= nc/
=C2=A0 =C2=A0 etc=E2=80=A6

--001a1142e598f7c94d0561e861f2-- From nobody Wed Jan 3 22:47:04 2018 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 7C51412422F for ; Wed, 3 Jan 2018 22:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 0c36RY09KTtz for ; Wed, 3 Jan 2018 22:47:01 -0800 (PST) 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 54A9A1200FC for ; Wed, 3 Jan 2018 22:47:01 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eWzIj-0007ZA-TW; Thu, 04 Jan 2018 06:46:54 +0000 Date: Thu, 04 Jan 2018 15:46:51 +0900 Message-ID: From: Randy Bush To: Stephen Farrell Cc: Paul Hoffman , Phillip Hallam-Baker , saag@ietf.org In-Reply-To: <4a03140e-05ee-f3a5-3dbd-3b7e0f967e63@cs.tcd.ie> References: <20180103211723.5c7g2c32lbpx2emj@mx4.yitter.info> <4a03140e-05ee-f3a5-3dbd-3b7e0f967e63@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 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] Use of TSIG 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, 04 Jan 2018 06:47:02 -0000 the prudent operator/sysadmin does not swollow without analysis data from the net of a thousand lies. From nobody Fri Jan 5 13:37:31 2018 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 30769126DEE for ; Fri, 5 Jan 2018 13:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 (1024-bit key) header.d=nistgov.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 XJgnchk1AXfc for ; Fri, 5 Jan 2018 13:37:27 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0121.outbound.protection.outlook.com [23.103.201.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E5C124D6C for ; Fri, 5 Jan 2018 13:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3FMld7vFo9cKHVV12iIJBGYiZzSOr+fnoF1BmN9TKQA=; b=Kaaui8tnWEuZ55nlDNnJ1ysCoBvSJN/FY4zwqQmcexN6gyv9ZI9af4mK9amZ/Tt2JGodKPp738KwdtLrBO4giKh0pel3fq7YUBYaLdysuO0i90HQ44a5Xx+axJPqyWZDmO07w9L1PmfWZgF9UTfTKtB4wxQTt3NvGtKZ9gZuKD8= Received: from MWHPR09MB1520.namprd09.prod.outlook.com (10.173.50.146) by MWHPR09MB1517.namprd09.prod.outlook.com (10.173.50.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 5 Jan 2018 21:37:25 +0000 Received: from MWHPR09MB1520.namprd09.prod.outlook.com ([10.173.50.146]) by MWHPR09MB1520.namprd09.prod.outlook.com ([10.173.50.146]) with mapi id 15.20.0386.005; Fri, 5 Jan 2018 21:37:25 +0000 From: "Polk, Tim (Fed)" To: "saag@ietf.org" Thread-Topic: draft report on countering botnets available for public comment Thread-Index: AQHThm1arDysMrGOdkWcNnNt70+Qrg== Date: Fri, 5 Jan 2018 21:37:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.226.182] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR09MB1517; 7:NqEeABmyqdUSScBmwORkNBe1cXcybbspWanES86NCDKXgPMwd0PnhRzEav9GW8kaPLyuc7RvUUGu9R+WotlCcqgvhme93RxbB2xS5lw1kQKvdK0ShfFBfwDcQKgTMZGd2IoXPwhoncIxRLvEoWIdtfHaKSAtTQ0109uw/9Gn2Z+yqZEEnR8bfJUqy+DcpJDRP8YGy+2YuqC/G/i/AeJXyXzZ9gaWuNmwkm9sQaVD4I6xpvwUt/fjw0LnTMjJjqHM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9b9890a1-d5fd-4a23-6248-08d5548482e0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:MWHPR09MB1517; x-ms-traffictypediagnostic: MWHPR09MB1517: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(189930954265078)(131022147185803)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6055026)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:MWHPR09MB1517; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR09MB1517; x-forefront-prvs: 05437568AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39380400002)(396003)(346002)(39860400002)(189003)(199004)(53936002)(2900100001)(14454004)(25786009)(478600001)(9686003)(6916009)(6606003)(106356001)(102836004)(6506007)(59450400001)(316002)(236005)(55016002)(97736004)(53946003)(7736002)(6436002)(54896002)(606006)(86362001)(77096006)(6306002)(5640700003)(66066001)(105586002)(6116002)(3846002)(2501003)(1730700003)(3280700002)(8676002)(3660700001)(74316002)(99286004)(2906002)(5660300001)(8936002)(68736007)(81156014)(19627405001)(7696005)(2351001)(81166006)(33656002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1517; H:MWHPR09MB1520.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=william.polk@nist.gov; x-microsoft-antispam-message-info: Y+1YxXpoMA59wLuc3qQjDJIAQqZrhuNRjO62lR+qbQo19zeCVqKOLYnmxM5DaAOifNfUANyBc1J94g60yepU5Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR09MB15207FF5B66E41C31B8A2C30E71C0MWHPR09MB1520namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 9b9890a1-d5fd-4a23-6248-08d5548482e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2018 21:37:24.9859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1517 Archived-At: Subject: [saag] draft report on countering botnets available for public comment 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, 05 Jan 2018 21:37:30 -0000 --_000_MWHPR09MB15207FF5B66E41C31B8A2C30E71C0MWHPR09MB1520namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, Departments of Commerce and Homeland Security have released the public draf= t of a report on countering botnets. I hope this community will review and= contribute to this project. I have appended a brief announcement with a c= ouple of relevant URLs to this message.. Thanks, Tim Polk ------------ Departments of Commerce and Homeland Security release draft report to the P= resident on "Enhancing the Resilience of the Internet and Communications Ec= osystem Against Botnets and Other Automated, Distributed Threats" A draft report that establishes goals and proposes actions to address autom= ated and distributed threats to the digital ecosystem was published today a= s part of the activity directed by Executive Order 13800, =93Strengthening = the Cybersecurity of Federal Networks and Critical Infrastructure.=94 The = Departments of Commerce and Homeland Security request public comments from = all interested stakeholders=97including private industry, academia, civil = society, and other security experts=97on this draft report, its characteriz= ation of the threat landscape, the goals laid out, and the actions to furth= er these goals. The report is available athttps://csrc.nist.gov/publicati= ons/detail/white-paper/2018/01/05/enhancing-resilience-against-botnets--rep= ort-to-the-president/draft and the public comment period i= s open until February 12, 2018. NIST has also announced a public workshop on February 28 and March 1 for further discussion of the comments. --_000_MWHPR09MB15207FF5B66E41C31B8A2C30E71C0MWHPR09MB1520namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Folks,

 

Departments of Commerce and Homeland Security have released = the public draft of a report on countering botnets.  I hope this community will review and contribute to th= is project.  I have appended a brief announcement with a couple of relevant URLs = to this message..

 

Thanks,

 

Tim Polk

 

------------


Departments of Commerce and Homeland Security release draft = report to the President on "Enhancing the Resilience of the Internet and Communications Ecosystem Against Botnet= s and Other Automated, Distributed Threats"

 

A draft report that establishes goals and proposes actions t= o address automated and distributed threats to the digital ecosystem was published today as part of = the activity directed by Executive Order 13800, =93Strengthening the Cybers= ecurity of Federal Networks and Critical Infrastructure.=94  The Depar= tments of Commerce and Homeland Security request public comments from  all interested stakeholders=97including private indust= ry, academia, civil society, and other security experts=97on this draft rep= ort, its characterization of the threat landscape, the goals laid out, and = the actions to further these goals.   The report is available athttps://csrc.nist.gov/publications/detail/white-paper/2018/01/0= 5/enhancing-resilience-against-botnets--report-to-the-president/draft and the public comment period is open until February 12, 2018. NIST has a= lso announced a public workshop on February 28 and March 1 for further&= nbsp;discussion of the comments.

--_000_MWHPR09MB15207FF5B66E41C31B8A2C30E71C0MWHPR09MB1520namp_-- From nobody Tue Jan 9 02:01:30 2018 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 F1D3F1270AC for ; Tue, 9 Jan 2018 02:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgjhBMMZSsCe for ; Tue, 9 Jan 2018 02:01:21 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 C8EA512D835 for ; Tue, 9 Jan 2018 02:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1515492055; x=1547028055; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=miXGob7WTc8nvwaln0nv/RoewRWeUDDxkXBeXfZ7ZeA=; b=ENXrafXp4X2NoBqLoCAeWj8t/1uBVluuEGtn8tW32wnY/CA5TrxfErHD cb36BwqNs66YWnL1hjdnOf7rUaIMLJSp0fbodR61IyI7R0dHCgyUnWWEO IfdRJMIY0MLHOtBDhH0uz2B5lRLaLZhBHRKaVaBT+UuRN5e2qepNsEX6l v0R+ax0KePbiSwngYwud1G3ZnjUXrdqM8aVCavnRlvIrI1+ODCiRDGvnx jV4OLkMoy2OW9mDtWuhbD414FSCs1b5Qe+8NTrzn3XcCgqY50MAygqzkS UaGZRi5w/8DV+gvM+L/50gU4FnD4g0YC95g8HJkbtVnMmGoSrgKZWQYbZ Q==; X-IronPort-AV: E=Sophos;i="5.46,335,1511780400"; d="scan'208";a="208580369" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jan 2018 23:00:38 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 Jan 2018 23:00:38 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 9 Jan 2018 23:00:37 +1300 From: Peter Gutmann To: Jim Schaad , 'Sean Turner' CC: "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM52C8AgABMNQCAAEU+gIAAA2GAgAGSL4CAAU7l1YAAWooAgAASSgCAABRIgIAAGIGAgAA3hQCAAPfrwf//ypGAgAHHt6L//y31gIArq88v Date: Tue, 9 Jan 2018 10:00:37 +0000 Message-ID: <1515492035228.58783@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> <1513050187576.97593@cs.auckland.ac.nz>, <1513136348753.3364@cs.auckland.ac.nz>, <027e01d373c7$b7d608e0$27821aa0$@augustcellars.com> In-Reply-To: <027e01d373c7$b7d608e0$27821aa0$@augustcellars.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft 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, 09 Jan 2018 10:01:29 -0000 Jim Schaad writes:=0A= =0A= Tying up loose ends...=0A= =0A= >My view would be a couple of very simple examples to show major concepts i= n=0A= >the document. Base64 is better for me because I can run it through my cod= e=0A= >and see what happens, this also implies needing any keys used as well. If= =0A= >you want to do a more complete set of examples (and I would encourage you)= ,=0A= >then a pointer to a web site someplace would be my preference.=0A= =0A= The intent of the sample messages was more to provide a picture of "your=0A= messages should look something like this", so a dumpasn1-formatted breakdow= n=0A= of what's in there. After watching the lengthy process with RFC 4134 I'm n= ot=0A= sure I want to try and sort out all the bits and pieces that would be neede= d=0A= to process each message in situ. The fact that there are nonces present wo= uld=0A= also make it a real pain for anyone to recreate the processing, it's really= =0A= just an illustration of what the messages should look like, to help=0A= implementers.=0A= =0A= In terms of a pointer to a web site, that would certainly make things easie= r,=0A= because the multiple layers of wrapping means I can't just include the oute= r=0A= message but would have to include the inner decrypted stuff in the doc as= =0A= well. However, I'm not sure what the view is on including links from a lon= g-=0A= term RFC to a potentially ephemeral external web site... is there some IETF= -=0A= blessed location to store them or link to?=0A= =0A= Peter.=0A= From nobody Tue Jan 9 11:28:01 2018 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 D8C811271DF for ; Tue, 9 Jan 2018 11:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 JQ76ognkisUX for ; Tue, 9 Jan 2018 11:27:58 -0800 (PST) Received: from mail2.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 C615D120725 for ; Tue, 9 Jan 2018 11:27:57 -0800 (PST) Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Jan 2018 11:26:27 -0800 From: Jim Schaad To: 'Peter Gutmann' CC: References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> <1513050187576.97593@cs.auckland.ac.nz>, <1513136348753.3364@cs.auckland.ac.nz>, <027e01d373c7$b7d608e0$27821aa0$@augustcellars.com> <1515492035228.58783@cs.auckland.ac.nz> In-Reply-To: <1515492035228.58783@cs.auckland.ac.nz> Date: Tue, 9 Jan 2018 11:27:51 -0800 Message-ID: <005401d3897f$f1f19670$d5d4c350$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJICfxZFNYifoQOvFO0olqkGbOF0gFT4r69AlF0NYsCKsmpCgFfn+XtArJG0ZcBsI0kSQJMdG1sAqlSsVEB5l7btQE+kRxXArE1DH8DIBQcYgGuf4vCAcRqSIgBM+XnxAHIE+mUoYN/rZA= Content-Language: en-us X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft 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, 09 Jan 2018 19:28:00 -0000 I don't know that there is a solid place that is good. Basically URL that is not going to go away in the near future is probably just fine. I used my account on GitHub and created a project to hold the samples that I created for the COSE document. So far that has seemed to work out well as people can contribute as well as get notifications in the event that I correct something. Jim > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Tuesday, January 9, 2018 2:01 AM > To: Jim Schaad ; 'Sean Turner' > Cc: saag@ietf.org > Subject: Re: [saag] Status of the SCEP RFC draft > > Jim Schaad writes: > > Tying up loose ends... > > >My view would be a couple of very simple examples to show major > >concepts in the document. Base64 is better for me because I can run it > >through my code and see what happens, this also implies needing any > >keys used as well. If you want to do a more complete set of examples > >(and I would encourage you), then a pointer to a web site someplace would > be my preference. > > The intent of the sample messages was more to provide a picture of "your > messages should look something like this", so a dumpasn1-formatted > breakdown of what's in there. After watching the lengthy process with RFC > 4134 I'm not sure I want to try and sort out all the bits and pieces that would > be needed to process each message in situ. The fact that there are nonces > present would also make it a real pain for anyone to recreate the processing, > it's really just an illustration of what the messages should look like, to help > implementers. > > In terms of a pointer to a web site, that would certainly make things easier, > because the multiple layers of wrapping means I can't just include the outer > message but would have to include the inner decrypted stuff in the doc as > well. However, I'm not sure what the view is on including links from a long- > term RFC to a potentially ephemeral external web site... is there some IETF- > blessed location to store them or link to? > > Peter. > = From nobody Tue Jan 9 14:39:46 2018 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 57A1012773A for ; Tue, 9 Jan 2018 14:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpE-gkgh4_Px for ; Tue, 9 Jan 2018 14:39:43 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (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 B9A1512422F for ; Tue, 9 Jan 2018 14:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1515537582; x=1547073582; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=A0VfZdyo4A+UJvYEUi2vxnU+BKVwGHirCCuxQvdm7z8=; b=hRyOGHcFPWN8zovW14iMERr9a5FFcdralDDaFrHjUZr2uMWSyXGLhU+h 70JZpK2k9Xes8urCWaoauPL+ooUXx7ZqJp82mFmWHxXNR8Jaus/24j7Nl pmQilQQ6udZI/8MR2rbP/ykMvdEXnfHv7aNvIoI6adEuoUCtfnX7jzk/0 fRNMAAcaOhdzL2EABDqVnjeisbhG8nmomtL6ADtelSg2UErbWfXu8zKJs DWPlRv8W75bLXytgYMD90ZliBJPs5RiRuOyczsUNSu94D3qMHMj9eEBfT C+w0FmDs0wHYzQXxtlQN1H6mcl3oJ9JMxlwW0/QLP+/ph1ddbJbVydfK/ w==; X-IronPort-AV: E=Sophos;i="5.46,337,1511780400"; d="scan'208";a="208709797" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Jan 2018 11:39:38 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 Jan 2018 11:39:38 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 10 Jan 2018 11:39:38 +1300 From: Peter Gutmann To: Jim Schaad CC: "saag@ietf.org" Thread-Topic: [saag] Status of the SCEP RFC draft Thread-Index: AQHTbw4UUnneaIh1UU6hdrWtX9hT6aM52C8AgABMNQCAAEU+gIAAA2GAgAGSL4CAAU7l1YAAWooAgAASSgCAABRIgIAAGIGAgAA3hQCAAPfrwf//ypGAgAHHt6L//y31gIArq88v///EpoAAIe2Wtg== Date: Tue, 9 Jan 2018 22:39:38 +0000 Message-ID: <1515537575406.18704@cs.auckland.ac.nz> References: <1512618517258.43968@cs.auckland.ac.nz> <0150f450-6dba-87c2-b333-e96b6c028adb@lounge.org> <6f26b6bd-fab8-9961-2fc1-5969c573b3c2@lounge.org> <1512952085878.6345@cs.auckland.ac.nz> <6399716C-BD6C-49A0-A346-9AC431241B51@akamai.com> <840AAD22-8A8A-4482-AEF6-B695B5B2E8A7@icloud.com> <91B7C40D-1801-4899-B4E9-09976D2C029D@akamai.com> <30C85592-D5CE-4A32-A6A1-CA22AEEB86A2@sn3rd.com> <1513050187576.97593@cs.auckland.ac.nz>, <1513136348753.3364@cs.auckland.ac.nz>, <027e01d373c7$b7d608e0$27821aa0$@augustcellars.com> <1515492035228.58783@cs.auckland.ac.nz>, <005401d3897f$f1f19670$d5d4c350$@augustcellars.com> In-Reply-To: <005401d3897f$f1f19670$d5d4c350$@augustcellars.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Status of the SCEP RFC draft 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, 09 Jan 2018 22:39:45 -0000 Jim Schaad writes:=0A= =0A= >I don't know that there is a solid place that is good. Basically URL that= is=0A= >not going to go away in the near future is probably just fine. I used my= =0A= >account on GitHub and created a project to hold the samples that I created= =0A= >for the COSE document.=0A= =0A= If GitHub is fine to use, I'll go with that. I just don't want to provide = an=0A= external link in the doc that'll require another five iterations of the tex= t=0A= to get right :-).=0A= =0A= >So far that has seemed to work out well as people can contribute as well a= s=0A= >get notifications in the event that I correct something.=0A= =0A= Yeah, good point. I'll see if I can use the JSCEP repository, which seems= =0A= like a natural fit for SCEP samples.=0A= =0A= Peter.=0A= From nobody Tue Jan 9 15:49:54 2018 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 C0EDA1241F5 for ; Tue, 9 Jan 2018 15:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 LFgIYZPzTBoE for ; Tue, 9 Jan 2018 15:49:51 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4612C120713 for ; Tue, 9 Jan 2018 15:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10674; q=dns/txt; s=iport; t=1515541791; x=1516751391; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v67i70tNaV938yypiPdAuaRRKdrjCiOFAfL6CBWxt5g=; b=PenuhnNzA6jztrl3r09Hwrsn35uazO+yZiEIeYnPv7UQZ0Jmt+Opvp6S 3iaOgAifmY7NFoDT1v0w5fz/KzThU60aaXN7FJrH3lXz1lB1KVbxd4WZY Akk0adkMrNq+yTVe+QOQ63caZVBErdp8H2nLv+a3GD3fh4fvDyi24zq77 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAQAuVFVa/40NJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDEDBmdCcHhACKJI5eggJ9iA6OI4IVChgLhRgCGoQgPxgBAQE?= =?us-ascii?q?BAQEBAQFrKIUjAQEBAQIBAQEMFRExCQsMBAIBCBEEAQEBAgIjAwICAh8GCxQBC?= =?us-ascii?q?AgCBAENBYoZAw0IEK8lgieHPA2CcAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+?= =?us-ascii?q?DEYIVg0ApgXdYNoJrRAGBQwQBJheDADGCNAWjIj0CkD+FAJQJjXSIeAIRGQGBO?= =?us-ascii?q?wEfOYFQbxU9KgGBf4RWAXgBiHMBJoENgRcBAQE?= X-IronPort-AV: E=Sophos;i="5.46,337,1511827200"; d="scan'208";a="341101048" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2018 23:49:50 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w09Nnnt0028293 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Jan 2018 23:49:50 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 9 Jan 2018 18:49:49 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 9 Jan 2018 18:49:48 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Kathleen Moriarty , Roman Danyliw CC: "saag@ietf.org" Thread-Topic: [saag] Thoughts on SecDispatch Experiment Thread-Index: AQHTiaSIG0YKmlqaME+EhvtbQ8tTxQ== Date: Tue, 9 Jan 2018 23:49:48 +0000 Message-ID: <6BC2F896-FD98-426B-BC8E-7D663A8E6AEA@cisco.com> References: <359EC4B99E040048A7131E0F4E113AFC010500B041@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.84.81] Content-Type: text/plain; charset="utf-8" Content-ID: <2B3B833EDE9E3A49B8602CC528F71E5B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Thoughts on SecDispatch Experiment 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, 09 Jan 2018 23:49:54 -0000 SGksDQpBcG9sb2dpZXMgY29taW5nIGluIGxhdGUgd2l0aCBmZWVkYmFjazoNCg0KSGVyZSBhcmUg YSBmZXcgbW9yZSBpZGVhcyBmb3IgaW1wcm92aW5nIHRoZSBwcm9jZXNzLCB0aG91Z2ggSSB0aGlu ayBtb3N0IGhhdmUgYWxyZWFkeSBiZWVuIGFydGljdWxhdGVkOg0KDQotIEFncmVlZCBpbiBwcmUt c2NyZWVuaW5nIGFuZCBhbHNvIGhhdmluZyBjbGVhciBleHBlY3RhdGlvbnMgc2V0IHRvL2Zyb20g cHJlc2VudGVycyB3aWxsIGJlIHJlcXVpcmVkLiAgV2hpbGUgd2UgY2FuIGNsYXJpZnkgb24gZXhw ZWN0ZWQgc2V0IG9mIG91dGNvbWVzLCBJ4oCZbSBzdXJlIHRoZXJlIHdpbGwgbGlrZWx5IGJlIHNv bWUgZXhjZXB0aW9ucyB0aGF0IG1heSBhcmlzZSBkZXBlbmRpbmcgb24gdGhlIGNvbnRleHQgb2Yg dGhlIGRpc2N1c3Npb24gKGVzcGVjaWFsbHkgaWYgZHJhZnRzIHByZXNlbnRlZCBoYXZlIG5vdCBo YWQgYWRlcXVhdGUgcmV2aWV3L2ZlZWRiYWNrKS4NCi0gR3VpZGVsaW5lcyBmb3IgcHJlc2VudGVy cyBhbmQgdGhlaXIgc2V0IG9mIGV4cGVjdGF0aW9ucyBjYW4gYWxzbyBiZSBiZXR0ZXIgY2xhcmlm aWVkLiAgRXNwZWNpYWxseSBpZiBhIGRyYWZ0IGlzIGJlaW5nIHByZXNlbnRlZCwgZW5zdXJpbmcg dGhhdCB0aGUgZHJhZnQgaGFzIGhhZCBzb21lIHByaW9yIHJldmlldyAoYmV5b25kIHRoZSBjaGFp cnMgYW5kIEFEcyByZXZpZXcpLg0KLSBTZWNEaXNwYXRjaCBjYW4gYW5ub3VuY2UgdGhlIGRyYWZ0 cy9wcmVzZW50YXRpb25zIHdpdGggcHJvcG9zZWQgZ29hbHMgdG8gZW5zdXJlIHdpZGVyIHJldmll dywgdGhvdWdodCBhbmQgY29uc2lkZXJhdGlvbiBwcmlvciB0byB0aGUgZjJmIHNlc3Npb24uICBD b25jbHVzaW9ucyBjYW4gYmUgcG9zdGVkIHRvIHRoZSBsaXN0IHRvIGVuc3VyZSB0aGVyZSBhcmUg bm8gc3Ryb25nIG9iamVjdGlvbnMgZnJvbSB0aG9zZSB3aG8gY291bGRu4oCZdCBwYXJ0aWNpcGF0 ZSBsaXZlLg0KDQpBcyBpdCB3YXMgb3VyIGZpcnN0IHNlc3Npb24gd2UvdGhlIGNoYWlycyBzZXQg YSB0aW1lIGxpbWl0IGZvciBlYWNoIHByZXNlbnRlciBpbmRlcGVuZGVudCBvZiB0aGUgdG9waWMg d2hpY2ggSSBmZWx0IGxlZnQgc29tZSBvZiB0aGVtIHNob3J0IG9uIG5lZWRlZCBkaXNjdXNzaW9u IGFuZCBxdWljayBkZWNpc2lvbnMuICBTbywgYmV0dGVyIHByb3Zpc2lvbnMgZm9yIHRpbWUgYWxs b2NhdGlvbiBwZXJoYXBzIGludm9sdmluZyBwcmVzZW50ZXJzIHRvIGVuc3VyZSB3ZSBjYW4gZ2l2 ZSBhcHByb3ByaWF0ZSBjb25zaWRlcmF0aW9uIHRvIHRoZSB0b3BpYyBwcmVzZW50ZWQuDQoNCkni gJlkIGFsc28gYWxsb3csIGF0IGxlYXN0IGZvciB0aGUgZmlyc3QgZmV3IHNlc3Npb25zLCBhIHNt YWxsIOKAnHdyYXAtdXDigJ0gdGltZSBzbG90IHRvIGFsbG93IGxpdmUgZmVlZGJhY2sgZm9yIHJl ZmluaW5nIG91ciBwcm9jZXNzIHRvb+KApi4NCg0KTmFuY3kNCg0KT24gMTEvMjAvMTcsIDEwOjAz IEFNLCAic2FhZyBvbiBiZWhhbGYgb2YgS2F0aGxlZW4gTW9yaWFydHkiIDxzYWFnLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3 cm90ZToNCg0KICAgIFRoYW5rIHlvdSwgRGF2aWQgYW5kIFJvbWFuIGZvciB5b3VyIGhlbHBmdWwg ZmVlZGJhY2suICBJbmxpbmUuDQogICAgDQogICAgU2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UN CiAgICANCiAgICA+IE9uIE5vdiAyMCwgMjAxNywgYXQgOTozNiBBTSwgUm9tYW4gRGFueWxpdyA8 cmRkQGNlcnQub3JnPiB3cm90ZToNCiAgICA+IA0KICAgID4gSGVsbG8hDQogICAgPiANCiAgICA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4+IEZyb206IHNhYWcgW21haWx0bzpz YWFnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCbGFjaywgRGF2aWQNCiAgICA+PiBT ZW50OiBTdW5kYXksIE5vdmVtYmVyIDE5LCAyMDE3IDExOjU3IFBNDQogICAgPj4gVG86IEthdGhs ZWVuIE1vcmlhcnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT47IHNhYWdAaWV0 Zi5vcmcNCiAgICA+PiBTdWJqZWN0OiBSZTogW3NhYWddIFRob3VnaHRzIG9uIFNlY0Rpc3BhdGNo IEV4cGVyaW1lbnQNCiAgICA+IA0KICAgID4gW3NuaXBdDQogICAgPiANCiAgICA+IEFzIGFuIGV4 cGVyaW1lbnQsIEkgdGhpbmsgaXQgd2FzIGEgc3VjY2Vzcy4NCiAgICA+IA0KICAgID4+IFRoZSBT ZWNEaXNwYXRjaCBwcm9jZXNzIGZlbHQgbGlrZSBpdCBjb3VsZCB1c2Ugc29tZSBtb3JlIGNsYXJp dHksIHBhcnRpY3VsYXJseSBpbg0KICAgID4+IGRlbGluZWF0aW5nIHBvc3NpYmxlIG91dGNvbWVz IGluIGFkdmFuY2UuICAgSXQgYXBwZWFyZWQgdGhhdCBwcm9jZXNzIHdhcw0KICAgID4+IGJlaW5n IGludmVudGVkIG9uIHRoZSBmbHkgYXMgdGhlIHNlc3Npb24gd2VudCBhbG9uZywgZS5nLiwgcmVm ZXJyYWwgdG8gQ0ZSRw0KICAgID4+IGFuZCBjbGFyaWZpY2F0aW9uIG9mIEFEIHNwb25zb3JzaGlw IHJlY29tbWVuZGF0aW9ucy4gDQogICAgPiANCiAgICA+ICsxLiAgQmVpbmcgY2xlYXIgb24gdGhl IHBvc3NpYmxlIG91dGNvbWVzIGluIGFkdmFuY2Ugd291bGQgaGVscC4gIA0KICAgIA0KICAgIFll cywgaXQncyBvbiB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0LiAgQXMgYSBXRywgdGhhdCB3b3Vs ZCBoYXZlIGJlZW4gbW9yZSBjbGVhciBJIHN1c3BlY3QuDQogICAgDQogICAgPiBBZGRpdGlvbmFs bHksIEknZCByZWNvbW1lbmQgdGhlIGZvbGxvd2luZzoNCiAgICA+IA0KICAgID4gKiogRG9jdW1l bnRpbmcgdGhlIHdob2xlIHByb2Nlc3MgaW4gb25lIHBsYWNlIHRvIHNldCBleHBlY3RhdGlvbnMg b2YgdGhlIGRyYWZ0IHByb3BvbmVudHMgYW5kIGdldCB0aGUgYmVzdCBmZWVkYmFjayBmcm9tIHRo ZSBwcm9jZXNzIHBhcnRpY2lwYW50cyAoZS5nLiwgZHJhZnQgcHJlc2NyZWVuaW5nIGNyaXRlcmlh L2RyYWZ0cyBwcmV2aW91c2x5IGRpc2N1c3NlZCBpbiBvdGhlciBXR3M7IGlkZW50aWZ5IG91dGNv bWVzOyBkZXNjcmliZSB3aGF0IHRoZSBTZWNEaXNwYXRjaCBwcm9jZXNzIHdpbGwgbm90IGRvOyBn dWlkYW5jZSBvbiB0aGUgZHJhZnQgcHJlc2VudGF0aW9uIGdpdmVuIHRoZSBsaW1pdGVkIHRpbWUg c2xvdCkNCiAgICANCiAgICBJIGFncmVlIGFuZCB3YXMgdGhpbmtpbmcgaXQgd291bGQgYmUgaGVs cGZ1bCB0byBjYXB0dXJlIHRoZSBmZWVkYmFjayBhbmQgb3JnYW5pemUgaXQgdG8gcG9zdCBvbiBh IHdpa2kgcGFnZS4gIEkgZ3Vlc3MgdGhhdCBjb3VsZCBiZSB0aGUgb25lIGZvciBTZWNEaXNwYXRj aCBpZiB3ZSBjaGFydGVyIGl0LiAgDQogICAgPiANCiAgICA+ICoqIERvY3VtZW50aW5nIHRoZSBk ZWNpc2lvbnMgbWFkZSBkdXJpbmcgdGhlIGRpc3BhdGNoIHByb2Nlc3MgKGFyZSBtZWV0aW5nIG1p bnV0ZXMgZW5vdWdoPyk7IGFuZCBpZGVudGlmeWluZyB3aGF0IHRoYXQgbmV4dCBzdGVwIGlzIGFu ZCB3aG8gaGFzIGl0Lg0KICAgIA0KICAgIE1lZXRpbmcgbWludXRlcyBhbmQgY29uZmlybWF0aW9u IHRvIHRoZSBsaXN0IHdvdWxkIGJlIGdvb2QgZW5vdWdoLCBJIHRoaW5rLg0KICAgIA0KICAgIFRo YW5rIHlvdSwNCiAgICBLYXRobGVlbiANCiAgICA+IA0KICAgID4gUm9tYW4NCiAgICA+IA0KICAg ID4+IFRoYW5rcywgLS1EYXZpZA0KICAgID4+IA0KICAgID4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KICAgID4+PiBGcm9tOiBzYWFnIFttYWlsdG86c2FhZy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgS2F0aGxlZW4NCiAgICA+Pj4gTW9yaWFydHkNCiAgICA+Pj4gU2VudDog RnJpZGF5LCBOb3ZlbWJlciAxNywgMjAxNyAxMjozMSBBTQ0KICAgID4+PiBUbzogc2FhZ0BpZXRm Lm9yZw0KICAgID4+PiBTdWJqZWN0OiBbc2FhZ10gVGhvdWdodHMgb24gU2VjRGlzcGF0Y2ggRXhw ZXJpbWVudA0KICAgID4+PiANCiAgICA+Pj4gSGksDQogICAgPj4+IA0KICAgID4+PiBJbiB0aGUg aW50ZXJlc3Qgb2YgaW1wcm92aW5nIFNlY0Rpc3BhdGNoIGluIHRoZSBldmVudCB3ZSBnbyBmb3J3 YXJkDQogICAgPj4+IHdpdGggdGhpcyBhcyBhIFdHLCBJJ20gc2hhcmluZyBteSB0aG91Z2h0cyBh bmQgaWRlYXMgb2YgaG93IHRvIGltcHJvdmUNCiAgICA+Pj4gaXQuICBZb3VyIHRob3VnaHRzIGFy ZSB3ZWxjb21lLg0KICAgID4+PiANCiAgICA+Pj4gU2VjRGlzcGF0Y2ggRXhwZXJpbWVudCBUaG91 Z2h0cw0KICAgID4+PiANCiAgICA+Pj4gQWRkaXRpb25hbCBwcmUtc2NyZWVuaW5nIG9mIGRyYWZ0 cyB3b3VsZCBiZSBuZWVkZWQgZm9yIHRoaXMgdG8gYmUNCiAgICA+PiBzdWNjZXNzZnVsLg0KICAg ID4+PiANCiAgICA+Pj4gRm9yIFNBQUcgc2Vzc2lvbnMgYW5kIEFEIHNwb25zb3JlZCBkcmFmdHMs IHdoYXQgd2UgaGF2ZSBkb25lIGluIHRoZQ0KICAgID4+PiBwYXN0IGZldyB5ZWFycyBpcyB0byB3 YWl0IGZvciByZXF1ZXN0cyB0byBjb21lIGluLCB3ZSBkaWRu4oCZdCBzb2xpY2l0DQogICAgPj4+ IHRoZW0uIFRoZW4gd2XigJlkIHJldmlldyB0aGUgYXNzb2NpYXRlZCBkcmFmdChzKS4gSUYgd2Ug dGhvdWdodCBpdCB3YXMNCiAgICA+Pj4gcmVhZHkgYW5kIHdvcnRod2hpbGUsIHdl4oCZZCBhc2sg Zm9yIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuIElGIHRoZXJlDQogICAgPj4+IHdhcyBpbnRlcmVz dCBhbmQgdGltZSwgd2XigJlkIHB1dCBpdCBvbiB0aGUgYWdlbmRhLg0KICAgID4+PiANCiAgICA+ Pj4gVGhlIHByZS1zY3JlZW5pbmcgd291bGQgaW52b2x2ZSBhc2tpbmcgaWYvd2hlcmUgdGhpcyBo YWQgYmVlbg0KICAgID4+PiBwcmVzZW50ZWQgYmVmb3JlIGFuZCB0aGUgb3V0Y29tZS4gV2UgbWln aHQgY2hlY2sgbGlzdCB0cmFmZmljIG9uIHRoZQ0KICAgID4+PiBkcmFmdCBhbmQgbWlnaHQgY2hl Y2sgd2l0aCB0aGUgY2hhaXJzIG9mIGFzc29jaWF0ZWQgV0dzIHRvIGdldCB0aGVpcg0KICAgID4+ PiB0aG91Z2h0cy4NCiAgICA+Pj4gDQogICAgPj4+IFN0ZXBoZW4gYW5kIEkgd291bGQgZGlzY3Vz cyBBRCBzcG9uc29yIGRyYWZ0IHJlcXVlc3RzLCB3aGljaCBtaWdodCBiZQ0KICAgID4+PiBzZXBh cmF0ZSBmcm9tIFNBQUcgc2xvdCByZXF1ZXN0cy4gVGhlcmUgd2VyZSB0aW1lcyBvbmUgb2YgdXMg d291bGQNCiAgICA+Pj4ganVzdCBhY2NlcHQgb25lIHRoYXQgd2UgdGhvdWdodCB3YXMgc2Vuc2li bGUgYW5kIHRob3VnaHQgdGhhdA0KICAgID4+PiBhZGRpdGlvbmFsIHByb2Nlc3MgYXJvdW5kIGl0 IHdhc27igJl0IG5lZWRlZC4gRm9yIHNvbWUgb3RoZXJzLCB3ZSBtaWdodA0KICAgID4+PiBkaXNj dXNzIHRoZSByZXF1ZXN0IGFuZCBzZWUgd2hvIGNvdWxkIHRha2UgaXQgb24sIHNwbGl0dGluZyB1 cCB0aGUNCiAgICA+Pj4gd29yayBldmVubHkuDQogICAgPj4+IA0KICAgID4+PiBUaGVuIG15IHBy b2Nlc3MgZm9yIEFEIHNwb25zb3JlZCBkcmFmdHMgKGRpZmZlcmVudCBmcm9tIFN0ZXBoZW7igJlz KSB3YXMNCiAgICA+Pj4gdG8gZWl0aGVyIGFzayB0aGUgYXV0aG9ycyB0byBmaW5kIGEgc2hlcGhl cmQgb3IgdG8gYXNzaWduIG9uZSBpZiB0aGV5DQogICAgPj4+IHdlcmUgbm90IGFibGUgdG8gZmlu ZCBzb21lb25lIHJlYXNvbmFibGUgb24gdGhlaXIgb3duLiBJIHVzZWQgdGhpcyBhcw0KICAgID4+ PiBhbiBvcHBvcnR1bml0eSB0byB0cmFpbiBwb3NzaWJsZSBXRyBjaGFpcnMgYW5kIGluIHNvbWUg Y2FzZXMgZm9sa3Mgd2hvDQogICAgPj4+IG1pZ2h0IGJlIGludGVyZXN0ZWQgdG8gYmUgYSBTZWNB RCBpbiB0aGUgZnV0dXJlLiBUaGUgc2hlcGhlcmQgd291bGQNCiAgICA+Pj4gcGVyZm9ybSBhIGRy YWZ0IHJldmlldywgbG9vayBhdCBkaXNjdXNzaW9ucyBvbiB0aGUgZHJhZnQsIGFzayBhbGwgdGhl DQogICAgPj4+IHF1ZXN0aW9ucyBvbiB0aGUgc2hlcGhlcmQgcmVwb3J0LCBhbmQgcHJvdmlkZSB0 aGVpciB0aG91Z2h0cy4gSeKAmWQgdGhlbg0KICAgID4+PiBwZXJmb3JtIG15IHJldmlldyBhbmQg aWYgYXBwcm9wcmlhdGUga2ljayBvZmYgbGFzdCBjYWxsLiBUaGUgc2hlcGhlcmQNCiAgICA+Pj4g d291bGQgZW5zdXJlIGFsbCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgd2VyZSBhZGRyZXNzZWQgaW4g dGhlIGRyYWZ0LA0KICAgID4+PiBJ4oCZZCByZWNoZWNrIHRoYXQgYW5kIHRoZSBub3JtYWwgY2hl Y2tzIGZvciBhIGRyYWZ0IGFuZCBwdXQgaXQgb24gYQ0KICAgID4+PiB0ZWxlY2hhdC4NCiAgICA+ Pj4gDQogICAgPj4+IFNlY0Rpc3BhdGNoIHNlZW1lZCB1c2VmdWwgdG8gaGF2ZSBhIGh1bSBvbiBy ZXN0YXJ0aW5nIGEgV0csIHNvIHdlDQogICAgPj4+IGNvdWxkIGF2b2lkIGEgQm9GLiBGb3Igc29t ZSB0aGF0IGEgc2VwYXJhdGUgV0cgaXMgbmVlZGVkLCBhIEJvRiBtYXkgb3INCiAgICA+Pj4gbWF5 IG5vdCBiZSBuZWNlc3NhcnkuIFdlIGhhdmUgc3RhcnRlZCBXR3MgaW4gdGhlIHBhc3Qgd2l0aCBs aXN0DQogICAgPj4+IGRpc2N1c3Npb24gb25seSwgc28gdGhhdOKAmXMgcG9zc2libGUgc3RpbGwg dG9vLg0KICAgID4+PiANCiAgICA+Pj4gSWYgd2Ugd2VudCBhaGVhZCB3aXRoIFNlY0Rpc3BhdGNo LCBJ4oCZZCBleHBlY3QgdGhlIGNoYWlycyB0byBjYWxsIGENCiAgICA+Pj4gZGVjaXNpb24gd2l0 aCBlYWNoIHByb3Bvc2FsIGFuZCBoYXZlIHRoaXMgZ28gdG8gdGhlIGxpc3QgZm9yDQogICAgPj4+ IG9iamVjdGlvbnMuIElmIHRoZSByZXN1bHQgd2FzIGEgcmVjb21tZW5kYXRpb24gZm9yIEFEIHNw b25zb3JzaGlwLCBJDQogICAgPj4+IHdvdWxkIGV4cGVjdCB0aGF0IHRoZSBkaXNjdXNzaW9uIGFz IHRvIHdobyB3b3VsZCBzcG9uc29yIHdvdWxkIGhhcHBlbg0KICAgID4+PiBhZnRlciB0aGUgbWVl dGluZyBiZXR3ZWVuIEFEcyB3aG8gY291bGQgY29uc2lkZXIgYSBiYWxhbmNlIGluIHdvcmtsb2Fk DQogICAgPj4+IHdoZW4gZGl2aWRpbmcgdGhlbSB1cC4NCiAgICA+Pj4gDQogICAgPj4+IE5hbmN5 IGFsc28gaGFkIHNvbWUgaWRlYXMgdG8gc3RyZWFtbGluZSBhbmQgaW1wcm92ZSB0aGUgc2Vzc2lv biBpZg0KICAgID4+PiB0aGlzIGV4cGVyaW1lbnQgZ29lcyBmb3J3YXJkLCBzbyBpdOKAmWxsIGJl IGdvb2QgdG8gZ2V0IHRoYXQgZG9jdW1lbnRlZC4NCiAgICA+Pj4gSeKAmWxsIG5lZWQgdG8gdGhp bmsgYSBiaXQgbW9yZSBvbiBpZiBJIHRoaW5rIHRoaXMgc2hvdWxkIGdvIGZvcndhcmQsDQogICAg Pj4+IGJ1dCB3b3VsZCBsaWtlIGVhY2ggb2YgeW91ciB0aG91Z2h0cy4NCiAgICA+Pj4gDQogICAg Pj4+IA0KICAgID4+PiANCiAgICA+Pj4gLS0NCiAgICA+Pj4gDQogICAgPj4+IEJlc3QgcmVnYXJk cywNCiAgICA+Pj4gS2F0aGxlZW4NCiAgICA+Pj4gDQogICAgPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPj4+IHNhYWcgbWFpbGluZyBsaXN0 DQogICAgPj4+IHNhYWdAaWV0Zi5vcmcNCiAgICA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zYWFnDQogICAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICA+PiBzYWFnIG1haWxpbmcgbGlzdA0KICAgID4+IHNhYWdA aWV0Zi5vcmcNCiAgICA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nh YWcNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgIHNhYWcgbWFpbGluZyBsaXN0DQogICAgc2FhZ0BpZXRmLm9yZw0KICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KICAgIA0KDQo= From nobody Wed Jan 17 19:52:49 2018 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 84EC5128896 for ; Wed, 17 Jan 2018 19:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5JLdqWfBHjm for ; Wed, 17 Jan 2018 19:52:46 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E2512D940 for ; Wed, 17 Jan 2018 19:52:46 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0I3qcx8002120; Thu, 18 Jan 2018 03:52:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=EjUHINq+kSmK1GBRziWlrkiZwM2W4U8MiPY1lJ49aPY=; b=WamfjzQzIA/um4yKtrzFqJWFOTfq65ZKgwqi1/leaCwsx5Ly8YU3JHXxTFKLiGrm4JKE Th/eB3ovswms52WfWp8NWwbpqAFDC77akgO2t2xnt4l7ab/Owfyo40C7QB6QImyyCSnf SVM+5q1IOBYZedvZEa8bnWGMlc4U9HpUCPwOmaKN238u7qcwZEeQ7eoHK6guohIyPpWX eYnk0VxbBfWvwuNTYvWMxd4KM52aqmzA6RlHIYEtFWNURpzW4aMpPEqebevhKEPweH7V icETRxX1JT5gp8v7gj1Q/kObJr+hPFWovZ6sJR2SLJFCkaxW2uiVvIa9gCcq0X7lld0j zQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2ffbdbnvr7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jan 2018 03:52:44 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0I3pCYe004620; Wed, 17 Jan 2018 22:52:43 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ffeb1cawv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Jan 2018 22:52:43 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 17 Jan 2018 22:52:42 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 17 Jan 2018 22:52:41 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 17 Jan 2018 22:52:41 -0500 From: "Salz, Rich" To: Yakov Shafranovich , "saag@ietf.org" CC: Ed Overflow Thread-Topic: [saag] Proposal for "security.txt" Thread-Index: AQHTSFRcugmlICdcW0ur1clpjKVr0qN54ryA Date: Thu, 18 Jan 2018 03:52:41 +0000 Message-ID: <52EE1E3C-2252-492E-BE88-CAEC61E2D35B@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.12] Content-Type: text/plain; charset="utf-8" Content-ID: <543847885F5B3E4290EDBE95F31A1D55@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-18_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=588 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801180055 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-18_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=517 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801180055 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: Thu, 18 Jan 2018 03:52:48 -0000 DQo+ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mb3VkaWwtc2VjdXJpdHl0 eHQtMDAgDQrigKYNCj4gICAgRUtSIGhhcyBzdWdnZXN0ZWQgdGhhdCB0aGlzIG1heSBiZSBhIGdv b2QgdG9waWMgdG8gYWRkIHRvIHRoZSB1cGNvbWluZw0KICAgIFNFQy1ESVNQQVRDSCBtZWV0aW5n IGF0IElFVEYgMTAwIGluIFNpbmdhcG9yZS4NCiAgDQpJIGRvbuKAmXQgdGhpbmsgd2UgYWN0dWFs bHkgZGlzY3Vzc2VkIHRoaXMsIGRpZCB3ZT8gIFdoYXTigJlzIGhhcHBlbmluZyB0aGVuPw0KDQo= From nobody Thu Jan 18 00:20:20 2018 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 D7EB4127869 for ; Thu, 18 Jan 2018 00:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 i2uwVSGgb11D for ; Thu, 18 Jan 2018 00:20:18 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034AC124D68 for ; Thu, 18 Jan 2018 00:20:18 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id q6so6253659ywg.3 for ; Thu, 18 Jan 2018 00:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gDYQ53aw1We9kpNk29hv8nMzK3HaPSg+uLygQSIIueU=; b=XRVIwMgOsfxizn0Bb76+nws1dSPF9EnBKWK6uzsByhLBLQYkjdBVdqKZNnvmy4J+RN Dil3VRMfMl/42sr2hj5GY0Kj1w5phlx/IutUMlkmC78E9FCvQUQn0FqeNfAt/ZWnPwv6 wrlS06zYdYUVnVzhkJ8/LhCMK6lIW2EJw+A7bxhnyvNyAoEK2zY/OQfIkkuRy8XiqR21 kLABc/3RM58QHV++nX9ScOnUCHhr++dwPqBbcSZQwfBHZ7NjbIq9NLszp6WFCd4l/bfU ryakJIVY9nHQR23yA/8V/+NlR3iF2Xp46Y6nXbQLE6L/fCjZWXoUQMinqnwdG5opnWW7 sKbg== 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=gDYQ53aw1We9kpNk29hv8nMzK3HaPSg+uLygQSIIueU=; b=iNVznTMtB8SRG3nDgMP2lTwZsrgu/dFPpY7LRiO6JoXg1gDfR4QvPr4jiJXFmy3UxY 4gYqDEA6MlSgFPDZ/J164azhMtWiO5MzjmWBvvh6eDlnbOgVBF89Xv03ntnQIx48/OSp dkr3SLp2UHu+S/dpPoDHa0ljy0C4r92YNH6TmeNQfvZ8lopgIVo9r0sUuLYul9oXsTQ6 hBdR0c6uM5vz5LP72StA+m8fvpbDngy/uCygfHGE0YiGhtDabY+XSJs2s4Z0sSUOF39o PH8saH0N5vGsIYQbiVuPSfIqSTtHUwEgNU2XutLqjmHWlu3tpueAp6uEO8JzInf58E/m 3HBQ== X-Gm-Message-State: AKwxytddK64W2zypQ7kvVdIXQeZMU5ylayjg3yccMUmoa+S5639PcQIk Ta+GkkfZBgEdnwj6Cv2lJgY5pB6XH/Ub9Ci+sWYy4A== X-Google-Smtp-Source: ACJfBottqQIv4/OmC6GCmP3QuK7BkBpCzuhZkoEd2GYl1ArGEg0ud3jIszaVQaUJBuhWKK1nHWgb+5FU0cE6S3OQOOc= X-Received: by 10.129.152.138 with SMTP id p132mr5247108ywg.378.1516263617018; Thu, 18 Jan 2018 00:20:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.66 with HTTP; Thu, 18 Jan 2018 00:19:36 -0800 (PST) In-Reply-To: <52EE1E3C-2252-492E-BE88-CAEC61E2D35B@akamai.com> References: <52EE1E3C-2252-492E-BE88-CAEC61E2D35B@akamai.com> From: Eric Rescorla Date: Thu, 18 Jan 2018 00:19:36 -0800 Message-ID: To: "Salz, Rich" Cc: Yakov Shafranovich , "saag@ietf.org" , Ed Overflow Content-Type: multipart/alternative; boundary="94eb2c0b8fe44756f0056308a24c" 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: Thu, 18 Jan 2018 08:20:20 -0000 --94eb2c0b8fe44756f0056308a24c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've asked them to bring it back to SECDISPATCH London (more details on that soonish) -Ekr On Wed, Jan 17, 2018 at 7:52 PM, Salz, Rich wrote: > > > https://tools.ietf.org/html/draft-foudil-securitytxt-00 > =E2=80=A6 > > EKR has suggested that this may be a good topic to add to the upcomi= ng > SEC-DISPATCH meeting at IETF 100 in Singapore. > > I don=E2=80=99t think we actually discussed this, did we? What=E2=80=99s= happening then? > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --94eb2c0b8fe44756f0056308a24c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've asked them to bring it back to SECDISPATCH London= (more details on that soonish)

-Ekr


On Wed, Ja= n 17, 2018 at 7:52 PM, Salz, Rich <rsalz@akamai.com> wrote:

>=C2=A0 =C2=A0 https://tools.ietf.org/html= /draft-foudil-securitytxt-00
=E2=80=A6
>=C2=A0 =C2=A0 EKR has suggested that this may be a goo= d topic to add to the upcoming
=C2=A0 =C2=A0 SEC-DISPATCH meeting at IETF 100 in Singapore.

I don=E2=80=99t think we actually discussed this, did we?=C2=A0 What= =E2=80=99s happening then?

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

--94eb2c0b8fe44756f0056308a24c-- From nobody Thu Jan 18 00:21:02 2018 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 1F69A12EB18 for ; Thu, 18 Jan 2018 00:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 j2eY1K3o_9gt for ; Thu, 18 Jan 2018 00:20:58 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 67F2B12EB19 for ; Thu, 18 Jan 2018 00:20:58 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u21so10575336ywc.2 for ; Thu, 18 Jan 2018 00:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=saCM67kzMLmuRAteDGyV+AkaH30Vb+rdscLQI/isD7I=; b=zWibZXfAuD0NSELSvBPIYdMtshJaI03yBxlppFn/PrvIjQWxA/XZ8DijyxQjlIpf+Q ylpJgzZdpaYCjDHrvr0bXKKTC8J9KgOcC6p1HQBYb/pVE8QPmFmDoyZ2A4T2kcmaAmq9 WlpesPXr53VVlikgMVNpsC9LbQFN0/CkvNclErVY5Bg0CEGhgRLGHaAXqE/VCdTksUei Fai7AogLVRL8KHftM5VHQjxNrHlz3+Ud++bWJ45DXcKdjXg3+OFJWaWGmqwoJNWYcxSF 5RF2E+M6UEPm1Hgl59EDuai9o6aUmN8Co4mruBw2ZX7+xMKHW5NEiLjf5LBvmWFcYksn PQYA== 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=saCM67kzMLmuRAteDGyV+AkaH30Vb+rdscLQI/isD7I=; b=lcz9oqqa2YSYbMOQs1eO7LqNfeoqPcAaKQzDISxHpt/xh7YGKrqqClTnhpPJNlWCqE cSJ8wWJmpoDBAKhHj3DhetaDf6qrCpnkqZHkFoteP2YPsv5TQLrlQmkWVtQsTk66h4Er bPCDHW6cwgHCemACRqrl4dlGMZDl+wx21QCrxpiRRMYCI3HbbiBEXsFuAnfD9p1X0hvP PGiF7haCWNZGmMwKKc+ztcv8vU6dTNGnV39DDZ/yRANpvyOdvVm7EUZhagsSsutuCq60 9/9Eres5QDox92FXOJVPMel0rvQkLLPKIWyJzfdNee0b1HUxQw/p6HSdRO0R4+Z/tEKB tk7A== X-Gm-Message-State: AKwxytdCIMWmTQYvJqgI0z7q5NFwNOmnmD8eUefl10/NIVUPj+aXoIB1 DVwz2EsQiww0RLExxomsZt/EtUl2/pi0E0xjwjqpxw== X-Google-Smtp-Source: ACJfBouAyy3lL8IReVU2UaNUfOEfBC1laI65ixEGXc1QhiR6guE7SHd67O00l9qo619CPDvbkmRwXvDx+UCZ73A4llY= X-Received: by 10.37.185.134 with SMTP id r6mr8552036ybg.423.1516263657607; Thu, 18 Jan 2018 00:20:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.66 with HTTP; Thu, 18 Jan 2018 00:20:17 -0800 (PST) In-Reply-To: References: <52EE1E3C-2252-492E-BE88-CAEC61E2D35B@akamai.com> From: Eric Rescorla Date: Thu, 18 Jan 2018 00:20:17 -0800 Message-ID: To: "Salz, Rich" Cc: Yakov Shafranovich , "saag@ietf.org" , Ed Overflow Content-Type: multipart/alternative; boundary="f403043d4ad0b2a8d2056308a44b" 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: Thu, 18 Jan 2018 08:21:01 -0000 --f403043d4ad0b2a8d2056308a44b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 18, 2018 at 12:19 AM, Eric Rescorla wrote: > I've asked them to bring it back to SECDISPATCH London (more details on > that soonish) > Edit: Kathleen and I have asked them. > > -Ekr > > > On Wed, Jan 17, 2018 at 7:52 PM, Salz, Rich wrote: > >> >> > https://tools.ietf.org/html/draft-foudil-securitytxt-00 >> =E2=80=A6 >> > EKR has suggested that this may be a good topic to add to the >> upcoming >> SEC-DISPATCH meeting at IETF 100 in Singapore. >> >> I don=E2=80=99t think we actually discussed this, did we? What=E2=80=99= s happening then? >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > --f403043d4ad0b2a8d2056308a44b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 18, 2018 at 12:19 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:
I've asked = them to bring it back to SECDISPATCH London (more details on that soonish)<= /div>

Edit: Kathleen and I have asked them.=
=C2=A0

-Ekr


On We= d, Jan 17, 2018 at 7:52 PM, Salz, Rich <rsalz@akamai.com> wro= te:

>=C2=A0 =C2=A0 https://tools.ietf.org/html= /draft-foudil-securitytxt-00
=E2=80=A6
>=C2=A0 =C2=A0 EKR has suggested that this may be a good topic to = add to the upcoming
=C2=A0 =C2=A0 SEC-DISPATCH meeting at IETF 100 in Singapore.

I don=E2=80=99t think we actually discussed this, did we?=C2=A0 What= =E2=80=99s happening then?

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


--f403043d4ad0b2a8d2056308a44b-- From nobody Thu Jan 18 09:51:36 2018 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 A1EBE12AF83 for ; Thu, 18 Jan 2018 09:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzXw-NcMndXx for ; Thu, 18 Jan 2018 09:51:33 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 D5E6E129C59 for ; Thu, 18 Jan 2018 09:51:32 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id j129so16272681oib.12 for ; Thu, 18 Jan 2018 09:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=22b/cz9Vdp25c9J25ylSJuceI5hrYSy1zxAaD/LBuDA=; b=mJ44iPFB9ktOenhXF1HqYWXDsiGxG3pHbDzvSRvypREvD/yzYye023R8z5RGrRwqp6 9rXiSFkBu5OYTHja9iCy/xJR3lMhIXQ6YRwwnmvt72tk0ZF/alZievsvK37ocs0B0GW3 iE46Stdm7mk2Z0sg6ePf7XClfwiov3NWbsT0NNJ/3L6Ht+uEBGiTe6i5kdOGw1rNfXKv ub0l/75/j+S3bUcxvwo5SM0UU0KEQV7CW30tv4eywrzQwvcxvMd7kcJS4XWFDZ1M/5hx O5gNWX2yISgaBgD27m15Hk/VVxWeh7K1AB8opK7QaGSJMat4XYY2XjPtdj7emJO3uW/i hDYQ== 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:from:date:message-id :subject:to; bh=22b/cz9Vdp25c9J25ylSJuceI5hrYSy1zxAaD/LBuDA=; b=P+iLVKFdocFLDyQur0rHQLof791fKoghzvCaySeLzNpeQKvlmtDHb7rxyG+lao1UsI gV0hOEpci/bREI5hMKgamYRTmZueoFZIFsCBg01dS/vmSdsulIN3fuKmFsKIbJEfkywq Sww5X46l7HGErP40RjX0/1uK7duTlsTKS+8ViKpMh/P4yGfvI7aWY4aSvYF+dE2muHv3 6rM03DUJtlKrp7CdqEX4RLRGWbjYfkn+NTJiHloYvQmNkt+KgreiE+mTsEIUe8eAO01P wAkMjbYY4SWsMZ8fO4kscFNSIA2745kEwn3MA3som+pIbseZ8bLdI51xyCiZLZ19MyWH Fbyg== X-Gm-Message-State: AKwxytcFouamt6jafhNO4yfWRIQoXZIVVCXgb/STV4Cl+PBVqYrT2kSl XrMCy0zi4EQIPHfzPOWoq8p1N/GoBKabF9d/Mq9ty/JL X-Google-Smtp-Source: ACJfBovcBXM0FWG34P1w5DFKYH7eLEuJXIemdTX1aj789ocOVqpIkKKDSNT1ho94Hpqr7VP5zwr/09qhu7sBQ1htA20= X-Received: by 10.202.253.7 with SMTP id b7mr3580168oii.250.1516297891918; Thu, 18 Jan 2018 09:51:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.15.89 with HTTP; Thu, 18 Jan 2018 09:51:31 -0800 (PST) Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Thu, 18 Jan 2018 12:51:31 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 17:51:34 -0000 Hi Everyone, RFC 7748 is Elliptic Curves for Security (https://tools.ietf.org/html/rfc7748). Section 6.1 states: ... The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with small order, where the order divides the cofactor of the curve (see Section 7). ... I believe the all 0's check is too late. By the time the result is available the multiplication has been performed and the leak has already been witnessed. It looks like libsodium is using a blacklist method to screen-out low-order elements that lead to an all 0's shared secret at https://github.com/jedisct1/libsodium/blob/master/src/libsodium/crypto_scalarmult/curve25519/ref10/x25519_ref10.c Jeff From nobody Thu Jan 18 11:46:19 2018 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 C27831270FC for ; Thu, 18 Jan 2018 11:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVGnannsczwo for ; Thu, 18 Jan 2018 11:46:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6A4126BFD for ; Thu, 18 Jan 2018 11:46:16 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 4F0457A330D for ; Thu, 18 Jan 2018 19:46:15 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 18 Jan 2018 14:46:14 -0500 Content-Transfer-Encoding: 7bit Reply-To: saag@ietf.org Message-Id: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> References: To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 19:46:19 -0000 > On Jan 18, 2018, at 12:51 PM, Jeffrey Walton wrote: > > RFC 7748 is Elliptic Curves for Security > (https://tools.ietf.org/html/rfc7748). Section 6.1 states: > > ... > The check for the all-zero value results from the fact that the > X25519 function produces that value if it operates on an input > corresponding to a point with small order, where the order divides > the cofactor of the curve (see Section 7). ... > > I believe the all 0's check is too late. By the time the result is > available the multiplication has been performed and the leak has > already been witnessed. What "leak" did you have in mind? IIRC, the check for all 0's is intended to ensure "contributory" key-agreement, it is not any sort of side-channel counter-measure. -- Viktor. From nobody Thu Jan 18 12:00:26 2018 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 EE65812DA54 for ; Thu, 18 Jan 2018 12:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtLtGkVKooIv for ; Thu, 18 Jan 2018 12:00:23 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 C976E12DA22 for ; Thu, 18 Jan 2018 12:00:19 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id t8so16576918oie.6 for ; Thu, 18 Jan 2018 12:00:19 -0800 (PST) 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:content-transfer-encoding; bh=bIyfYokcypxqW2j4i8R4MN+/0KAl15HiGvEZKy9iv9I=; b=pw1DsqWl/INmKHXgnMejJF6fa8FrQeVRgHwcoivIQb9Kolss3fn+FDkGuJ0ULy4oBK tGptsolQXKxqV4yaniUrEsSpG8dZLHuudboVh/Vs6f7SN5urYc8CjOcv49CsBIw7ov44 nL7i/s4eIigJ2JUz3+xRz/yLKPqKZF7KaIrOOE3yDwJ3V9ekdnaI7y6FgQjEV7+9R2vZ Wmb1XCb/kdy6BEQ2cd0x5PI9N6ngEwOPAFqGpNQyhFIYrQBCs97JzV9LiSz0Hxpj1tJ1 DS+olNeqWfZ25igy1JUfIqgDaS0VS6qpIrdEQSeXBXQH50oBikTKxbf8Z42MWKkBKal5 BhTw== 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:content-transfer-encoding; bh=bIyfYokcypxqW2j4i8R4MN+/0KAl15HiGvEZKy9iv9I=; b=B2GO3tjtR9/MocLauUB+Ar2q3wE9NIRVi5aa2P9Lu/zk3G8hjyqRVW1qUkZYN3rS88 LtrxPmtNpYh0Z3WDw3SWdeiou5BhmNlYkC6z7Ffi6WkxSV8wqj4lxUA186SHGbC/Fovo eoFTqDXhtuN129y1xpYtUDRUbqYKtUBvYN4o3eCnCzyglDWZUbZK+MDLhylRxD9x/9OX NVIaEgs/sYUdvbqohKar6qgOvE0LicHWjVvuKmXfAub+6D/BC0GlzJzNzyYaT4j7utkg raUMIn67SRj0EXUI/9PoEgpVwsy4U8b/cI7G1NyCDIfscRY4wOyO88Oi7bft6bkUJRNs S0Mg== X-Gm-Message-State: AKwxytfV08tJksOs0NW7TAR/Cet0l6c2lZRO4WIKyl0Jdd3NHUWqpSrF 4h46dco1DpJAK43q5ZpZpr7mmflKhAw7QoObPOck93xk X-Google-Smtp-Source: ACJfBotXK6OwTMRGgR5EJaO0chBSgupqKSmg4lYHU/+IByROapSPjAEAgp6ZhJXZOUSMUAOG1o0G0OBENNe4SQTMZ3Q= X-Received: by 10.202.245.215 with SMTP id t206mr3376171oih.172.1516305618748; Thu, 18 Jan 2018 12:00:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.15.89 with HTTP; Thu, 18 Jan 2018 12:00:17 -0800 (PST) Reply-To: noloader@gmail.com In-Reply-To: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> From: Jeffrey Walton Date: Thu, 18 Jan 2018 15:00:17 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:00:25 -0000 On Thu, Jan 18, 2018 at 2:46 PM, Viktor Dukhovni w= rote: > >> On Jan 18, 2018, at 12:51 PM, Jeffrey Walton wrote: >> >> RFC 7748 is Elliptic Curves for Security >> (https://tools.ietf.org/html/rfc7748). Section 6.1 states: >> >> ... >> The check for the all-zero value results from the fact that the >> X25519 function produces that value if it operates on an input >> corresponding to a point with small order, where the order divides >> the cofactor of the curve (see Section 7). ... >> >> I believe the all 0's check is too late. By the time the result is >> available the multiplication has been performed and the leak has >> already been witnessed. > > What "leak" did you have in mind? IIRC, the check for all 0's is intende= d > to ensure "contributory" key-agreement, it is not any sort of side-channe= l > counter-measure. "May the Fourth Be With You: A Microarchitectural Side Channel Attack on Several Real-World Applications of Curve25519", https://eprint.iacr.org/2017/806.pdf. Section 1.1 (p.3): ... Even when countermeasures against low order elements and small subgroup attacks exist, they often do not prevent all side-channel attacks. For example, RFC 7748 [53] recommends =E2=80=9CORing all the bytes (of the output) together and checking whether the result is zero, as this eliminates standard side-channels in software implementations.=E2=80=9D One reason that this countermeasure does not work against side-channel attacks that exploit low-order elements is that it is enacted after the scalar-by-point multiplication has been performed, when the leakage is already obtained by the adversary. Jeff From nobody Thu Jan 18 12:08:30 2018 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 55FFD12D833 for ; Thu, 18 Jan 2018 12:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvg3irI0_2-x for ; Thu, 18 Jan 2018 12:08:27 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE3E12D82F for ; Thu, 18 Jan 2018 12:08:27 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 038CC7A330D for ; Thu, 18 Jan 2018 20:08:26 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 18 Jan 2018 15:08:26 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: saag@ietf.org Message-Id: <2E64E647-4765-40DF-B5BF-59A00BF4C5C8@dukhovni.org> References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:08:29 -0000 > On Jan 18, 2018, at 3:00 PM, Jeffrey Walton = wrote: >=20 >=20 > "May the Fourth Be With You: A Microarchitectural Side Channel Attack > on Several Real-World Applications of Curve25519", > https://eprint.iacr.org/2017/806.pdf. Section 1.1 (p.3): >=20 > ... Even when countermeasures against low order elements and > small subgroup attacks exist, they often do not prevent all > side-channel attacks. For example, RFC 7748 [53] recommends > =E2=80=9CORing all the bytes (of the output) together and checking > whether the result is zero, as this eliminates standard > side-channels in software implementations.=E2=80=9D One reason that > this countermeasure does not work against side-channel attacks > that exploit low-order elements is that it is enacted after the > scalar-by-point multiplication has been performed, when the > leakage is already obtained by the adversary. Key agreement private keys should be single-use. The all zero check is solely a counter-measure against non-contributory outcomes. --=20 Viktor. From nobody Thu Jan 18 12:08:50 2018 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 C7B9F12D84A for ; Thu, 18 Jan 2018 12:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yvx2Q5zSg5R for ; Thu, 18 Jan 2018 12:08:47 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 233B512D838 for ; Thu, 18 Jan 2018 12:08:47 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id r4so17371219oti.12 for ; Thu, 18 Jan 2018 12:08:47 -0800 (PST) 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:content-transfer-encoding; bh=hlbjKctOm5UNUUCm+mYWiZ8aih5Stc6W8+ZgjBlbdiU=; b=Y+stroHAiaGQr9MIg0/0s2cYMol62RXLVhJDVtoLd/dDsxvsJ5g4kmkvZjhpLW+xaJ jiUQmoScT0+Y1y8mlKFTs+i4FKgae+Z3V0CHvijYHBxdNHBnHK1QMZVud7u31D18kBDo w76SWyjZy/5c28xP2VbDALjuGqARIoDq/D01Ufpqsh/exvL9UkM5y8gO3CB/SmS0N+V4 teWZyzJ7PWgyAgQzGqnQd7a2bfQnneBSEEZQ8woQmUyQALRFViTxGMYh4U7jcjcatRah uiWQ+JB6WMegt7CZPuR8cQ2M/k2nUIDsJD+D2NOZnao7MZgeKMVMGFWqkMfMxhAQwJdr 0XCw== 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:content-transfer-encoding; bh=hlbjKctOm5UNUUCm+mYWiZ8aih5Stc6W8+ZgjBlbdiU=; b=AJCLBVNrI4bMOZMAfxrz+zTOWfJMjTDcnfMCVyyc9Smb36aqecdLdgxS2Yyt+Lf7NV F3OPs1Gp1WGeBDhwYMRabrVe5MZsVy5cAbbOwA4YCSfiWRC5aHedaN0XxxdzoDgiGSzW qiKdHNIYtDErmbDIwnVhdzrQ0K6Cz3DzmTYe8UppBDjViXTwp3W5bM8y3Cip/SesTM3n Ty1hnaiVAv4PhV8zF9uVEfaawhsnBtfcrXBP0gLfJwVMavdY5Yz4bjNPM5kCVUhtfaEh HQ8BmhR6ATkR16ov3SzPY0pExLHDu4P0BcTX/QQGlKga3d7r+roUBVCcAFTtcss0GlSj SBKA== X-Gm-Message-State: AKwxytco4JdKx53XaPSSivur06dMSLP3pXv09mhYeGbtz3S6QxoPj6d5 nlDY2uSiGcsUsd4SbFC63Kt4hPhfRZM1i6YZEyQaf9p0 X-Google-Smtp-Source: ACJfBose3ofSbIHf4iHS2jg0bQi+aSjFduKWsvSvT49FBcKOVED4hlfr3tJ7DpA4p3ajZAkS9iuHGlOQa/rXfaNYadM= X-Received: by 10.157.50.22 with SMTP id t22mr3888808otc.299.1516306126395; Thu, 18 Jan 2018 12:08:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.15.89 with HTTP; Thu, 18 Jan 2018 12:08:45 -0800 (PST) Reply-To: noloader@gmail.com In-Reply-To: References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> From: Jeffrey Walton Date: Thu, 18 Jan 2018 15:08:45 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:08:49 -0000 On Thu, Jan 18, 2018 at 3:00 PM, Jeffrey Walton wrote: > On Thu, Jan 18, 2018 at 2:46 PM, Viktor Dukhovni = wrote: >> >>> On Jan 18, 2018, at 12:51 PM, Jeffrey Walton wrote= : >>> >>> RFC 7748 is Elliptic Curves for Security >>> (https://tools.ietf.org/html/rfc7748). Section 6.1 states: >>> >>> ... >>> The check for the all-zero value results from the fact that the >>> X25519 function produces that value if it operates on an input >>> corresponding to a point with small order, where the order divides >>> the cofactor of the curve (see Section 7). ... >>> >>> I believe the all 0's check is too late. By the time the result is >>> available the multiplication has been performed and the leak has >>> already been witnessed. >> >> What "leak" did you have in mind? IIRC, the check for all 0's is intend= ed >> to ensure "contributory" key-agreement, it is not any sort of side-chann= el >> counter-measure. > > "May the Fourth Be With You: A Microarchitectural Side Channel Attack > on Several Real-World Applications of Curve25519", > https://eprint.iacr.org/2017/806.pdf. Section 1.1 (p.3): > > ... Even when countermeasures against low order elements and > small subgroup attacks exist, they often do not prevent all > side-channel attacks. For example, RFC 7748 [53] recommends > =E2=80=9CORing all the bytes (of the output) together and checking > whether the result is zero, as this eliminates standard > side-channels in software implementations.=E2=80=9D One reason that > this countermeasure does not work against side-channel attacks > that exploit low-order elements is that it is enacted after the > scalar-by-point multiplication has been performed, when the > leakage is already obtained by the adversary. By the way... if interested, here are the libsodium test vectors that include the small element case: https://github.com/jedisct1/libsodium/blob/master/test/default/box.c . The useage of interest is: // 0 =3D success; non-0 =3D failure ret =3D crypto_box(c, m, 163, nonce, small_order_p, alicesk); assert(ret !=3D 0); If a function or system consumes the small order element then it may be susceptible to the side channel attack. This is how we came to know the paper and the blacklist. We did not fail when we were supposed to. Jeff From nobody Thu Jan 18 12:12:43 2018 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 1A07B12D837 for ; Thu, 18 Jan 2018 12:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTBmA9oCdxBx for ; Thu, 18 Jan 2018 12:12:40 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 BAC2412D831 for ; Thu, 18 Jan 2018 12:12:40 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id f100so8642078otf.3 for ; Thu, 18 Jan 2018 12:12:40 -0800 (PST) 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:content-transfer-encoding; bh=BudhcohJPF15UY6Ix3C4nTdQ61Yl9mubWtQV6im6gyw=; b=b41Mtd4pxEFHiMsMXKJ/efQCMi+UaWz6PTQvsb3gt8RCOkZKm6OULUXQqatgC68Jmv 9/uiwb90Ez2CKcfy1upV7vLT2ORnIFSyhJOdX7N/kp1R0cutmtZ9+W/3n3/prjCI9Q0K 4sA3JEXcN5a+iBQP2EvD1h9lLZ8p91ZtIn2kmI/xL1uga+834p8aqHdmO+WaZ2SSVh3Q uZ0fU1W8kRdLqgsHzAg4Zg5Y5FIeM+8EjKI0tBL6zEJxOeHRxmdgIznbqjrPfFqCLgtS tmr8nXov4Nn3ekw4O+6QRnLyzAD1cZgDZXfGE44CYs2hDWs9rtQ8k3YsQuI2qVWgrw8v hN+w== 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:content-transfer-encoding; bh=BudhcohJPF15UY6Ix3C4nTdQ61Yl9mubWtQV6im6gyw=; b=goutcZ7xaMArETYrqCL+zQzApy0Czot/nwtrAi6TVX4oAoXnRUQZKaK93Wu9QnrY9r sU10bZDnfc6AJaJXXguOVWDYZA6CSvl4E7zMO7/ZKsiRdoJjbIz8Z8qHi6c5IC7OwlB7 dRGnoYc+1tno4h5qkXNv86UEw+dC/l+gLwvYf342y/Dq1yiI6jFdR4VYvVjHQGuoBZOY G4rvNvRi84CuLLWATpJ1x369qnCF09xTKlHGH8sj50WRxffrQ80/NssX/7ww6d155Kc9 tTX2+8421jH4btH/dnorZcFlieQ4AQQSAdRHe+XH+czF22y9QCt82yG7oErL9QIkk/gK +DFg== X-Gm-Message-State: AKwxytf86FC38BwuJfdbUNTCnFzC4Di3B4BE23jaXGBrpMSg/N0btpNy GWb8IXnzCK02pZRZkTh7zC+mtmZJGKg63ftt31HyQY53 X-Google-Smtp-Source: ACJfBovWYInVyMAF3u7jjuJXx334RQsjvHO4685ZnxGNneGVZCNE0NqlLiwSbkVaaD+djK/FocywfZ80lkI2dFp2ZXA= X-Received: by 10.157.89.203 with SMTP id u11mr4350136otg.319.1516306360037; Thu, 18 Jan 2018 12:12:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.15.89 with HTTP; Thu, 18 Jan 2018 12:12:39 -0800 (PST) Reply-To: noloader@gmail.com In-Reply-To: <2E64E647-4765-40DF-B5BF-59A00BF4C5C8@dukhovni.org> References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> <2E64E647-4765-40DF-B5BF-59A00BF4C5C8@dukhovni.org> From: Jeffrey Walton Date: Thu, 18 Jan 2018 15:12:39 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:12:42 -0000 On Thu, Jan 18, 2018 at 3:08 PM, Viktor Dukhovni w= rote: > > >> On Jan 18, 2018, at 3:00 PM, Jeffrey Walton wrote: >> >> >> "May the Fourth Be With You: A Microarchitectural Side Channel Attack >> on Several Real-World Applications of Curve25519", >> https://eprint.iacr.org/2017/806.pdf. Section 1.1 (p.3): >> >> ... Even when countermeasures against low order elements and >> small subgroup attacks exist, they often do not prevent all >> side-channel attacks. For example, RFC 7748 [53] recommends >> =E2=80=9CORing all the bytes (of the output) together and checking >> whether the result is zero, as this eliminates standard >> side-channels in software implementations.=E2=80=9D One reason that >> this countermeasure does not work against side-channel attacks >> that exploit low-order elements is that it is enacted after the >> scalar-by-point multiplication has been performed, when the >> leakage is already obtained by the adversary. > > Key agreement private keys should be single-use. The all zero > check is solely a counter-measure against non-contributory outcomes. Thanks. The RFC states otherwise: The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with small order, where the order divides the cofactor of the curve ... Jeff From nobody Thu Jan 18 12:24:27 2018 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 6157612D838 for ; Thu, 18 Jan 2018 12:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7YIomEdZwd6 for ; Thu, 18 Jan 2018 12:24:25 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304A112D833 for ; Thu, 18 Jan 2018 12:24:25 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 681267A330D for ; Thu, 18 Jan 2018 20:24:24 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 18 Jan 2018 15:24:23 -0500 Content-Transfer-Encoding: 7bit Reply-To: saag@ietf.org Message-Id: <9451BAC1-96F7-4F0A-80E7-B2B5DA2523B3@dukhovni.org> References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> <2E64E647-4765-40DF-B5BF-59A00BF4C5C8@dukhovni.org> To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:24:26 -0000 > On Jan 18, 2018, at 3:12 PM, Jeffrey Walton wrote: > >> Key agreement private keys should be single-use. The all zero >> check is solely a counter-measure against non-contributory outcomes. > > Thanks. The RFC states otherwise: > > The check for the all-zero value results from the fact that the > X25519 function produces that value if it operates on an input > corresponding to a point with small order, where the order divides > the cofactor of the curve ... You're reading meaning into that text that is not there. All the all-zero outcome is the only non-contributory outcome. All small-order points result in that value. The check avoids non-contributory shared keys. That's all. Implementations that re-use private keys need to avoid computations that leak, quite separately from this check. -- Viktor. From nobody Thu Jan 18 12:26:45 2018 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 65FD212D835 for ; Thu, 18 Jan 2018 12:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLHShhVpBWqM for ; Thu, 18 Jan 2018 12:26:43 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179781200C1 for ; Thu, 18 Jan 2018 12:26:43 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 612AE7A330D for ; Thu, 18 Jan 2018 20:26:42 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <9451BAC1-96F7-4F0A-80E7-B2B5DA2523B3@dukhovni.org> Date: Thu, 18 Jan 2018 15:26:41 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: saag@ietf.org Message-Id: <7AADDA52-1311-4203-AE59-1F47C0FEB76D@dukhovni.org> References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> <2E64E647-4765-40DF-B5BF-59A00BF4C5C8@dukhovni.org> <9451BAC1-96F7-4F0A-80E7-B2B5DA2523B3@dukhovni.org> To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:26:44 -0000 > On Jan 18, 2018, at 3:24 PM, Viktor Dukhovni = wrote: >=20 > You're reading meaning into that text that is not there. All the > all-zero outcome is the only non-contributory outcome. All = small-order > points result in that value. The check avoids non-contributory shared > keys. That's all. Implementations that re-use private keys need to > avoid computations that leak, quite separately from this check. Quoting the RFC: Protocol designers using Diffie-Hellman over the curves defined in this document must not assume "contributory behaviour". Specially, contributory behaviour means that both parties' private keys contribute to the resulting shared key. Since curve25519 and curve448 have cofactors of 8 and 4 (respectively), an input point of small order will eliminate any contribution from the other party's private key. This situation can be detected by checking for the all- zero output, which implementations MAY do, as specified in Section 6. However, a large number of existing implementations do not do this. --=20 Viktor. From nobody Thu Jan 18 12:43:34 2018 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 C6D9A12D0C3 for ; Thu, 18 Jan 2018 12:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URa9gchTpdHq for ; Thu, 18 Jan 2018 12:43:30 -0800 (PST) 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 31FA6120227 for ; Thu, 18 Jan 2018 12:43:29 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id t16so16629653oif.10 for ; Thu, 18 Jan 2018 12:43:29 -0800 (PST) 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; bh=wukCKiTC1hBLjpvrur6/E4eeHGw+N1xVttJ2/5ZtMx8=; b=JxdwH2tl9Rv1vmRPeZ8O/cg6IuMrgpagvtEFPTVvroAh2m0iGmOp/2AuRZNt+AgnU9 Ga9inOmH+3+LycMuaCy7DnCOkcF0irrpnX+g8rtPXLlRU5KpjYvhHTqjSigICYp9/hhI CXWjPW8Z52DGa68aYEpxSd4gM5VU7nkWfJeCLmzBwhmN5in2N++mXX1DNTpN/h4SCz21 YLinHX2znyR03r7I+Kio2w1hesyP3kXEIF6ZBZv4NczIHD5c5zEiUjszbo4q0GMoEdgJ s58UJORXnbPSKuEPMuOZALUw8yTaNmoTQxgb7W88gBw50AuShYSwfr9df9s9BOtK4uYD KPjA== 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; bh=wukCKiTC1hBLjpvrur6/E4eeHGw+N1xVttJ2/5ZtMx8=; b=gsblZ7bCHaCk11zm/e9jy5sYTnyvvWgm42LJRlWG7xB+u6XKXIlDmiFPukuqGSJdcp F9Q9mHspE1XmWnQ5CiZoSw20A8/q+LW1pJYsVyK2dioyebdZZAmPgt2TSF9F64ZBU5ti sfgZsGghZYac7QfJzQlMjFtEvAqhtz1MwDCnxvRJQiQnNlCf4ZDOmEp2PmnKicTsQwUY XryRYIOySdkHmqWKY2v1mt39K2gB8uQN3dr9rjfYtlGXzrhkfhw6jZ2cAIOGAxOziWQt Is/jni7uO6JNujgvu+RawX9RRgfjcaFSekPyPHXcRs5topqUOMNU+htnKCmErXqvbnXI gUNA== X-Gm-Message-State: AKwxyteUzhyLUk+kH/zAzW8HOrHjS6+S3R1kom2J1dFw+FqV8VxGyy/C 120gELttesny4bXTg2dlFFa5azCvt3cur7ehN8o/y0AI X-Google-Smtp-Source: ACJfBou08y+nMWO5MTBtNi/r4u6dO7jgTDkaBwtf6Bw/l8kshPg/WlqviK67aiivTXVDy/TgUWFB4GJ+yTP/FRKZwho= X-Received: by 10.202.104.8 with SMTP id d8mr3838772oic.200.1516308209097; Thu, 18 Jan 2018 12:43:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.15.89 with HTTP; Thu, 18 Jan 2018 12:43:28 -0800 (PST) Reply-To: noloader@gmail.com In-Reply-To: <7AADDA52-1311-4203-AE59-1F47C0FEB76D@dukhovni.org> References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> <2E64E647-4765-40DF-B5BF-59A00BF4C5C8@dukhovni.org> <9451BAC1-96F7-4F0A-80E7-B2B5DA2523B3@dukhovni.org> <7AADDA52-1311-4203-AE59-1F47C0FEB76D@dukhovni.org> From: Jeffrey Walton Date: Thu, 18 Jan 2018 15:43:28 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:43:32 -0000 On Thu, Jan 18, 2018 at 3:26 PM, Viktor Dukhovni wrote: > > >> On Jan 18, 2018, at 3:24 PM, Viktor Dukhovni wrote: >> >> You're reading meaning into that text that is not there. All the >> all-zero outcome is the only non-contributory outcome. All small-order >> points result in that value. The check avoids non-contributory shared >> keys. That's all. Implementations that re-use private keys need to >> avoid computations that leak, quite separately from this check. > > Quoting the RFC: > > Protocol designers using Diffie-Hellman over the curves defined in > this document must not assume "contributory behaviour". Specially, > contributory behaviour means that both parties' private keys > contribute to the resulting shared key. Since curve25519 and > curve448 have cofactors of 8 and 4 (respectively), an input point of > small order will eliminate any contribution from the other party's > private key. This situation can be detected by checking for the all- > zero output, which implementations MAY do, as specified in Section 6. > However, a large number of existing implementations do not do this. As it is written, Section 6.1 states the "all 0's check" is used for the standard side channel attacks, which includes the attack detailed in the paper. If the "all 0's check" in Section 6.1 only applies to contributory behavior, then Section 6.1 needs to clearly state it. That's what the Security Considerations section is for. Otherwise, it is confusing (q.v.). Jeff From nobody Thu Jan 18 12:49:14 2018 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 DB11E12D84C for ; Thu, 18 Jan 2018 12:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VA532uUn6N3 for ; Thu, 18 Jan 2018 12:49:11 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1043A12420B for ; Thu, 18 Jan 2018 12:49:10 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 182057A330D for ; Thu, 18 Jan 2018 20:49:10 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 18 Jan 2018 15:49:09 -0500 Content-Transfer-Encoding: 7bit Reply-To: saag@ietf.org Message-Id: <944BD9D5-1A38-45D8-A170-E1E971499620@dukhovni.org> References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> <2E64E647-4765-40DF-B5BF-59A00BF4C5C8@dukhovni.org> <9451BAC1-96F7-4F0A-80E7-B2B5DA2523B3@dukhovni.org> <7AADDA52-1311-4203-AE59-1F47C0FEB76D@dukhovni.org> To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:49:13 -0000 > On Jan 18, 2018, at 3:43 PM, Jeffrey Walton wrote: > > As it is written, Section 6.1 states the "all 0's check" is used for > the standard side channel attacks, which includes the attack detailed > in the paper. No, it just says that when performing the check one should not introduce new side-channel attacks. It does NOT say that the check is a side-channel counter-measure: The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with small order, where the order divides the cofactor of the curve (see Section 7). The check may be performed by ORing all the bytes together and checking whether the result is zero, as this eliminates standard side-channels in software implementations. The "...as this eliminates..." language is only about avoiding side-channel issues when doing the comparison. -- Viktor. From nobody Thu Jan 18 12:53:14 2018 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 86165127136 for ; Thu, 18 Jan 2018 12:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uugvs0t_Cvf6 for ; Thu, 18 Jan 2018 12:53:11 -0800 (PST) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (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 1B51C124B17 for ; Thu, 18 Jan 2018 12:53:11 -0800 (PST) Received: by mail-ot0-x241.google.com with SMTP id p16so21326038otf.1 for ; Thu, 18 Jan 2018 12:53:11 -0800 (PST) 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; bh=ugUJ6hINBPfJsi9hLg6LuviK8+aD5RSq2W/FOQrPWIs=; b=JjUZiTDW8BdHCzQi/zRvaT3/0MRky+/nbs/9CkRFCchh3vzC6rGGvQkgfW6/KL8egL nqXWhz8M7s7z+cnNR5u21bjiulEZKAfArwJxzFAKAo/yyZ3Pow+lj5uRG+UwLz2LO+G6 72aecSimLgplJ8M+pZUBHSXzH1sBcqejQyQu6TUYzO80m6eMhMP67wf3ZMcDwL21qyLT X+/KM421vBdYHfLK8Y1TUkzjb7KMYSbW4XGhc/1t7l6hckQIPMwwnVWc9NAymkuXfgAk uqB6BHVRRk+XpXjf+OcmWIUJISPLwIO+ydx7j1bVuo5n59cifwcsZK2pNmKbzDYcLLYP V+OA== 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; bh=ugUJ6hINBPfJsi9hLg6LuviK8+aD5RSq2W/FOQrPWIs=; b=lBpYCciCf9hdL0s11tcUmTpbed6WJceu7KhsHZ0+UynV3l8iILA0l1f2pOWt1Hq/wf Rw3tTUWSDZ5guvNLNbIg6t3W2VHLFV1JIK0+HjnKwoSxWF/6LleNay7mig2S+Poy9Ww7 EeCtFkrH4vJa0yLYAWFP2OhosKQ9h9X2nxgi8CvlbOdixYrzb91DC84100/6CkCVnua/ uRQ47y0qrIDd0ThH9iqKIwRPnmuF3LrOBLXaTgJFgYbAFf4as1HfuvUzrXJt1/3/IT1S QxFEx+Ne7CsIDYEwbhq2mijUGYheVmkySkmswkLrlunIwmfN+eGQ9rBCl9pENPDfgJsc ucKA== X-Gm-Message-State: AKwxytdTPhSxF08ZEKLNkws7pSofztSPyQ9CyAODjSZKaFRzYYv8y6Vd 7uIeTUpNUpGqSFxByI4/jRUYqT/oD8i3RVY98azoikoX X-Google-Smtp-Source: ACJfBoukpG5X68PHdfSZ1r1vBqtLoKQorFahShJCY0mT8TbTb+ts1Rq3PIcnDNqGIGb0nX+/+qd+JyE6aojMq/Yufeg= X-Received: by 10.157.34.22 with SMTP id o22mr3936412ota.159.1516308790302; Thu, 18 Jan 2018 12:53:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.15.89 with HTTP; Thu, 18 Jan 2018 12:53:09 -0800 (PST) Reply-To: noloader@gmail.com In-Reply-To: <944BD9D5-1A38-45D8-A170-E1E971499620@dukhovni.org> References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> <2E64E647-4765-40DF-B5BF-59A00BF4C5C8@dukhovni.org> <9451BAC1-96F7-4F0A-80E7-B2B5DA2523B3@dukhovni.org> <7AADDA52-1311-4203-AE59-1F47C0FEB76D@dukhovni.org> <944BD9D5-1A38-45D8-A170-E1E971499620@dukhovni.org> From: Jeffrey Walton Date: Thu, 18 Jan 2018 15:53:09 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:53:12 -0000 On Thu, Jan 18, 2018 at 3:49 PM, Viktor Dukhovni wrote: > > >> On Jan 18, 2018, at 3:43 PM, Jeffrey Walton wrote: >> >> As it is written, Section 6.1 states the "all 0's check" is used for >> the standard side channel attacks, which includes the attack detailed >> in the paper. > > No, it just says that when performing the check one should not introduce > new side-channel attacks. It does NOT say that the check is a side-channel > counter-measure: > > The check for the all-zero value results from the fact that the > X25519 function produces that value if it operates on an input > corresponding to a point with small order, where the order divides > the cofactor of the curve (see Section 7). The check may be > performed by ORing all the bytes together and checking whether the > result is zero, as this eliminates standard side-channels in software > implementations. > > The "...as this eliminates..." language is only about avoiding side-channel > issues when doing the comparison. Here we go again... Here is what Section 6.1 says: The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with small order, where the order divides the cofactor of the curve (see Section 7). The check may be performed by ORing all the bytes together and checking whether the result is zero, as this eliminates standard side-channels in software implementations. The "all 0's check" does not eliminate the standard side-channels in software. The world is a bigger place than single use DH in TLS. Jeff From nobody Thu Jan 18 12:58:33 2018 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 B218912D867 for ; Thu, 18 Jan 2018 12:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdHTJ5MspDhb for ; Thu, 18 Jan 2018 12:58:28 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E8112D84C for ; Thu, 18 Jan 2018 12:58:17 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id E95AB7A330D for ; Thu, 18 Jan 2018 20:58:15 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 18 Jan 2018 15:58:14 -0500 Content-Transfer-Encoding: quoted-printable Reply-To: saag@ietf.org Message-Id: <6D376C9B-99C1-4DCE-BF37-C47833CA7ED4@dukhovni.org> References: <63886223-4E1A-4A9F-A4D3-73DE156D3A9B@dukhovni.org> <2E64E647-4765-40DF-B5BF-59A00BF4C5C8@dukhovni.org> <9451BAC1-96F7-4F0A-80E7-B2B5DA2523B3@dukhovni.org> <7AADDA52-1311-4203-AE59-1F47C0FEB76D@dukhovni.org> <944BD9D5-1A38-45D8-A170-E1E971499620@dukhovni.org> To: saag@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [saag] RFC 7748, Section 6.1, and the "all 0's check" 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, 18 Jan 2018 20:58:30 -0000 > On Jan 18, 2018, at 3:53 PM, Jeffrey Walton = wrote: >=20 > Here we go again... Here is what Section 6.1 says: >=20 > The check for the all-zero value results from the fact that the > X25519 function produces that value if it operates on an input > corresponding to a point with small order, where the order divides > the cofactor of the curve (see Section 7). The check may be > performed by ORing all the bytes together and checking whether the > result is zero, as this eliminates standard side-channels in = software > implementations. >=20 > The "all 0's check" does not eliminate the standard side-channels in = software. You (and the paper's authors) are misreading the text of the RFC. There is NO claim that the all zeros check is a side-channel counter-measure (let alone a universally effective one). ALL that is said is that the comparison should be done in constant time, such as by using OR on all the bytes, THEREBY avoiding creating a side-channel. The "this" in question is the use of "OR" not the all the all zeros = check itself. Perhaps this could have been more clear, but to me that is the most natural reading of the RFC's language. --=20 Viktor. From nobody Fri Jan 19 00:42:37 2018 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 83AA312AAB6 for ; Fri, 19 Jan 2018 00:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-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 1jSs7jt0n4qB for ; Fri, 19 Jan 2018 00:42:33 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBFB1201F2 for ; Fri, 19 Jan 2018 00:42:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 529312CD0D for ; Fri, 19 Jan 2018 10:42:31 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAZ8NTJncUK9 for ; Fri, 19 Jan 2018 10:42:30 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id E8BC32CCBA for ; Fri, 19 Jan 2018 10:42:29 +0200 (EET) (envelope-from jari.arkko@piuha.net) From: Jari Arkko Content-Type: multipart/alternative; boundary="Apple-Mail=_CC79E4B7-6C58-4523-AA80-626EDDF15132" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 19 Jan 2018 10:42:28 +0200 To: Security Area Advisory Group X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [saag] Potential new working group under discussion for EAP related maintenance + small extensions 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, 19 Jan 2018 08:42:36 -0000 --Apple-Mail=_CC79E4B7-6C58-4523-AA80-626EDDF15132 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I wanted to bring this to the SAAG list as well, although some of us = have been discussing this on the EMU list. We have been discussing of what to do with the EAP work that got = discussed both in the SAAG meeting last time as well on the list. You = may recall that there were a number of different topics: * At IETF #100 SAAG, I presented a draft on small updates/corrections to = EAP-AKA=E2=80=99 (RFC 5448) * And adding perfect forward secrecy as an extension * On the list, there were a lot of discussion about how to use TLS 1.3 = in EAP-TLS. The discussion has converged, I think, and there seems to be = work to be done. There=E2=80=99s a draft, and it has been updated per = the most recent discussion. * There was also a discussion of operational issues relating to long = certificate chains in EAP-TLS. * On the list, some new issues were also brought up affecting EAP-SIM, = EAP-AKA, EAP-AKA=E2=80=99, which may need small updates. I was wondering how we could get the work moving forward. The first = thought that came to my mind was to start a small working group. = Thoughts? A draft charter proposal is at = https://www.ietf.org/mail-archive/web/emu/current/msg02239.html but also = copied at the end of this message. Comments, suggestions and other thoughts would be much welcome. Would = such a small working group be reasonable? Are the suggested work items = the right ones? We will continue the discussion in the emu list, but if there are = responses on this list those are much appreciated as well. I can also = summarise to the emu list as needed. The full archive of the emu list is = at https://www.ietf.org/mail-archive/web/emu/current/maillist.html. If = you want to subscribe, go to https://www.ietf.org/mailman/listinfo/emu Jari > EAP Maintenance Update (emu) > or > EAP Method Maintenance Update (emmu) > ------------------------------------ >=20 > Chairs: > TBD >=20 > Security Area Directors: > Eric Rescorla > > Kathleen Moriarty > >=20 > Security Area Advisor: > TBD >=20 > Mailing Lists: > General Discussion: emu@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/emu = > Archive: http://www.ietf.org/mail-archive/web/emu/ = >=20 > Description of Working Group: >=20 >=20 > The Extensible Authentication Protocol (EAP) [RFC 3748] is a = network > access authentication framework used, for instance, in 802.11 and = VPN > networks and mobile networks. EAP itself is a simple > protocol and actual authentication happens in EAP methods. >=20 > Over 50 different EAP methods exist, including several methods > developed in the IETF, and support for EAP exists in a broad set > of different devices. Previous larger EAP-related efforts at the > IETF included rewriting the base EAP protocol documentation and > the development of several standards track EAP methods. >=20 > EAP methods are generally based on existing other security > technologies, such as TLS, SIM cards, and various algorithms. > Some of these technologies continue to evolve. And the > understanding of security threats in today's Internet evolves as > well, which has driven some of the evolution in these underlying > technologies. At the same time, some new use cases for EAP have > been identified, such as broader use of EAP in mobile network > authentication. >=20 > This working group has been chartered to provide updates to some > commonly used EAP method. Specifically, the working group shall > produce documents to: >=20 > - Provide a guidance or update to enable the use of TLS 1.3 in the > context of EAP TLS (RFC 5216). Update the security > considerations relating to EAP TLS, to document the implications > of using new vs. old TLS version, any recently gained new > knowledge on vulnerabilities, and the possible implications of > pervasive survellaince or other new concerns. >=20 > - Update the EAP-AKA' specification (RFC 5448) to ensure that its > capability to provide a cryptographic binding to network context > stays in sync with what updates may come to the referenced 3GPP > specifications through the use of EAP in 5G. >=20 > Also, the group should document any recently gained new=20 > knowledge on vulnerabilities or the possible implications of=20 > pervasive surveillance or other new concerns. >=20 > - Define session identifiers for fast re-authentication for > EAP-SIM, EAP-AKA, and EAP-AKA=E2=80=99. The lack of this = definition > is a recently discovered bug in the original RFCs. >=20 > - Develop an extension to EAP-AKA' such that Perfect Forward = Secrecy > can be provided. There may also be privacy improvements that > have become feasible with the introduction of recent identity > privacy improvements in 3GPP networks. >=20 > - Gather experience regarding the use of large certificate and > certificate chain sizes in the context of EAP-TLS (all versions), > as some implementations and access networks may limit the=20 > number of EAP packet exchanges that can be handled. > Document operational recommendations or other mitigation > strategies to avoid issues. >=20 > In all of the above, it is a requirement that none of the updates > break backwards compatibility with existing specifications or > implementations. The current RFCs shall not be obsoleted but > rather updated with either new information or instructions on > what is needed, for instance, to employ a new TLS version. >=20 > The working group is expected to stay in close collaboration with > the EAP deployment community, the TLS working group (for EAP-TLS > work), and the 3GPP security architecture group (for EAP-AKA' > work). >=20 > Milestones: >=20 > TBD --Apple-Mail=_CC79E4B7-6C58-4523-AA80-626EDDF15132 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I wanted to bring this to the SAAG list as = well, although some of us have been discussing this on the EMU = list.

We have = been discussing of what to do with the EAP work that got discussed both = in the SAAG meeting last time as well on the list. You may recall that = there were a number of different topics:

* At IETF #100 SAAG, I presented a = draft on small updates/corrections to EAP-AKA=E2=80=99 (RFC = 5448)
* And adding perfect forward secrecy as an = extension
* On the list, there were a lot of = discussion about how to use TLS 1.3 in EAP-TLS. The discussion has = converged, I think, and there seems to be work to be done. There=E2=80=99s= a draft, and it has been updated per the most recent = discussion.
* There was also a discussion of = operational issues relating to long certificate chains in = EAP-TLS.
* On the list, some new issues were also = brought up affecting EAP-SIM, EAP-AKA, EAP-AKA=E2=80=99, which may need = small updates.

I= was wondering how we could get the work moving forward. The first = thought that came to my mind was to start a small working group. = Thoughts? A draft charter proposal is at https://www.ietf.org/mail-archive/web/emu/current/msg02239.html= but also copied at the end of this message.

Comments, suggestions and other = thoughts would be much welcome. Would such a small working group be = reasonable? Are the suggested work items the right ones?

We will continue the = discussion in the emu list, but if there are responses on this list = those are much appreciated as well. I can also summarise to the emu list = as needed. The full archive of the emu list is at https://www.ietf.org/mail-archive/web/emu/current/maillist.html= . If you want to subscribe, go to https://www.ietf.org/mailman/listinfo/emu

Jari

EAP = Maintenance Update (emu)
       or
EAP = Method Maintenance Update (emmu)
------------------------------------

Chairs:
    TBD

Security Area Directors:
    Eric Rescorla <ekr@rtfm.com>
    Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>

Security Area Advisor:
    TBD

Mailing Lists:
    General = Discussion: emu@ietf.org
    To = Subscribe:       https://www.ietf.org/mailman/listinfo/emu
    Archive: =            http://www.ietf.org/mail-archive/web/emu/
Description of Working Group:

   The Extensible Authentication Protocol = (EAP) [RFC 3748] is a network
   access = authentication framework used, for instance, in 802.11 and VPN
   networks and mobile networks. EAP itself is = a simple
   protocol and actual = authentication happens in EAP methods.

   Over 50 different EAP methods exist, = including several methods
   developed in = the IETF, and support for EAP exists in a broad set
   of different devices. Previous larger = EAP-related efforts at the
   IETF included = rewriting the base EAP protocol documentation and
   the development of several standards track = EAP methods.

   EAP methods = are generally based on existing other security
   technologies, such as TLS, SIM cards, and = various algorithms.
   Some of these = technologies continue to evolve. And the
   understanding of security threats in = today's Internet evolves as
   well, which = has driven some of the evolution in these underlying
   technologies. At the same time, some new = use cases for EAP have
   been identified, = such as broader use of EAP in mobile network
   authentication.

   This working group has been chartered to = provide updates to some
   commonly used = EAP method. Specifically, the working group shall
   produce documents to:

   - Provide a guidance or update to enable = the use of TLS 1.3 in the
     context of EAP TLS (RFC 5216). = Update the security
     considerations relating to EAP = TLS, to document the implications
     of using new vs. old TLS = version, any recently gained new
     knowledge on vulnerabilities, = and the possible implications of
     pervasive survellaince or other = new concerns.

   - Update = the EAP-AKA' specification (RFC 5448) to ensure that its
     capability to provide a = cryptographic binding to network context
     stays in sync with what updates = may come to the referenced 3GPP
     specifications through the use = of EAP in 5G.

     Also, the group should document = any recently gained new 
    =  knowledge on vulnerabilities or the possible implications = of 
     pervasive surveillance = or other new concerns.

   - = Define session identifiers for fast re-authentication for
     EAP-SIM, EAP-AKA, and EAP-AKA=E2=80=99. = The lack of this definition
     is = a recently discovered bug in the original RFCs.

   - Develop an extension to EAP-AKA' such = that Perfect Forward Secrecy
     can be provided. There may also = be privacy improvements that
    =  have become feasible with the introduction of recent = identity
     privacy improvements = in 3GPP networks.

   - = Gather experience regarding the use of large certificate and
     certificate chain sizes in the context of = EAP-TLS (all versions),
     as some = implementations and access networks may limit the 
     number of EAP packet exchanges that can = be handled.
     Document = operational recommendations or other mitigation
     strategies to avoid issues.

   In all of the above, it is a = requirement that none of the updates
   break= backwards compatibility with existing specifications or
   implementations. The current RFCs shall not = be obsoleted but
   rather updated with = either new information or instructions on
   what is needed, for instance, to employ a = new TLS version.

   The = working group is expected to stay in close collaboration with
   the EAP deployment community, the TLS = working group (for EAP-TLS
   work), and = the 3GPP security architecture group (for EAP-AKA'
   work).

Milestones:

  =  TBD
= --Apple-Mail=_CC79E4B7-6C58-4523-AA80-626EDDF15132-- From nobody Mon Jan 22 06:53:11 2018 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 CD23A127342 for ; Mon, 22 Jan 2018 06:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 AFDCfshzgf9N for ; Mon, 22 Jan 2018 06:53:08 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 CAC1C1200E5 for ; Mon, 22 Jan 2018 06:53:07 -0800 (PST) Received: from [192.168.91.213] ([97.105.200.130]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M1msU-1exlaV0iwE-00tnR4 for ; Mon, 22 Jan 2018 15:53:05 +0100 References: <96b5a963-ecf5-c9a5-6514-a515460de420@gmx.net> To: saag From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Forwarded-Message-Id: <96b5a963-ecf5-c9a5-6514-a515460de420@gmx.net> Message-ID: <971e9d8c-cc30-cf3d-1ffa-ea0d3ff21888@gmx.net> Date: Mon, 22 Jan 2018 15:53:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <96b5a963-ecf5-c9a5-6514-a515460de420@gmx.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:O09USliLwF2IRwmDA72lzG5D5faOswxIwwjimdtkU6hzPw3IQq8 CTnSMu6eSfZvuffQlwUn9V/L5+82IddgIMxk8WsQUifoYf/wBWJnXHE7q8brA3H5sU3sFN3 SSuRZb3M7yAz4dx3++h5pvh/suMhDNZssYmDNjZVggEGifY2TGiyilfLOdkE7pmf7qlWRT5 EHoWwk0wvIHwqwdK9adjw== X-UI-Out-Filterresults: notjunk:1;V01:K0:K7J6YKg4KPw=:kUkFdV+T2q021jdARDLtY8 Jy11pF2pCUr52vxl8HlIqmXL+yphWHEVueCor8LxptH15rCAOTQkHM80oFan1EZSK+RG1zMR6 JJrvXhh1mMBM3doil1eZArZIkHw20gAMZZtc6gwxLjAIcI4dZBQIdw0UDIXB0Zq0EV5guD1es MfsBjJKFyvgsOEsE+4BBrG3HDrccI04reX/8dbxiyAq5HFMCvAxLA4fStYXcCXWU0KLv+4lt7 NoyXDTJ28lixID4GqBLqakr4CzI+dm7zqoX77GlWYigZRKQIcie198+M2GgJo1wUcJYWEY6O0 ZqC6ogbwcaZCxPepkTtG0g7GOq8o5BRieYtw5WAMs9iPaXDkJ7jesyVyb/VizovZFcnQPUX8X 5OGguc0jr9dzHRNSKnXOOIRepzhvcIqJd+ICaniPR0L5J8vV1OM458qEq6WLfddeisAEm5M7g U6yW7zX283vc73ciugqMzumWMkpzCuHGr9/N+XKBCkxXPe2ol49udeqK6R0/xjRuFlWMuSr8A ECE3rxyRCMXVKOGdRgRksYRmXne4Nx+bH/IREYo3hRxOZSzsYOz/xcuYAiKNo8RcUCe5DI0hD an/oo7TiB12pYXlI+6smLc6YDdQHTYTfQCoE0BnFJ28TSLSQYBWlw7jdh925+azUe4by2JUAW HIvWdByVGBoTgQl1ZsBgVU9WV+oMTTw00fSFl2RuPcASRzkCUYYpxNGU818roNzZbbrMItgKs KHxb6OLoeaAVjK8QEL67aCkQqrxzbNb1xW73TzDIlVRw1BJKWNeNPvfDAdnd2JOOkGLZ+daXA OYUAVDlZmTJXD05blOVwRULu9hK3pzYLpfPpoiNlQKZgxJYuWA= Archived-At: Subject: [saag] Fwd: Application Transport LAyer Security (ATLAS) 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, 22 Jan 2018 14:53:10 -0000 FYI: You could be interested in this effort that touches on TLS, end-to-end security, and also IoT. -------- Forwarded Message -------- Subject: Application Transport LAyer Security (ATLAS) Date: Mon, 22 Jan 2018 15:52:07 +0100 From: Hannes Tschofenig To: Hi all, around the last IETF meeting we had a good discussion on the list regarding application layer TLS, as proposed in draft-friel-tls-over-http-00 and various other drafts. For the next IETF meeting we are planning to request a BOF to have a dedicated timeslot allocated. For upfront discussions we have created a new mailing list, see https://www.ietf.org/mailman/listinfo/atlas We are planning to distribute a strawman charter proposal to that list in the next few days. Ciao Hannes