From nobody Tue Oct 6 14:24:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517E71B333C for ; Tue, 6 Oct 2015 14:24:35 -0700 (PDT) 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 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 PDBD3SDCUkvV for ; Tue, 6 Oct 2015 14:24:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9391B3373 for ; Tue, 6 Oct 2015 14:24:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9AAB9BE35; Tue, 6 Oct 2015 22:24:32 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fIZNhmTPH91; Tue, 6 Oct 2015 22:24:31 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.26.211]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 83E5EBE2F; Tue, 6 Oct 2015 22:24:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444166671; bh=04PhU9PEvCJ33zrlGMrxAoInw0MCmA0SUbJG0MyPv2g=; h=To:Cc:Reply-To:From:Subject:Date:From; b=RlHTPLj/+i0f6RHDM2MPRXWNbHB5n0S4fPkbnk2KZczUQOboru0e5OF71qhaFGPwm 7ILpF4dggiQ9uj1Hf983aJM26xemjsuTvd0kr0lW/l1lULmCiV7IWaGil3S+0HRACM O1TfyUK59zg+XXF9ZCpGeRhDkpsYH8ucASolgb+M= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <56143C0E.9030807@cs.tcd.ie> Date: Tue, 6 Oct 2015 22:24:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Subject: [saag] Anyone up to review draft-rescorla-tcpinc-tls-option-04 in the next week or so? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "tcpinc@ietf.org" List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 21:24:35 -0000 Hiya, The TCPINC WG have been having a hard time in picking an approach to take with two reasonable proposals on the table. [1,2] The tcpcrypt draft [2] has been around for a while and has had a good bit of review so its content is fairly well understood. The idea of the TLS approach has also been around for a while, but the nitty-gritty details are really only documented in [1] in the current revision. The chair of TCPINC intends to try again to poll the WG about adopting drafts in the relatively near future and has asked if we can get some security folks to review [1] in the next week or so. What's being asked for here is a review of the content of [1] and *not an analysis of [1] vs. [2]*. The WG have probably seen all of the arguments there already, so the ask now is really just to get some more eyeballs on the content of [1] before the WG consider adopting a draft (again;-). So, if one or two of you could please do a review of [1] in the next week or so and post that to the TCPINC mailing list (which believe it or not is tcpinc@ietf.org:-), that'd be great. If you know TLS (esp the ongoing work on TLS1.3) and TCP it ought not be much work to do that. Aside from that, fresh voices or arguments in the [1] vs. [2] debate are of course also always welcome on the WG list, but please do check the WG archive to see if an argument is really fresh - most of the pros and cons have already been aired I think. Thanks in advance, S. [1] https://tools.ietf.org/html/draft-rescorla-tcpinc-tls-option-04 [2] https://tools.ietf.org/html/draft-bittau-tcpinc-tcpcrypt-03 From nobody Tue Oct 6 23:26:41 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC871AD357 for ; Tue, 6 Oct 2015 23:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjG6pxs2Jf7W for ; Tue, 6 Oct 2015 23:26:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CE21AD35F for ; Tue, 6 Oct 2015 23:26:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39A47BE35 for ; Wed, 7 Oct 2015 07:26:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtrqeJyBZYTA for ; Wed, 7 Oct 2015 07:26:34 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.26.211]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B8BD8BE2F for ; Wed, 7 Oct 2015 07:26:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444199194; bh=PiFdMgik1NgqwLoONyvLj05q9GRL8VFURWrm5yLxmQE=; h=Subject:References:To:From:Date:In-Reply-To:From; b=unBwSbG/AjpDY9cQodVEurdTOQYQhloF3FwqtJTZT9kcyJHuNOQjrrs+OoFy1GJ0K vYZDalv4vVmMmnkhj8I1n4jNWiVUD663qnIjx52ipoo3v/W3KfQq8nY00abgJxjYtU +5PP1OO5Z6h3tXGc4FRgdO96FLWKKQf3drKmOszE= References: To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: Message-ID: <5614BB19.50503@cs.tcd.ie> Date: Wed, 7 Oct 2015 07:26:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4Rj8fpbf9SdB87HKs195eAxoH80p7kE7U" Archived-At: Subject: [saag] Fwd: [IRTF-Announce] Deadline in 3 weeks! Call for Nominations: 2016 Applied Networking Research Prize (ANRP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 06:26:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4Rj8fpbf9SdB87HKs195eAxoH80p7kE7U Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks, Can you consider nominating good IETF-relevant papers you've read in the last year? This is a great way to get some academics along to an IETF meeting who'd otherwise not come or not have funds to come. If nominating, so long as the paper is identified it'll get handled properly, so don't worry too much about all the info you are asked to supply. (And there's an email backup if like me you're allergic to javascript and new account signups:-) But please do take a moment to nominate something good you've seen - the ANRP talks on security/privacy that've happened in the past have I think lead to some useful contacts and follow on work. Cheers, S. -------- Forwarded Message -------- Subject: [IRTF-Announce] Deadline in 3 weeks! Call for Nominations: 2016 Applied Networking Research Prize (ANRP) Date: Wed, 7 Oct 2015 04:03:05 +0000 From: Eggert, Lars Reply-To: anrp@irtf.org To: anrp@irtf.org CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2016 http://irtf.org/anrp ******************************************************************** *** Submit nominations for the 2016 award period of the *** *** Applied Networking Research Prize until October 31, 2015! *** *** *** *** (Please share this announcement with your colleagues.) *** ******************************************************************** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recent results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: =E2=80=A2 cash prize of $500 (USD) =E2=80=A2 invited talk at the IRTF Open Meeting =E2=80=A2 travel grant to attend a week-long IETF meeting (airfare, hotel= , registration, stipend) =E2=80=A2 recognition at the IETF plenary =E2=80=A2 invitation to related social activities =E2=80=A2 potential for additional travel grants to future IETF meetings,= based on community feedback The Applied Networking Research Prize will be awarded once per calendar year. Each year, several winners will be chosen and invited to present their work at one of the three IETF meetings during the year. HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, original journal, conference or workshop paper they authored, which was recently published or accepted for publication. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one=E2=80=99s o= wn paper) and third-party nominations (nominating someone else=E2=80=99s pap= er) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year=E2=80=99s IETF meetings in person and in its entirety. Nominations must include: =E2=80=A2 the name and email address of the nominee =E2=80=A2 a bibliographic reference to the published (or accepted) nominated paper =E2=80=A2 a PDF copy of the nominated paper =E2=80=A2 a statement that describes how the nominated paper fulfills the= goals of the award =E2=80=A2 a statement about which of the year=E2=80=99s IETF meetings the= nominee would be available to attend in person and in its entirety =E2=80=A2 a brief biography or CV of the nominee =E2=80=A2 optionally, any other supporting information (link to nominee=E2= =80=99s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2016/. In exceptional cases, nominations may also be submitted by email to anrp@irtf.org. IMPORTANT DATES Applications close: October 31, 2015 (hard) Notifications: December 1, 2015 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2016-flyer.pdf --4Rj8fpbf9SdB87HKs195eAxoH80p7kE7U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWFLsZAAoJEC88hzaAX42iW+gH/2NiVI2nE+4Lp7DwIeR0xKEG SzlM2E51Ek3TqrzWGSpX6qbJNuY6mSE2FyFsNV/VsvQ3/dILrrsemJJlUm7LBVts gSycVPzb90twhD4N+nD/PL/dyIu6lia0/Ih0rJfRaZUzPz+DE2XYjtbSCshgJVOR PvKixBdVK4gcCoK5IaBUrGqQUtSMo2jTicvkW6DRRFsCaAzOOR+R4feXclME0JA9 N5qpfbz37x0AzyQNPVEyIU0pT/k+rWW7keA62x0lWT8GeJxcIOmAIC3vGiuEYlwq 0Lc4kFbYL6DTTi+gH6YJ0A9FGxTPs+P9H0Gj3J/DLgXp7TaRNHc6D5ha1hP9FSM= =vVTj -----END PGP SIGNATURE----- --4Rj8fpbf9SdB87HKs195eAxoH80p7kE7U-- From nobody Thu Oct 8 08:37:48 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE7E1A9076 for ; Thu, 8 Oct 2015 08:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnIIyjlyMMmf for ; Thu, 8 Oct 2015 08:37:44 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.148]) (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 68E891A9072 for ; Thu, 8 Oct 2015 08:37:44 -0700 (PDT) Received: from [85.158.139.163] by server-12.bemta-5.messagelabs.com id 90/71-19220-6CD86165; Thu, 08 Oct 2015 15:37:42 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-7.tower-188.messagelabs.com!1444318661!22251897!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27477 invoked from network); 8 Oct 2015 15:37:41 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-7.tower-188.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Oct 2015 15:37:41 -0000 Received: from mailint03.vodafone.com (mailint03.vodafone.com [195.232.244.200]) by mailout04.vodafone.com (Postfix) with ESMTP id 3nWxVs46P6znTYX for ; Thu, 8 Oct 2015 17:37:41 +0200 (CEST) Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailint03.vodafone.com (Postfix) with ESMTP id 3nWxVs396xz16J9f for ; Thu, 8 Oct 2015 17:37:41 +0200 (CEST) Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 3nWxVs369Xz16J5c for ; Thu, 8 Oct 2015 17:37:41 +0200 (CEST) Received: from VOEXM18W.internal.vodafone.com ([169.254.2.125]) by VOEXC02W.internal.vodafone.com ([145.230.101.22]) with mapi id 14.03.0224.002; Thu, 8 Oct 2015 17:37:41 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "saag@ietf.org" Thread-Topic: [saag] feedback for draft-mm-wg-effect-encrypt Thread-Index: AdEB3L2IVB4bc+CARb+CJn/cEegD/Q== Date: Thu, 8 Oct 2015 15:37:39 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] feedback for draft-mm-wg-effect-encrypt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 15:37:47 -0000 Hi Kathleen, As discussed at MaRNEW[1] , here are two sections of draft-smith-encrypted-= traffic-management-03[2] which can be added to 'Effect of Ubiquitous Encryp= tion' [3] . Once agreed, I can remove the same text from [2] and simply po= int to the relevant section in [3]; and hence [2] will focus on solutions t= o persist traffic management for encrypted traffic (whilst maintaining priv= acy/security).=20 Many thanks Kevin [1] https://www.iab.org/activities/workshops/marnew/=20 [2] http://tools.ietf.org/html/draft-smith-encrypted-traffic-management-03= =20 [3] https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/=20 --------------------------------------------------------------------------- Additions for draft-mm-wg-effect-encrypt --------------------------------------------------------------------------- {for section 2.1: new sub-section} Access and policy enforcement Server load balancing Where network load balancers have been configured to route according to application-layer semantics, an encrypted payload is effectively invisible. This has resulted in practices of intercepting TLS in front of load balancers to regain that visibility, but at a cost to security and privacy. Network access Approved access to a network is a prerequisite to requests for Internet traffic - hence network access, including any authentication and authorisation, is not impacted encryption.=20 Cellular networks often sell tariffs that allow free-data access to certain sites, known as 'zero rating'. A session to visit such a site incurs no additional cost or data usage to the user. This feature may be impacted if encryption hides the domain from the network. =20 Regulation and policy enforcement =20 Mobile networks (and usually ISPs) operate under the regulations of thei= r=20 licencing government authority. These regulations include Lawful Interce= pt,=20 adherence to Codes of Practice on content filtering, and application of = court order filters. =20 These functions are impacted by encryption, typically by allowing a less granular means of implementation. The enforcement of any Net Neutrality regulations is unlikely to be affected by content being encrypted. SPAM and malware filtering This has typically required full access to application data to filter various keywords, fraudulent headers and virus attachments. =20 =20 {New top level section}=20 =20 Flow information visible to a network IP 5-tuple This indicates source and destination IP addresses/ports and the transport protocol. This information is available during TLS, TCP- layer encryption (except ports), and IP-layer encryption (IPSec); although it may be obscured in Tunnel mode IPSec. This allows network management at a coarse IP-source level, which makes it of limited value where the origin server supports a blend of service types. TLS Server Name Indication When initiating the TLS handshake, the Client may provide an extension field (server_name) which indicates the server to which it is attempting a secure connection. TLS SNI was standardized in 2003 to enable servers to present the "correct TLS certificate" to clients in a deployment of multiple virtual servers hosted by the same server infrastructure and IP-address. Although this is an optional extension, it is today supported by all modern browsers, web servers and developer libraries. Notable exceptions are Android 2.2 and Internet Explorer 6 on Windows XP. It should be noted that HTTP/2 introduces the Alt-SVC method for upgrading the connection from HTTP/1 to either unencrypted or encrypted HTTP/2. If the initial HTTP/1 request is unencrypted, the destination alternate service name can be identified before the communication is potentially upgraded to encrypted HTTP/2 transport. HTTP/2 implementations MUST support the Server Name Indication (SNI) extension. This information is only visible if the client is populating the Server Name Indication extension. This need not be done, but may be done as per TLS standard. Therefore, even if existing network filters look out for seeing a Server Name Indication extension, they may not find one. The per-domain nature of SNI may not reveal the specific service or media type being accessed, especially where the domain is of a provider offering a range of email, video, Web pages etc. For example, certain blog or social network feeds may be deemed 'adult content', but the Server Name Indication will only indicate the server domain rather than a URL path to be blocked. Application Layer Protocol Negotiation (ALPN) ALPN is a TLS extension which may be used to indicate the application protocol within the TLS session. This is likely to be of more value to the network where it indicates a protocol dedicated to a particular traffic type (such as video streaming) rather than a multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will not indicate the traffic types which may make up streams within an HTTP/2 multiplex. =20 Content length, bitrate and pacing =20 The content length of encrypted traffic is effectively the same as=20 the cleartext. Although block ciphers utilise padding this makes a=20 negligible difference. Bitrate and pacing are generally application specific, and do not change when the content is encrypted. Multiplexed=20 formats (such as HTTP/2 and QUIC) may however incorporate several applic= ation streams over one connection, which makes the bitrate/pacing no longer applicatio= n-specific. =20 =20 =20 =20 =20 From nobody Fri Oct 9 02:50:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9FC1A0338 for ; Fri, 9 Oct 2015 02:50:09 -0700 (PDT) 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 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 lzmZ-bQ00-Nd for ; Fri, 9 Oct 2015 02:50:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217431A0318 for ; Fri, 9 Oct 2015 02:50:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC793BE59 for ; Fri, 9 Oct 2015 10:50:06 +0100 (IST) 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 2e_s3kcZJ_p7 for ; Fri, 9 Oct 2015 10:50:06 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D4EE7BE4D for ; Fri, 9 Oct 2015 10:50:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444384206; bh=MvMfnlTytQfSOycB+Fqr4kzhhMFZe497odB9EI7hDJ0=; h=Subject:References:To:From:Date:In-Reply-To:From; b=sq5iDkpK5GShdTnK19bMIW9hvwqKdhD8uS96ZaLmE8v5oM0b4sz7VxoNiW90QrxAN /T80uDtXcDHeRYhG0Kiy4VnDhEH5FvAL1MTB1/5OVvpnwIH/ybJs7CAsm1jCd8ANQm 3r5d3M12R741QAuNyWPHAwUTJ/C7ZR3Y+xh9vuiI= References: <5616DE2A.6060508@cs.tcd.ie> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <5616DE2A.6060508@cs.tcd.ie> Message-ID: <56178DCA.60709@cs.tcd.ie> Date: Fri, 9 Oct 2015 10:50:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5616DE2A.6060508@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Fwd: [TLS] TRON workshop X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 09:50:10 -0000 FYI -------- Forwarded Message -------- Subject: [TLS] TRON workshop Date: Thu, 8 Oct 2015 22:20:42 +0100 From: Stephen Farrell To: tls@ietf.org Hiya, First, thanks all for all your ongoing work on TLS1.3. I'm sure we're all aware that this is important stuff that needs to be, and is being, done carefully with due attention to security analysis. Early in the process we had some brief discussion of pausing towards the end of the work to give folks a chance to do analyses of the security and other properties of TLS1.3 just before publication of the RFC. Chatting with the chairs in Prague and with various others since, we think we've reached the point where we need to start executing that bit of the plan, since doing such analyses also takes time and we don't want to add a big delay if we can avoid it. So we're organising a workshop on just that topic to be co-located with NDSS in San Diego in late February 2016. The call for papers is at [1], please read that and circulate to folks who you think could produce useful analyses that can help the WG get an even higher quality TLS1.3 out the door. I'm sure some of you will be wondering about invites to this workshop etc. We'll have to see how many submissions we get and the level of interest and figure out logistics etc closer to time, but this clearly does need a bunch of folks in the room who are important contributors to the WG but who won't be submitting papers. I'll work with the workshop programme committee and the WG chairs to figure out how best to handle that, via invites, remote access if possible etc. More on that as we figure it out. (Feel free to send me and/or the WG chairs your thoughts and offers for help on that.) And just to clarify a possible process question - this workshop will provide input - we're hoping that'll be very high quality input but the normal WG consensus process will be used to process that input in all the usual ways. Think of TRON as being a mega-big design team on steroids if that helps. (Lousy imagery, I know:-) If the workshop indicates that TLS1.3 is fine then that's fairly obviously great, if there are significant new issues identified though, those will need to be brought to this list, and to meetings at IETF95, for resolution via our normal process. Cheers, S. [1] https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-papers _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Oct 9 06:25:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07761B3DDE for ; Fri, 9 Oct 2015 06:25:47 -0700 (PDT) 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 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 5ANc7DoUyWCN for ; Fri, 9 Oct 2015 06:25:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0991B3DB6 for ; Fri, 9 Oct 2015 06:25:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 20928BE59 for ; Fri, 9 Oct 2015 14:25:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV4MS28PHxwr for ; Fri, 9 Oct 2015 14:25:41 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.26.211]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5D0EEBDD0 for ; Fri, 9 Oct 2015 14:25:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444397141; bh=2mmjzH5u05xZYaXWP9F2U7wdPCTlgRXFHmi2L0VCAIA=; h=To:From:Subject:Date:From; b=o4bD+Bl9yhQuGu77rYs2bN02JJreRJCoU0S3jS6icrDN3Or27sIkyO1i6ZVxUYjNQ EwWcSeacH1Zod9UAWz6D/hrYmn/EFW7noBWNC0NmS4u40+ctnI4UGJJL8D3SSuy0hf w6MJP4SitrgSJzZ1U1NobWgwi7NlxnJC4SuxWXDo= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5617C054.1070207@cs.tcd.ie> Date: Fri, 9 Oct 2015 14:25:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] sha1 - have we more work to do? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 13:25:48 -0000 Hiya, While it may be still under submission, and not yet peer reviewed, I was just looking at [1,2] and wondered if we've still work to do to deprecate sha1 anywhere that we've not yet done. I know a lot of this was done already but just wanted to check that we're good. Anyone know places where sha1 is still a should or must or where it's still in widespread use despite no longer being a should or must? (No need to mention root stores in browser for that last though, as that's a known issue and is I think already being tackled by browser makers.) I guess we can make a list and then figure out what to do if the list is non-empty. Cheers, S. [1] https://sites.google.com/site/itstheshappening/ [2] https://sites.google.com/site/itstheshappening/shappening_article.pdf From nobody Fri Oct 9 07:07:56 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF3F1B3FAE for ; Fri, 9 Oct 2015 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imvwc-dsf0-L for ; Fri, 9 Oct 2015 07:07:53 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0C21B3FAD for ; Fri, 9 Oct 2015 07:07:53 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so72127563wic.1 for ; Fri, 09 Oct 2015 07:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kDYV7isnzuv7hasYNYyEQWwM7clEBBiFAcyB1FwH8iI=; b=krACdHrYqeZb3c88zFsFfuJAQafgc18nXPJPZSCDqropA/MTZooDDPqHFlPJLZA4L8 qsyoa7P1UqXnbkryE5/7NnLgUpJuxd/AgPg25Z+rAr2Bp6pzsPwD+NQByv4ZFx+iVTSm X7PZAhjif8VeDLlGFy0fwZWk775sVi0L6C5K9Cg7lZrWh0XAG87hBzA/2mQfXD+Psdlo 9FNKHTC4JI5SFuHzzLOwMaxZ+5uWgza2OtvgOqYAH4P9mvXCh4XF5l0wlZQxZF888RqP r9N3hxCx450LYuLU0dqLKM4KdOHgD3WkjnK4elUB8zIM3hvPOwP+z9NF4a9OVx0lPQ2d mFIA== X-Received: by 10.180.24.33 with SMTP id r1mr4190547wif.7.1444399672161; Fri, 09 Oct 2015 07:07:52 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id bk4sm2371006wjc.1.2015.10.09.07.07.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Oct 2015 07:07:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <5617C054.1070207@cs.tcd.ie> Date: Fri, 9 Oct 2015 17:07:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5617C054.1070207@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] sha1 - have we more work to do? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 14:07:55 -0000 > On Oct 9, 2015, at 4:25 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > While it may be still under submission, and not yet peer reviewed, > I was just looking at [1,2] and wondered if we've still work to do > to deprecate sha1 anywhere that we've not yet done. I know a lot > of this was done already but just wanted to check that we're good. >=20 > Anyone know places where sha1 is still a should or must or where it's > still in widespread use despite no longer being a should or must? > (No need to mention root stores in browser for that last though, as > that's a known issue and is I think already being tackled by browser > makers.) >=20 > I guess we can make a list and then figure out what to do if the > list is non-empty. - SHA-1 is used less and less in signatures, but HMAC-SHA1 is still = very=20 widespread, although it is not supposed to be affected by collision=20= attacks. - IKE (RFC 7296) has a few places where SHA-1 is a non-negotiated MUST: - NAT detection works by sending SHA-1 hashes of the IP addresses and IKE ports. Considering that for IPv4 there are only 2^32 possible=20= inputs to the hash function, I don=E2=80=99t think it matters which = function is used. - The hash&URL certificate encoding relies on SHA-1 hashes. An = attacker=20 could MITM the HTTP connection and provide a bad certificate if = they=20 could create a 2nd pre-image certificate that is properly signed. - The Certificate Request payload has SHA-1 hashes of the SPKIs in = the certification authority certificates. Yoav= From nobody Fri Oct 9 17:19:59 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796781B29BE for ; Fri, 9 Oct 2015 17:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agpvi3l7u3GU for ; Fri, 9 Oct 2015 17:19:55 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3061B29B7 for ; Fri, 9 Oct 2015 17:19:53 -0700 (PDT) X-AuditID: 1209190f-f799c6d000001933-a6-561859a80549 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 73.0A.06451.8A958165; Fri, 9 Oct 2015 20:19:52 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t9A0JpRD026610; Fri, 9 Oct 2015 20:19:51 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t9A0JlY7025113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Oct 2015 20:19:50 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t9A0JltK019726; Fri, 9 Oct 2015 20:19:47 -0400 (EDT) Date: Fri, 9 Oct 2015 20:19:46 -0400 (EDT) From: Benjamin Kaduk To: Yoav Nir In-Reply-To: Message-ID: References: <5617C054.1070207@cs.tcd.ie> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT110RKRFmcOs+v8WU/k4mi+l7r7Fb LD32gcmB2WNt91U2j52z7rJ7LFnykymAOYrLJiU1J7MstUjfLoErY/qSGSwF35kr7u8sbGDs Ye5i5OSQEDCR6Fl+gBXCFpO4cG89WxcjF4eQwGImiZPvL7KBJIQENjBKLLvPC5E4yCTR9nMR E0SiXqL9wyx2EJtFQEti6cxDYDabgIrEzDcbwZpFBJQkDl/5CraNWSBN4sXKa2A1wgLGEt8u XAKLcwrYSnz50gRWzyvgKPG2bTkrxPxIidW3d4DFRQV0JFbvn8ICUSMocXLmExaImVoSy6dv Y5nAKDgLSWoWktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFuiZ6uZkleqkppZsYQaHLKcm/ g/HbQaVDjAIcjEo8vB/cJMKEWBPLiitzDzFKcjApifLmhgCF+JLyUyozEosz4otKc1KLDzFK cDArifA+1QXK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8DZGADUK FqWmp1akZeaUIKSZODhBhvMADS8FqeEtLkjMLc5Mh8ifYtTlWPDj9lomIZa8/LxUKXFeO5Ai AZCijNI8uDnglLObSfUVozjQW8K8RSBVPMB0BTfpFdASJqAlOfxiIEtKEhFSUg2MsyxSEsSu X6id833Pti07nsz40BJl2FYvtF7Ze25DmKxWeKnzzJ/3W3v2Cnzi0G1+YfIyVrg6Y6ut25Lm OUxhTAuOtgd/CVdKT93EOmHZSh6DruSKskmtwcUV/bM3fU5xkHa479PJ/1BgnYZ/WF5VxMIP +xf1dtrWtGk23mf9ySvSu2U1wywlluKMREMt5qLiRADriuXTFAMAAA== Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] sha1 - have we more work to do? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2015 00:19:57 -0000 On Fri, 9 Oct 2015, Yoav Nir wrote: > > - SHA-1 is used less and less in signatures, but HMAC-SHA1 is still very > widespread, although it is not supposed to be affected by collision > attacks. Indeed, HMAC-SHA1 (truncated to 96 bit, sigh) is used by the only Kerberos encryption types you should be using if you do not deal with Japanese government organizations. (There are people still using arcfour-hmac, triple-des, and yes even single-des, but we're working on that.) -Ben From nobody Mon Oct 12 08:10:38 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3ED1A6F61 for ; Mon, 12 Oct 2015 08:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 0p0MoTUSlO-o for ; Mon, 12 Oct 2015 08:10:36 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0641A6F60 for ; Mon, 12 Oct 2015 08:10:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 50285E2036; Mon, 12 Oct 2015 11:10:34 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10485-08; Mon, 12 Oct 2015 11:10:31 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C2F7DE2034; Mon, 12 Oct 2015 11:10:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1444662630; bh=cCokin8Lx4NgehhE95q38fgTBwDp1vmsPVAy0rlkxf0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=do71v70tf5MxnwYnAvUokV8T8mIDCpuEAVQOQ0JqVHB7urVO3AFbsodGJ9T6YQgLN UXDrynFHmiLrmUadFekScMPT3eiDysxgE36QwQftUofLkkOhT9fmoA14AUeQOZlSwe RrPnQjg/J+giLS8IDcbz3jquX7GltyqXi2TLmcrI= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t9CFAUxc011787; Mon, 12 Oct 2015 11:10:30 -0400 From: Derek Atkins To: Stephen Farrell References: <5617C054.1070207@cs.tcd.ie> Date: Mon, 12 Oct 2015 11:10:29 -0400 In-Reply-To: <5617C054.1070207@cs.tcd.ie> (Stephen Farrell's message of "Fri, 9 Oct 2015 14:25:40 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] sha1 - have we more work to do? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 15:10:37 -0000 Hi, Stephen Farrell writes: > Hiya, > > While it may be still under submission, and not yet peer reviewed, > I was just looking at [1,2] and wondered if we've still work to do > to deprecate sha1 anywhere that we've not yet done. I know a lot > of this was done already but just wanted to check that we're good. > > Anyone know places where sha1 is still a should or must or where it's > still in widespread use despite no longer being a should or must? > (No need to mention root stores in browser for that last though, as > that's a known issue and is I think already being tackled by browser > makers.) > > I guess we can make a list and then figure out what to do if the > list is non-empty. > > Cheers, > S. > > [1] https://sites.google.com/site/itstheshappening/ > [2] https://sites.google.com/site/itstheshappening/shappening_article.pdf OpenPGP (RFC4880) still uses SHA-1 for its key fingerprints. However, it's using the SHA1 preimage resistance and not the SHA1 collision resistance. So even though finding collisions in SHA1 appears to be getting easier, preimage attacks seem still out of reach. But it'll probably be easier to change to a new hash algorithm in a V5 key than it would be to educate everyone on why the way 4880 uses SHA1 isn't vulnerable to these "new" SHA1 attacks. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Oct 14 05:02:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69DE1A1B1C for ; Wed, 14 Oct 2015 05:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 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 UnJbOar5lWKV for ; Wed, 14 Oct 2015 05:02:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF761A1B1D for ; Wed, 14 Oct 2015 05:02:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 72665BEB6 for ; Wed, 14 Oct 2015 13:01:59 +0100 (IST) 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 I0fnrMEJeS2e for ; Wed, 14 Oct 2015 13:01:59 +0100 (IST) Received: from [134.226.62.192] (cswireless62-192.scss.tcd.ie [134.226.62.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 85A43BEE9 for ; Wed, 14 Oct 2015 13:01:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444824096; bh=NJsMLPm3YaniBQoNUsSdivo1TnL8b6hOiCgRykR41Yg=; h=From:Subject:To:Date:From; b=OB2Ak2/Xvs06sjjAMWKVgl1NvXJU8/cmWMhCXeXEKSsI7gqGMiPHpxBC/60aKdj+V hDYTxgVlS9s2bt8HI9VfrwUdxozyPY3HfRK+Fbv+as6E2TlvJ7NiN8Bp+VrBCvux4o 1u5tsSVwHHrHpycKLZLJJYCJjLW0Xhd3Bntilc5M= From: Stephen Farrell To: "saag@ietf.org" Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <561E441E.50309@cs.tcd.ie> Date: Wed, 14 Oct 2015 13:01:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] apologies - a survey X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 12:02:08 -0000 (This is without any hat, except an apologetic one:-) For various reasons a project I'm involved with has to do a quick survey [1] that has 5 questions asking about web security. I'm told that the results will be fed into a process that'll eventually end up shaping where the European commission spend research funding. I doubt this survey will influence anything at all very much, but who knows and some answers to these few questions could help provide validation for some recommendations our project is making to the commission. (Or they could invalidate those.) If you do this kind of thing, thanks in advance. Cheers, S. [1] https://www.surveymonkey.com/r/CW8L62P From nobody Wed Oct 14 05:14:02 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB7B1A1B72 for ; Wed, 14 Oct 2015 05:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h27sdhFvp3Sc for ; Wed, 14 Oct 2015 05:13:58 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E2A1A1B4B for ; Wed, 14 Oct 2015 05:13:58 -0700 (PDT) Received: by oihr205 with SMTP id r205so26406784oih.3 for ; Wed, 14 Oct 2015 05:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QuxHug6yMXw459/aCqusFrTim1EOKnsIBw4utCHkwGM=; b=HxwR/3ybLfYS0rBWZZ1eb0VWvOIdx8A2UI33Az09voCNnVRzc9JSml98GreJu7O2g4 3sKfWyx9CxofyPc2WjTILrwAnj1+QQDQhJN/dv7d3K61y9245u2cX3FYhGKsmteeS54V Q5LLM5JneKnP7dxfpz238GTF94Z2C0+JayMUyEdRihhcFkmbJjMdhtaYVlkepFGdJLcs N79TnBD26XD0huM1E9AwXvp/9V9Fer6GNl7gYEsKxlovb0SWEjhLhXxkD9O7X6RwNYJF m6m2MKl0u8xZXJjEzUae7Tb+Ck61VQeCievfrMdR4ftaS8l+5iRHPyPRQ4fFntXeUBhO pjKg== X-Received: by 10.202.174.80 with SMTP id x77mr1499797oie.50.1444824838075; Wed, 14 Oct 2015 05:13:58 -0700 (PDT) Received: from macbook-pro.attlocal.net (99-64-100-131.lightspeed.austtx.sbcglobal.net. [99.64.100.131]) by smtp.gmail.com with ESMTPSA id ol4sm3951368oeb.8.2015.10.14.05.13.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Oct 2015 05:13:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Adam Montville In-Reply-To: <561E441E.50309@cs.tcd.ie> Date: Wed, 14 Oct 2015 07:13:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1BD567B6-2C2A-4B1F-92D3-A104D2C13E50@gmail.com> References: <561E441E.50309@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] apologies - a survey X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 12:14:00 -0000 Should we assume survey results will, at some point, become publicly = available? Can we repost the link, if it makes sense? > On Oct 14, 2015, at 7:01 AM, Stephen Farrell = wrote: >=20 >=20 > (This is without any hat, except an apologetic one:-) >=20 > For various reasons a project I'm involved with has to do a quick > survey [1] that has 5 questions asking about web security. I'm told > that the results will be fed into a process that'll eventually end > up shaping where the European commission spend research funding. I > doubt this survey will influence anything at all very much, but who > knows and some answers to these few questions could help provide > validation for some recommendations our project is making to the > commission. (Or they could invalidate those.) >=20 > If you do this kind of thing, thanks in advance. >=20 > Cheers, > S. >=20 > [1] https://www.surveymonkey.com/r/CW8L62P >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Oct 14 05:20:47 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEC91A1B8A for ; Wed, 14 Oct 2015 05:20:44 -0700 (PDT) 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 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 PYS8ZIJMK7aW for ; Wed, 14 Oct 2015 05:20:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87751A1B8B for ; Wed, 14 Oct 2015 05:20:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F1BEBEA1; Wed, 14 Oct 2015 13:20:41 +0100 (IST) 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 6Rt83dLf-zbz; Wed, 14 Oct 2015 13:20:41 +0100 (IST) Received: from [134.226.62.192] (cswireless62-192.scss.tcd.ie [134.226.62.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E9E80BE77; Wed, 14 Oct 2015 13:20:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444825241; bh=qQbMCCQj2CofKIDR78J0Zzze+985CEorAA6ZfOz6mzs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=VfGSEQYssGdKSGgwIG878kHWmreB5gbTGWs0mh7Q05Nxvm3p9ka2GnWVJFB4yGhsn KbfVzHXJrqxXy0xQ+CA0InpOkeKn7ahrzvluyJfEcrvBXZJXXbqM2BdKxvu1tvafV0 uLtGdsr4pXzuXO7VuqnTVZjXyGZkHaATtaFJNbmY= To: Adam Montville References: <561E441E.50309@cs.tcd.ie> <1BD567B6-2C2A-4B1F-92D3-A104D2C13E50@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <561E4898.6050001@cs.tcd.ie> Date: Wed, 14 Oct 2015 13:20:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1BD567B6-2C2A-4B1F-92D3-A104D2C13E50@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] apologies - a survey X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 12:20:45 -0000 On 14/10/15 13:13, Adam Montville wrote: > Should we assume survey results will, at some point, become publicly available? Good question for which I should've found out the answer before posting;-) Checking now. S > > Can we repost the link, if it makes sense? > >> On Oct 14, 2015, at 7:01 AM, Stephen Farrell wrote: >> >> >> (This is without any hat, except an apologetic one:-) >> >> For various reasons a project I'm involved with has to do a quick >> survey [1] that has 5 questions asking about web security. I'm told >> that the results will be fed into a process that'll eventually end >> up shaping where the European commission spend research funding. I >> doubt this survey will influence anything at all very much, but who >> knows and some answers to these few questions could help provide >> validation for some recommendations our project is making to the >> commission. (Or they could invalidate those.) >> >> If you do this kind of thing, thanks in advance. >> >> Cheers, >> S. >> >> [1] https://www.surveymonkey.com/r/CW8L62P >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > From nobody Wed Oct 14 08:05:05 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8941A1A92B6 for ; Wed, 14 Oct 2015 08:04:59 -0700 (PDT) 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 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 lJji3pSzmZKz for ; Wed, 14 Oct 2015 08:04:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ACF31A92E0 for ; Wed, 14 Oct 2015 08:04:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D0E17BEA1; Wed, 14 Oct 2015 16:04:56 +0100 (IST) 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 b-nvBkc4I_1A; Wed, 14 Oct 2015 16:04:56 +0100 (IST) Received: from [134.226.62.192] (cswireless62-192.scss.tcd.ie [134.226.62.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14ACDBE9A; Wed, 14 Oct 2015 16:04:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444835096; bh=k2efzfmRsPnFTTIbC7bel9d0YELeZ79t/MAqEWF3heI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pmlx07j7uh6surP1faWUvU1U0RqQCtAvIOYE0uRfRRwRx3WWz9RHsKYHvLP+KSodV hoIyApuKEwy8lOBDgCc27RQeqsihsNYJ1gYIZkKhyQPGpEmTRmT73NnfvPTlgWkTHn /kZPQW8H8IKduEifM1oM0p9yofOzIK/ojbhO5XE4= To: Adam Montville References: <561E441E.50309@cs.tcd.ie> <1BD567B6-2C2A-4B1F-92D3-A104D2C13E50@gmail.com> <561E4898.6050001@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <561E6F17.8040904@cs.tcd.ie> Date: Wed, 14 Oct 2015 16:04:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <561E4898.6050001@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] apologies - a survey X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 15:04:59 -0000 On 14/10/15 13:20, Stephen Farrell wrote: > > > On 14/10/15 13:13, Adam Montville wrote: >> Should we assume survey results will, at some point, become publicly available? > > Good question for which I should've found out the answer before > posting;-) Checking now. Apparently, anonymised versions of the non-nonsense answers will be put up on the project web site if there are enough of those. I'll send a mail here when that happens. (Personally, I'm not at all sure there'll be many answers, but I guess we'll see;-) Cheers, S. > > S > >> >> Can we repost the link, if it makes sense? >> >>> On Oct 14, 2015, at 7:01 AM, Stephen Farrell wrote: >>> >>> >>> (This is without any hat, except an apologetic one:-) >>> >>> For various reasons a project I'm involved with has to do a quick >>> survey [1] that has 5 questions asking about web security. I'm told >>> that the results will be fed into a process that'll eventually end >>> up shaping where the European commission spend research funding. I >>> doubt this survey will influence anything at all very much, but who >>> knows and some answers to these few questions could help provide >>> validation for some recommendations our project is making to the >>> commission. (Or they could invalidate those.) >>> >>> If you do this kind of thing, thanks in advance. >>> >>> Cheers, >>> S. >>> >>> [1] https://www.surveymonkey.com/r/CW8L62P >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> >> > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Thu Oct 15 03:56:34 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901F01B2A4E for ; Thu, 15 Oct 2015 03:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkM4u2xdDahI for ; Thu, 15 Oct 2015 03:56:31 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3501B2A34 for ; Thu, 15 Oct 2015 03:56:30 -0700 (PDT) Received: by wicll6 with SMTP id ll6so34914740wic.0 for ; Thu, 15 Oct 2015 03:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wVlNhWF+enKcQ3jfGKkYeLUvrZEfVZVyhXqYjdll7rc=; b=yRk5PVS7IZr1697W/L4awajZwG+U8bv1GMEnISRaEj9LBsHfkqkpVW3sllm6cnq7Hz h67NC+tYwmtBpNIp0KuwgWWg9lReaReVXDiaDJkxv1/pjR3c2M4Yd+xkTNpgEQlYzqX0 UoAeVrLnHJxLmGbevrQJWdmMQ3G5XnqYjqdSBKnyno/fwWyoo0PDDlXRMWOK4VIIJlho 9iVaxMxBmXlv8vc6flc7azVS5+CvOfmRV9De5z9Fm3M+k7D6vLeX3wEqpRdy9h1R9Zwy 31aCh/BqGwCZ2SP+S2KLWGaAUU1E7HOmN1lzmGMyqPAqWIFKxakOnSzkhh9rRHAOE41l FocQ== MIME-Version: 1.0 X-Received: by 10.180.186.10 with SMTP id fg10mr10317921wic.30.1444906589140; Thu, 15 Oct 2015 03:56:29 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Thu, 15 Oct 2015 03:56:29 -0700 (PDT) Date: Thu, 15 Oct 2015 06:56:29 -0400 Message-ID: From: Watson Ladd To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Retire 1024 bit DH X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 10:56:32 -0000 Dear all, Most attack papers use uncomfortably round numbers in time estimates. Unfortunately estimates of 1024 prime field discrete logarithm times made a second mistake, relying on sieving and ignoring the possibility of dedicated hardware for finding smooth factors. In addition there is a potential to batch the relation gathering in the number field sieve across multiple primes. These estimates have been done by Bernstein and Lange for RSA in [1] but I believe that their methods can be extended to the discrete log problem trivially. Furthermore, precomputation techniques can make this attack almost realtime. As a result we should assume that all data protected by 1024 bit Diffie-Hellman are readable by a nation state attacker today. Sincerely, Watson [1] http://cr.yp.to/factorization/batchnfs-20141109.pdf From nobody Thu Oct 15 04:02:21 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0877E1B2AAF for ; Thu, 15 Oct 2015 04:02:20 -0700 (PDT) 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 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 isWCbuukL7Od for ; Thu, 15 Oct 2015 04:02:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2921B2AAC for ; Thu, 15 Oct 2015 04:02:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 29AC9BE83; Thu, 15 Oct 2015 12:02:15 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHTsQDKTx6hT; Thu, 15 Oct 2015 12:02:12 +0100 (IST) Received: from [10.87.48.91] (unknown [86.42.17.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 26EF3BEAF; Thu, 15 Oct 2015 12:02:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1444906930; bh=MRGsW8i5oJV9E/VirQgiTl4KTVAKcmPJJ3qVAk/5Fd0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=H+/r4jmmT8cAL4EP+5HirQhCAzTlGquyYT2JHYr55soObGQ7r0LeKbZojhcyGeyGU SsFzun4RQNJvCvOJ0md5CrWcUbIu3us9V3QSxaGrrmTQgAvgABOFlaAOoLu7DhpgoE VbOtBWZy67vhJp6+suzneGTbJ7tY0x4isOVpQCk0= To: Watson Ladd , "saag@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <561F87AF.7040004@cs.tcd.ie> Date: Thu, 15 Oct 2015 12:02:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] Retire 1024 bit DH X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:02:20 -0000 Seems reasonable and might even help some folks transition away from tools that still have that restriction if those aren't all fixed already. (Not sure.) I'd be interested in opinions as to whether it'd be useful for this to be processed as a BCP or what, and if so, if someone's willing to volunteer to do the editing work. (Let me know offlist for the latter.) S. On 15/10/15 11:56, Watson Ladd wrote: > Dear all, > Most attack papers use uncomfortably round numbers in time estimates. > Unfortunately estimates of 1024 prime field discrete logarithm times > made a second mistake, relying on sieving and ignoring the possibility > of dedicated hardware for finding smooth factors. In addition there is > a potential to batch the relation gathering in the number field sieve > across multiple primes. > > These estimates have been done by Bernstein and Lange for RSA in [1] > but I believe that their methods can be extended to the discrete log > problem trivially. Furthermore, precomputation techniques can make > this attack almost realtime. As a result we should assume that all > data protected by 1024 bit Diffie-Hellman are readable by a nation > state attacker today. > > Sincerely, > Watson > > [1] http://cr.yp.to/factorization/batchnfs-20141109.pdf > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Thu Oct 15 04:15:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4771B2B1C for ; Thu, 15 Oct 2015 04:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSzCQRRn68TX for ; Thu, 15 Oct 2015 04:15:03 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673351B2AF6 for ; Thu, 15 Oct 2015 04:15:03 -0700 (PDT) Received: by wicll6 with SMTP id ll6so35599410wic.0 for ; Thu, 15 Oct 2015 04:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:in-reply-to:references :content-type; bh=TLK5xBcoU42gbyPYuI5/ofCV1jfYErxEpDt19kMh3GE=; b=r/6T8gwTEAyYTnFIy9P29MyQEX6Zbig5tO7YMz7DJjk5kLNyChi1Ae8Wl6G5gFQxK+ wFjC16TJd+9f7MQiXqM0d5mu+ILNi9jqUnhLBCtmHyH4YgWg/bcF7Uel11lJf3iSIwZQ fQfgsEDC958lH335LJl0daCqbHjX6M9+4Tjbhrf37sRp3MpQfHcTlSJfsM6GPT2gj99M AjzVJlMvFKiCRUjFKERFnfKqaODxFk1vWJdXGLaO8Lq1xsvHupwHKpUyXmsAkAHJVBta tddFk/RNhTkLQfFFY57EpvJCuKkQkyLKDSLYEzf7o3u+wGijdTfjOb1GRDNjywix/0HQ qHlg== X-Received: by 10.194.21.163 with SMTP id w3mr10064712wje.70.1444907702042; Thu, 15 Oct 2015 04:15:02 -0700 (PDT) Received: from [10.128.25.236] ([176.13.1.208]) by smtp.gmail.com with ESMTPSA id gd10sm15839990wjb.47.2015.10.15.04.14.59 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 15 Oct 2015 04:15:00 -0700 (PDT) Message-ID: <561f8ab4.6a68c20a.a317f.2512@mx.google.com> MIME-Version: 1.0 To: Stephen Farrell , Watson Ladd , "saag@ietf.org" From: Yoav Nir Date: Thu, 15 Oct 2015 14:15:00 +0300 In-Reply-To: <561F87AF.7040004@cs.tcd.ie> References: <561F87AF.7040004@cs.tcd.ie> Content-Type: multipart/alternative; boundary="_7DE8CA84-EC36-4880-A5E5-8702EB4009D7_" Archived-At: Subject: Re: [saag] Retire 1024 bit DH X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:15:06 -0000 --_7DE8CA84-EC36-4880-A5E5-8702EB4009D7_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Both TLS and IPsecME are retiring 1024-bit DH. TLS is not including it in 1= .3, and at IPsecME we're revving 4307 to make it a SHOULD NOT at least. Regards, Yoav Sent from my Windows Phone=20 -----Original Message----- From: "Stephen Farrell" Sent: =E2=80=8E10/=E2=80=8E15/=E2=80=8E2015 14:02 To: "Watson Ladd" ; "saag@ietf.org" Subject: Re: [saag] Retire 1024 bit DH Seems reasonable and might even help some folks transition away from tools that still have that restriction if those aren't all fixed already. (Not sure.) I'd be interested in opinions as to whether it'd be useful for this to be processed as a BCP or what, and if so, if someone's willing to volunteer to do the editing work. (Let me know offlist for the latter.) S. On 15/10/15 11:56, Watson Ladd wrote: > Dear all, > Most attack papers use uncomfortably round numbers in time estimates. > Unfortunately estimates of 1024 prime field discrete logarithm times > made a second mistake, relying on sieving and ignoring the possibility > of dedicated hardware for finding smooth factors. In addition there is > a potential to batch the relation gathering in the number field sieve > across multiple primes. >=20 > These estimates have been done by Bernstein and Lange for RSA in [1] > but I believe that their methods can be extended to the discrete log > problem trivially. Furthermore, precomputation techniques can make > this attack almost realtime. As a result we should assume that all > data protected by 1024 bit Diffie-Hellman are readable by a nation > state attacker today. >=20 > Sincerely, > Watson >=20 > [1] http://cr.yp.to/factorization/batchnfs-20141109.pdf >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_7DE8CA84-EC36-4880-A5E5-8702EB4009D7_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Both TLS and IPsecME are retiring 1024-bit DH. TLS is not= including it in 1.3, and at IPsecME we're revving 4307 to make it a SHOULD= NOT at least.

Regards,

Yoav

Sent from my Windows Phon= e
From: Stephen Farrell
Sent: =E2=80=8E10/= =E2=80=8E15/=E2=80=8E2015 14:02
To: Watson Ladd; saag= @ietf.org
Subject: Re: [saag] Retire 1024 bit DH


Seems reasonable and might even help some folks transit= ion away from
tools that still have that restriction if those aren't all= fixed
already. (Not sure.)

I'd be interested in opinions as to w= hether it'd be useful for this
to be processed as a BCP or what, and if = so, if someone's willing to
volunteer to do the editing work. (Let me kn= ow offlist for the latter.)

S.


On 15/10/15 11:56, Watson = Ladd wrote:
> Dear all,
> Most attack papers use uncomfortably = round numbers in time estimates.
> Unfortunately estimates of 1024 pr= ime field discrete logarithm times
> made a second mistake, relying o= n sieving and ignoring the possibility
> of dedicated hardware for fi= nding smooth factors. In addition there is
> a potential to batch the= relation gathering in the number field sieve
> across multiple prime= s.
>
> These estimates have been done by Bernstein and Lange f= or RSA in [1]
> but I believe that their methods can be extended to t= he discrete log
> problem trivially. Furthermore, precomputation tech= niques can make
> this attack almost realtime. As a result we should = assume that all
> data protected by 1024 bit Diffie-Hellman are reada= ble by a nation
> state attacker today.
>
> Sincerely,> Watson
>
> [1] http://cr.yp.to/factorization/batchnfs-2= 0141109.pdf
>
> ______________________________________________= _
> saag mailing list
> saag@ietf.org
> https://www.ietf.= org/mailman/listinfo/saag
>

_________________________________= ______________
saag mailing list
saag@ietf.org
https://www.ietf.or= g/mailman/listinfo/saag
= --_7DE8CA84-EC36-4880-A5E5-8702EB4009D7_-- From nobody Thu Oct 15 04:35:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87141B2A5F for ; Thu, 15 Oct 2015 04:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnGxBMnXKynj for ; Thu, 15 Oct 2015 04:35:43 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD831B2A59 for ; Thu, 15 Oct 2015 04:35:42 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so268210632wic.1 for ; Thu, 15 Oct 2015 04:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=k5bFeKMWT7jhKIT3Y657FuHm9WCHyjRc9ykacGLKDh4=; b=g42A1mwkpTMzjd6oSQX5y3HUVzR/UBdfcomxtebNDWHsIlyyMM7c2D3H1H5+fiES+5 f+x1z4Xv/1b7pRdgvDVFka8XlI6liN7BigMXF+0CuJ7/ede7+uqzyJkXCwIQABVPqlvQ C/IXsOYY6jcRO7bby6JIRhg6gzR2OU7B5jViohRdLD+6MMuUUMtDOjnuLB5jhgCAarwK 1sIvvC3yWzOHqyDWVhNiDIHcJZbOcfuSMCc2NlJWC0qwmF8rNvprdlRKFvF+K6ItJm1c qa9yxkXkGjyR43G1thwiRH0+SGKup332GLGWtVyfBLdNrgecyf2Drt7xQ5sDAAwmclp+ xNXw== MIME-Version: 1.0 X-Received: by 10.194.19.169 with SMTP id g9mr9751276wje.64.1444908941370; Thu, 15 Oct 2015 04:35:41 -0700 (PDT) Received: by 10.28.51.145 with HTTP; Thu, 15 Oct 2015 04:35:41 -0700 (PDT) In-Reply-To: <561f8ab4.6a68c20a.a317f.2512@mx.google.com> References: <561F87AF.7040004@cs.tcd.ie> <561f8ab4.6a68c20a.a317f.2512@mx.google.com> Date: Thu, 15 Oct 2015 07:35:41 -0400 Message-ID: From: Watson Ladd To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Retire 1024 bit DH X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:35:44 -0000 On Thu, Oct 15, 2015 at 7:15 AM, Yoav Nir wrote: > Both TLS and IPsecME are retiring 1024-bit DH. TLS is not including it in > 1.3, and at IPsecME we're revving 4307 to make it a SHOULD NOT at least. I think we still need a BCP for several reasons: -New versions and crypto fixes take years to be deployed (see BEAST). A BCP tells (the few who read them) systems administrators and users what they can do now. -Lots of protocols will have problems here, and in some cases (SSH) there is no WG handling it anymore. Even if protocols have other options, they may require administrative action to deploy. -We're seeing real world exploitation, as with IKE v1 aggressive mode (where we know exactly what the NSA is doing. No surprise, it's been known for years) I'd volunteer to write it, but for some reason (me!) the other drafts I've at one point tried to write have been languishing on my hard drive for months. > > Regards, > > Yoav > > Sent from my Windows Phone > ________________________________ > From: Stephen Farrell > Sent: =E2=80=8E10/=E2=80=8E15/=E2=80=8E2015 14:02 > To: Watson Ladd; saag@ietf.org > Subject: Re: [saag] Retire 1024 bit DH > > > Seems reasonable and might even help some folks transition away from > tools that still have that restriction if those aren't all fixed > already. (Not sure.) > > I'd be interested in opinions as to whether it'd be useful for this > to be processed as a BCP or what, and if so, if someone's willing to > volunteer to do the editing work. (Let me know offlist for the latter.) > > S. > > > On 15/10/15 11:56, Watson Ladd wrote: >> Dear all, >> Most attack papers use uncomfortably round numbers in time estimates. >> Unfortunately estimates of 1024 prime field discrete logarithm times >> made a second mistake, relying on sieving and ignoring the possibility >> of dedicated hardware for finding smooth factors. In addition there is >> a potential to batch the relation gathering in the number field sieve >> across multiple primes. >> >> These estimates have been done by Bernstein and Lange for RSA in [1] >> but I believe that their methods can be extended to the discrete log >> problem trivially. Furthermore, precomputation techniques can make >> this attack almost realtime. As a result we should assume that all >> data protected by 1024 bit Diffie-Hellman are readable by a nation >> state attacker today. >> >> Sincerely, >> Watson >> >> [1] http://cr.yp.to/factorization/batchnfs-20141109.pdf >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Oct 15 04:42:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E741A011B for ; Thu, 15 Oct 2015 04:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDGhMMpJVbxO for ; Thu, 15 Oct 2015 04:42:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::791]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5305D1A00FD for ; Thu, 15 Oct 2015 04:42:23 -0700 (PDT) Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.293.16; Thu, 15 Oct 2015 11:42:04 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0293.007; Thu, 15 Oct 2015 11:42:04 +0000 From: "Dang, Quynh" To: Watson Ladd , Yoav Nir Thread-Topic: [saag] Retire 1024 bit DH Thread-Index: AQHRBzgvLkABKDk350KZ+uQyBkIKy55sY2yAgAADmQCAAAXIgIAAAWF2 Date: Thu, 15 Oct 2015 11:42:03 +0000 Message-ID: References: <561F87AF.7040004@cs.tcd.ie> <561f8ab4.6a68c20a.a317f.2512@mx.google.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [129.6.225.178] x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:a0v/sIK9MoZOBWmZ/Th9DoexJqXUh60WG7x7T704GXzz+bxQnQzuy4NrRdKeUZ54DKJOgUmZEj/QFjUEYr7mAoaKAcX+JHO/8C7ulgPrDCfMc6EfYiEx+rR85QOZwHmVztkXs0izMTIs1OGvlfaDDg==; 24:hFWbZwdgkZ8LW6NgsomCnLWODA0kXFsbo4SoFC7e/k2UhpnK0bhyW+kaEV6B7D0efE3QnyysjQ+W1hMe2s+lqFjcthUqwLNHQQf7jjh8jfA=; 20:QFrp2DA3vfm5+b4l9KRUdbJO3B4RrkXFBrr6DWf/RsVo4gIfcJEibeYP/dcX8n41tem6UIV/ppCfO9BLLEE3pg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(202767206196957); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(199003)(43544003)(479174004)(189002)(243025005)(10400500002)(87936001)(76176999)(77096005)(5001960100002)(19580405001)(5002640100001)(11100500001)(74316001)(15975445007)(5001770100001)(106356001)(33656002)(19580395003)(105586002)(81156007)(122556002)(101416001)(93886004)(99286002)(50986999)(102836002)(106116001)(5008740100001)(54356999)(97736004)(5007970100001)(2950100001)(76576001)(5003600100002)(64706001)(2900100001)(92566002)(189998001)(46102003)(5004730100002)(66066001)(40100003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 11:42:03.8712 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Retire 1024 bit DH X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 11:42:26 -0000 This would be a very good item to take care of. Quynh.=20 ________________________________________ From: saag on behalf of Watson Ladd Sent: Thursday, October 15, 2015 7:35 AM To: Yoav Nir Cc: saag@ietf.org Subject: Re: [saag] Retire 1024 bit DH On Thu, Oct 15, 2015 at 7:15 AM, Yoav Nir wrote: > Both TLS and IPsecME are retiring 1024-bit DH. TLS is not including it in > 1.3, and at IPsecME we're revving 4307 to make it a SHOULD NOT at least. I think we still need a BCP for several reasons: -New versions and crypto fixes take years to be deployed (see BEAST). A BCP tells (the few who read them) systems administrators and users what they can do now. -Lots of protocols will have problems here, and in some cases (SSH) there is no WG handling it anymore. Even if protocols have other options, they may require administrative action to deploy. -We're seeing real world exploitation, as with IKE v1 aggressive mode (where we know exactly what the NSA is doing. No surprise, it's been known for years) I'd volunteer to write it, but for some reason (me!) the other drafts I've at one point tried to write have been languishing on my hard drive for months. > > Regards, > > Yoav > > Sent from my Windows Phone > ________________________________ > From: Stephen Farrell > Sent: =FD10/=FD15/=FD2015 14:02 > To: Watson Ladd; saag@ietf.org > Subject: Re: [saag] Retire 1024 bit DH > > > Seems reasonable and might even help some folks transition away from > tools that still have that restriction if those aren't all fixed > already. (Not sure.) > > I'd be interested in opinions as to whether it'd be useful for this > to be processed as a BCP or what, and if so, if someone's willing to > volunteer to do the editing work. (Let me know offlist for the latter.) > > S. > > > On 15/10/15 11:56, Watson Ladd wrote: >> Dear all, >> Most attack papers use uncomfortably round numbers in time estimates. >> Unfortunately estimates of 1024 prime field discrete logarithm times >> made a second mistake, relying on sieving and ignoring the possibility >> of dedicated hardware for finding smooth factors. In addition there is >> a potential to batch the relation gathering in the number field sieve >> across multiple primes. >> >> These estimates have been done by Bernstein and Lange for RSA in [1] >> but I believe that their methods can be extended to the discrete log >> problem trivially. Furthermore, precomputation techniques can make >> this attack almost realtime. As a result we should assume that all >> data protected by 1024 bit Diffie-Hellman are readable by a nation >> state attacker today. >> >> Sincerely, >> Watson >> >> [1] http://cr.yp.to/factorization/batchnfs-20141109.pdf >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Thu Oct 15 05:41:41 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4B21A1B47 for ; Thu, 15 Oct 2015 05:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 N3cyP72IoPlM for ; Thu, 15 Oct 2015 05:41:38 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880101A1B2A for ; Thu, 15 Oct 2015 05:41:38 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-92-561f3eb88716 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9F.FF.32596.8BE3F165; Thu, 15 Oct 2015 07:50:48 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 08:41:36 -0400 From: Daniel Migault To: "Dang, Quynh" , Watson Ladd , Yoav Nir Thread-Topic: [saag] Retire 1024 bit DH Thread-Index: AQHRBzgr5K1hRBzeXU2Jc6qLCvetsp5spnqAgAADmgCAAAXHgIAAAceA///LF7A= Date: Thu, 15 Oct 2015 12:41:35 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C11216DD3B@eusaamb107.ericsson.se> References: <561F87AF.7040004@cs.tcd.ie> <561f8ab4.6a68c20a.a317f.2512@mx.google.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPgu4OO/kwg8/XFCzOPlvPZjGlv5PJ oqfzJJvF0mMfmBxYPHbOusvusWTJTyaPayf/sgYwR3HZpKTmZJalFunbJXBlzHj2iL1ggkLF v2dHWRoY50h1MXJySAiYSEy4NZEZwhaTuHBvPVsXIxeHkMBRRonNu16yQzjLGSUmTbzBBlLF JmAk0Xaonx3EFhHIk7jZvIkVxGYWUJZ4++cJE4gtLKAmcWbZSiaIGnWJxqUbgWwOINtPYnm3 JUiYRUBVYtnrk4wgNq+Ar8T3FYcZIXZtZZL4Mn0SM0g9p0C0xIJziiA1jEDHfT+1hglilbjE rSfzmSCOFpBYsuc81AOiEi8f/2OFsJUk5ry+xgxRbyBxbvtGdghbW2LZwtfMEHsFJU7OfMIy gVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UYGmxiBMXRMgk13B+Oel5aHGAU4GJV4eBVm yIUJsSaWFVfmHmKU5mBREufdv+R+qJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGHsb1zKkq jj9eL5vSIHRo1bSvbw/k53N4/w/lL5op3PHN/vLTM47G+2+4dv//F5Ni+UMrQt8lnPXW+jP3 Zj56NiPHV2xNwgPDhRf+H/MQZJro/kzUckr0/X8TNr85OoOxpCHGt8Hx1DdGqUinPvsP5gUz vxotUjjEHcF/T+SOz5v+7XNqTqxpVmIpzkg01GIuKk4EANaBj+eCAgAA Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Retire 1024 bit DH X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 12:41:40 -0000 Hi,=20 This would be good to clearly have that statement, which could would make a= ll protocols start their own cleanup. One other reason I think this documen= t would be useful for is that it would make everyone aware that crypto prot= ocols are evolving, and that deployment must consider their config will be = updated overtime. =20 BR,=20 Daniel -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Dang, Quynh Sent: Thursday, October 15, 2015 7:42 AM To: Watson Ladd; Yoav Nir Cc: saag@ietf.org Subject: Re: [saag] Retire 1024 bit DH This would be a very good item to take care of. Quynh.=20 ________________________________________ From: saag on behalf of Watson Ladd Sent: Thursday, October 15, 2015 7:35 AM To: Yoav Nir Cc: saag@ietf.org Subject: Re: [saag] Retire 1024 bit DH On Thu, Oct 15, 2015 at 7:15 AM, Yoav Nir wrote: > Both TLS and IPsecME are retiring 1024-bit DH. TLS is not including it=20 > in 1.3, and at IPsecME we're revving 4307 to make it a SHOULD NOT at leas= t. I think we still need a BCP for several reasons: -New versions and crypto fixes take years to be deployed (see BEAST). A BCP tells (the few who read them) systems administrators and users what t= hey can do now. -Lots of protocols will have problems here, and in some cases (SSH) there i= s no WG handling it anymore. Even if protocols have other options, they may= require administrative action to deploy. -We're seeing real world exploitation, as with IKE v1 aggressive mode (wher= e we know exactly what the NSA is doing. No surprise, it's been known for y= ears) I'd volunteer to write it, but for some reason (me!) the other drafts I've = at one point tried to write have been languishing on my hard drive for mont= hs. > > Regards, > > Yoav > > Sent from my Windows Phone > ________________________________ > From: Stephen Farrell > Sent: =FD10/=FD15/=FD2015 14:02 > To: Watson Ladd; saag@ietf.org > Subject: Re: [saag] Retire 1024 bit DH > > > Seems reasonable and might even help some folks transition away from=20 > tools that still have that restriction if those aren't all fixed=20 > already. (Not sure.) > > I'd be interested in opinions as to whether it'd be useful for this to=20 > be processed as a BCP or what, and if so, if someone's willing to=20 > volunteer to do the editing work. (Let me know offlist for the=20 > latter.) > > S. > > > On 15/10/15 11:56, Watson Ladd wrote: >> Dear all, >> Most attack papers use uncomfortably round numbers in time estimates. >> Unfortunately estimates of 1024 prime field discrete logarithm times=20 >> made a second mistake, relying on sieving and ignoring the=20 >> possibility of dedicated hardware for finding smooth factors. In=20 >> addition there is a potential to batch the relation gathering in the=20 >> number field sieve across multiple primes. >> >> These estimates have been done by Bernstein and Lange for RSA in [1]=20 >> but I believe that their methods can be extended to the discrete log=20 >> problem trivially. Furthermore, precomputation techniques can make=20 >> this attack almost realtime. As a result we should assume that all=20 >> data protected by 1024 bit Diffie-Hellman are readable by a nation=20 >> state attacker today. >> >> Sincerely, >> Watson >> >> [1] http://cr.yp.to/factorization/batchnfs-20141109.pdf >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Thu Oct 15 10:33:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDBF1ACEE8 for ; Thu, 15 Oct 2015 10:33:26 -0700 (PDT) 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfscan-Gc0hO for ; Thu, 15 Oct 2015 10:33:24 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF4BC1ACECD for ; Thu, 15 Oct 2015 10:33:24 -0700 (PDT) X-AuditID: d80ac3f1-f79fd6d0000022fa-d4-561fe364cf97 Received: from tus1opsmtapin01.ges.symantec.com (uscu-zone.relay.symantec.com [192.168.214.43]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id BD.17.08954.463EF165; Thu, 15 Oct 2015 18:33:24 +0100 (BST) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1ZmmP6-0001bH-29 for saag@ietf.org; Thu, 15 Oct 2015 17:33:24 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Thu, 15 Oct 2015 10:32:10 -0700 From: Rick Andrews To: "saag@ietf.org" Date: Thu, 15 Oct 2015 10:33:23 -0700 Thread-Topic: sha1 - have we more work to do? Thread-Index: AdEHblz9JocChklwR4Chrb4eagGLcQ== Message-ID: <544B0DD62A64C1448B2DA253C011414619276B8B23@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B4_01D10734.EA9DD0C0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsVyYMU1bd2Ux/JhBie2cVhM6e9kcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuc7YQWTvSr2PD7M0sC4162LkZNDQsBE4tumTiYIW0ziwr31 bF2MXBxCAm8YJa7tnskO4fxjlHh/YiUThLOKUaLp+Bx2kBY2AT2JLY+vgNkiAsoSy/88B7NZ BFQlJlz7zAJiCwvoSpw6PJe1i5EDqEZP4l5jJIx54JERSAWvQJTEtXP7wY5gBDri+6k1YDaz gLjErSfzoY4TkXh48TQbhC0q8fLxP1aIelGJO+3rGUFOYxboZZR49rWBGWKooMTJmU9YJjAK z0IyaxayullI6mYB3cQMdFPbRkaIenmJ7W/nMEPY1hIzfh1kg7AVJaZ0P2SHsE0lXh/9yLiA kWMVo0xJabFhcW5JfmlJQWqFgaFecWVuIjCakvWS83M3MQIj6gbX4Y87GI/udTzEKMDBqMTD 63FPPkyINbEMqPIQowrQuEcbVl9glGLJy89LVRLh7asCSvOmJFZWpRblxxeV5qQWH2KU5mBR EucVznoVKiSQnliSmp2aWpBaBJNl4uCUamDsrqu9sEPp7SWPr98Ygnwf8znlzpkdrbD9Nlft EVvO9P8s2262L/2n5hwbNHO9TJPPWdX05LR0XWH+H/bvMh1llwgZ+9ss/fdYRI7b19frRnie dNFco/kGm+Y6dnPcUJtv9dz5hUnNgoUFbs4Ziz+tVDJqVV98LqeooO/Pju9pp1c7SksvtVdi Kc5INNRiLipOBAAZN6EbsAIAAA== Archived-At: Subject: Re: [saag] sha1 - have we more work to do? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:33:26 -0000 ------=_NextPart_000_00B4_01D10734.EA9DD0C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephen, OCSP (RFC 6960) mandates SHA-1 for KeyHash, though the risk of using it here is probably very low. --------------- Message: 2 Date: Fri, 9 Oct 2015 14:25:40 +0100 From: Stephen Farrell To: "saag@ietf.org" Subject: [saag] sha1 - have we more work to do? Message-ID: <5617C054.1070207@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Hiya, While it may be still under submission, and not yet peer reviewed, I was just looking at [1,2] and wondered if we've still work to do to deprecate sha1 anywhere that we've not yet done. I know a lot of this was done already but just wanted to check that we're good. Anyone know places where sha1 is still a should or must or where it's still in widespread use despite no longer being a should or must? (No need to mention root stores in browser for that last though, as that's a known issue and is I think already being tackled by browser makers.) I guess we can make a list and then figure out what to do if the list is non-empty. Cheers, S. [1] https://sites.google.com/site/itstheshappening/ [2] https://sites.google.com/site/itstheshappening/shappening_article.pdf ------------------------------ ------=_NextPart_000_00B4_01D10734.EA9DD0C0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRhzCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBkwwggU0oAMCAQICEBw3Lcu5cD5rtz7z+tELQgYwDQYJ KoZIhvcNAQELBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTE1MDEwNjAw MDAwMFoXDTI1MDEwNTIzNTk1OVowgbAxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFu dGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALbX9Fd7nt9wUT7ISGRoQMGJbj8EkkrtHHQnINo4z1KTPLnRWscXLT5oTmFpC7JuaHn0AnYK +NJutht+e0vGtU/avfhJDgLP7K1qZ+vOBHm9hMzzmiME1s9CP0nOlifrJK5h2TS5Znq8g4kfGJTA asB5zmfjNVCJomx17jhf8fuZrvMXSBsWDxl6NGohZloUgxFAwrCe0NuDzt8E8jJCgw5lewsqjlll eBvJbCxOXhcuMvjK6/ilNC1WjkaIlTWXyaraGQAMPm2nsZED4+aBNRMX855Amtk5zAoKh1oeIiN7 2YaPVmiIIOeGKqY0B3RYTY7cmxgU4RA5xgKA3LeMIP0CAwEAAaOCAkQwggJAMBIGA1UdEwEB/wQI MAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8v d3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t L3JwYTAOBgNVHQ8BAf8EBAMCAQYwNwYIKwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8v cGtpLW9jc3Auc3ltYXV0aC5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL2NybC53cy5zeW1h bnRlYy5jb20vcGNhMi1nMy5jcmwwKAYDVR0RBCEwH6QdMBsxGTAXBgNVBAMTEFN5bWFudGVjUEtJ LTItMjMwHQYDVR0OBBYEFKQzr7DDRoer5XhJsrTiRp/qCfwVMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MA0GCSqG SIb3DQEBCwUAA4IBAQChthp96rPOdkvEEfo4yk4Q8auHf5LqUJUlwDdoAvuCrYDLM9TMQzCwRWf7 IpiGPMAVnddFj2ohiX3bYd0tkaqyjfDJDtZQK9YgN5GD0RTO2gHS0PHOOyJBSDJ5G0um4NLofhkB h9RqEE3mBF68RGe4Te7Z5ST+pvgqGzC8v/2xDEZcClXhch8gNU7muFl18YdX9gWV54BcTj0lo9E9 9/2HVCPB5QAzFhHqgHjDnETpw5S3JlpKTEMXyqaWd/5+Vo+ID+jd51HS+BS1u2Dguv+FvgINTVrr IO1ymEh5L3XM4gQrCgD7yajPRf/BIjyF/xzL/ONUoxd8e1gR/E1N98oyMIIHFjCCBf6gAwIBAgIQ OVrt7EotOiYavftZTf7D7jANBgkqhkiG9w0BAQsFADCBsDELMAkGA1UEBhMCVVMxHTAbBgNVBAoT FFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUw MwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEqMCgG A1UEAxMhU3ltYW50ZWMgQ2xhc3MgMiBFbXBsb3llZSBDQSAtIEczMB4XDTE1MDYwNTAwMDAwMFoX DTE2MDYwNDIzNTk1OVowWDEdMBsGA1UECgwUU3ltYW50ZWMgQ29ycG9yYXRpb24xIDAeBgNVBAsM F1N5bWFudGVjIEVtcGxveWVlIEVtYWlsMRUwEwYDVQQDDAxSaWNrIEFuZHJld3MwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMkzz3/cxC5IPK1PgEVnb2v6HNo5VaRHC5nKGTtKfmdl58 yBdBK4SJwGSIHiQsIgItAQc4mmd7MUIQOxt5RN7dCFMDFzxbSF0nIl1GR52WzN8mgVE9+6oMxDKN 5LOckMEKNH13NF7Ebjz/p0v0JaRHEuzG4w12ah3B8GkBKJn0XDRJjZNq1R/fJJxklUWsQcimw7S5 bb9bGQwCipDGDn1WLaXP1UWDqyP/ja6OYyKY3QFlk1olDk5iZ5XipSiX57euk9FigV4Ddu6gsVaE hQR/mZNcNag1rH/RjcVoox7iTgvKxyBh3VVT2dEX4vebLdt2/rwIgz626XDSTeUmJQ+ZAgMBAAGj ggOBMIIDfTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEF BQcDBDAdBgNVHQ4EFgQUVoVKaC1xEPB9EWKq3dWrwskIufkwJAYDVR0RBB0wG4EZUmlja19BbmRy ZXdzQHN5bWFudGVjLmNvbTAfBgNVHSMEGDAWgBSkM6+ww0aHq+V4SbK04kaf6gn8FTCCAWQGCCsG AQUFBwEBBIIBVjCCAVIwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTCC ASUGCCsGAQUFBzAChoIBF2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIw U3ltYW50ZWMlMjBDbGFzcyUyMDIlMjBFbXBsb3llZSUyMENBJTIwLSUyMEczJTJDJTIwT1UlMjAl M0QlMjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIl MjBDQSUyQyUyME9VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkMlMjBPJTIw JTNEJTIwU3ltYW50ZWMlMjBDb3Jwb3JhdGlvbiUyQyUyMEMlMjAlM0QlMjBVUz9jQUNlcnRpZmlj YXRlO2JpbmFyeTBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9j YV8yYzc5ZDVmMGM0NTZlMGUzZTJmYjNlMjM2OTAzZGExNS9MYXRlc3RDUkwuY3JsMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkP BDUwMzAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAr BgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICAQGdpPp0FgUxNjc0ODA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEB CwUAA4IBAQAXM1lZbwfKyY8FFxOxBuM1zaVaoRHcKD6EjwhcTlIeFQSGl/n24G+1xpy6NIe7Mwzp EAwVUwzb3wKFyKnDMdDvPIedes3QyC1yIjA3ZViOLNpIhWmalth1ohXYFGjjLx7eAq6GJ7oorcJH ZCWOMNr4Nm82UlZ4WoOw1W9mU2ll9R4rfDxsWOImko7O0E9fvozhf4B224DA6cin71gk5rFzzzKC Knjv2lUSpjNuOmlcY2LFOIKPyFzpGKRikO/LwfWVsefhppBSRGKaxfbKS9QP8ex1IcZgGbdCTBzW t9u/tgGv8+qMCn347fdIwO3qFAFgGfJULuFLOvdwqtkJZ8CxMYIEsDCCBKwCAQEwgcUwgbAxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFudGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MwIQOVrt7EotOiYavftZTf7D7jAJBgUrDgMCGgUAoIICvzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEwMTUxNzMzMjJaMCMGCSqGSIb3DQEJBDEWBBTciSxwGe5C iWp9bOGZQpRSfcLAiTCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQME ARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAsGCWCGSAFlAwQCATCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEdMBsG A1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB MSowKAYDVQQDEyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEDla7exKLTomGr37 WU3+w+4wgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNV BAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMSowKAYDVQQD EyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEDla7exKLTomGr37WU3+w+4wDQYJ KoZIhvcNAQEBBQAEggEAl7ztUM25blJnTfP9FpQNLRYwfax6O8Y7l3t4ZIhPWIYrAST+zajlVtO4 ZDpVTyJWRXlP54xJ4gOTBekNzl49YEFtLuM7Kb+VwaLw8mHCcnurf0yUFT5Jr6qiiJaq+qvtjzTP e0OGBoaS8qM7DYLo9TurrH6+GMOFjGULQ0Y4paLk5/3xw941P/yV6GSgSkjJ6t0Co5HJMz6GgBIt y9T8SmvPRJZKGtl/XEyYZSR7cw3NoN5XqEDFl7AyrXefgh3tFBTZEecbgP3U+y1rLLa12WPceBe1 Pu6AjGKqxrYHATx9sNZCC9A3YS2MfIjFfEYkazimu7yvt3Se0dblXE3OjwAAAAAAAA== ------=_NextPart_000_00B4_01D10734.EA9DD0C0-- From nobody Mon Oct 19 13:38:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D072D1ACAD5 for ; Mon, 19 Oct 2015 13:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70ZdHsVGzu8q for ; Mon, 19 Oct 2015 13:38:35 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 E115B1ACCDF for ; Mon, 19 Oct 2015 13:38:31 -0700 (PDT) Received: by qkbl190 with SMTP id l190so31122069qkb.2 for ; Mon, 19 Oct 2015 13:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lo0oH3xb1Qvur6nR82Mtv7l23+8d6bYXjrrf5om12yg=; b=J8N8JvIMQOPHRdnxsv9mcz1sa/jH/sc2uGhkYNSX7xQ/Vx74ofHy9myDoCsLFp+Nen JMIoeZHw6lRlhsSCeOw0TAH6/++7AtGLmCMjniSqz+tBcaJ+GdbS3ESFcv8ECck+O1n+ izPidACq56Nv6eczsChSc+8wYqaGajtpTSLv9TIrdwyrqQIGZ5uMwTDExat+yfxoobjt iKUv0ihxEwMtU7U7k/LT38cQw3YD/klnKDkOc0pcB7YPw7iklf6y7hrpcLuC0Tjo4Rfy 0ogwXDL4fpvl2N/CNRjTlNyAOKCNFwNYz8rFeyOu8iFzWdH94Bl6GpyxQgJiwBWDM9Ql aKIA== MIME-Version: 1.0 X-Received: by 10.194.234.40 with SMTP id ub8mr34568742wjc.95.1445287110922; Mon, 19 Oct 2015 13:38:30 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Mon, 19 Oct 2015 13:38:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2015 16:38:30 -0400 Message-ID: From: Kathleen Moriarty To: "Smith, Kevin, (R&D) Vodafone Group" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" , "MORTON, ALFRED C \(AL\)" Subject: Re: [saag] feedback for draft-mm-wg-effect-encrypt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:38:38 -0000 Hi Kevin, Thanks for your contribution to our draft. We added most of your text, but some overlap of existing text had us leave out a subsection. See inline. On Thu, Oct 8, 2015 at 11:37 AM, Smith, Kevin, (R&D) Vodafone Group wrote: > Hi Kathleen, > > As discussed at MaRNEW[1] , here are two sections of draft-smith-encrypte= d-traffic-management-03[2] which can be added to 'Effect of Ubiquitous Encr= yption' [3] . Once agreed, I can remove the same text from [2] and simply = point to the relevant section in [3]; and hence [2] will focus on solutions= to persist traffic management for encrypted traffic (whilst maintaining pr= ivacy/security). > > Many thanks > Kevin > > [1] https://www.iab.org/activities/workshops/marnew/ > [2] http://tools.ietf.org/html/draft-smith-encrypted-traffic-management-0= 3 > [3] https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ > > -------------------------------------------------------------------------= -- > Additions for draft-mm-wg-effect-encrypt > -------------------------------------------------------------------------= -- > {for section 2.1: new sub-section} Great, thanks for this, a new section was added in 2.1 to cover this helpful information. > > Access and policy enforcement > > Server load balancing > > Where network load balancers have been configured to route according > to application-layer semantics, an encrypted payload is effectively > invisible. This has resulted in practices of intercepting TLS in front > of load balancers to regain that visibility, but at a cost to > security and privacy. > > Network access > > Approved access to a network is a prerequisite to requests for > Internet traffic - hence network access, including any authentication > and authorisation, is not impacted encryption. > > Cellular networks often sell tariffs that allow free-data access to > certain sites, known as 'zero rating'. A session to visit such a > site incurs no additional cost or data usage to the user. This feature > may be impacted if encryption hides the domain from the network. > > Regulation and policy enforcement > > Mobile networks (and usually ISPs) operate under the regulations of th= eir > licencing government authority. These regulations include Lawful Inter= cept, > adherence to Codes of Practice on content filtering, and application o= f court order filters. > These functions are impacted by encryption, typically > by allowing a less granular means of implementation. The enforcement > of any Net Neutrality regulations is unlikely to be affected by > content being encrypted. > > SPAM and malware filtering > > This has typically required full access to application data to filter > various keywords, fraudulent headers and virus attachments. > > > {New top level section} This has been added just after the security monitoring section since both may apply across network types that we used as groupings. > > Flow information visible to a network The word application was added in front of the section header as that made sense once IP 5-tuple was removed. We cover that already in section 3.1.1, which also covers 2-tuple. The 2-tuple and 5-tuple are used in multiple network types, so we may want to think about bumping this to another section. > > IP 5-tuple > > This indicates source and destination IP addresses/ports and the > transport protocol. This information is available during TLS, TCP- > layer encryption (except ports), and IP-layer encryption (IPSec); > although it may be obscured in Tunnel mode IPSec. > > This allows network management at a coarse IP-source level, which > makes it of limited value where the origin server supports a blend of > service types. > Thank you for the rest of the text for this section, it's very helpful. > TLS Server Name Indication > > When initiating the TLS handshake, the Client may provide an > extension field (server_name) which indicates the server to which it > is attempting a secure connection. TLS SNI was standardized in 2003 > to enable servers to present the "correct TLS certificate" to clients > in a deployment of multiple virtual servers hosted by the same server > infrastructure and IP-address. Although this is an optional > extension, it is today supported by all modern browsers, web servers > and developer libraries. Notable exceptions are Android 2.2 and > Internet Explorer 6 on Windows XP. It should be noted that HTTP/2 > introduces the Alt-SVC method for upgrading the connection from > HTTP/1 to either unencrypted or encrypted HTTP/2. If the initial > HTTP/1 request is unencrypted, the destination alternate service name > can be identified before the communication is potentially upgraded to > encrypted HTTP/2 transport. HTTP/2 implementations MUST support the > Server Name Indication (SNI) extension. > > This information is only visible if the client is populating the > Server Name Indication extension. This need not be done, but may be > done as per TLS standard. Therefore, even if existing network > filters look out for seeing a Server Name Indication extension, they > may not find one. The per-domain nature of SNI may not reveal the > specific service or media type being accessed, especially where the > domain is of a provider offering a range of email, video, Web pages > etc. For example, certain blog or social network feeds may be deemed > 'adult content', but the Server Name Indication will only indicate > the server domain rather than a URL path to be blocked. > > Application Layer Protocol Negotiation (ALPN) > > ALPN is a TLS extension which may be used to indicate the application > protocol within the TLS session. This is likely to be of more value > to the network where it indicates a protocol dedicated to a > particular traffic type (such as video streaming) rather than a > multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will > not indicate the traffic types which may make up streams within an > HTTP/2 multiplex. > > Content length, bitrate and pacing > > The content length of encrypted traffic is effectively the same as > the cleartext. Although block ciphers utilise padding this makes a > negligible difference. Bitrate and pacing are generally application > specific, and do not change when the content is encrypted. Multiplexed > formats (such as HTTP/2 and QUIC) may however incorporate several appl= ication streams > over one connection, which makes the bitrate/pacing no longer applicat= ion-specific. > > > Best regards, Kathleen & Al > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 Best regards, Kathleen From nobody Tue Oct 20 03:26:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4D31B3253 for ; Tue, 20 Oct 2015 03:26:43 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0Iy94MvmXK1 for ; Tue, 20 Oct 2015 03:26:41 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.173]) (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 AAA991B324E for ; Tue, 20 Oct 2015 03:26:40 -0700 (PDT) Received: from [85.158.138.179] by server-13.bemta-3.messagelabs.com id FA/A4-00536-ED616265; Tue, 20 Oct 2015 10:26:38 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-13.tower-169.messagelabs.com!1445336797!28590088!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7362 invoked from network); 20 Oct 2015 10:26:37 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-13.tower-169.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Oct 2015 10:26:37 -0000 Received: from mailint03.vodafone.com (mailint03.vodafone.com [195.232.244.200]) by mailout04.vodafone.com (Postfix) with ESMTP id 3ngB2P4S8CznTYd; Tue, 20 Oct 2015 12:26:37 +0200 (CEST) Received: from mailint03.vodafone.com (localhost [127.0.0.1]) by mailint03.vodafone.com (Postfix) with ESMTP id 3ngB2P2S33z16L3g; Tue, 20 Oct 2015 12:26:37 +0200 (CEST) Received: from VOEXC04W.internal.vodafone.com (voexc04w.dc-ratingen.de [145.230.101.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint03.vodafone.com (Postfix) with ESMTPS id 3ngB2P2Kxvz16Kb7; Tue, 20 Oct 2015 12:26:37 +0200 (CEST) Received: from VOEXC20W.internal.vodafone.com (145.230.103.125) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 20 Oct 2015 12:26:36 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.63]) by VOEXC20W.internal.vodafone.com ([145.230.103.125]) with mapi id 14.03.0224.002; Tue, 20 Oct 2015 12:26:36 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: Kathleen Moriarty Thread-Topic: [saag] feedback for draft-mm-wg-effect-encrypt Thread-Index: AdEB3L2IVB4bc+CARb+CJn/cEegD/QIwJwUAACEOPUA= Date: Tue, 20 Oct 2015 10:26:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" , "MORTON, ALFRED C \(AL\)" Subject: Re: [saag] feedback for draft-mm-wg-effect-encrypt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 10:26:43 -0000 SGkgS2F0aGxlZW4gYW5kIEFsLA0KDQpNYW55IHRoYW5rcyEgSSB3aWxsIHVwZGF0ZSB0aGUgTmV0 d29yayBNYW5hZ2VtZW50IEktRCBhY2NvcmRpbmdseSBhbmQgbm90aWZ5IHRoZSBsaXN0Lg0KDQpB bGwgYmVzdCwNCktldmluDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEth dGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb21d IA0KU2VudDogMTkgT2N0b2JlciAyMDE1IDIxOjM5DQpUbzogU21pdGgsIEtldmluLCAoUiZEKSBW b2RhZm9uZSBHcm91cA0KQ2M6IHNhYWdAaWV0Zi5vcmc7IE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0K U3ViamVjdDogUmU6IFtzYWFnXSBmZWVkYmFjayBmb3IgZHJhZnQtbW0td2ctZWZmZWN0LWVuY3J5 cHQNCg0KSGkgS2V2aW4sDQoNClRoYW5rcyBmb3IgeW91ciBjb250cmlidXRpb24gdG8gb3VyIGRy YWZ0LiAgV2UgYWRkZWQgbW9zdCBvZiB5b3VyIHRleHQsIGJ1dCBzb21lIG92ZXJsYXAgb2YgZXhp c3RpbmcgdGV4dCBoYWQgdXMgbGVhdmUgb3V0IGEgc3Vic2VjdGlvbi4NClNlZSBpbmxpbmUuDQoN Ck9uIFRodSwgT2N0IDgsIDIwMTUgYXQgMTE6MzcgQU0sIFNtaXRoLCBLZXZpbiwgKFImRCkgVm9k YWZvbmUgR3JvdXAgPEtldmluLlNtaXRoQHZvZGFmb25lLmNvbT4gd3JvdGU6DQo+IEhpIEthdGhs ZWVuLA0KPg0KPiBBcyBkaXNjdXNzZWQgYXQgTWFSTkVXWzFdICwgaGVyZSBhcmUgdHdvIHNlY3Rp b25zIG9mIGRyYWZ0LXNtaXRoLWVuY3J5cHRlZC10cmFmZmljLW1hbmFnZW1lbnQtMDNbMl0gd2hp Y2ggY2FuIGJlIGFkZGVkIHRvICdFZmZlY3Qgb2YgVWJpcXVpdG91cyBFbmNyeXB0aW9uJyBbM10g LiBPbmNlIGFncmVlZCwgIEkgY2FuIHJlbW92ZSB0aGUgc2FtZSB0ZXh0IGZyb20gWzJdIGFuZCBz aW1wbHkgcG9pbnQgdG8gdGhlIHJlbGV2YW50IHNlY3Rpb24gaW4gWzNdOyBhbmQgaGVuY2UgWzJd IHdpbGwgZm9jdXMgb24gc29sdXRpb25zIHRvIHBlcnNpc3QgdHJhZmZpYyBtYW5hZ2VtZW50IGZv ciBlbmNyeXB0ZWQgdHJhZmZpYyAod2hpbHN0IG1haW50YWluaW5nIHByaXZhY3kvc2VjdXJpdHkp Lg0KPg0KPiBNYW55IHRoYW5rcw0KPiBLZXZpbg0KPg0KPiBbMV0gaHR0cHM6Ly93d3cuaWFiLm9y Zy9hY3Rpdml0aWVzL3dvcmtzaG9wcy9tYXJuZXcvDQo+IFsyXSANCj4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc21pdGgtZW5jcnlwdGVkLXRyYWZmaWMtbWFuYWdlbWVudC0wMw0K PiBbM10gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbW0td2ctZWZmZWN0 LWVuY3J5cHQvDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0gQWRkaXRpb25zIGZvciBkcmFm dC1tbS13Zy1lZmZlY3QtZW5jcnlwdA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tDQo+IHtmb3Ig c2VjdGlvbiAyLjE6IG5ldyBzdWItc2VjdGlvbn0NCg0KR3JlYXQsIHRoYW5rcyBmb3IgdGhpcywg YSBuZXcgc2VjdGlvbiB3YXMgYWRkZWQgaW4gMi4xIHRvIGNvdmVyIHRoaXMgaGVscGZ1bCBpbmZv cm1hdGlvbi4NCg0KPg0KPiBBY2Nlc3MgYW5kIHBvbGljeSBlbmZvcmNlbWVudA0KPg0KPiAgICBT ZXJ2ZXIgbG9hZCBiYWxhbmNpbmcNCj4NCj4gICAgV2hlcmUgbmV0d29yayBsb2FkIGJhbGFuY2Vy cyBoYXZlIGJlZW4gY29uZmlndXJlZCB0byByb3V0ZSBhY2NvcmRpbmcNCj4gICAgdG8gYXBwbGlj YXRpb24tbGF5ZXIgc2VtYW50aWNzLCBhbiBlbmNyeXB0ZWQgcGF5bG9hZCBpcyBlZmZlY3RpdmVs eQ0KPiAgICBpbnZpc2libGUuIFRoaXMgaGFzIHJlc3VsdGVkIGluIHByYWN0aWNlcyBvZiBpbnRl cmNlcHRpbmcgVExTIGluIGZyb250DQo+ICAgIG9mIGxvYWQgYmFsYW5jZXJzIHRvIHJlZ2FpbiB0 aGF0IHZpc2liaWxpdHksIGJ1dCBhdCBhIGNvc3QgdG8NCj4gICAgc2VjdXJpdHkgYW5kIHByaXZh Y3kuDQo+DQo+ICAgIE5ldHdvcmsgYWNjZXNzDQo+DQo+ICAgIEFwcHJvdmVkIGFjY2VzcyB0byBh IG5ldHdvcmsgaXMgYSBwcmVyZXF1aXNpdGUgdG8gcmVxdWVzdHMgZm9yDQo+ICAgIEludGVybmV0 IHRyYWZmaWMgLSBoZW5jZSBuZXR3b3JrIGFjY2VzcywgaW5jbHVkaW5nIGFueSBhdXRoZW50aWNh dGlvbg0KPiAgICBhbmQgYXV0aG9yaXNhdGlvbiwgaXMgbm90IGltcGFjdGVkIGVuY3J5cHRpb24u DQo+DQo+ICAgIENlbGx1bGFyIG5ldHdvcmtzIG9mdGVuIHNlbGwgdGFyaWZmcyB0aGF0IGFsbG93 IGZyZWUtZGF0YSBhY2Nlc3MgdG8NCj4gICAgY2VydGFpbiBzaXRlcywga25vd24gYXMgJ3plcm8g cmF0aW5nJy4gIEEgc2Vzc2lvbiB0byB2aXNpdCBzdWNoIGENCj4gICAgc2l0ZSBpbmN1cnMgbm8g YWRkaXRpb25hbCBjb3N0IG9yIGRhdGEgdXNhZ2UgdG8gdGhlIHVzZXIuIFRoaXMgZmVhdHVyZQ0K PiAgICBtYXkgYmUgaW1wYWN0ZWQgaWYgZW5jcnlwdGlvbiBoaWRlcyB0aGUgZG9tYWluIGZyb20g dGhlIG5ldHdvcmsuDQo+DQo+ICAgIFJlZ3VsYXRpb24gYW5kIHBvbGljeSBlbmZvcmNlbWVudA0K Pg0KPiAgICBNb2JpbGUgbmV0d29ya3MgKGFuZCB1c3VhbGx5IElTUHMpIG9wZXJhdGUgdW5kZXIg dGhlIHJlZ3VsYXRpb25zIG9mIHRoZWlyDQo+ICAgIGxpY2VuY2luZyBnb3Zlcm5tZW50IGF1dGhv cml0eS4gVGhlc2UgcmVndWxhdGlvbnMgaW5jbHVkZSBMYXdmdWwgSW50ZXJjZXB0LA0KPiAgICBh ZGhlcmVuY2UgdG8gQ29kZXMgb2YgUHJhY3RpY2Ugb24gY29udGVudCBmaWx0ZXJpbmcsIGFuZCBh cHBsaWNhdGlvbiBvZiBjb3VydCBvcmRlciBmaWx0ZXJzLg0KPiAgICBUaGVzZSBmdW5jdGlvbnMg YXJlIGltcGFjdGVkIGJ5IGVuY3J5cHRpb24sIHR5cGljYWxseQ0KPiAgICBieSBhbGxvd2luZyBh IGxlc3MgZ3JhbnVsYXIgbWVhbnMgb2YgaW1wbGVtZW50YXRpb24uICBUaGUgZW5mb3JjZW1lbnQN Cj4gICAgb2YgYW55IE5ldCBOZXV0cmFsaXR5IHJlZ3VsYXRpb25zIGlzIHVubGlrZWx5IHRvIGJl IGFmZmVjdGVkIGJ5DQo+ICAgIGNvbnRlbnQgYmVpbmcgZW5jcnlwdGVkLg0KPg0KPiAgICBTUEFN IGFuZCBtYWx3YXJlIGZpbHRlcmluZw0KPg0KPiAgICBUaGlzIGhhcyB0eXBpY2FsbHkgcmVxdWly ZWQgZnVsbCBhY2Nlc3MgdG8gYXBwbGljYXRpb24gZGF0YSB0byBmaWx0ZXINCj4gICAgdmFyaW91 cyBrZXl3b3JkcywgZnJhdWR1bGVudCBoZWFkZXJzIGFuZCB2aXJ1cyBhdHRhY2htZW50cy4NCj4N Cj4NCj4gICB7TmV3IHRvcCBsZXZlbCBzZWN0aW9ufQ0KDQpUaGlzIGhhcyBiZWVuIGFkZGVkIGp1 c3QgYWZ0ZXIgdGhlIHNlY3VyaXR5IG1vbml0b3Jpbmcgc2VjdGlvbiBzaW5jZSBib3RoIG1heSBh cHBseSBhY3Jvc3MgbmV0d29yayB0eXBlcyB0aGF0IHdlIHVzZWQgYXMgZ3JvdXBpbmdzLg0KDQo+ DQo+ICAgRmxvdyBpbmZvcm1hdGlvbiB2aXNpYmxlIHRvIGEgbmV0d29yaw0KDQpUaGUgd29yZCBh cHBsaWNhdGlvbiB3YXMgYWRkZWQgaW4gZnJvbnQgb2YgdGhlIHNlY3Rpb24gaGVhZGVyIGFzIHRo YXQgbWFkZSBzZW5zZSBvbmNlIElQIDUtdHVwbGUgd2FzIHJlbW92ZWQuICBXZSBjb3ZlciB0aGF0 IGFscmVhZHkgaW4gc2VjdGlvbiAzLjEuMSwgd2hpY2ggYWxzbyBjb3ZlcnMgMi10dXBsZS4gIFRo ZSAyLXR1cGxlIGFuZCA1LXR1cGxlIGFyZSB1c2VkIGluIG11bHRpcGxlIG5ldHdvcmsgdHlwZXMs IHNvIHdlIG1heSB3YW50IHRvIHRoaW5rIGFib3V0IGJ1bXBpbmcgdGhpcyB0byBhbm90aGVyIHNl Y3Rpb24uDQoNCj4NCj4gICAgSVAgNS10dXBsZQ0KPg0KPiAgICBUaGlzIGluZGljYXRlcyBzb3Vy Y2UgYW5kIGRlc3RpbmF0aW9uIElQIGFkZHJlc3Nlcy9wb3J0cyBhbmQgdGhlDQo+ICAgIHRyYW5z cG9ydCBwcm90b2NvbC4gIFRoaXMgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGR1cmluZyBUTFMs IFRDUC0NCj4gICAgbGF5ZXIgZW5jcnlwdGlvbiAoZXhjZXB0IHBvcnRzKSwgYW5kIElQLWxheWVy IGVuY3J5cHRpb24gKElQU2VjKTsNCj4gICAgYWx0aG91Z2ggaXQgbWF5IGJlIG9ic2N1cmVkIGlu IFR1bm5lbCBtb2RlIElQU2VjLg0KPg0KPiAgICBUaGlzIGFsbG93cyBuZXR3b3JrIG1hbmFnZW1l bnQgYXQgYSBjb2Fyc2UgSVAtc291cmNlIGxldmVsLCB3aGljaA0KPiAgICBtYWtlcyBpdCBvZiBs aW1pdGVkIHZhbHVlIHdoZXJlIHRoZSBvcmlnaW4gc2VydmVyIHN1cHBvcnRzIGEgYmxlbmQgb2YN Cj4gICAgc2VydmljZSB0eXBlcy4NCj4NCg0KVGhhbmsgeW91IGZvciB0aGUgcmVzdCBvZiB0aGUg dGV4dCBmb3IgdGhpcyBzZWN0aW9uLCBpdCdzIHZlcnkgaGVscGZ1bC4NCg0KPiAgICBUTFMgU2Vy dmVyIE5hbWUgSW5kaWNhdGlvbg0KPg0KPiAgICBXaGVuIGluaXRpYXRpbmcgdGhlIFRMUyBoYW5k c2hha2UsIHRoZSBDbGllbnQgbWF5IHByb3ZpZGUgYW4NCj4gICAgZXh0ZW5zaW9uIGZpZWxkIChz ZXJ2ZXJfbmFtZSkgd2hpY2ggaW5kaWNhdGVzIHRoZSBzZXJ2ZXIgdG8gd2hpY2ggaXQNCj4gICAg aXMgYXR0ZW1wdGluZyBhIHNlY3VyZSBjb25uZWN0aW9uLiAgVExTIFNOSSB3YXMgc3RhbmRhcmRp emVkIGluIDIwMDMNCj4gICAgdG8gZW5hYmxlIHNlcnZlcnMgdG8gcHJlc2VudCB0aGUgImNvcnJl Y3QgVExTIGNlcnRpZmljYXRlIiB0byBjbGllbnRzDQo+ICAgIGluIGEgZGVwbG95bWVudCBvZiBt dWx0aXBsZSB2aXJ0dWFsIHNlcnZlcnMgaG9zdGVkIGJ5IHRoZSBzYW1lIHNlcnZlcg0KPiAgICBp bmZyYXN0cnVjdHVyZSBhbmQgSVAtYWRkcmVzcy4gIEFsdGhvdWdoIHRoaXMgaXMgYW4gb3B0aW9u YWwNCj4gICAgZXh0ZW5zaW9uLCBpdCBpcyB0b2RheSBzdXBwb3J0ZWQgYnkgYWxsIG1vZGVybiBi cm93c2Vycywgd2ViIHNlcnZlcnMNCj4gICAgYW5kIGRldmVsb3BlciBsaWJyYXJpZXMuICBOb3Rh YmxlIGV4Y2VwdGlvbnMgYXJlIEFuZHJvaWQgMi4yIGFuZA0KPiAgICBJbnRlcm5ldCBFeHBsb3Jl ciA2IG9uIFdpbmRvd3MgWFAuICBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBIVFRQLzINCj4gICAg aW50cm9kdWNlcyB0aGUgQWx0LVNWQyBtZXRob2QgZm9yIHVwZ3JhZGluZyB0aGUgY29ubmVjdGlv biBmcm9tDQo+ICAgIEhUVFAvMSB0byBlaXRoZXIgdW5lbmNyeXB0ZWQgb3IgZW5jcnlwdGVkIEhU VFAvMi4gIElmIHRoZSBpbml0aWFsDQo+ICAgIEhUVFAvMSByZXF1ZXN0IGlzIHVuZW5jcnlwdGVk LCB0aGUgZGVzdGluYXRpb24gYWx0ZXJuYXRlIHNlcnZpY2UgbmFtZQ0KPiAgICBjYW4gYmUgaWRl bnRpZmllZCBiZWZvcmUgdGhlIGNvbW11bmljYXRpb24gaXMgcG90ZW50aWFsbHkgdXBncmFkZWQg dG8NCj4gICAgZW5jcnlwdGVkIEhUVFAvMiB0cmFuc3BvcnQuICBIVFRQLzIgaW1wbGVtZW50YXRp b25zIE1VU1Qgc3VwcG9ydCB0aGUNCj4gICAgU2VydmVyIE5hbWUgSW5kaWNhdGlvbiAoU05JKSBl eHRlbnNpb24uDQo+DQo+ICAgIFRoaXMgaW5mb3JtYXRpb24gaXMgb25seSB2aXNpYmxlIGlmIHRo ZSBjbGllbnQgaXMgcG9wdWxhdGluZyB0aGUNCj4gICAgU2VydmVyIE5hbWUgSW5kaWNhdGlvbiBl eHRlbnNpb24uICBUaGlzIG5lZWQgbm90IGJlIGRvbmUsIGJ1dCBtYXkgYmUNCj4gICAgZG9uZSBh cyBwZXIgVExTIHN0YW5kYXJkLiAgVGhlcmVmb3JlLCBldmVuIGlmIGV4aXN0aW5nIG5ldHdvcmsN Cj4gICAgZmlsdGVycyBsb29rIG91dCBmb3Igc2VlaW5nIGEgU2VydmVyIE5hbWUgSW5kaWNhdGlv biBleHRlbnNpb24sIHRoZXkNCj4gICAgbWF5IG5vdCBmaW5kIG9uZS4gIFRoZSBwZXItZG9tYWlu IG5hdHVyZSBvZiBTTkkgbWF5IG5vdCByZXZlYWwgdGhlDQo+ICAgIHNwZWNpZmljIHNlcnZpY2Ug b3IgbWVkaWEgdHlwZSBiZWluZyBhY2Nlc3NlZCwgZXNwZWNpYWxseSB3aGVyZSB0aGUNCj4gICAg ZG9tYWluIGlzIG9mIGEgcHJvdmlkZXIgb2ZmZXJpbmcgYSByYW5nZSBvZiBlbWFpbCwgdmlkZW8s IFdlYiBwYWdlcw0KPiAgICBldGMuICBGb3IgZXhhbXBsZSwgY2VydGFpbiBibG9nIG9yIHNvY2lh bCBuZXR3b3JrIGZlZWRzIG1heSBiZSBkZWVtZWQNCj4gICAgJ2FkdWx0IGNvbnRlbnQnLCBidXQg dGhlIFNlcnZlciBOYW1lIEluZGljYXRpb24gd2lsbCBvbmx5IGluZGljYXRlDQo+ICAgIHRoZSBz ZXJ2ZXIgZG9tYWluIHJhdGhlciB0aGFuIGEgVVJMIHBhdGggdG8gYmUgYmxvY2tlZC4NCj4NCj4g ICAgQXBwbGljYXRpb24gTGF5ZXIgUHJvdG9jb2wgTmVnb3RpYXRpb24gKEFMUE4pDQo+DQo+ICAg IEFMUE4gaXMgYSBUTFMgZXh0ZW5zaW9uIHdoaWNoIG1heSBiZSB1c2VkIHRvIGluZGljYXRlIHRo ZSBhcHBsaWNhdGlvbg0KPiAgICBwcm90b2NvbCB3aXRoaW4gdGhlIFRMUyBzZXNzaW9uLiAgVGhp cyBpcyBsaWtlbHkgdG8gYmUgb2YgbW9yZSB2YWx1ZQ0KPiAgICB0byB0aGUgbmV0d29yayB3aGVy ZSBpdCBpbmRpY2F0ZXMgYSBwcm90b2NvbCBkZWRpY2F0ZWQgdG8gYQ0KPiAgICBwYXJ0aWN1bGFy IHRyYWZmaWMgdHlwZSAoc3VjaCBhcyB2aWRlbyBzdHJlYW1pbmcpIHJhdGhlciB0aGFuIGENCj4g ICAgbXVsdGktdXNlIHByb3RvY29sLiAgQUxQTiBpcyB1c2VkIGFzIHBhcnQgb2YgSFRUUC8yICdo MicsIGJ1dCB3aWxsDQo+ICAgIG5vdCBpbmRpY2F0ZSB0aGUgdHJhZmZpYyB0eXBlcyB3aGljaCBt YXkgbWFrZSB1cCBzdHJlYW1zIHdpdGhpbiBhbg0KPiAgICBIVFRQLzIgbXVsdGlwbGV4Lg0KPg0K PiAgICBDb250ZW50IGxlbmd0aCwgYml0cmF0ZSBhbmQgcGFjaW5nDQo+DQo+ICAgIFRoZSBjb250 ZW50IGxlbmd0aCBvZiBlbmNyeXB0ZWQgdHJhZmZpYyBpcyBlZmZlY3RpdmVseSB0aGUgc2FtZSBh cw0KPiAgICB0aGUgY2xlYXJ0ZXh0LiBBbHRob3VnaCBibG9jayBjaXBoZXJzIHV0aWxpc2UgcGFk ZGluZyB0aGlzIG1ha2VzIGENCj4gICAgbmVnbGlnaWJsZSBkaWZmZXJlbmNlLiBCaXRyYXRlIGFu ZCBwYWNpbmcgYXJlIGdlbmVyYWxseSBhcHBsaWNhdGlvbg0KPiAgICBzcGVjaWZpYywgYW5kIGRv IG5vdCBjaGFuZ2Ugd2hlbiB0aGUgY29udGVudCBpcyBlbmNyeXB0ZWQuIE11bHRpcGxleGVkDQo+ ICAgIGZvcm1hdHMgKHN1Y2ggYXMgSFRUUC8yIGFuZCBRVUlDKSBtYXkgaG93ZXZlciBpbmNvcnBv cmF0ZSBzZXZlcmFsIGFwcGxpY2F0aW9uIHN0cmVhbXMNCj4gICAgb3ZlciBvbmUgY29ubmVjdGlv biwgd2hpY2ggbWFrZXMgdGhlIGJpdHJhdGUvcGFjaW5nIG5vIGxvbmdlciBhcHBsaWNhdGlvbi1z cGVjaWZpYy4NCj4NCj4NCj4NCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4gJiBBbA0KDQo+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNh YWcgbWFpbGluZyBsaXN0DQo+IHNhYWdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zYWFnDQoNCg0KDQotLSANCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxl ZW4NCg== From nobody Tue Oct 20 12:46:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1BB1ACE76 for ; Tue, 20 Oct 2015 12:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=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 COz7ZnXcmpky for ; Tue, 20 Oct 2015 12:46:11 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116921ACDEE for ; Tue, 20 Oct 2015 12:46:11 -0700 (PDT) Received: by lbbwb3 with SMTP id wb3so23331373lbb.1 for ; Tue, 20 Oct 2015 12:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=3x3S0RTa6naVLlwPM0a7mHwa/z+jud15ZwCJIL4Ck5c=; b=GMsa1ROefSiaxs7qYu8YiPIJGhUgri7XG4YTHoi8SgqUQjCXdBpVWANHU4w/J6r4Ys BLZBh7a4jodsrvlWglnsg0AFs/M11lhYELgLa9YrhBrk9a25bzxco4P0Xyr4wSfdM48r LTkaxXUzE0iQuKoBZL4J6LdFTBRvz/nnaHQVzYzUK+N1978OsovFLbbtap2vxrrxCW70 b64uDkqnjZY2xUP3eLs//XfVOppaZLl6iJKvxjmUjD9Y9ybhQwv8svr1aFjrzuY1zb3y c0idzmixkBveZuJodSg5hd7Casp8dbWxAdgbHFWqNPjqXRv21xN80Xk4RmZMkP68eQNS NK2w== MIME-Version: 1.0 X-Received: by 10.112.72.40 with SMTP id a8mr3002190lbv.55.1445370369239; Tue, 20 Oct 2015 12:46:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.213.75 with HTTP; Tue, 20 Oct 2015 12:46:09 -0700 (PDT) Date: Tue, 20 Oct 2015 15:46:09 -0400 X-Google-Sender-Auth: F1dSSfgriheNnLrTVG3TcqfGcgY Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] URI for a blockchain token X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 19:46:12 -0000 All, So I have this need for a compact representation of a generalized hash chain token value as a string, it seems natural to represent it as a URI. Let us assume that there is some service X that regularly emits a value V(t) and accompanying proof P(t) which is then recorded by multiple authorities. V(t) is a 256+ bit output value that is a 'cryptographically strong' function of V(t-1) (aka we stuff V(t-1) and some other data through a hash function to produce it. P(t) is evidence which allows a party that has at least one value V(tt), tt:: Comments? The immediate application I have is for a system where I want to be able to use this for bounding replay attack by providing a cryptographically hard timestamp on each request without the need to muck about requesting nonces. From nobody Thu Oct 22 01:13:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500B11A1B2A for ; Thu, 22 Oct 2015 01:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 c2l5N93FdwKk for ; Thu, 22 Oct 2015 01:13:01 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122651B2ED8 for ; Thu, 22 Oct 2015 01:13:01 -0700 (PDT) Received: by lffv3 with SMTP id v3so38755348lff.0 for ; Thu, 22 Oct 2015 01:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=XUHKyzejysM++I1V00U4VY1YV3V252S4x63hRVp6jqU=; b=Fd4NVs+Ni/5NgHYM5YeGGiA2kqjze2inaaG0BaMUX3qiYZeJR3cnxWII1wxDMK1pk5 1LMKM2bpYqfm+UmuCRNG0SnKHUZoLQVEWMONPlIX1JoFJXhumQm3IQUa7TW2an6O07uV URygbklrNV+pjO+PXTeogORxRbmGCuzOxw5bFh/jX/vUVDxMR3EvAonpEKdtCPOTbzIl QDdn3QVRDeEpjN+1IiMPc+At7FM6kiHQACCd9gZxx8t431zBjB/1ORNnSDPi0zcYZjdl +DvzQrvYHwg7OrsG/fFxYH9oZC8xg1ksY70LIfyS7vNkug+BUwSnRDXcAAACbaJcnFvT 2Baw== MIME-Version: 1.0 X-Received: by 10.112.198.69 with SMTP id ja5mr6578350lbc.106.1445501579280; Thu, 22 Oct 2015 01:12:59 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.30.108 with HTTP; Thu, 22 Oct 2015 01:12:59 -0700 (PDT) Date: Thu, 22 Oct 2015 10:12:59 +0200 X-Google-Sender-Auth: WqtzzwsS1M7Dx0DCDEoCpC7gTbA Message-ID: From: Nikos Mavrogiannopoulos To: IETF SAAG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] preventing denial of service in IPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 08:13:05 -0000 I've been looking on ways to prevent denial of service on a server application, and I stumbled on IPv6. By denial of service, I mean exhaustion of resources, being memory or CPU. Unlike IPv4, in IPv6 a user may typically have 2^64, and more able adversaries may have 2^80 or even more addresses(*). That means that single IP blacklisting to prevent DoS is not going to work; not even against a single adversary who has 2^64 IPs. So one would expect software to blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs violate some of its "detection properties". Given recommendations like RFC6164 which recommend /127 for PtP links (which can be a user VPN link), any heuristic that will ban whole networks looks more like a vessel to perform another denial of service (e.g., denying some user access to a server), rather than a solution to the original denial of service. Are there any recommendations for protecting servers from the IPv6 address proliferation? If not, are there any conventions for IPv6 address assignment to end-users? regards, Nikos [0]. rfc6177 is supposed to describe the best current practice, but it mostly focuses on what isn't the current best practice (i.e., /48 is not recommended any more). From nobody Thu Oct 22 08:34:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D761A701C for ; Thu, 22 Oct 2015 08:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIgrhSoNFo9D for ; Thu, 22 Oct 2015 08:29:23 -0700 (PDT) Received: from mail-yk0-x242.google.com (mail-yk0-x242.google.com [IPv6:2607:f8b0:4002:c07::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 12B1B1B38CA for ; Thu, 22 Oct 2015 08:29:22 -0700 (PDT) Received: by ykdy125 with SMTP id y125so7061924ykd.1 for ; Thu, 22 Oct 2015 08:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W+03OzKtxOHtbgcHcyeOhQ8k0Jfag4D2KZjdGBBAGO4=; b=E5LBGbGcIjTRy3Af97PVlaBUJFeKNlHhjqnTLOazK2MMNr2nbpmm1R/AluohPzwTMI bjMwa/d6w8yd5Bl/DkdI0+uRxFGLkf/stESSV7nWIPCz35kSESPvmoUP3wo9DPPO7OZC 0BTqRgYBJgaBjrHVgXOgLmI3dg3AExQb0aGHo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=W+03OzKtxOHtbgcHcyeOhQ8k0Jfag4D2KZjdGBBAGO4=; b=VgZ+qH1gR5MLfzPSpln05ygygfNK9/aG7TzKqMxf1rna7DJ9GoLT7egesnMH+M7d4S BC+OzJHUwHZCyfPQjzwj0WpXSD1H1Z4eUJiAoa4r3Ie3wg/WCJ++sXkBW/ygXcO0YGpg 7EBLJGJSzIwmQu3JtiGTHvMbBOrOe32aHGjPAhjaxdwI72frNTTlvfreRIbbPd35ttxL BAUf8+sNC/MS5HYeGko2JtAR+rsd/WPQHm5nxPZOB8TiSK5JNId9c17+okiEgVG8kUsI w5lsYyyzjePyxb91NNHV1IhUsJckPBEp5PKh04T5UEwHzfqIPZJjIT/zQ5ZTaU1wj9OI KFwQ== X-Gm-Message-State: ALoCoQkxx0PMELhQFPilyMXjP9wg8FZJ6mXul8aWgmdUtUePq+rYFQ+iUAsi0DCDfWnqeha+VlTe X-Received: by 10.129.97.65 with SMTP id v62mr9962044ywb.262.1445527762146; Thu, 22 Oct 2015 08:29:22 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-126-234.washdc.east.verizon.net. [173.73.126.234]) by smtp.gmail.com with ESMTPSA id o145sm10160630ywd.14.2015.10.22.08.29.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 08:29:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: Date: Thu, 22 Oct 2015 11:29:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: IETF SAAG Subject: Re: [saag] preventing denial of service in IPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 15:29:26 -0000 Might be worth asking the v6ops WG too: http://datatracker.ietf.org/wg/v6ops/documents/ spt > On Oct 22, 2015, at 04:12, Nikos Mavrogiannopoulos = wrote: >=20 > I've been looking on ways to prevent denial of service on a server > application, and I stumbled on IPv6. By denial of service, I mean > exhaustion of resources, being memory or CPU. >=20 > Unlike IPv4, in IPv6 a user may typically have 2^64, and more able = adversaries > may have 2^80 or even more addresses(*). That means that single IP > blacklisting to prevent DoS is not going to work; not even against a > single adversary who has 2^64 IPs. So one would expect software to > blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs > violate some of its "detection properties". Given recommendations > like RFC6164 which recommend /127 for PtP links (which can be a user > VPN link), any heuristic that will ban whole networks looks more like > a vessel to perform another denial of service (e.g., denying some user > access to a server), rather than a solution to the original denial of > service. >=20 > Are there any recommendations for protecting servers from the IPv6 > address proliferation? If not, are there any conventions for IPv6 > address assignment to end-users? >=20 > regards, > Nikos >=20 > [0]. rfc6177 is supposed to describe the best current practice, but it > mostly focuses on what isn't the current best practice (i.e., /48 is > not recommended any more). >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Oct 22 08:52:21 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B532F1A1A98 for ; Thu, 22 Oct 2015 08:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwXkpgJ3J2O3 for ; Thu, 22 Oct 2015 08:52:10 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 523FB1B3944 for ; Thu, 22 Oct 2015 08:52:08 -0700 (PDT) Received: by wijp11 with SMTP id p11so38794029wij.0 for ; Thu, 22 Oct 2015 08:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:mime-version:to:from:subject:date:in-reply-to:references :content-type; bh=RZiPArDKNVNycOuC28egjxexL1bGACJVScUhkmpAa3o=; b=eqVKJi1lbcIi8fRxst+shuSC6847p17SteEobLJE8nlTRb+VsSVSoYIe9qoBe2BiEo RXrC/Jh+3OlXvVFk69etLVsK5DkSm5pHpSz3pw3WZQh87rHzN+5oA/3GNhmiZf6uFqff 9LyyD6VfLJRZDyhFAruuVJDb1BSar/8XjUstktmOIOKzLbjzdHF6m8Z/6sLAwDpquobz ZhAppt402qMFFvJbnbEYUMpMEBp5G/LDo9n8ZPpIZdLH8Eu3G3lHh9H+YXP8WYwulQ+G d0FBJb8ISR5T7QttSGy6ClNiX37XFfGgPeT92kqk/ozfeT/E60sQ68Po0TpAwcq/XB6L aZ9Q== X-Received: by 10.194.116.74 with SMTP id ju10mr13444042wjb.127.1445529126924; Thu, 22 Oct 2015 08:52:06 -0700 (PDT) Received: from [10.221.228.6] ([176.12.150.238]) by smtp.gmail.com with ESMTPSA id ld5sm17595805wjc.18.2015.10.22.08.52.04 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 22 Oct 2015 08:52:05 -0700 (PDT) Message-ID: <56290625.25cdc20a.2aa7c.ffff9598@mx.google.com> MIME-Version: 1.0 To: Nikos Mavrogiannopoulos , IETF SAAG From: Yoav Nir Date: Thu, 22 Oct 2015 18:52:06 +0300 In-Reply-To: References: Content-Type: multipart/alternative; boundary="_1BED129A-DBFF-4CC3-9F03-CCED95A8A133_" Archived-At: Subject: Re: [saag] preventing denial of service in IPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 15:52:15 -0000 --_1BED129A-DBFF-4CC3-9F03-CCED95A8A133_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We've been looking at this issue for the anti-ddos draft at IPsecME. We hav= en't come up with anything better than blacklisting or limiting entire /64 = networks. It should be noted that those /64 networks often replace non-routable IPv4 = networks natted behind a single IP. So you had to blacklist them before as = well. Regards, Yoav Sent from my Windows Phone=20 -----Original Message----- From: "Nikos Mavrogiannopoulos" Sent: =E2=80=8E10/=E2=80=8E22/=E2=80=8E2015 11:13 To: "IETF SAAG" Subject: [saag] preventing denial of service in IPv6 I've been looking on ways to prevent denial of service on a server application, and I stumbled on IPv6. By denial of service, I mean exhaustion of resources, being memory or CPU. Unlike IPv4, in IPv6 a user may typically have 2^64, and more able adversar= ies may have 2^80 or even more addresses(*). That means that single IP blacklisting to prevent DoS is not going to work; not even against a single adversary who has 2^64 IPs. So one would expect software to blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs violate some of its "detection properties". Given recommendations like RFC6164 which recommend /127 for PtP links (which can be a user VPN link), any heuristic that will ban whole networks looks more like a vessel to perform another denial of service (e.g., denying some user access to a server), rather than a solution to the original denial of service. Are there any recommendations for protecting servers from the IPv6 address proliferation? If not, are there any conventions for IPv6 address assignment to end-users? regards, Nikos [0]. rfc6177 is supposed to describe the best current practice, but it mostly focuses on what isn't the current best practice (i.e., /48 is not recommended any more). _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_1BED129A-DBFF-4CC3-9F03-CCED95A8A133_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
We've been looking at this issue for the anti-ddos draft = at IPsecME. We haven't come up with anything better than blacklisting or li= miting entire /64 networks.

It should be noted that those /64 networ= ks often replace non-routable IPv4 networks natted behind a single IP. So y= ou had to blacklist them before as well.

Regards,

Yoav
Sent from my Windows Phone
From= : = Nikos Mavrogiannopoulos
Sent: =E2=80=8E10/=E2=80=8E22/=E2=80=8E2015 11:13
To: IETF SAAG
Subje= ct: like RFC6164 which recommend /127 for PtP links (whi= ch can be a user
VPN link), any heuristic that will ban whole networks l= ooks more like
a vessel to perform another denial of service (e.g., deny= ing some user
access to a server), rather than a solution to the origina= l denial of
service.

Are there any recommendations for protecting= servers from the IPv6
address proliferation? If not, are there any conv= entions for IPv6
address assignment to end-users?

regards,
Nik= os

[0]. rfc6177 is supposed to describe the best current practice, b= ut it
mostly focuses on what isn't the current best practice (i.e., /48 = is
not recommended any more).

___________________________________= ____________
saag mailing list
saag@ietf.org
https://www.ietf.org/= mailman/listinfo/saag
= --_1BED129A-DBFF-4CC3-9F03-CCED95A8A133_-- From nobody Fri Oct 23 02:13:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20571B338D for ; Fri, 23 Oct 2015 02:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 N96Xqll4Obdv for ; Fri, 23 Oct 2015 02:13:18 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913301B3385 for ; Fri, 23 Oct 2015 02:13:18 -0700 (PDT) Received: by lfbn126 with SMTP id n126so42011755lfb.2 for ; Fri, 23 Oct 2015 02:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MKhiGWLLlwvLh5HC3PNpH3tyBp8HZXOoNJSqopeTXIo=; b=nqXMaTvk4bqkHAd4e5rsTD/BY1FJEABHTBpA12JJ8BRzOB5RCEsn/0Jb6GvF3MusZB 0YjieOAkwMvhMobDfzXQXdDmg71ImPMBV5dn/IR2lWbimys9rSUyGKKEvzi3Em8MKAuq Ea15rEkitfL68/x1KoY/hVOB2VWPuzlBwLuYnK4FTcbAXCcinET6h+zkIKi13HKc6YrB VOzt5n1VOPTzx5zeG8r/TWmpwqVhjwfPCtSpc6ekSCYcHCZ+kHNn9o+kQE3SFKhCu5M/ ZPH21fDnwZFI/xUMv1HqWIJoA+/JeQ6hfi0H47zsMFhFaQ+svtg/YlYK1LX16WgYxGAr YDJA== MIME-Version: 1.0 X-Received: by 10.112.198.69 with SMTP id ja5mr9517280lbc.106.1445591596551; Fri, 23 Oct 2015 02:13:16 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.30.108 with HTTP; Fri, 23 Oct 2015 02:13:16 -0700 (PDT) In-Reply-To: <56290625.25cdc20a.2aa7c.ffff9598@mx.google.com> References: <56290625.25cdc20a.2aa7c.ffff9598@mx.google.com> Date: Fri, 23 Oct 2015 11:13:16 +0200 X-Google-Sender-Auth: 54gaehgNysjVTxXCTzGqr729avQ Message-ID: From: Nikos Mavrogiannopoulos To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF SAAG Subject: Re: [saag] preventing denial of service in IPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 09:13:19 -0000 On Thu, Oct 22, 2015 at 5:52 PM, Yoav Nir wrote: > We've been looking at this issue for the anti-ddos draft at IPsecME. We > haven't come up with anything better than blacklisting or limiting entire > /64 networks. > It should be noted that those /64 networks often replace non-routable IPv4 > networks natted behind a single IP. So you had to blacklist them before as > well. That's a reasonable thing to do in the blurry IPv6 waters, but I don't think it's viable. A /64 network is sufficient for an ISP to use (and in fact I'm aware of ISPs who hand out smaller than /64 subnets to their users), so a blanket ban of /64 or /48 would not be without repercussion. Given the vast amount of addresses in such networks the collateral damage could range from enormous (banning a whole country) to none. From nobody Fri Oct 23 07:29:33 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDE61A1A8F for ; Fri, 23 Oct 2015 07:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Huo5Fv4Daoz for ; Fri, 23 Oct 2015 07:29:30 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) (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 939651A1A87 for ; Fri, 23 Oct 2015 07:29:30 -0700 (PDT) Received: from [85.158.139.163] by server-13.bemta-5.messagelabs.com id 02/BC-06091-8444A265; Fri, 23 Oct 2015 14:29:28 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-7.tower-188.messagelabs.com!1445610568!71096!1 X-Originating-IP: [195.232.244.135] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31939 invoked from network); 23 Oct 2015 14:29:28 -0000 Received: from mailout03.vodafone.com (HELO mailout03.vodafone.com) (195.232.244.135) by server-7.tower-188.messagelabs.com with AES256-SHA encrypted SMTP; 23 Oct 2015 14:29:28 -0000 Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout03.vodafone.com (Postfix) with ESMTP id 3nj7HD0p3Rz17HLl; Fri, 23 Oct 2015 16:29:28 +0200 (CEST) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3nj7HC6cKgzxPpW; Fri, 23 Oct 2015 16:29:27 +0200 (CEST) Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3nj7HC6GxQzxPVW; Fri, 23 Oct 2015 16:29:27 +0200 (CEST) Received: from VOEXC20W.internal.vodafone.com (145.230.103.125) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 23 Oct 2015 16:29:27 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.63]) by VOEXC20W.internal.vodafone.com ([145.230.103.125]) with mapi id 14.03.0224.002; Fri, 23 Oct 2015 16:29:26 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: "saag@ietf.org" Thread-Topic: [saag] draft-smith-encrypted-traffic-management updated Thread-Index: AdENnhnayi6wHdO/Qri9KwjvgqtI8g== Date: Fri, 23 Oct 2015 14:29:26 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] draft-smith-encrypted-traffic-management updated X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 14:29:32 -0000 Hi Kathleen, Stephen, Following alignment with the 'Effect of ubiquitous encryption' [1] I've re-= edited the 'Network management of encrypted traffic' I-D [2], albeit after = the submission deadline. The updates can however be previewed on github [3]= . These can form part of the MaRNEW summary at IETF 94, agenda permitting. Many thanks! Kevin [1] https://tools.ietf.org/html/draft-mm-wg-effect-encrypt-03=20 [2] https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-manageme= nt/ [3] https://github.com/Kevsy/encrypted-traffic-management/blob/master/draft= -smith-encrypted-traffic-management.html , use http://htmlpreview.github.io= / for easy reading From nobody Fri Oct 23 07:42:38 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE171A1B59 for ; Fri, 23 Oct 2015 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U270d4QNjsIt for ; Fri, 23 Oct 2015 07:42:35 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502DF1A1B56 for ; Fri, 23 Oct 2015 07:42:35 -0700 (PDT) Received: by qkfm62 with SMTP id m62so77462944qkf.1 for ; Fri, 23 Oct 2015 07:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WWQdlHXDNy3cJi/zVUgmFpOO20V+1tX7SHWG1RqsXAI=; b=ZQ05+8kkIgs1/rWuuyipGuQL03zxZGh772/xQpEGSO/yggMd1ZbhnfGblywq3wrISb n6PVM8XZHMsRr3kib6Fw4C46CmGsnQ1J+XmykSQjeSVltTBRRMyxOIuRsRruU/ubAR73 CsLXrpNp55FAiE55XW7ZeqUUrrwSCW2lfvN1K0G0UqCiKL3aWumahWtFgofmnt0+P6NN 1/ixSH9jL54KT8wRiN3Al0ajynrUf9ola6MaqV0BKlI2tgysvLFZdl5evbTIAPsV1xHS GlHsM06RK0MamLlQ3KE5DiscLj1O8eiFQGEsvDnKJFFX5d2nlqwgovE1j3Dd+vyeBNmk HTUg== X-Received: by 10.55.192.16 with SMTP id o16mr25412658qki.58.1445611354299; Fri, 23 Oct 2015 07:42:34 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id g197sm7509213qhc.35.2015.10.23.07.42.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Oct 2015 07:42:33 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: Date: Fri, 23 Oct 2015 10:42:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Smith, Kevin, (R&D) Vodafone Group" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-smith-encrypted-traffic-management updated X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 14:42:37 -0000 Thanks, Kevin. This is helpful. Could you have it ready to post when submi= ssions open again? Best regards, Kathleen=20 Sent from my iPhone > On Oct 23, 2015, at 10:29 AM, Smith, Kevin, (R&D) Vodafone Group wrote: >=20 > Hi Kathleen, Stephen, >=20 > Following alignment with the 'Effect of ubiquitous encryption' [1] I've re= -edited the 'Network management of encrypted traffic' I-D [2], albeit after t= he submission deadline. The updates can however be previewed on github [3]. T= hese can form part of the MaRNEW summary at IETF 94, agenda permitting. >=20 > Many thanks! > Kevin >=20 > [1] https://tools.ietf.org/html/draft-mm-wg-effect-encrypt-03=20 > [2] https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-managem= ent/ > [3] https://github.com/Kevsy/encrypted-traffic-management/blob/master/draf= t-smith-encrypted-traffic-management.html , use http://htmlpreview.github.io= / for easy reading >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Oct 23 07:44:34 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910F41A1B64 for ; Fri, 23 Oct 2015 07:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE8KIEf7KPeS for ; Fri, 23 Oct 2015 07:44:31 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.150]) (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 9FE851A1B5C for ; Fri, 23 Oct 2015 07:44:30 -0700 (PDT) Received: from [85.158.139.163] by server-14.bemta-5.messagelabs.com id 81/49-22142-DC74A265; Fri, 23 Oct 2015 14:44:29 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-12.tower-188.messagelabs.com!1445611468!73871!1 X-Originating-IP: [195.232.244.135] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4120 invoked from network); 23 Oct 2015 14:44:28 -0000 Received: from mailout03.vodafone.com (HELO mailout03.vodafone.com) (195.232.244.135) by server-12.tower-188.messagelabs.com with AES256-SHA encrypted SMTP; 23 Oct 2015 14:44:28 -0000 Received: from mailint04.vodafone.com (mailint04.vodafone.com [195.232.244.201]) by mailout03.vodafone.com (Postfix) with ESMTP id 3nj7cX3XjJz17HLl; Fri, 23 Oct 2015 16:44:28 +0200 (CEST) Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailint04.vodafone.com (Postfix) with ESMTP id 3nj7cX2Qsyzff10; Fri, 23 Oct 2015 16:44:28 +0200 (CEST) Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 3nj7cX253nzff48; Fri, 23 Oct 2015 16:44:28 +0200 (CEST) Received: from AVOEXH04W.internal.vodafone.com (145.230.15.136) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 23 Oct 2015 16:44:27 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.63]) by AVOEXH04W.internal.vodafone.com ([145.230.15.136]) with mapi id 14.03.0224.002; Fri, 23 Oct 2015 16:44:27 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: Kathleen Moriarty Thread-Topic: [saag] draft-smith-encrypted-traffic-management updated Thread-Index: AQHRDaEPKfw0g2D3RUOj+EpG7yrHD555JzMw Date: Fri, 23 Oct 2015 14:44:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] draft-smith-encrypted-traffic-management updated X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 14:44:32 -0000 > Could you have it ready to post when submissions open again? Sure, it's all good to go. All best, Kevin -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: 23 October 2015 15:43 To: Smith, Kevin, (R&D) Vodafone Group Cc: saag@ietf.org Subject: Re: [saag] draft-smith-encrypted-traffic-management updated Thanks, Kevin. This is helpful. Could you have it ready to post when subm= issions open again? Best regards, Kathleen=20 Sent from my iPhone > On Oct 23, 2015, at 10:29 AM, Smith, Kevin, (R&D) Vodafone Group wrote: >=20 > Hi Kathleen, Stephen, >=20 > Following alignment with the 'Effect of ubiquitous encryption' [1] I've r= e-edited the 'Network management of encrypted traffic' I-D [2], albeit afte= r the submission deadline. The updates can however be previewed on github [= 3]. These can form part of the MaRNEW summary at IETF 94, agenda permitting= . >=20 > Many thanks! > Kevin >=20 > [1] https://tools.ietf.org/html/draft-mm-wg-effect-encrypt-03 > [2]=20 > https://datatracker.ietf.org/doc/draft-smith-encrypted-traffic-managem > ent/ [3]=20 > https://github.com/Kevsy/encrypted-traffic-management/blob/master/draf > t-smith-encrypted-traffic-management.html , use=20 > http://htmlpreview.github.io/ for easy reading >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Oct 23 10:28:53 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0798F1A8876 for ; Fri, 23 Oct 2015 10:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwiTbrZHNmn5 for ; Fri, 23 Oct 2015 10:28:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E8F1A8874 for ; Fri, 23 Oct 2015 10:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DsfYtq2XgWWlS4KgMlCrdFplaztfLBjAczmtOl0xnr0=; b=C791D8QWhICLMNMLuMei4u9Eq25JYm0CWOaXUaVqA/ILrQ9wGoxGNGaiD3/gr4zxzcGDTn/af62ApQBaPoi2v8jGpPfSfZmVKTQTqnwZvHK+74zzmNGgH9oeS77uJJpmg/1RpK6CqK4x8Yd3Fu7QecRceImJH5FNLGwsAPM58go= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.300.14; Fri, 23 Oct 2015 17:28:46 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0300.010; Fri, 23 Oct 2015 17:28:46 +0000 From: Christian Huitema To: Nikos Mavrogiannopoulos , Yoav Nir Thread-Topic: [saag] preventing denial of service in IPv6 Thread-Index: AQHRDKGB/LmbflJAaku7Z46VhUgY8553qfAAgAEi5gCAAIkyoA== Date: Fri, 23 Oct 2015 17:28:46 +0000 Message-ID: References: <56290625.25cdc20a.2aa7c.ffff9598@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.160.75] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:3R59CxvHad+cTBZc1MZR6bk2UaQd0je6MpHORZneAwFGLJgeYKn6i2QYesMANvgNPMdocjXXN9Mipu0KqALKJrT9wbLqTt9lFhvqRCShJL8xgVNSlZel5Pu7FzK3Gtv9kHTy0E5alE0ghWUt8mr5Kg==; 24:vssUkDFu1iDaRdrgTDRL+xCXjTdw1/2+IixwvZ08AYU/U1sJG4K0Mn0y6Pj23VZY/pM3z0i+3SxNZmh6O5eTPQkPh2hYpW8RG8zPsJ8m28M=; 20:k+Q+QxIE3EzLhpXBGXobbS/aQbwdE0Xu1Tyid/uIjAL2le7pTYCSurRXCs5dTCTrZY4U8mq+cJw68ln6VmPDOA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(102215026)(61426024)(61427024); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(24454002)(122556002)(87936001)(5005710100001)(97736004)(54356999)(76176999)(50986999)(33656002)(5004730100002)(11100500001)(10290500002)(5001960100002)(81156007)(66066001)(5007970100001)(5008740100001)(101416001)(10400500002)(5001770100001)(40100003)(8990500004)(86362001)(19580395003)(10090500001)(99286002)(19580405001)(86612001)(5002640100001)(106116001)(74316001)(102836002)(5003600100002)(92566002)(105586002)(77096005)(106356001)(76576001)(2900100001)(2950100001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2015 17:28:46.2841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Cc: IETF SAAG Subject: Re: [saag] preventing denial of service in IPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 17:28:51 -0000 On Friday, October 23, 2015 2:13 AM, Nikos Mavrogiannopoulos wrote: >=20 > On Thu, Oct 22, 2015 at 5:52 PM, Yoav Nir wrote: > > We've been looking at this issue for the anti-ddos draft at IPsecME. > > We haven't come up with anything better than blacklisting or limiting > > entire > > /64 networks. > > It should be noted that those /64 networks often replace non-routable > > IPv4 networks natted behind a single IP. So you had to blacklist them > > before as well. >=20 > That's a reasonable thing to do in the blurry IPv6 waters, but I don't th= ink it's > viable. A /64 network is sufficient for an ISP to use (and in fact I'm aw= are of > ISPs who hand out smaller than /64 subnets to their users), so a blanket = ban > of /64 or /48 would not be without repercussion. Given the vast amount of > addresses in such networks the collateral damage could range from > enormous (banning a whole country) to none. The ISP who handle less than /64 to their customers are not following IETF = recommendations. They should not complain about the repercussions if a sing= le misbehaving user leads to a blocked /64 and impacts many of their custom= ers. In fact, such breakage should push them to ask for a larger address bl= ock, and follow the recommended practice. =20 -- Christian Huitema From nobody Mon Oct 26 13:04:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2B71A00DB for ; Mon, 26 Oct 2015 13:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_nL4Rkckqu9 for ; Mon, 26 Oct 2015 13:04:06 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBFA1A00CD for ; Mon, 26 Oct 2015 13:04:06 -0700 (PDT) Received: by wikq8 with SMTP id q8so181270842wik.1 for ; Mon, 26 Oct 2015 13:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CyZEiJW3NDbhsz9OsuHsWTOQhePaY6vn1px/TKosjY4=; b=UtALuCQVwP6xEZxyB0ooNTOmVIcJ8INO06z+pu3KFLm6DOjk0oL0tlgTg3SMaU8TOS lpJkaT/3hW2kZmRIIYS7Dh8UhYIhzJEGxvEgTUkc3cl7UpE3pLZoh68FhN8NOAGNtQVL 4F/+8z01UhxvWYYr0HZCBMN61LNEAA9YhjUDwOiKiTea18dXXFVHHILwNFV3Olv4ADaY 4ENwpzm1cv1sUDebkP4IUPP45TZO1Ysm0bMDEe4+eSmQuZfq+UVP2rcfCSHh7ZcOYjz5 TZLpvS9TVpTpNRXsXH0qMMMLYo0RwP++75gZMolFuRFbwPxAnzGZWPfJb6Ay7mHoE40I A0lw== MIME-Version: 1.0 X-Received: by 10.194.20.135 with SMTP id n7mr22426291wje.95.1445889844643; Mon, 26 Oct 2015 13:04:04 -0700 (PDT) Received: by 10.28.214.142 with HTTP; Mon, 26 Oct 2015 13:04:04 -0700 (PDT) Date: Mon, 26 Oct 2015 16:04:04 -0400 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] SAAG Agenda X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 20:04:07 -0000 Hello, The SAAG Agenda can be found at: https://datatracker.ietf.org/meeting/94/agenda/saag/ Thank you. -- Best regards, Kathleen & Stephen From nobody Mon Oct 26 14:28:56 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B271A1ADD for ; Mon, 26 Oct 2015 14:28:55 -0700 (PDT) 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 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 WoheEOQ6ohUu for ; Mon, 26 Oct 2015 14:28:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A421A1ADB for ; Mon, 26 Oct 2015 14:28:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 25E29BE58; Mon, 26 Oct 2015 21:28:51 +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 QUF22O8NWJ1M; Mon, 26 Oct 2015 21:28:49 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.30.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2FFFABE54; Mon, 26 Oct 2015 21:28:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1445894929; bh=B5TBu8sOdAhpgJP4mFtvoPnOdAz4XF+c1rORgh/Fc5g=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pyndjq754CFirTpx42gmsUf2jmqgppbQ/VYKSGXx9ozMn2Kg8jlzMCc4LJORqmKFY PSNVQRWqlaHnGf28AEH8kpQfjzdPrJJg58eIi+821PhuFqQayYeb7yS/q1b8SW4aGL lWE1glnPBSF6gqaY3LyzFAeIiTJRfWCpJwlqgTHc= To: Ing-Wher Chen , "Kathleen.Moriarty.ietf@gmail.com" , "saag@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <562E9B0F.2050309@cs.tcd.ie> Date: Mon, 26 Oct 2015 21:28:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "aretana@cisco.com" , "db3546@att.com" , "akatlas@gmail.com" Subject: Re: [saag] advice on key table YANG module X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 21:28:55 -0000 Hi all, If folks have input to offer on this one I'm sure the authors would appreciate that. Thanks, S. On 15/10/15 18:03, Ing-Wher Chen wrote: > Dear Security ADs, > > Currently, RTGWG is trying to define a key management YANG module. > There are two competing key management YANG modules, one organizes > keys into key chains [1], and the other organizes keys as a key table > [2] based on RFC 7210 [3]. Several implementations take the first > approach, the key chain approach, and they were developed long before > the publication of RFC 7210. > > I was wondering if there is a need to continue both key-chain and > key-table YANG modules in parallel? More specifically, is there a > need to continue to work on the key-table YANG module? > > Thanks, Helen > > [1] > > > [2] > > > [3] > From nobody Mon Oct 26 14:32:34 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F87B1A1B25 for ; Mon, 26 Oct 2015 14:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMOUEF9iCnOv for ; Mon, 26 Oct 2015 14:32:32 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDE51A1B24 for ; Mon, 26 Oct 2015 14:32:32 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 39225F2417C; Mon, 26 Oct 2015 17:32:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id QdF+ES82MJWm; Mon, 26 Oct 2015 17:31:20 -0400 (EDT) Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DE406F2416E; Mon, 26 Oct 2015 17:32:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <562E9B0F.2050309@cs.tcd.ie> Date: Mon, 26 Oct 2015 17:32:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <68F2376B-4E59-476B-A6FE-099FEBD7A298@vigilsec.com> References: <562E9B0F.2050309@cs.tcd.ie> To: Stephen Farrell , Kathleen Moriarty X-Mailer: Apple Mail (2.1085) Archived-At: Cc: Alvaro Retana , Ing-Wher Chen , IETF SAAG , Deborah Brungard , Alia Atlas Subject: Re: [saag] advice on key table YANG module X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 21:32:33 -0000 I'd be willing to hel with the work related to RFC 7210 if that is the = one that will move forward. Russ On Oct 26, 2015, at 5:28 PM, Stephen Farrell wrote: >=20 > Hi all, >=20 > If folks have input to offer on this one I'm sure the authors > would appreciate that. >=20 > Thanks, > S. >=20 > On 15/10/15 18:03, Ing-Wher Chen wrote: >> Dear Security ADs, >>=20 >> Currently, RTGWG is trying to define a key management YANG module. >> There are two competing key management YANG modules, one organizes >> keys into key chains [1], and the other organizes keys as a key table >> [2] based on RFC 7210 [3]. Several implementations take the first >> approach, the key chain approach, and they were developed long before >> the publication of RFC 7210. >>=20 >> I was wondering if there is a need to continue both key-chain and >> key-table YANG modules in parallel? More specifically, is there a >> need to continue to work on the key-table YANG module? >>=20 >> Thanks, Helen >>=20 >> [1] >> >>=20 >> [2] >> >>=20 >> [3] >>=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Oct 27 07:30:57 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47311A8A71 for ; Tue, 27 Oct 2015 07:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 2FlxVo-7qxDS for ; Tue, 27 Oct 2015 07:30:50 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AC91A8A72 for ; Tue, 27 Oct 2015 07:30:50 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-2b-562f29b1af28 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 89.67.32596.1B92F265; Tue, 27 Oct 2015 08:37:21 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Tue, 27 Oct 2015 10:30:30 -0400 From: Ing-Wher Chen To: Russ Housley , Stephen Farrell , Kathleen Moriarty Thread-Topic: [saag] advice on key table YANG module Thread-Index: AdEHa2C3hAv6HkiXTLGDc5zfi/cgWAI63KqAAAAdpwAAGyeIwA== Date: Tue, 27 Oct 2015 14:30:30 +0000 Message-ID: References: <562E9B0F.2050309@cs.tcd.ie> <68F2376B-4E59-476B-A6FE-099FEBD7A298@vigilsec.com> In-Reply-To: <68F2376B-4E59-476B-A6FE-099FEBD7A298@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZXLonQXejpn6YwdFPqhavXtxkt2jYmW8x pb+TyWL63mvsDiwea7uvsnnsnHWX3WPJkp9MHqvufGENYInisklJzcksSy3St0vgyvg37yZz wTTpirt7xBsYv4p2MXJySAiYSLyf1c4CYYtJXLi3nq2LkYtDSOAIo8Satc+hnOWMEo2vz7GD VLEJGEhs+LiFCcQWEehjlLh/qw7EZhaQlWjqOAsWFxYwlujv2QBVYyJxYN0aZgjbSWLxkqtg NouAqsTnm5sZQWxeAV+J6xNPMkIsW8QoMW32ZtYuRg4OTgEHidunskBqGIGu+35qDRPELnGJ W0/mM0FcLSCxZM95ZghbVOLl43+sELaSxKSl51gh6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9Y JjCKzUIydhaSlllIWmYhaVnAyLKKkaO0OLUsN93IYBMjMJaOSbDp7mDc89LyEKMAB6MSD+8H e70wIdbEsuLK3EOMEhzMSiK8Pdn6YUK8KYmVValF+fFFpTmpxYcYpTlYlMR59y+5HyokkJ5Y kpqdmlqQWgSTZeLglGpgTF8W8k/rw8PHZmymMVuL3/9S80vw2b/qobHRy6dzTjVbnQvW/ZF9 dcaBn3PbD8eEz523cFnYriep31V0d+6e/6zF6vgDxTkNs2695GeczhhXHjBnoYBd5f1Nv3yP Zj5evHidn7RV8vxzWVsvydROWef8XJJx59kX7+/MvLBL9ZCd6qLNe8otHe8rsRRnJBpqMRcV JwIA1bfyeKECAAA= Archived-At: Cc: IETF SAAG Subject: Re: [saag] advice on key table YANG module X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 14:30:55 -0000 Thanks in advance, Russ. In terms of which version will/should move forward, here's a little more ba= ckground and some questions for the SAAG mailing list. The two YANG modules are key-chain [1] (based on existing implementations) = and key-table [2] (based on RFC 7210 [3]). The two are not identical, but = they have the same purpose---to manage routing protocol keys, and so only o= ne is necessary. I'd like some feedback from the mailing list for the foll= owing questions: Does the security community care how the keys are managed? Is there a technical reason for keys to be managed and configured exactly a= s described in RFC 7210? If there is a reason, I'll continue to work on key-table YANG module to add= ress the concerns that came up a few months ago and try to make another arg= ument for choosing key-table. (I have an update that attempts to address s= ome of those concerns, but I haven't submitted it because I'm not sure if i= t's necessary.) There's a lot of interest in key-chain because there are existing implement= ations, although all of the implementations date from before the publicatio= n of RFC 7210. (This is just my opinion, but because of the existing imple= mentations, key-chain is unlikely to be dropped, unless there's a compellin= g reason to drop it.) If the current thinking is that key-chain is also a = reasonable approach to manage keys and is equivalent to key-table, then it = is easier to just improve and standardize key-chain. [1] [2] [3] Thanks, Helen > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Monday, October 26, 2015 5:32 PM > To: Stephen Farrell; Kathleen Moriarty > Cc: Ing-Wher Chen; IETF SAAG; Alvaro Retana; Deborah Brungard; Alia Atlas > Subject: Re: [saag] advice on key table YANG module >=20 > I'd be willing to hel with the work related to RFC 7210 if that is the on= e that > will move forward. >=20 > Russ >=20 >=20 > On Oct 26, 2015, at 5:28 PM, Stephen Farrell wrote: >=20 > > > > Hi all, > > > > If folks have input to offer on this one I'm sure the authors would > > appreciate that. > > > > Thanks, > > S. > > > > On 15/10/15 18:03, Ing-Wher Chen wrote: > >> Dear Security ADs, > >> > >> Currently, RTGWG is trying to define a key management YANG module. > >> There are two competing key management YANG modules, one organizes > >> keys into key chains [1], and the other organizes keys as a key table > >> [2] based on RFC 7210 [3]. Several implementations take the first > >> approach, the key chain approach, and they were developed long before > >> the publication of RFC 7210. > >> > >> I was wondering if there is a need to continue both key-chain and > >> key-table YANG modules in parallel? More specifically, is there a > >> need to continue to work on the key-table YANG module? > >> > >> Thanks, Helen > >> > >> [1] > >> > >> > >> [2] > >> > >> > >> [3] > >> > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Oct 30 09:04:56 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964461B2D61 for ; Fri, 30 Oct 2015 09:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 brp--dsnCmIq for ; Fri, 30 Oct 2015 09:04:54 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12401B2D5C for ; Fri, 30 Oct 2015 09:04:53 -0700 (PDT) Received: by lbjm5 with SMTP id m5so53788717lbj.3 for ; Fri, 30 Oct 2015 09:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=3d4LbQgwdnuANHqBDMaEO2eRnR2YiP31+K5VgiVtr0U=; b=ORZrj+lg03txU+r6hGKomoyXs+rGtfzYkxZXq0RzOM0D37INDl/8WYLJfZGnmvTHHZ pK7tXbadK+UETWiVgNnnNEuxyQp8y2mWfndzEw4+RkQjCiyap5ivEUMMzeSloikR+nl0 1wbbyocOoM8o1TUg5nz6/3uSU1vTptoh7oQ5p3YU81GYkke5CrDxq/IgsB36zjovAK2r mgTBY8ZQrud0tPq57YesD4adoSaimf+7iiInOdaOSvdK9fOfSP7UNR2Klk8HxsR13Mmu iAs8tMCEd1rETm6+w6+dC7RuwI870Q6iBNYOj9LfNPqgemSbJiPlLLAYK9yp6iZzBrUu nXhA== MIME-Version: 1.0 X-Received: by 10.112.72.40 with SMTP id a8mr4470751lbv.55.1446221092095; Fri, 30 Oct 2015 09:04:52 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.213.75 with HTTP; Fri, 30 Oct 2015 09:04:52 -0700 (PDT) Date: Fri, 30 Oct 2015 12:04:52 -0400 X-Google-Sender-Auth: ww0bs0dn1xIda2ZItMy2U2G6E1o Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Need a public key authentication for SMTP etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 16:04:55 -0000 Note the use of the definite article. I want exactly one mechanism for authenticating SMTP, IMAP, POP3 etc server to a client. Looking at the EAP list we seem to have two dozen authentication schemes. That is no help, there should be one authentication mechanism for public key. In the proposed mode of deployment, every user will be identified by the fingerprint of their public 'master signing key' which is a long lived key that does not have a predetermined expiry. Devices assigned to a user will be identifier by a unique device key. These are bound to the master key via a certificate chain (using JSON data structures, not X.509). Since people add and remove devices periodically, these are going to change over time. So the configuration file for the mail server is likely to look something like this: alice@example.com/MCGJJ-RLX4O-EDSHN-XZBRF-DWE3L-2XW3J bob@example.com/MDDZJ-AMXZW-2XZ76-U26H3-X6TEW-KCANU ... Assume that I have an infrastructure that makes it easy to provision the keys to devices, manage application profiles and allow a relying party to obtain the necessary trust chain. The user is going to have a matching application profile something like this: "MailProfile" : { "AccountID": "alice@example.com", "Inbound" : { "Service" : "imap3.example.com", "Port" : "993", "Protocol" : "IMAP", "Transport" : "TLS", "EAP" : "XXX" } } So what to put in "XXX" ? I want one choice that provides secure authentication on the basis of a choice of RSA or DH keys that is secure against replay attack, MITM attack, etc. It is possible that we would want to use TLS client auth in addition to EAP but I am not a fan of using transport authentication for application clients. The problem being that when an accelerator is used, the binding between the authentication validation point and the application server becomes weak. Any implementation is going to require new code at the client and the server. Therefore I am expecting this would use the CFRG ECC algorithms. I would like to be able to use the same algorithm in HTTP. So if HTTP Auth actually came to any convergence then it might make most sense to use that. Of course it is quite possible that the whole field has been so hopelessly bike shedded that the best course for me is to pull out the dart board and pick one. That could be dangerous though. My darts club nickname was 'the acupuncturist'. From nobody Fri Oct 30 09:25:05 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83EE1A1B3D for ; Fri, 30 Oct 2015 09:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 JIz8OulwqB4k for ; Fri, 30 Oct 2015 09:25:01 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 499FF1A1B64 for ; Fri, 30 Oct 2015 09:25:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8E6C92240822; Fri, 30 Oct 2015 17:25:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjiO7zqf-uFo; Fri, 30 Oct 2015 17:24:56 +0100 (CET) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 736002240817; Fri, 30 Oct 2015 17:24:56 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: Date: Fri, 30 Oct 2015 12:24:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <33E77BAC-599E-402F-9470-5359465C5288@deployingradius.com> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Need a public key authentication for SMTP etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 16:25:03 -0000 On Oct 30, 2015, at 12:04 PM, Phillip Hallam-Baker = wrote: > Looking at the EAP list we seem to have two dozen authentication > schemes. That is no help, there should be one authentication mechanism > for public key. The practical choices for EAP are EAP-TLS, PEAP, and TTLS. > The user is going to have a matching application profile something = like this: >=20 > "MailProfile" : { > "AccountID": "alice@example.com", > "Inbound" : { > "Service" : "imap3.example.com", > "Port" : "993", > "Protocol" : "IMAP", > "Transport" : "TLS", > "EAP" : "XXX" > } > } >=20 > So what to put in "XXX" ? If you want to have passwords as part of this process, then PEAP or = TTLS. Personally, I'd pick TTLS. It allows for the transport of additional = data inside of the TLS tunnel, where PEAP does not. This is good for = future extensibility. > It is possible that we would want to use TLS client auth in addition > to EAP but I am not a fan of using transport authentication for > application clients. The problem being that when an accelerator is > used, the binding between the authentication validation point and the > application server becomes weak. You may also want to look at moonshot: https://wiki.moonshot.ja.net/display/HOME/Home They've added EAP authentication to a lot of applications. It's = deployed now, it works, and the code changes are surprisingly small. > I would like to be able to use the same algorithm in HTTP. So if HTTP > Auth actually came to any convergence then it might make most sense to > use that. Yes. IMHO passwords should be deprecated where possible, and systems = should be encouraged to use EAP. Alan DeKok. From nobody Fri Oct 30 10:28:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF01A9056 for ; Fri, 30 Oct 2015 10:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1xUN0W6zasE for ; Fri, 30 Oct 2015 10:28:41 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14A71A90A9 for ; Fri, 30 Oct 2015 10:28:40 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0084.outbound.protection.outlook.com [213.199.154.84]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-23-Sd4STx-MSu2Udu8fPAflUQ-1; Fri, 30 Oct 2015 17:28:35 +0000 Received: from DB3PR07MB138.eurprd07.prod.outlook.com (10.242.132.20) by DB3PR07MB137.eurprd07.prod.outlook.com (10.242.132.16) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 30 Oct 2015 17:28:33 +0000 Received: from DB3PR07MB138.eurprd07.prod.outlook.com ([169.254.16.135]) by DB3PR07MB138.eurprd07.prod.outlook.com ([169.254.16.135]) with mapi id 15.01.0312.014; Fri, 30 Oct 2015 17:28:33 +0000 From: Josh Howlett To: Alan DeKok , Phillip Hallam-Baker Thread-Topic: [saag] Need a public key authentication for SMTP etc. Thread-Index: AQHREyzLFHhDoEdieUugjKtNxqnGnJ6EOKmAgAAMgOA= Date: Fri, 30 Oct 2015 17:28:33 +0000 Message-ID: References: <33E77BAC-599E-402F-9470-5359465C5288@deployingradius.com> In-Reply-To: <33E77BAC-599E-402F-9470-5359465C5288@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.233.116.146] x-microsoft-exchange-diagnostics: 1; DB3PR07MB137; 5:lvjOKeEYCDsZY69BPrGVo5++vEvt42ROD5w/aeg6KMS3BK01VFa4Wf4i6NXGCcNnFV8yE5bBmBcLkVJ682f3INOgkKG5TeXf1j58/SB7OVslyZqNKxQ/e3coRmoT3RJI5+Tsup1RHa8yAcMOoViSNg==; 24:f44+3VmFmoWHngo7jKi4fU5YjotOEe7xmaB+3oC4sDA9YWYryVBJYU0bTjOdUaR81TMd5s/KGq7PzUBPiYF6ofnh/O6/bUIx8+NlKoEE1q0=; 20:Lk9MyCrd5Qx7oeeqpHhE10fT1VKlbGfUZoNQm7U6b6k8Of4PWLNmxHBhHGv9qB1qEdmsOvVEe0HU372D71ZJTfyz2nn6JvmDZaf+TrRrsl7v8CJhCGtbx/k/asKm7TcVkFY60xfG0oOAoDKTveeMtzd9n53G1/5T76tPQjAVxw0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB137; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(102215026); SRVR:DB3PR07MB137; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB137; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(5003600100002)(92566002)(122556002)(106356001)(74482002)(5007970100001)(5004730100002)(11100500001)(33656002)(54356999)(5002640100001)(66066001)(101416001)(76176999)(105586002)(106116001)(50986999)(40100003)(76576001)(5001960100002)(86362001)(81156007)(87936001)(5001920100001)(74316001)(5008740100001)(102836002)(2950100001)(5001770100001)(189998001)(10400500002)(2900100001)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB137; H:DB3PR07MB138.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2015 17:28:33.8645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB137 X-MC-Unique: Sd4STx-MSu2Udu8fPAflUQ-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Need a public key authentication for SMTP etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 17:28:44 -0000 > Personally, I'd pick TTLS. It allows for the transport of additional d= ata inside > of the TLS tunnel, where PEAP does not. This is good for future extensib= ility. TTLS (and PEAP) also provide anonymity, a desirable property for authentica= tion in federated scenarios (the motivation for Moonshot), whereas EAP-TLS = does not (and nor did any of the other PK based methods, when I last review= ed them). Personally I'd welcome work to address this as TTLS is pretty ine= fficient if all you need is public key authentication. We recommend the use= of TTLS for both network and application authentication to our users. Josh. Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc=E2=80=99s registered office is: One Castlepark, Tower Hil= l, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800. =20 From nobody Fri Oct 30 10:40:00 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96381B2DC2 for ; Fri, 30 Oct 2015 10:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 PBTEBBTlcmkO for ; Fri, 30 Oct 2015 10:39:57 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 343531B2DBD for ; Fri, 30 Oct 2015 10:39:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 9642F2240822; Fri, 30 Oct 2015 18:39:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WKBXnKuP-3g; Fri, 30 Oct 2015 18:39:26 +0100 (CET) Received: from [192.168.120.41] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by power.freeradius.org (Postfix) with ESMTPSA id AE4EF224075E; Fri, 30 Oct 2015 18:39:25 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Alan DeKok In-Reply-To: Date: Fri, 30 Oct 2015 13:39:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <33E77BAC-599E-402F-9470-5359465C5288@deployingradius.com> To: Josh Howlett X-Mailer: Apple Mail (2.3094) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Need a public key authentication for SMTP etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 17:39:59 -0000 On Oct 30, 2015, at 1:28 PM, Josh Howlett = wrote: > TTLS (and PEAP) also provide anonymity, a desirable property for = authentication in federated scenarios (the motivation for Moonshot), = whereas EAP-TLS does not RFC 5216 provides for EAP-TLS inside of EAP-TLS, which provides = anonymity. Alan DeKok. From nobody Fri Oct 30 10:48:36 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1E1B2DE8 for ; Fri, 30 Oct 2015 10:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 vHunxhP1N2Z5 for ; Fri, 30 Oct 2015 10:48:34 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB97A1B2DDE for ; Fri, 30 Oct 2015 10:48:33 -0700 (PDT) Received: by lbbwb3 with SMTP id wb3so55705363lbb.1 for ; Fri, 30 Oct 2015 10:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=X0JMcp3uv2PM9nVGJoISX0XMkrVGfj3wm7I8XeVnPBs=; b=UWyBl6/pC9V7DkapI5xoSZPgQdJ0mUXUd9cpG49bSbfPgwupcGZ05YqGhwTrn6OzUQ sxuNTTFrrQfY/hGCxOE0rZ2KU0Sgr0XPbYYVjlqOdmYrWN6+6Vs09ydYwezJyGPcQhZH NXphFJH/r1faY4hxTfK10I7RdmjX7jb7JeHhHaG13as/9qBPeaesk0LV/aVyEbPRV9A2 qjGgpuVn3Gzf+EjLwGs7rHWM8pkR1wcDmPkXFnd4309jFzcnMk4Rx9Z+j1Kk5yRGhpGT xECLSMVHffqZraPB0SSYcmp9BEtkmA4kAus261SLmwXbRUTslFnDlfdq0JhwxuV2f4XU frbw== MIME-Version: 1.0 X-Received: by 10.112.147.10 with SMTP id tg10mr4746881lbb.58.1446227311776; Fri, 30 Oct 2015 10:48:31 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.213.75 with HTTP; Fri, 30 Oct 2015 10:48:31 -0700 (PDT) In-Reply-To: <33E77BAC-599E-402F-9470-5359465C5288@deployingradius.com> References: <33E77BAC-599E-402F-9470-5359465C5288@deployingradius.com> Date: Fri, 30 Oct 2015 13:48:31 -0400 X-Google-Sender-Auth: AOt-TYfBu5-0cQO2POVHAmIe66g Message-ID: From: Phillip Hallam-Baker To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Need a public key authentication for SMTP etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 17:48:35 -0000 On Fri, Oct 30, 2015 at 12:24 PM, Alan DeKok wrote: > On Oct 30, 2015, at 12:04 PM, Phillip Hallam-Baker wrote: >> Looking at the EAP list we seem to have two dozen authentication >> schemes. That is no help, there should be one authentication mechanism >> for public key. > > The practical choices for EAP are EAP-TLS, PEAP, and TTLS. > >> The user is going to have a matching application profile something like this: >> >> "MailProfile" : { >> "AccountID": "alice@example.com", >> "Inbound" : { >> "Service" : "imap3.example.com", >> "Port" : "993", >> "Protocol" : "IMAP", >> "Transport" : "TLS", >> "EAP" : "XXX" >> } >> } >> >> So what to put in "XXX" ? > > If you want to have passwords as part of this process, then PEAP or TTLS. No, there are no passwords involved. The user does not have a password. The device has an RSA Keypair or a ECDHE keypair. This is only for client auth. Anonymity is not a concern as the user is logging into a named account. Alice is logging into alice@example.com to read her email. The way I see the communication going in the ideal case is that the client knows that it can use TLS a-priori and so there is no need to do a STARTTLS upgrade. So layering in a second TLS tunnel inside the first is looking Rube Goldberg to me. What I was looking for was a scheme of the form: C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH XXX C: AUTH XXX S: 334 C: S: 235 Authenticated. I was expecting that there was a mechanism that connected these directly and it would involve EAP as all the SASL mechanisms seem to be password based. This is hard core public key. No passwords. For symmetric auth, I would use SCRAM with a randomly generated 128 bit password or the like to prevent brute force attack. But that would actually be a lot harder to implement. From nobody Fri Oct 30 11:57:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4150B1B3123 for ; Fri, 30 Oct 2015 11:57:07 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6LFyPeE_f23 for ; Fri, 30 Oct 2015 11:57:05 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED591B3122 for ; Fri, 30 Oct 2015 11:57:05 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8AE8228304A; Fri, 30 Oct 2015 18:57:04 +0000 (UTC) Date: Fri, 30 Oct 2015 18:57:04 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20151030185704.GF18315@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [saag] Need a public key authentication for SMTP etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 18:57:07 -0000 On Fri, Oct 30, 2015 at 12:04:52PM -0400, Phillip Hallam-Baker wrote: > Note the use of the definite article. I want exactly one mechanism for > authenticating SMTP, IMAP, POP3 etc server to a client. > > Looking at the EAP list we seem to have two dozen authentication > schemes. That is no help, there should be one authentication mechanism > for public key. Why EAP? If this is to have a decent chance of integration with a broad range of MSAs in a reasonable timeframe, then what makes sense (for authentication) is either a SASL mechanism (channel binding with client authentication via the new PKI, or just SASL "EXTERNAL" authentication if the new PKI can be made to work as a TLS ciphersuite with client certs). > In the proposed mode of deployment, every user will be identified by > the fingerprint of their public 'master signing key' which is a long > lived key that does not have a predetermined expiry. In TLS 1.3 IIRC client certificates don't travel in the clear, so a self-signed client certificate with embedded metadata linking it to the CryptoMesh PKI would be a good way to go. The self-signed cert can be generated on the fly (and cached). NO X.509 CAs, rather a sheep in wolf's clothing (raw public key dressed in X.509 splendour). This can be supported in MSAs without dragging in new and exotic crypto libraries. Perhaps I'm missing some implicit requirements, more than happy to discuss further, and even prototype in Postfix if something practical emerges from the discussion. -- Viktor. From nobody Fri Oct 30 12:02:26 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E921A89C4 for ; Fri, 30 Oct 2015 12:02:25 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKSh16CcwHPn for ; Fri, 30 Oct 2015 12:02:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354B31A89BB for ; Fri, 30 Oct 2015 12:02:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 924FB28304A; Fri, 30 Oct 2015 19:02:23 +0000 (UTC) Date: Fri, 30 Oct 2015 19:02:23 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20151030190223.GG18315@mournblade.imrryr.org> References: <33E77BAC-599E-402F-9470-5359465C5288@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [saag] Need a public key authentication for SMTP etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 19:02:25 -0000 On Fri, Oct 30, 2015 at 01:48:31PM -0400, Phillip Hallam-Baker wrote: > I was expecting that there was a mechanism that connected these > directly and it would involve EAP as all the SASL mechanisms seem to > be password based. SASL also hash "EXTERNAL" and GSSAPI is not password based. Specifically with GS2 you can expose your new underlying mechanism as part of the negotiation: https://tools.ietf.org/html/rfc5801 then just do a suitable authenticated channel binding with the user's public key. -- Viktor. From nobody Fri Oct 30 12:41:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFD71A8AD6 for ; Fri, 30 Oct 2015 12:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 WEqqietYM7_U for ; Fri, 30 Oct 2015 12:41:25 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 775501A8AD2 for ; Fri, 30 Oct 2015 12:41:25 -0700 (PDT) Received: by lbbec13 with SMTP id ec13so58241905lbb.0 for ; Fri, 30 Oct 2015 12:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=lyJ1iETqJIcKCEucSdTOU7vZdYfAdx/QJBSHaHKZJeQ=; b=gLSdi6xMqO//siNBv3tQBBbbQiHOG6geB4RyJ+fJtbczm9JHdOaiFwpyqoTbVc9yA2 Y2+EqmLV5/QEsrJcLHlZpbN5px3sBg9ezWMqRSk8GY4JJwSdcSzISYFbVbFnweHhtcWD c+b1J/mSHw3oWcdyO1Hyqjdj+4WdFEoSbwYjdiyVdKpwVQayUUi28M3YAx+DGHG+uXoC Ab+z7SYxCmrdOxJGqhCI1DbvvoLl7EmkhSnRnM2pQeAgAYVNcdUFaglUyHMre8hVektZ kbyCJQhp6fh2Vs2HGi51AeB9IIYaANP4PBYr3QdmOjU6Z3iOrDE4UbhOPtkW0gdsWItQ 2zGg== MIME-Version: 1.0 X-Received: by 10.112.166.102 with SMTP id zf6mr4913695lbb.124.1446234083462; Fri, 30 Oct 2015 12:41:23 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.213.75 with HTTP; Fri, 30 Oct 2015 12:41:23 -0700 (PDT) In-Reply-To: <20151030185704.GF18315@mournblade.imrryr.org> References: <20151030185704.GF18315@mournblade.imrryr.org> Date: Fri, 30 Oct 2015 15:41:23 -0400 X-Google-Sender-Auth: I9g1mb-s_8-qI1ZXaC84wJTDurw Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [saag] Need a public key authentication for SMTP etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 19:41:27 -0000 On Fri, Oct 30, 2015 at 2:57 PM, Viktor Dukhovni wrote: > On Fri, Oct 30, 2015 at 12:04:52PM -0400, Phillip Hallam-Baker wrote: > >> Note the use of the definite article. I want exactly one mechanism for >> authenticating SMTP, IMAP, POP3 etc server to a client. >> >> Looking at the EAP list we seem to have two dozen authentication >> schemes. That is no help, there should be one authentication mechanism >> for public key. > > Why EAP? If this is to have a decent chance of integration with > a broad range of MSAs in a reasonable timeframe, then what makes > sense (for authentication) is either a SASL mechanism (channel > binding with client authentication via the new PKI, or just SASL > "EXTERNAL" authentication if the new PKI can be made to work as a > TLS ciphersuite with client certs). Well it was process of elimination... I couldn't find a SASL mechanism that did what I wanted so I assumed there must be an EAP. I am also looking to avoid X.509 here. Yes, even though what I showed last year was a personal PKI based on PKIX, I found that when it came to writing actual code, I could not use any of the easily accessible PKIX chain building code. It is looking to me like I should just cut a new SASL auth mechanism. >> In the proposed mode of deployment, every user will be identified by >> the fingerprint of their public 'master signing key' which is a long >> lived key that does not have a predetermined expiry. > > In TLS 1.3 IIRC client certificates don't travel in the clear, so > a self-signed client certificate with embedded metadata linking it > to the CryptoMesh PKI would be a good way to go. The self-signed > cert can be generated on the fly (and cached). NO X.509 CAs, rather > a sheep in wolf's clothing (raw public key dressed in X.509 > splendour). > > This can be supported in MSAs without dragging in new and exotic > crypto libraries. > > Perhaps I'm missing some implicit requirements, more than happy to > discuss further, and even prototype in Postfix if something practical > emerges from the discussion. Thanks, will bear that in mind. I am just finishing up the profile manager. Next step is the specs and documentation. What the Mesh does is to provide a mechanism that replicates credentials and application configuration data of any type across multiple devices using strong end-to-end cryptography. So there is a cloud service (the cryptomesh) but that isn't a trusted service except with respect to service and that exposure is bounded in time. Every device, every user, every application has separate sets of public keys, each of which is separated by function. In 1992 we could barely process chains of two certs. That isn't a concern today. The initial application for the Mesh will be to manage usernames and passwords for Web sites. So the user has six different devices and three browsers on each but they all have access to the common password profile. At the suggestion of David Clark, the next application will be SSH (and thus Git). Any machine/account you connect to your personal profile will have access to all the SSH credentials you have stored.