From dean.willis@softarmor.com Mon Sep 2 09:08:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD821E805A for ; Mon, 2 Sep 2013 09:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SWVVGD8gwtO for ; Mon, 2 Sep 2013 09:08:26 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 08BC021E8054 for ; Mon, 2 Sep 2013 09:08:25 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id cz11so3157511veb.22 for ; Mon, 02 Sep 2013 09:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=oBMT6stNX88KxcFIU2F3hIfX4TNHiTLpbP6BjPyjWSs=; b=PzANDik5mafqmpgJkzz0T/NHkD8UieIvpBVV1fuGdEjRpK37qjemRxe+l0gr7NajaV 7w/R811hAcvW75ghgWJDuuOceqo6MDciMsyfvxFNwDWDXAfPvWx/F6DRS1Mj4tc0wrJR hQHI4Fh8glZolTeoriw+aCfFRESfL0GmJpgFE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=oBMT6stNX88KxcFIU2F3hIfX4TNHiTLpbP6BjPyjWSs=; b=mxk5zcUtBB/wFTKK3k7TeiKSFW2r3aIY7IPITe4LlRPwA2UL0okp01tispc56ImBVw UGg0wW7maB1yy0KM3pCWm+dsZLOxCK1S4JGA2Jjv2bL40Q1Wa+l2jYXH3UHOVsPVITBM tu546PSxM7+pDs1nwJInfRJAMHqZ1ayg+HmM7gxLIahprPQgtVoolIA3oN+XYQCg2Vkh nAoKND2PgeU2UW/4oZuqOhunqp6xDXsI54Djbt1bnhR/zKFZj4ioiWCstQpUrQIPZQiy xFtU0I4vmfcisTaTVcn2trTlJVRQ1NOuQttRyW6N8YQaKAvJ5+Bf/BX+ishbKlnoDvXu /TOw== X-Gm-Message-State: ALoCoQn+5BhnX+G8cbDbRzm+ekb9vAThMhpVFTDrJkMjPE43tkHd9UUxZaLjQAF2AR+L3N+zAvvx MIME-Version: 1.0 X-Received: by 10.58.235.193 with SMTP id uo1mr8960724vec.6.1378138105495; Mon, 02 Sep 2013 09:08:25 -0700 (PDT) Received: by 10.58.168.180 with HTTP; Mon, 2 Sep 2013 09:08:25 -0700 (PDT) Date: Mon, 2 Sep 2013 11:08:25 -0500 Message-ID: From: Dean Willis To: perpass@ietf.org Content-Type: multipart/alternative; boundary=047d7bd6ac723ad36f04e568c828 Subject: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 16:08:27 -0000 --047d7bd6ac723ad36f04e568c828 Content-Type: text/plain; charset=ISO-8859-1 St. Peter redirected me here, which list had escaped my attention. I'm hoping it's a raging hotbed of subversive or at least somewhat paranoid activity. Because we really ought to be quite worried by now. And yes, this is really just a test message to see if I can hear myself. -- Dean --047d7bd6ac723ad36f04e568c828 Content-Type: text/html; charset=ISO-8859-1
St. Peter redirected me here, which list had escaped my attention. I'm hoping it's a raging hotbed of subversive or at least somewhat paranoid activity. Because we really ought to be quite worried by now.

And yes, this is really just a test message to see if I can hear myself.

--
Dean

--047d7bd6ac723ad36f04e568c828-- From stephen.farrell@cs.tcd.ie Mon Sep 2 11:55:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8424C21F9675 for ; Mon, 2 Sep 2013 11:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzgvZLnMTIho for ; Mon, 2 Sep 2013 11:55:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C353E21F962D for ; Mon, 2 Sep 2013 11:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 18C98BE6F; Mon, 2 Sep 2013 19:55:35 +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 L8oD6gvSMECD; Mon, 2 Sep 2013 19:55:34 +0100 (IST) Received: from [10.87.48.15] (unknown [86.41.6.141]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 23579BE61; Mon, 2 Sep 2013 19:55:34 +0100 (IST) Message-ID: <5224DF25.60503@cs.tcd.ie> Date: Mon, 02 Sep 2013 19:55:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dean Willis References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 18:55:41 -0000 Hi Dean, On 09/02/2013 05:08 PM, Dean Willis wrote: > St. Peter redirected me here, which list had escaped my attention. I'm > hoping it's a raging hotbed of subversive or at least somewhat paranoid > activity. Because we really ought to be quite worried by now. So, given you've been thinking about this for maybe longer than most I'm wondering if you have any specific protocol changes or additions you'd suggest, or descriptions of new threat models that could be useful to WGs developing or maintaining protocols? IMO, things like that would be most useful for now. > > And yes, this is really just a test message to see if I can hear myself. It worked:-) Cheers, S. > > -- > Dean > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From yakov@shaftek.org Mon Sep 2 13:02:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C085421F9B8A for ; Mon, 2 Sep 2013 13:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4AqDUV9b5oY for ; Mon, 2 Sep 2013 13:02:36 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id B924121F8DDD for ; Mon, 2 Sep 2013 13:02:35 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ib11so3440577vcb.28 for ; Mon, 02 Sep 2013 13:02:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=44B3rTZFAi7Yn0LJtOhrXrzPUUYWxdh/FuRvn7tdC9U=; b=PGB9b3HIlg4k1PrNA++Pw2SjC6jX0EXqkzXQyOiSvLnuDNp04C7o3OxTGJbWzrL0+D MGifRbNCX76iRfUqkhsncN8GTb9g7kHjfOErMA169CJn6nD3MIHdVrNloBVaAwR7CNH2 rQ92B9JRC5aQozNSCilWxn6KBLeCOVOY9954Z7mOeV63Ffz+6wa/2kBrZ6d7CiNvC4h/ b/pF5enQfrvB3qQB0UA3EBQ0MGz3P1mmxLYrxs1ksj1I5cZJ6LTOnv0PliQuVR/a+v03 dNybX46bQME4lHwUQS5gQJYgmbA3uV7NaUy8NmMlmHaCbMFqDiaFKvCWrfagJ6nSywnu dWNA== X-Gm-Message-State: ALoCoQlSPft4+tF6RPlvTkvNypXx+t0niKGYDFpQmuNmzUuNrSHnXLSb5rv97E18sdvGyNEsKDUY X-Received: by 10.58.136.4 with SMTP id pw4mr24990782veb.10.1378152154900; Mon, 02 Sep 2013 13:02:34 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.52.183.4 with HTTP; Mon, 2 Sep 2013 13:02:04 -0700 (PDT) X-Originating-IP: [96.244.132.139] From: Yakov Shafranovich Date: Mon, 2 Sep 2013 16:02:04 -0400 X-Google-Sender-Auth: Ghev9gdiRNErbAo0eH5KuEP0UoI Message-ID: To: perpass@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [perpass] Proposal for e2e email encryption X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 20:02:41 -0000 This is a followup on Jim Fenton's proposal and is somewhat inspired by Cyberpunk remailers and Tor/Onion routing. My goals are to compartmentalize the knowledge in the mail handling process to as needed only: 1. Only the author's and recipient's message user agents (MUA) have access to the full headers and body of the email. 2. Only the author's message user agent (MUA) and the receipient's message delivery agent (MDA) would know the destination mailbox of the email, and the author's domain. However, the receipient's MDA would not be able to know the sender's mailbox or see the message itself. 3. The author's message submission agent (MSA) would know the author's mailbox and how to resolve a bounced email back to the author, and the destination domain of the email, but not the recipient's mailbox or the anything in the email itself. 4. The author's message transfer agent (MTA) and all the other MTA's between the author and the recipient would only know the domain names of the author and recipient but not their individual mailboxes. They also would not be able to see what's inside the email. 5. All transactions including SMTP and local submission would require TLS/SSL as per Jim Fenton's proposal. This would work as follows: 1. Domains participating in this protocol would publish an S/MIME or PGP key in DNS, and a mailbox address to be used for secure email. 2. Authors that send email to domains participating in this protocol, would encrypt their email using S/MIME or PGP, addressing it to the recipient's mailbox. They would then encrypt the inner message a second time, wrapping it in outer envelope, addressed from the secure mailbox of the author's domain, and addressed to the secure mailbox of the recipient's domain. This should be done in the MUA, either a software client, or a browser plugin for webmail. It can also be digitally signed at that point. 3. The email would then travel via SMTP to the author's MSA, with TLS/SSL required as per Jim Fenton's proposal. At this point the author's MSA would need to record some information about the message in order to handle bounce backs. It can also be digitally signed using DKIM or similar mechanism. 4. The MSA would hand it over the MTA, using SSL/TLS, and the email would be delivered to the destination domain via one or more MTAs, addressed from the secure mailbox of the author's domain to the secure mailbox of the recipient's domain. 4. The destination domain would receive the email, unwrap the outer envelope and find the recipient's mailbox, and then deliver the message, optionally digitally signing it as well via DKIM. 5. The recipient would then unwrap the message a second time, finding the original email. In the ideal world, where all steps along the way are compliant with this protocol, everything would be encrypted with TLS/SSL for transport, and the message information itself would not reveal to any MTA who the parties are. Here are some fallback provisions: 1. If one of the MTAs along the way does not support "TLS/SSL required" for SMTP, the message would automatically be delivered via non encrypted SMTP. At that point any attacker monitoring the channel would only learn that the message is traveling from the generic "secure mailbox" of domain A to the same on domain B. With commercial providers like Gmail, etc. delivering millions of messages via this mechanism, it would be pretty hard to figure out the parties involved. Same goes if the TLS/SSL process is somehow hacked along the way, or the TLS/SSL key is obtained from the MTA via a court order. The digital signatures from the author's MSA tied to DNS would prevent MIM attacks. 2. If the receiver's MDA is compromised, the most they will learn is which domain the message came from as well but not the mailbox of the sender. In order to learn that, both the sender's MSA and the receiver's MDA would need to be compromised. In that case, the inner email is still encrypted. If multiple gateways are used, then the number of providers that need to be compromised increases. 3. If the sender's MSA does not support this protocol, the most an attacker can learn is that a message is being send from the author's mailbox but not to whom, only the domain of the destination. Additionally, one can envision the author using this protocol with any email system today, as long as the receiver's domain publishes the correct data, and the author's MUA can encrypt it. 4. This system does not assume a prior agreement between the sender's and receiver's mail providers, just like things work today. As long they publish their information in DNS, it can work. Obviously, there is still an issue of key exchange among individual users. 5. Spam and abuse are obviously an issue here. If the messages are encrypted e2e, then it would be hard to analyze them for spam, phishing, etc. 6. SSL/TLS key issues, key rotation, etc are still a problem. 7. This assumes DNS SEC. It becomes really interesting if you start doing what Tor does with multiple gateways for the message. Thanks, Yakov From yakov@shaftek.org Mon Sep 2 13:03:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650FB21F9F19 for ; Mon, 2 Sep 2013 13:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwT2hQ2WrZVk for ; Mon, 2 Sep 2013 13:03:24 -0700 (PDT) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3A79921F9B8A for ; Mon, 2 Sep 2013 13:03:24 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so3246843vbh.40 for ; Mon, 02 Sep 2013 13:03:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=OzYqiQmydJgd9zc7dmD2KOzZh/qCG5eaqhIFD/KicYw=; b=ZT/fNtRpUP8ym67zpufpjgbxugtyxPhCjqu2c0C6mJheG5vyX0ftWRa2u/hKBoMCsq D1k22G5snSBi83403PVPASE2XKgvHaVAvecCfqHt1c6uxQuxMu/HmPPibqKZKWAvqjEd APHtfZgTO/8GMcQgimI7gjAUrhRR72oNjOJDJR/YjA4+iyb7mCVRb1oTaHxRTSkg0FBW FlQCuFQup/tU2/MQD1LJN4ekqg6Yq/2HA+P49lqqcqbjv66OHXcLM3y0jpk6vDIUwd2q tOPAmwOhxz7oFTrUu08UkYVlb/8J20pHqlDDTG3KmYSrQn1mg0eG0Yr4wJKC62yuKmkn gROw== X-Gm-Message-State: ALoCoQlGDRS1aCqQ6L1bAVpHPH8TZmZPR81iEOxowYA76VvhKrCGtq30g+ibvtqcUReqnHLVgAbf X-Received: by 10.58.208.130 with SMTP id me2mr24749569vec.13.1378152202901; Mon, 02 Sep 2013 13:03:22 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.52.183.4 with HTTP; Mon, 2 Sep 2013 13:02:52 -0700 (PDT) X-Originating-IP: [96.244.132.139] From: Yakov Shafranovich Date: Mon, 2 Sep 2013 16:02:52 -0400 X-Google-Sender-Auth: lMi13KpsT4-DrNuFePRtPKKpTpk Message-ID: To: perpass@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 20:03:30 -0000 There has been some chatter about Perfect Forward Secrecy (PFS) and insufficient key rotation for SSL/TLS. Is this something that should merit discussion and perhaps an information draft with recommendations? Thanks, Yakov From ynir@checkpoint.com Mon Sep 2 13:24:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13F421F9D0E for ; Mon, 2 Sep 2013 13:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xnq6-v1FHZmE for ; Mon, 2 Sep 2013 13:24:50 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BA0AE21F9D0D for ; Mon, 2 Sep 2013 13:24:49 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r82KOl4n027609; Mon, 2 Sep 2013 23:24:47 +0300 X-CheckPoint: {5224F40F-10-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Mon, 2 Sep 2013 23:24:47 +0300 From: Yoav Nir To: Dean Willis Thread-Topic: [perpass] Howdy! Thread-Index: AQHOp/avvVIFHENAPEWCE6HrojFNK5mysreA Date: Mon, 2 Sep 2013 20:24:47 +0000 Message-ID: <453E9A60-9959-4219-8EA5-54708565B1C2@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.48] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: <663978D85C3DD54CA21E273508ABC4B4@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 20:24:55 -0000 On Sep 2, 2013, at 7:08 PM, Dean Willis wrote: > St. Peter redirected me here, which list had escaped my attention. I'm ho= ping it's a raging hotbed of subversive or at least somewhat paranoid activ= ity. Half of us are subversive; the other half are spooks spying on the subversi= ve element. The question is, do you know which is which? > Because we really ought to be quite worried by now. >=20 > And yes, this is really just a test message to see if I can hear myself. Yeah, you can hear yourself. Also, *they* can hear you. OK. That's not too = difficult on a public mailing list with a public archive. We can't each and every one of us defeat the well-funded, well-equipped, an= d well trained adversaries who are willing to go to great lengths to spy on= us. At worst, they can break into your home ([1]). But that kind of expens= e doesn't scale. Even the TLAs don't have the resources to do this to billi= ons or even millions of people.=20 If we can raise the bar so that their resources are only enough to spy on, = say, 100,000 people, then I (please forgive me for being so self-centered),= and probably you, are off the hook. There's likely to be at least 100,000 = people who are perceived to be more dangerous to whatever country's nationa= l security. Yeah, it still sucks to be number 99.999 on this list of allege= d criminals and terrorists, but it's way better for the rest of us. So the question remains, do we have the ability to allow private communicat= ions between parties, such that the protection won't stand out? Can we allo= w anonymous or pseudonymous public speaking that won't be traceable by tech= nological means? Can we make it so that Internet-based services default to = private? Pretty much no constitution or declaration of rights protects people agains= t surveillance. That is because surveillance used to be so expensive, that = it was never abused or done on a large scale. Compare that to the US 3rd am= endment, prohibiting the quartering of soldiers in private houses. Nobody w= ould prohibit this today, because it's just not done anymore, but it probab= ly was in those days. Perhaps the right to be free from mass surveillance, = both governmental and private without due process should be codified in nat= ional constitutions, but that is not something that the IETF has any say in= .=20 Yoav [1] http://www.foreignpolicy.com/articles/2013/07/16/the_cias_new_black_bag= _is_digital_nsa_cooperation From npdoty@berkeley.edu Mon Sep 2 17:17:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1317621F9D7E for ; Mon, 2 Sep 2013 17:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYUrDCyjTGVU for ; Mon, 2 Sep 2013 17:17:32 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id D039C21F9D66 for ; Mon, 2 Sep 2013 17:17:32 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so5264395pdi.19 for ; Mon, 02 Sep 2013 17:17:32 -0700 (PDT) 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:message-id:references:to; bh=wtvp5ekMDrMH4IdXcnzDgN9/aka+nSCMPPUPIr5iUR8=; b=GUx2I3gmY9Uh8qtiuV7619YrdGiXDZRD+FpCnR9NwCB3xqY+uJNYh/5RXFl0zxF2Od 71FOxWISZ03wPyZ0O8/P71QJIslZNxgK37BtY7+jB5xBbfGf8Ks0zEzMEHnae3Kw/ntp qtwBwJX231TlVzbU7Al9gUpJNtkKsmXlYHQk642TnXXFmgAWiD2Q19tXi+h1mEUzO/G7 rNmoH8ix3UpykAqTg19m5S7tG+Gib+MzDR6HoceY2ZG+MiOu/Sx9iBNUgqbBbwP5lc0h QqI6g+zd2gvzHHU0UP/jjZLuVqdEo1YnhaNV6E2ec8l9fqGZHXVysweYe9bUuWY0soba M7Cg== X-Gm-Message-State: ALoCoQnI+fq/sb+B1cIznNSsBK89pAWi0mYAaN5kZbF22kwWXXo/GIeHdg9CL113MfSiAjKxSbDD X-Received: by 10.68.244.168 with SMTP id xh8mr27840515pbc.3.1378167452455; Mon, 02 Sep 2013 17:17:32 -0700 (PDT) Received: from [192.168.43.102] (mb80536d0.tmodns.net. [208.54.5.184]) by mx.google.com with ESMTPSA id ye1sm19903528pab.19.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Sep 2013 17:17:31 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E2E72511-373D-4D84-B2B9-327DE4754D15"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Nick Doty In-Reply-To: Date: Mon, 2 Sep 2013 17:17:31 -0700 Message-Id: References: To: Yakov Shafranovich X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] Proposal for e2e email encryption X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 00:23:06 -0000 --Apple-Mail=_E2E72511-373D-4D84-B2B9-327DE4754D15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I don't consider myself qualified to comment on all the details of your = proposed protocol, but I find one property interesting. Encrypting email = for a domain (and then separately for a user) can help with the problem = of metadata revealing our communication partners, but only to the extent = that domains are shared by lots of people. For those of us who maintain = personal domain names, knowing that an email comes from a particular = domain sufficiently identifies an individual author; e.g., emails sent = from any address @npdoty.name always come from me. Revelations about NSA = activities and user privacy concerns have created some renewed interest = in owning one's own email address (for example [0]). It would be = surprising (and I think, unfortunate) if advice was to *avoid* using = personalized domains or services in order to support a privacy model. The question of centralization/decentralization in this case might help = us clarify the threat model. A common privacy concern of centralization = is that a governmental adversary can compel that single bottleneck to = reveal the contents, or in this case, the to/from information of many = communications. If we all use @foo.com email addresses but Foo Inc. is = compelled by a PRISM-like program to allow an adversary to search for = who is emailing whom, then the proposed protocol may not provide an = advantage. On the other hand, if the adversary is inspecting unencrypted = traffic diverted from a backbone provider, then anonymizing recipients = down to the foo.com domain name could provide a real advantage. =97Nick [0] https://konklone.com/post/take-control-of-your-email-address On Sep 2, 2013, at 1:02 PM, Yakov Shafranovich = wrote: > This is a followup on Jim Fenton's proposal and is somewhat inspired > by Cyberpunk remailers and Tor/Onion routing. >=20 > My goals are to compartmentalize the knowledge in the mail handling > process to as needed only: >=20 > 1. Only the author's and recipient's message user agents (MUA) have > access to the full headers and body of the email. >=20 > 2. Only the author's message user agent (MUA) and the receipient's > message delivery agent (MDA) would know the destination mailbox of the > email, and the author's domain. However, the receipient's MDA would > not be able to know the sender's mailbox or see the message itself. >=20 > 3. The author's message submission agent (MSA) would know the author's > mailbox and how to resolve a bounced email back to the author, and the > destination domain of the email, but not the recipient's mailbox or > the anything in the email itself. >=20 > 4. The author's message transfer agent (MTA) and all the other MTA's > between the author and the recipient would only know the domain names > of the author and recipient but not their individual mailboxes. They > also would not be able to see what's inside the email. >=20 > 5. All transactions including SMTP and local submission would require > TLS/SSL as per Jim Fenton's proposal. >=20 > This would work as follows: > 1. Domains participating in this protocol would publish an S/MIME or > PGP key in DNS, and a mailbox address to be used for secure email. >=20 > 2. Authors that send email to domains participating in this protocol, > would encrypt their email using S/MIME or PGP, addressing it to the > recipient's mailbox. They would then encrypt the inner message a > second time, wrapping it in outer envelope, addressed from the secure > mailbox of the author's domain, and addressed to the secure mailbox of > the recipient's domain. This should be done in the MUA, either a > software client, or a browser plugin for webmail. It can also be > digitally signed at that point. >=20 > 3. The email would then travel via SMTP to the author's MSA, with > TLS/SSL required as per Jim Fenton's proposal. At this point the > author's MSA would need to record some information about the message > in order to handle bounce backs. It can also be digitally signed using > DKIM or similar mechanism. >=20 > 4. The MSA would hand it over the MTA, using SSL/TLS, and the email > would be delivered to the destination domain via one or more MTAs, > addressed from the secure mailbox of the author's domain to the secure > mailbox of the recipient's domain. >=20 > 4. The destination domain would receive the email, unwrap the outer > envelope and find the recipient's mailbox, and then deliver the > message, optionally digitally signing it as well via DKIM. >=20 > 5. The recipient would then unwrap the message a second time, finding > the original email. >=20 > In the ideal world, where all steps along the way are compliant with > this protocol, everything would be encrypted with TLS/SSL for > transport, and the message information itself would not reveal to any > MTA who the parties are. >=20 > Here are some fallback provisions: >=20 > 1. If one of the MTAs along the way does not support "TLS/SSL > required" for SMTP, the message would automatically be delivered via > non encrypted SMTP. At that point any attacker monitoring the channel > would only learn that the message is traveling from the generic > "secure mailbox" of domain A to the same on domain B. With commercial > providers like Gmail, etc. delivering millions of messages via this > mechanism, it would be pretty hard to figure out the parties involved. > Same goes if the TLS/SSL process is somehow hacked along the way, or > the TLS/SSL key is obtained from the MTA via a court order. The > digital signatures from the author's MSA tied to DNS would prevent MIM > attacks. >=20 > 2. If the receiver's MDA is compromised, the most they will learn is > which domain the message came from as well but not the mailbox of the > sender. In order to learn that, both the sender's MSA and the > receiver's MDA would need to be compromised. In that case, the inner > email is still encrypted. If multiple gateways are used, then the > number of providers that need to be compromised increases. >=20 > 3. If the sender's MSA does not support this protocol, the most an > attacker can learn is that a message is being send from the author's > mailbox but not to whom, only the domain of the destination. > Additionally, one can envision the author using this protocol with any > email system today, as long as the receiver's domain publishes the > correct data, and the author's MUA can encrypt it. >=20 > 4. This system does not assume a prior agreement between the sender's > and receiver's mail providers, just like things work today. As long > they publish their information in DNS, it can work. Obviously, there > is still an issue of key exchange among individual users. >=20 > 5. Spam and abuse are obviously an issue here. If the messages are > encrypted e2e, then it would be hard to analyze them for spam, > phishing, etc. >=20 > 6. SSL/TLS key issues, key rotation, etc are still a problem. >=20 > 7. This assumes DNS SEC. >=20 > It becomes really interesting if you start doing what Tor does with > multiple gateways for the message. >=20 > Thanks, > Yakov > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_E2E72511-373D-4D84-B2B9-327DE4754D15 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSJSqbAAoJEEAgPukLurMGfjIH/ReeFUaiPBCEjboNkM6Q05GY HOt9LFgoYsVYF9RyUXhl4pMhtfOj7Bp3mlgwaNTLKRstOeng/QDw+2OtNx2fnYmQ nCS+UicCBsTMc+JWKa2HQA65mECcEHbgdBpGOGtX46ciAr6njnYtO6e+H1AW9+NK iS2Fr/lkX94ZHD4vQ/KI/onvdbSM6xjg1q3Okv+phTdknpFrURt8bEmxD2VWT6G8 HhJUxQjJRbp9wqwpj1OYWjo2iyi3UYB4QAVAO/OFASbqzScYCGaJp4qPGMDr8U5c pYzqeH5oOrYYCgu1FwI1/xGPFdTtYMhH8HYd8T3ymLr8s2HESHDHUq1IcDlGG3Y= =uBuw -----END PGP SIGNATURE----- --Apple-Mail=_E2E72511-373D-4D84-B2B9-327DE4754D15-- From yakov@shaftek.org Mon Sep 2 17:37:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5048D21F9DAF for ; Mon, 2 Sep 2013 17:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yov0vHe19RfK for ; Mon, 2 Sep 2013 17:37:47 -0700 (PDT) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id D166321F9E0A for ; Mon, 2 Sep 2013 17:37:46 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id e15so3337705vbg.4 for ; Mon, 02 Sep 2013 17:37:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=uhvc73MF0mClAUm2Ok0hfPRZZyCowwbalJF1p+uKlYg=; b=E+1VGUSm4JuNP8XFmEqGbnYydK3hs3e0Il1d+2Dfws1r9CUE9XWvQKSgzZsg0vTnS7 e02mabAp27v7BciNQt3ltYJnKJ0pVDE3a3uZoOpcXnmoi05kY8r0mzRFUF65aDGOhbnH 09wzZDricXDARXxAxpz8uXNCNdPjYsTRwe9mzMxyNrdKowClwPqqJRti6e3CKqQQVatR oolJ263SMjWm857DzB0IPX0Ib2Mjk4xO8ygY+OhJww0gfFRS58yx8mthW2OWFI4v9ISO QoxvOFPiTGcw58NmdjR3g7Gv8iiDytXQjXSuwaXrzPg+Ro8bKtj+2gG9qYUeZCMBXlTZ YLqA== X-Gm-Message-State: ALoCoQnjGUnoDlIiGvFueTyJPtC0sLJX4eBndl2z6r0jbWJ+HjCfe495btljsYQI5Ue0VdOVF4XM X-Received: by 10.58.137.167 with SMTP id qj7mr25323274veb.1.1378168666171; Mon, 02 Sep 2013 17:37:46 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.52.183.4 with HTTP; Mon, 2 Sep 2013 17:37:15 -0700 (PDT) X-Originating-IP: [96.244.132.139] In-Reply-To: References: From: Yakov Shafranovich Date: Mon, 2 Sep 2013 20:37:15 -0400 X-Google-Sender-Auth: UQ8gY1fhwSAlB4QwIZp1MfIlUIU Message-ID: To: Nick Doty Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: perpass@ietf.org Subject: Re: [perpass] Proposal for e2e email encryption X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 00:37:52 -0000 Even for personal domains often another larger party handles the email traffic. Just like SPF, DKIM, SMTP information, etc. today can point to another provider, you can point to another provider as handling the secure email for you. For example, if your personal domain handles its own email but uses something like LavaBit for secure email, you can point to them via DNS. The actual email traveling would be addressed to "secure@lavabit" as opposed to your domain. Of course there would be a question of securing the DNS lookup itself. Regarding centralization, the nice thing about this proposal is that if an ISP is compromised, whether by a hacker or the government, the amount of leaked data would be limited. For the sender's ISP, only which domains email is being sent to would be known. For the receiver ISP only which domains email is coming from and for what user. The MTAs in between only see domains and not even users. It would take effort to control both the sender and the receiver's ISP in order to see the email traffic, and in that case, the inner layer of encryption would still protect the message. Thanks, Yakov On Mon, Sep 2, 2013 at 8:17 PM, Nick Doty wro= te: > I don't consider myself qualified to comment on all the details of your p= roposed protocol, but I find one property interesting. Encrypting email for= a domain (and then separately for a user) can help with the problem of met= adata revealing our communication partners, but only to the extent that dom= ains are shared by lots of people. For those of us who maintain personal do= main names, knowing that an email comes from a particular domain sufficient= ly identifies an individual author; e.g., emails sent from any address @npd= oty.name always come from me. Revelations about NSA activities and user pri= vacy concerns have created some renewed interest in owning one's own email = address (for example [0]). It would be surprising (and I think, unfortunate= ) if advice was to *avoid* using personalized domains or services in order = to support a privacy model. > > The question of centralization/decentralization in this case might help u= s clarify the threat model. A common privacy concern of centralization is t= hat a governmental adversary can compel that single bottleneck to reveal th= e contents, or in this case, the to/from information of many communications= . If we all use @foo.com email addresses but Foo Inc. is compelled by a PRI= SM-like program to allow an adversary to search for who is emailing whom, t= hen the proposed protocol may not provide an advantage. On the other hand, = if the adversary is inspecting unencrypted traffic diverted from a backbone= provider, then anonymizing recipients down to the foo.com domain name coul= d provide a real advantage. > > =97Nick > > [0] https://konklone.com/post/take-control-of-your-email-address > > On Sep 2, 2013, at 1:02 PM, Yakov Shafranovich w= rote: > >> This is a followup on Jim Fenton's proposal and is somewhat inspired >> by Cyberpunk remailers and Tor/Onion routing. >> >> My goals are to compartmentalize the knowledge in the mail handling >> process to as needed only: >> >> 1. Only the author's and recipient's message user agents (MUA) have >> access to the full headers and body of the email. >> >> 2. Only the author's message user agent (MUA) and the receipient's >> message delivery agent (MDA) would know the destination mailbox of the >> email, and the author's domain. However, the receipient's MDA would >> not be able to know the sender's mailbox or see the message itself. >> >> 3. The author's message submission agent (MSA) would know the author's >> mailbox and how to resolve a bounced email back to the author, and the >> destination domain of the email, but not the recipient's mailbox or >> the anything in the email itself. >> >> 4. The author's message transfer agent (MTA) and all the other MTA's >> between the author and the recipient would only know the domain names >> of the author and recipient but not their individual mailboxes. They >> also would not be able to see what's inside the email. >> >> 5. All transactions including SMTP and local submission would require >> TLS/SSL as per Jim Fenton's proposal. >> >> This would work as follows: >> 1. Domains participating in this protocol would publish an S/MIME or >> PGP key in DNS, and a mailbox address to be used for secure email. >> >> 2. Authors that send email to domains participating in this protocol, >> would encrypt their email using S/MIME or PGP, addressing it to the >> recipient's mailbox. They would then encrypt the inner message a >> second time, wrapping it in outer envelope, addressed from the secure >> mailbox of the author's domain, and addressed to the secure mailbox of >> the recipient's domain. This should be done in the MUA, either a >> software client, or a browser plugin for webmail. It can also be >> digitally signed at that point. >> >> 3. The email would then travel via SMTP to the author's MSA, with >> TLS/SSL required as per Jim Fenton's proposal. At this point the >> author's MSA would need to record some information about the message >> in order to handle bounce backs. It can also be digitally signed using >> DKIM or similar mechanism. >> >> 4. The MSA would hand it over the MTA, using SSL/TLS, and the email >> would be delivered to the destination domain via one or more MTAs, >> addressed from the secure mailbox of the author's domain to the secure >> mailbox of the recipient's domain. >> >> 4. The destination domain would receive the email, unwrap the outer >> envelope and find the recipient's mailbox, and then deliver the >> message, optionally digitally signing it as well via DKIM. >> >> 5. The recipient would then unwrap the message a second time, finding >> the original email. >> >> In the ideal world, where all steps along the way are compliant with >> this protocol, everything would be encrypted with TLS/SSL for >> transport, and the message information itself would not reveal to any >> MTA who the parties are. >> >> Here are some fallback provisions: >> >> 1. If one of the MTAs along the way does not support "TLS/SSL >> required" for SMTP, the message would automatically be delivered via >> non encrypted SMTP. At that point any attacker monitoring the channel >> would only learn that the message is traveling from the generic >> "secure mailbox" of domain A to the same on domain B. With commercial >> providers like Gmail, etc. delivering millions of messages via this >> mechanism, it would be pretty hard to figure out the parties involved. >> Same goes if the TLS/SSL process is somehow hacked along the way, or >> the TLS/SSL key is obtained from the MTA via a court order. The >> digital signatures from the author's MSA tied to DNS would prevent MIM >> attacks. >> >> 2. If the receiver's MDA is compromised, the most they will learn is >> which domain the message came from as well but not the mailbox of the >> sender. In order to learn that, both the sender's MSA and the >> receiver's MDA would need to be compromised. In that case, the inner >> email is still encrypted. If multiple gateways are used, then the >> number of providers that need to be compromised increases. >> >> 3. If the sender's MSA does not support this protocol, the most an >> attacker can learn is that a message is being send from the author's >> mailbox but not to whom, only the domain of the destination. >> Additionally, one can envision the author using this protocol with any >> email system today, as long as the receiver's domain publishes the >> correct data, and the author's MUA can encrypt it. >> >> 4. This system does not assume a prior agreement between the sender's >> and receiver's mail providers, just like things work today. As long >> they publish their information in DNS, it can work. Obviously, there >> is still an issue of key exchange among individual users. >> >> 5. Spam and abuse are obviously an issue here. If the messages are >> encrypted e2e, then it would be hard to analyze them for spam, >> phishing, etc. >> >> 6. SSL/TLS key issues, key rotation, etc are still a problem. >> >> 7. This assumes DNS SEC. >> >> It becomes really interesting if you start doing what Tor does with >> multiple gateways for the message. >> >> Thanks, >> Yakov >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > From code@funwithsoftware.org Mon Sep 2 23:41:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8452111E8193 for ; Mon, 2 Sep 2013 23:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HyFlpoJy2p7 for ; Mon, 2 Sep 2013 23:41:51 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 62B5011E818E for ; Mon, 2 Sep 2013 23:41:50 -0700 (PDT) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.39]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id E7BB81EE511F for ; Tue, 3 Sep 2013 02:41:45 -0400 (EDT) Received: (qmail 14766 invoked from network); 3 Sep 2013 06:41:45 -0000 Received: by simscan 1.4.0 ppid: 31326, pid: 7148, t: 2.0903s scanners: clamav: m: Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 3 Sep 2013 06:41:43 -0000 Message-Id: <66BFDF4E-52DE-407B-8BF7-928F848CB149@funwithsoftware.org> From: Patrick Pelletier To: perpass@ietf.org In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-12-451342203 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Sep 2013 23:41:40 -0700 References: X-Mailer: Apple Mail (2.936) Subject: Re: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 06:41:56 -0000 --Apple-Mail-12-451342203 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I'd definitely like to see such a thing. I feel like PFS in TLS is a bit fragmented since not everyone is ready to jump on the ECDHE bandwagon: https://bugzilla.redhat.com/show_bug.cgi?id=319901 but the situation with plain old DHE is not that great, since server software often uses ridiculously small prime sizes, and makes it hard for the user to configure larger ones: http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html and even if the server is willing to use a larger Diffie-Hellman prime, the problem is that clients often don't support larger primes either, and the server has no way to know what the client is willing to accept. Older (but still in use) versions of Java, and apparently also Windows, only support 1024 bit Diffie-Hellman (see above ivanristic URL for references on these), which of course is generally considered too small to be secure today. And until recently, NSS only supported prime sizes up to 2236 bits: https://bugzilla.mozilla.org/show_bug.cgi?id=636802 If the server chooses a prime size larger than the client can handle, the handshake will fail. I still think we need a TLS extension so that the client can tell the server what prime sizes it will accept (perhaps in the form of min/max/multiple), with the server assuming something conservative like 1024 (even though that is sadly inadequate) if the client doesn't send the extension: http://lists.gnutls.org/pipermail/gnutls-help/2012-May/002748.html But besides a TLS extension, I think what you suggest is good, some sort of informational RFC that would recommend "best practices" for PFS, e. g. something along the lines of "put ECDHE cipher suites first (for performance and so Java won't choke on DHE), make sure you support at least secp256r1 and secp384r1, put DHE cipher suites second, use a prime size of 2176 bits (largest multiple of 64 less than 2236)" or whatever. Also perhaps some recommendations (and maybe this is what you're getting at with key rotation) about how (and whether) to make use of session resumption, and especially session tickets, when PFS is desired, since these can weaken it. --Patrick On Sep 2, 2013, at 5:37 PM, perpass-request@ietf.org wrote: > From: Yakov Shafranovich > Date: September 2, 2013 1:02:52 PM PDT > To: perpass@ietf.org > Subject: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation > > > There has been some chatter about Perfect Forward Secrecy (PFS) and > insufficient key rotation for SSL/TLS. Is this something that should > merit discussion and perhaps an information draft with > recommendations? > > Thanks, > Yakov --Apple-Mail-12-451342203 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
I'd definitely like = to see such a thing.  I feel like PFS in TLS is a bit fragmented = since not everyone is ready to jump on the ECDHE = bandwagon:


but = the situation with plain old DHE is not that great, since server = software often uses ridiculously small prime sizes, and makes it hard = for the user to configure larger ones:


and even if the server is willing = to use a larger Diffie-Hellman prime, the problem is that clients often = don't support larger primes either, and the server has no way to know = what the client is willing to accept.  Older (but still in use) = versions of Java, and apparently also Windows, only support 1024 bit = Diffie-Hellman (see above ivanristic URL for references on these), which = of course is generally considered too small to be secure today. =  And until recently, NSS only supported prime sizes up to 2236 = bits:


If= the server chooses a prime size larger than the client can handle, the = handshake will fail.  I still think we need a TLS extension so that = the client can tell the server what prime sizes it will accept (perhaps = in the form of min/max/multiple), with the server assuming something = conservative like 1024 (even though that is sadly inadequate) if the = client doesn't send the extension:

http://lists.gnutls.org/pipermail/gnutls-help/2012-May/002748.html

But besides a TLS extension, I think what you = suggest is good, some sort of informational RFC that would recommend = "best practices" for PFS, e. g. something along the lines of "put ECDHE = cipher suites first (for performance and so Java won't choke on DHE), = make sure you support at least secp256r1 and secp384r1, put DHE cipher = suites second, use a prime size of 2176 bits (largest multiple of = 64 less than 2236)" or whatever.

Also perhaps = some recommendations (and maybe this is what you're getting at with key = rotation) about how (and whether) to make use of session resumption, and = especially session tickets, when PFS is desired, since these can weaken = it.

--Patrick


=
On Sep 2, 2013, at 5:37 PM, perpass-request@ietf.org = wrote:

From: Yakov Shafranovich <yakov-ietf@shaftek.org>
Date: September 2, 2013 = 1:02:52 PM PDT
Subject: = [perpass] TLS/SSL Perfect Forward Secrecy and Key = Rotation


There has been some chatter about = Perfect Forward Secrecy (PFS) and
insufficient key rotation for = SSL/TLS. Is this something that should
merit discussion and perhaps = an information draft = with
recommendations?

Thanks,
Yakov
= --Apple-Mail-12-451342203-- From stephen.farrell@cs.tcd.ie Tue Sep 3 02:31:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A90711E81B0 for ; Tue, 3 Sep 2013 02:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTo4vRtsie6k for ; Tue, 3 Sep 2013 02:31:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66521F8D90 for ; Tue, 3 Sep 2013 02:31:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B7BEEBE76; Tue, 3 Sep 2013 10:31:46 +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 I6ETl3kr0sD3; Tue, 3 Sep 2013 10:31:46 +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 923D5BE75; Tue, 3 Sep 2013 10:31:46 +0100 (IST) Message-ID: <5225AC82.20006@cs.tcd.ie> Date: Tue, 03 Sep 2013 10:31:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Patrick Pelletier , yakov-ietf@shaftek.org References: <66BFDF4E-52DE-407B-8BF7-928F848CB149@funwithsoftware.org> In-Reply-To: <66BFDF4E-52DE-407B-8BF7-928F848CB149@funwithsoftware.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 09:31:54 -0000 Patrick, Yakov, The TLS PFS stuff sounds to me like a fine internet draft. Why don't you two go write it up as one? Then when the -00 version is out, ask if the TLS wg want to adopt it as a work item. If they don't want to do the work within the wg, but don't object to it being done, then I'd take a look at AD sponsoring it. But either way, I'd expect that if it had reasonable content then we should be able to turn it into an RFC without too much pain. As to content, it'd maybe be better to keep the BCP like bits separate from any new TLS extension definition but if you think they belong together just do that for the -00 version and it can be sorted out later if need be. Feel free to ask me off-list if you need any help with how to go about getting that done. And assuming Patrick and Yakov can take this on, I'm sure they'd be interested in hearing from anyone else who'd like to help do the work. Cheers, S. PS: If this works out, it'd nicely fit what Sean and I hoped would be the modus operandi for this list - find a concrete thing that can be improved, (plus some victims willing to do the work:-), get that turned into an internet-draft, and then Sean and I can help figure out how to fit it into some IETF WG or get it AD sponsored. More examples are very welcome. On 09/03/2013 07:41 AM, Patrick Pelletier wrote: > I'd definitely like to see such a thing. I feel like PFS in TLS is a > bit fragmented since not everyone is ready to jump on the ECDHE bandwagon: > > https://bugzilla.redhat.com/show_bug.cgi?id=319901 > > but the situation with plain old DHE is not that great, since server > software often uses ridiculously small prime sizes, and makes it hard > for the user to configure larger ones: > > http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html > > and even if the server is willing to use a larger Diffie-Hellman prime, > the problem is that clients often don't support larger primes either, > and the server has no way to know what the client is willing to accept. > Older (but still in use) versions of Java, and apparently also Windows, > only support 1024 bit Diffie-Hellman (see above ivanristic URL for > references on these), which of course is generally considered too small > to be secure today. And until recently, NSS only supported prime sizes > up to 2236 bits: > > https://bugzilla.mozilla.org/show_bug.cgi?id=636802 > > If the server chooses a prime size larger than the client can handle, > the handshake will fail. I still think we need a TLS extension so that > the client can tell the server what prime sizes it will accept (perhaps > in the form of min/max/multiple), with the server assuming something > conservative like 1024 (even though that is sadly inadequate) if the > client doesn't send the extension: > > http://lists.gnutls.org/pipermail/gnutls-help/2012-May/002748.html > > But besides a TLS extension, I think what you suggest is good, some sort > of informational RFC that would recommend "best practices" for PFS, e. > g. something along the lines of "put ECDHE cipher suites first (for > performance and so Java won't choke on DHE), make sure you support at > least secp256r1 and secp384r1, put DHE cipher suites second, use a prime > size of 2176 bits (largest multiple of 64 less than 2236)" or whatever. > > Also perhaps some recommendations (and maybe this is what you're getting > at with key rotation) about how (and whether) to make use of session > resumption, and especially session tickets, when PFS is desired, since > these can weaken it. > > --Patrick > > > On Sep 2, 2013, at 5:37 PM, perpass-request@ietf.org wrote: > >> From: Yakov Shafranovich >> Date: September 2, 2013 1:02:52 PM PDT >> To: perpass@ietf.org >> Subject: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation >> >> >> There has been some chatter about Perfect Forward Secrecy (PFS) and >> insufficient key rotation for SSL/TLS. Is this something that should >> merit discussion and perhaps an information draft with >> recommendations? >> >> Thanks, >> Yakov > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From yakov@shaftek.org Tue Sep 3 05:12:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5961C21E8128 for ; Tue, 3 Sep 2013 05:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZrTLeR0v70t for ; Tue, 3 Sep 2013 05:12:14 -0700 (PDT) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD1121E8123 for ; Tue, 3 Sep 2013 05:12:11 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so3720983vbh.26 for ; Tue, 03 Sep 2013 05:12:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=zfGEpGyo7nf6JuhBr0l9nlc7s+39ABysRzj3lRf+wF8=; b=CpSnO/eN5qMm+ukRZyjruvLxF4gKum6dZxwqXY3HP8QNoPR3cMwI5fjI4aEYi4aKeJ RIwrnqoI/79DemacrJPXGR280ndJ9BdTMjHmfOQak5ackqmizj3k15Bdo1fNV/ESMU3F dBGvTmb6NaHausksKa5SR0mNdtsVi3qwg2q72fHOClugNN784Hc7bD3mcRqDEqNLBQM5 LGhcGEdbjd++Qt6pURI5la4HfftIjMZkyK3HG8mV1W2X4LI2r9ziZzTSkiOXy4O96HoJ o0lqR9/m41TyAst44f5L/aVlX/w0A9gI0dsOKdtpMMZtQCHp34+OVx7fqK4yz70RORVZ HA6A== X-Gm-Message-State: ALoCoQlhT4Ms6JaI5GxWI0KwMlrj/BnCJiMETcp3hUn8XMO+h9jlOORJXaivz+K3Itp7ccfLZKE6 X-Received: by 10.220.10.194 with SMTP id q2mr27726685vcq.2.1378210329716; Tue, 03 Sep 2013 05:12:09 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.52.183.4 with HTTP; Tue, 3 Sep 2013 05:11:39 -0700 (PDT) X-Originating-IP: [96.244.132.139] In-Reply-To: <66BFDF4E-52DE-407B-8BF7-928F848CB149@funwithsoftware.org> References: <66BFDF4E-52DE-407B-8BF7-928F848CB149@funwithsoftware.org> From: Yakov Shafranovich Date: Tue, 3 Sep 2013 08:11:39 -0400 X-Google-Sender-Auth: MXMKV3HkKbbrvcwBrdqnQAdJvKU Message-ID: To: Patrick Pelletier Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass@ietf.org Subject: Re: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 12:12:19 -0000 In addition to PFS, there is also a larger issue of SSL key rotation. PFS is really a means to get to a session key that gets generated every time. We have a separate issue with those not using PFS like plain RSA, etc. where they key is not rotated often enough. Assuming an attacker has access to the server's key, they can decrypt everyone's traffic. The CA/browser forum has begun some steps in this direction by lowering validity of SSL server certificates to 18 months. Is there a place for a discussion on recommending a lower time period for key rotation with the ensuing implications for those who do not want/can not use PFS? Thanks On Tue, Sep 3, 2013 at 2:41 AM, Patrick Pelletier wrote: > I'd definitely like to see such a thing. I feel like PFS in TLS is a bit > fragmented since not everyone is ready to jump on the ECDHE bandwagon: > > https://bugzilla.redhat.com/show_bug.cgi?id=319901 > > but the situation with plain old DHE is not that great, since server > software often uses ridiculously small prime sizes, and makes it hard for > the user to configure larger ones: > > http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html > > and even if the server is willing to use a larger Diffie-Hellman prime, the > problem is that clients often don't support larger primes either, and the > server has no way to know what the client is willing to accept. Older (but > still in use) versions of Java, and apparently also Windows, only support > 1024 bit Diffie-Hellman (see above ivanristic URL for references on these), > which of course is generally considered too small to be secure today. And > until recently, NSS only supported prime sizes up to 2236 bits: > > https://bugzilla.mozilla.org/show_bug.cgi?id=636802 > > If the server chooses a prime size larger than the client can handle, the > handshake will fail. I still think we need a TLS extension so that the > client can tell the server what prime sizes it will accept (perhaps in the > form of min/max/multiple), with the server assuming something conservative > like 1024 (even though that is sadly inadequate) if the client doesn't send > the extension: > > http://lists.gnutls.org/pipermail/gnutls-help/2012-May/002748.html > > But besides a TLS extension, I think what you suggest is good, some sort of > informational RFC that would recommend "best practices" for PFS, e. g. > something along the lines of "put ECDHE cipher suites first (for performance > and so Java won't choke on DHE), make sure you support at least secp256r1 > and secp384r1, put DHE cipher suites second, use a prime size of 2176 bits > (largest multiple of 64 less than 2236)" or whatever. > > Also perhaps some recommendations (and maybe this is what you're getting at > with key rotation) about how (and whether) to make use of session > resumption, and especially session tickets, when PFS is desired, since these > can weaken it. > > --Patrick > > > On Sep 2, 2013, at 5:37 PM, perpass-request@ietf.org wrote: > > From: Yakov Shafranovich > Date: September 2, 2013 1:02:52 PM PDT > To: perpass@ietf.org > Subject: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation > > > There has been some chatter about Perfect Forward Secrecy (PFS) and > insufficient key rotation for SSL/TLS. Is this something that should > merit discussion and perhaps an information draft with > recommendations? > > Thanks, > Yakov > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Tue Sep 3 05:47:33 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8130B21E812D for ; Tue, 3 Sep 2013 05:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9BY+dLOdR2V for ; Tue, 3 Sep 2013 05:47:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B521B21E8128 for ; Tue, 3 Sep 2013 05:47:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 78C2CBE5C; Tue, 3 Sep 2013 13:47:27 +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 GBgU668f-NRJ; Tue, 3 Sep 2013 13:47:27 +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 550F7BE58; Tue, 3 Sep 2013 13:47:27 +0100 (IST) Message-ID: <5225DA5F.4000505@cs.tcd.ie> Date: Tue, 03 Sep 2013 13:47:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yakov Shafranovich References: <66BFDF4E-52DE-407B-8BF7-928F848CB149@funwithsoftware.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Patrick Pelletier Subject: Re: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 12:47:33 -0000 Hiya, On the non-PFS topic: On 09/03/2013 01:11 PM, Yakov Shafranovich wrote: > The CA/browser forum has begun some steps in this direction by > lowering validity of SSL server certificates to 18 months. Is there a > place for a discussion on recommending a lower time period for key > rotation with the ensuing implications for those who do not want/can > not use PFS? This list is a fine place for discussing that if you think that a shorter RSA key rollover duty cycle would impact on pervasive monitoring. I'm not clear as to how it would though. Have you some scenario in mind? There are however plenty of other good reasons for rotating RSA keys more frequently. For the web, I guess the wpkops wg [1] would be a good place to discuss that, but that list has been quiet recently. And that doesn't cover other uses of TLS either, so discussing it here is fine for now. If we start to approach some conclusion then we can find the right venue then. S. [1] http://tools.ietf.org/wg/wpkops From yakov@shaftek.org Tue Sep 3 16:19:29 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D118021E8087 for ; Tue, 3 Sep 2013 16:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey3PGCj8Xsaz for ; Tue, 3 Sep 2013 16:19:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50AD621E8055 for ; Tue, 3 Sep 2013 16:19:20 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id e13so4421850vbg.17 for ; Tue, 03 Sep 2013 16:19:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=2W4kn2zUkMBebKRI1d4p1tTS5VLFf7taxBihhEOIX/0=; b=cIsDKlFwc+mye2DKvmWtPNIgjMahmSdOmrBghaz4Wo8W8l2gLMmi8rYPs1oSSCAW3q DimMKk23B3Y1SN64GSvIyZY7K8ABeah6nos92oZqWXm0vvNmYxJC6b9WCO1pgO3StXSo T/Wq9o+RGuB5UVEjoP6KZDIFrcIlGWhfOm+vE5mXzpstrDoc3SniGn50BLwqu+6O205g 7a1nj8G4kXga5KV5nvqNbEM/ZQsNHBrbXbXIEeFd0XLU5jtQqjx6sxWWqD/90XT660Do sdiV0OEGVqh2zsckURaVL/J+y/vsZXbKYGTQqRSNn5rLztivkv+U6/YadRZcS1J0HOF5 8EGw== X-Gm-Message-State: ALoCoQnbzCYFYrRVGcd3Gy8FPr8O6nHTz/iMz2XlWLBeNcbR5Upf4RVVVa4Y5SKHhiPitxnBLLwX X-Received: by 10.52.166.132 with SMTP id zg4mr4262vdb.71.1378250359353; Tue, 03 Sep 2013 16:19:19 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.52.183.4 with HTTP; Tue, 3 Sep 2013 16:18:49 -0700 (PDT) X-Originating-IP: [96.244.132.139] From: Yakov Shafranovich Date: Tue, 3 Sep 2013 19:18:49 -0400 X-Google-Sender-Auth: bbR2XtmppcoKPv5kf6EdNJvJ-Ws Message-ID: To: perpass@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [perpass] TLS/SSL Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 23:19:29 -0000 [splitting threads] On Tue, Sep 3, 2013 at 8:47 AM, Stephen Farrell wrote: > On 09/03/2013 01:11 PM, Yakov Shafranovich wrote: >> The CA/browser forum has begun some steps in this direction by >> lowering validity of SSL server certificates to 18 months. Is there a >> place for a discussion on recommending a lower time period for key >> rotation with the ensuing implications for those who do not want/can >> not use PFS? > > This list is a fine place for discussing that if you > think that a shorter RSA key rollover duty cycle would > impact on pervasive monitoring. I'm not clear as to > how it would though. Have you some scenario in mind? > The scenario would be where the RSA key on the server is compromised or forcefully disclosed via a court order or other legal mechanism. The shorter the interval, the less data would be available to the potential attacker. There has been media discussion about this with the US Government [1] where providers are forced to hand over their keys. I would also point out that TLS/SSL is used in non web scenarios as well. In cases of provider to provider SMTP, XMPP, SIP, etc. connections, there is a lot more data that can be sucked up if the key is compromised. Unlike web browsers, where there are some mechanisms in place to warn the user, SMTP, XMPP, SIP, etc. connections on a provider to provider level would be automated and no user may see the warnings until after the fact. Yakov [1] http://news.cnet.com/8301-13578_3-57595202-38/feds-put-heat-on-web-firms-for-master-encryption-keys/ From stephen.farrell@cs.tcd.ie Tue Sep 3 16:44:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE3521E80C8 for ; Tue, 3 Sep 2013 16:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG6z5-kfqXLL for ; Tue, 3 Sep 2013 16:43:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A31E521F997D for ; Tue, 3 Sep 2013 16:43:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9D695BE5B; Wed, 4 Sep 2013 00:43:55 +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 49dh5iUXOJ0Q; Wed, 4 Sep 2013 00:43:54 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.53.104]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1175DBE59; Wed, 4 Sep 2013 00:43:54 +0100 (IST) Message-ID: <52267424.3090402@cs.tcd.ie> Date: Wed, 04 Sep 2013 00:43:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yakov Shafranovich References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] TLS/SSL Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 23:44:03 -0000 Hiya, On 09/04/2013 12:18 AM, Yakov Shafranovich wrote: > [splitting threads] > > On Tue, Sep 3, 2013 at 8:47 AM, Stephen Farrell > wrote: >> On 09/03/2013 01:11 PM, Yakov Shafranovich wrote: >>> The CA/browser forum has begun some steps in this direction by >>> lowering validity of SSL server certificates to 18 months. Is there a >>> place for a discussion on recommending a lower time period for key >>> rotation with the ensuing implications for those who do not want/can >>> not use PFS? >> >> This list is a fine place for discussing that if you >> think that a shorter RSA key rollover duty cycle would >> impact on pervasive monitoring. I'm not clear as to >> how it would though. Have you some scenario in mind? >> > > The scenario would be where the RSA key on the server is compromised Potential private key leakage is a fine reason to more frequently roll key pairs. But I'm not so sure that's related to the topic of this list. You have to assume that the compromise is because of some non-repeatable event for it to be relevant here I think. I'm not sure that that's really so likely, but willing to be educated otherwise. I'd guess its really more likely that a private key compromise that's relevant here would involve persistent exploit code running that can constantly grab the latest private key and I can't see that anyone can roll keys so often as to achieve near the same effect as PFS for such a case. > or forcefully disclosed via a court order or other legal mechanism. > The shorter the interval, the less data would be available to the > potential attacker. There has been media discussion about this with > the US Government [1] where providers are forced to hand over their > keys. Right, but if the TLAs come calling, and the service provider's response is to hand over today's RSA private key and then roll a new keypair then you'll have an unhappy TLA, who'll come right back calling again. The phone records thing (court order being renewed every 3 months or whatever it was) also seems to argue that rolling key pairs isn't going to help really. > > I would also point out that TLS/SSL is used in non web scenarios as > well. In cases of provider to provider SMTP, XMPP, SIP, etc. > connections, there is a lot more data that can be sucked up if the key > is compromised. Unlike web browsers, where there are some mechanisms > in place to warn the user, SMTP, XMPP, SIP, etc. connections on a > provider to provider level would be automated and no user may see the > warnings until after the fact. Fully agree. But I'm still not seeing how its related to the topic of this list really. S. > > Yakov > > [1] http://news.cnet.com/8301-13578_3-57595202-38/feds-put-heat-on-web-firms-for-master-encryption-keys/ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From yakov@shaftek.org Tue Sep 3 17:12:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6505D11E8151 for ; Tue, 3 Sep 2013 17:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIqmmXCu89qF for ; Tue, 3 Sep 2013 17:12:17 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7583C11E8150 for ; Tue, 3 Sep 2013 17:12:17 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hz10so4608432vcb.12 for ; Tue, 03 Sep 2013 17:12:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=mnbDQg02O9YKLSdmWr0tyrEGDAT6SzN8imT5GBvTuZQ=; b=bNZL+bMVu6grHrFswQxs6TEGn8/WA6vRo2YefqVyXDUhTk5G6nWemjLmnzjjVUWyGI N0OFTVGGFB1uWuBGbMIosjaUOZiV8JBq3Li/V4P6OcPMVpI8gSLgUrssc41NLWXn/ltp +ZXV/7y4SFnZexcI+O4r2gNBqhN7RWAa3MIPobkOrlx1tXEyxutSuf67s21mJe7XfZZ7 wak0G3c6IZhiNFVsSSYs8x6qV8lzk+g95moXg5ugu4I5jqEa/G0+MAyBmd+npe21tUY8 eiSH7T8guHNhxgSwWiDUjV7e+hcUbxE0yW7yi+wzI2cZlW+HSNQlHnbmWadZRtFg7c8/ aQ5A== X-Gm-Message-State: ALoCoQk+DW6ocItGkyGCYrSqP4pf2619UXo8OgEnf4L2kxdRSv9uh1nW6jD3rlWt4fUl+ixIv3LH X-Received: by 10.52.228.202 with SMTP id sk10mr1010vdc.111.1378253528225; Tue, 03 Sep 2013 17:12:08 -0700 (PDT) MIME-Version: 1.0 Sender: yakov@shaftek.org Received: by 10.52.183.4 with HTTP; Tue, 3 Sep 2013 17:11:38 -0700 (PDT) X-Originating-IP: [96.244.132.139] In-Reply-To: <52267424.3090402@cs.tcd.ie> References: <52267424.3090402@cs.tcd.ie> From: Yakov Shafranovich Date: Tue, 3 Sep 2013 20:11:38 -0400 X-Google-Sender-Auth: NNh0vS0cWu2jbi70qF7ngk8Tzy8 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass@ietf.org Subject: Re: [perpass] TLS/SSL Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 00:12:23 -0000 On Tue, Sep 3, 2013 at 7:43 PM, Stephen Farrell wrote: > On 09/04/2013 12:18 AM, Yakov Shafranovich wrote: >> On Tue, Sep 3, 2013 at 8:47 AM, Stephen Farrell >> wrote: >>> On 09/03/2013 01:11 PM, Yakov Shafranovich wrote: ... >> >> or forcefully disclosed via a court order or other legal mechanism. >> The shorter the interval, the less data would be available to the >> potential attacker. There has been media discussion about this with >> the US Government [1] where providers are forced to hand over their >> keys. > > Right, but if the TLAs come calling, and the service provider's > response is to hand over today's RSA private key and then roll a > new keypair then you'll have an unhappy TLA, who'll come right > back calling again. The phone records thing (court order being > renewed every 3 months or whatever it was) also seems to argue > that rolling key pairs isn't going to help really. > One could envision a scenario where a small group of users or a particular user is being targeted by the court order for a limited period of time. Having regular key rotation will not stop the TLAs from reading everyone's email but will limit the damage once the key rotates. Yakov From ynir@checkpoint.com Tue Sep 3 20:55:53 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E9021E815A for ; Tue, 3 Sep 2013 20:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.631 X-Spam-Level: X-Spam-Status: No, score=-10.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJB0ffB0Li1u for ; Tue, 3 Sep 2013 20:55:47 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 13F7A21E8170 for ; Tue, 3 Sep 2013 20:55:29 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r843t9tX030884; Wed, 4 Sep 2013 06:55:10 +0300 X-CheckPoint: {5226AF1D-19-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 4 Sep 2013 06:55:09 +0300 From: Yoav Nir To: Yakov Shafranovich Thread-Topic: [perpass] TLS/SSL Key Rotation Thread-Index: AQHOqPxYqU3pLmniEkumgG6N8QMSgJm0wNeA Date: Wed, 4 Sep 2013 03:55:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.224] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [perpass] TLS/SSL Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 03:55:53 -0000 On Sep 4, 2013, at 2:18 AM, Yakov Shafranovich wrote: > [splitting threads] >=20 > On Tue, Sep 3, 2013 at 8:47 AM, Stephen Farrell > wrote: >> On 09/03/2013 01:11 PM, Yakov Shafranovich wrote: >>> The CA/browser forum has begun some steps in this direction by >>> lowering validity of SSL server certificates to 18 months. Is there a >>> place for a discussion on recommending a lower time period for key >>> rotation with the ensuing implications for those who do not want/can >>> not use PFS? >>=20 >> This list is a fine place for discussing that if you >> think that a shorter RSA key rollover duty cycle would >> impact on pervasive monitoring. I'm not clear as to >> how it would though. Have you some scenario in mind? >>=20 >=20 > The scenario would be where the RSA key on the server is compromised > or forcefully disclosed via a court order or other legal mechanism. > The shorter the interval, the less data would be available to the > potential attacker. There has been media discussion about this with > the US Government [1] where providers are forced to hand over their > keys. I agree with Stephen that key rollover would never be frequent enough to pr= ovide meaningful FS. It's also likely that a country where court orders for= RSA keys get issued will also have laws requiring companies to retain old = private keys for a certain period of time, just as there are laws requiring= the retention of certain documents and correspondence. Is seems to me that using ciphersuites with PFS, whether ECDHE or DHE, woul= d be a better way. Google is not implementing it at scale on their servers.= All browsers support some ECDHE ciphersuites, and they're also supported i= n libraries such as OpenSSL. So PFS is just a configuration away. Easier th= an manually or automatically rotating certificates often, no? Yoav From russw@riw.us Wed Sep 4 01:44:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A9321E80AB for ; Wed, 4 Sep 2013 01:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m33G7FNiSuyG for ; Wed, 4 Sep 2013 01:43:58 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 258CD11E80AD for ; Wed, 4 Sep 2013 01:43:58 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VH8gv-0004OH-9Q for perpass@ietf.org; Wed, 04 Sep 2013 01:43:57 -0700 From: "Russ White" To: Date: Wed, 4 Sep 2013 04:43:49 -0400 Message-ID: <00c201cea94a$ed5d45b0$c817d110$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac6pSEuNZl2CIu1sTv6BqvQfm+GR2w== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: [perpass] (Possibly Dumb) EMail Security Idea X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 08:44:04 -0000 Y'all: This entire issue with email security has been rattling around in my head ever since it's been discussed on list. I keep wondering why we can't do something TORRENT like with email... This is just a bare bones silly idea, but bear with me for a moment. Assume each person has more than one email address. Or at least they should --there are a number of "free" email services out there (yahoo, Hotmail, google, etc.), and everyone should have at least one email service through their local "residence" provider, then maybe one through their mobile phone provider, etc. Let's say you have a couple of new MIME types available, one for breaking a single message up into multiple pieces and transmitting it in parallel across many different SMTP services, and another that advertises all the services you have available to you (treating each email address in the traditional sense as a single service). What could happen is this: -- Your email client recognizes not only all your existing email services, but adds a new "unified identity service (UIS)." -- Your email client can send a "services supported" MIME type to any other client that supports this new UIS. -- Someone hands you a business card with their UIS address. What happens? -- You send them an email. There is a hitch here because there must be a single common channel known at this point, but let's leave this aside for a moment. -- Instead of sending them the email on the first shot, the enabled email client sends a list of all the services this UIS supports. -- The client on the other end gets this list, and compares to a local list of supported services, and sends back a "valid list." -- Your client now breaks each email up into multiple actual emails, sending each piece as MIME attachment on an actual underlying email service. The number of pieces depends on the number of overlapping services you have available. -- The receiving client gets all the different MIME attachments, one through each service, reconstructs the original email, and delivers it to the UIS inbox. A couple of interesting things: -- Once we introduce the idea of negotiating parameters through a MIME type, it might actually be possible to do some sort of KIK thing to encrypt each piece separately. -- Large files can be sent more efficiently between UIS' by spreading the load over multiple services. -- As each "service" (a complete email service in today's terms) only gets part of the message, anyone eavesdropping must now collate all the different pieces to get a complete conversation. -- You're introducing the idea of a unified identity that doesn't change even if you change your email providers. Maybe the client could even choose a different underlying SMTP service for shorter messages, so that a single conversation is spread out among a lot of different services, etc. Anyway, this is really bare bones, and I don't know enough about email to put all the pieces together, or if this would even work, but it seemed like throwing it out there just for discussion (even if it's to be shot down!). Russ From trammell@tik.ee.ethz.ch Wed Sep 4 02:14:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A548511E81A0 for ; Wed, 4 Sep 2013 02:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O44pXVoOjOL5 for ; Wed, 4 Sep 2013 02:14:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B714611E819C for ; Wed, 4 Sep 2013 02:14:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5856BD9305; Wed, 4 Sep 2013 11:14:27 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id szu-s2h4lblJ; Wed, 4 Sep 2013 11:14:27 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 23262D9303; Wed, 4 Sep 2013 11:14:27 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <00c201cea94a$ed5d45b0$c817d110$@riw.us> Date: Wed, 4 Sep 2013 11:14:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> To: Russ White X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:14:35 -0000 hi Russ, Intriguing idea; the approach of striping content across multiple points = at rest for eavesdropping resistance - spread-spectrum messaging, if you = will - is definitely worth considering as a tool in the toolbox here. A unified identity pushes us in the other direction, though, unless it's = done very carefully... Comments inline. On 4 Sep 2013, at 10:43 , Russ White wrote: > A couple of interesting things: >=20 > -- Once we introduce the idea of negotiating parameters through a MIME = type, > it might actually be possible to do some sort of KIK thing to encrypt = each > piece separately. > -- Large files can be sent more efficiently between UIS' by spreading = the > load over multiple services. > -- As each "service" (a complete email service in today's terms) only = gets > part of the message, anyone eavesdropping must now collate all the = different > pieces to get a complete conversation. I presume each chunk is (1) encrypted and (2) non-contiguous? Otherwise = you have the problem that the information density and = interesting-information-density in most email messages is unevenly = distributed, and then you only really need some subset of the content to = get the interesting information out. > -- You're introducing the idea of a unified identity that doesn't = change > even if you change your email providers. If each of the chunks contains the source identity and the destination = identity, then you're essentially scattering the fact of the association = between the source and the destination across multiple observation = points. While it makes content recovery harder, it may make = massive-scale association recovery easier. For pervasive surveillance, = one could argue the associations are more interesting than the content. = They're certainly easier to store and analyse en masse.=20 Cheers, Brian From russw@riw.us Wed Sep 4 05:20:38 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A5511E819B for ; Wed, 4 Sep 2013 05:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QghTkBkHQWb3 for ; Wed, 4 Sep 2013 05:20:33 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id DA27511E816F for ; Wed, 4 Sep 2013 05:20:32 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VHC4V-0001UE-2y; Wed, 04 Sep 2013 05:20:31 -0700 From: "Russ White" To: "'Brian Trammell'" References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> In-Reply-To: <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> Date: Wed, 4 Sep 2013 08:20:43 -0400 Message-ID: <021601cea969$2e11c5e0$8a3551a0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIR6KI5VPGSlnCYcdzgGTryK4XgWAGiPwBwmSHptoA= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: perpass@ietf.org Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 12:20:38 -0000 > Intriguing idea; the approach of striping content across multiple points at rest > for eavesdropping resistance - spread-spectrum messaging, if you will - is > definitely worth considering as a tool in the toolbox here. > > A unified identity pushes us in the other direction, though, unless it's done > very carefully... Comments inline. Very true... I was thinking of what could be done with existing tools, rather than creating new ones. What would be ideal would be a real TORRENT like email service, with its own port number and servers. There would still be the problem of solving "open servers," which could be used to mass email (spam) folks, but we might be able to think of other controls in that space. If we can't to an entirely new system, though, what can we do with what we already have given some modifications? > > -- Once we introduce the idea of negotiating parameters through a MIME > > type, it might actually be possible to do some sort of KIK thing to > > encrypt each piece separately. > > -- Large files can be sent more efficiently between UIS' by spreading > > the load over multiple services. > > -- As each "service" (a complete email service in today's terms) only > > gets part of the message, anyone eavesdropping must now collate all > > the different pieces to get a complete conversation. > > I presume each chunk is (1) encrypted and (2) non-contiguous? Otherwise > you have the problem that the information density and interesting- > information-density in most email messages is unevenly distributed, and > then you only really need some subset of the content to get the interesting > information out. Hadn't thought of the noncontiguous piece... It's a fair point. As for encrypted, I think that unless you build something new from the ground up, encryption is still going to be up to the user. > > -- You're introducing the idea of a unified identity that doesn't > > change even if you change your email providers. > > If each of the chunks contains the source identity and the destination > identity, then you're essentially scattering the fact of the association > between the source and the destination across multiple observation points. > While it makes content recovery harder, it may make massive-scale > association recovery easier. For pervasive surveillance, one could argue the > associations are more interesting than the content. They're certainly easier > to store and analyse en masse. Yes, this is the side effect... Again, short of creating a new system from the ground up, I don't see any way around this side effect. So... Maybe a new TORRENT like email system is in order, with encryption on as a default? If it could use the same SMTP protocol for sending, that would be cool, but I don't see how to do IMAP like functionality in a distributed system of this type, unless you could use an encrypted online store that did the gathering --but then you risk that online store being compromised, of course. Russ From trammell@tik.ee.ethz.ch Wed Sep 4 07:29:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A896B21F99C3 for ; Wed, 4 Sep 2013 07:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTji6p8+M5cm for ; Wed, 4 Sep 2013 07:29:03 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E4D9311E812E for ; Wed, 4 Sep 2013 07:28:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 794F5D9307; Wed, 4 Sep 2013 16:28:26 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tOzECdanUde8; Wed, 4 Sep 2013 16:28:26 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 33478D9305; Wed, 4 Sep 2013 16:28:26 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <436E1732-663B-42BF-8CA9-DFE48724D1F6@tik.ee.ethz.ch> Date: Wed, 4 Sep 2013 16:28:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <948B6E8A-8BD5-4776-BC7C-41D12C6F7537@tik.ee.ethz.ch> References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie> <436E1732-663B-42BF-8CA9-DFE48724D1F6@tik.ee.ethz.ch> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] On the perfect passive adversary X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 14:29:07 -0000 hi Stephen, all, One update, inline... On 19 Aug 2013, at 9:00 , Brian Trammell = wrote: > hi Stephen, all, >=20 > Yeah, sorry for the giant multitopic rant. I'll split this out into a = few threads to continue... >=20 > On Aug 18, 2013, at 11:47 PM, Stephen Farrell = wrote: >=20 >>=20 >> Hi Brian, >>=20 >> First, thanks for the thoughtful post. You make some good points. >> A few responses below. Might be better to follow up in separate >> mails, since you raise too many interesting points probably:-) >>=20 >> On 08/18/2013 07:45 PM, Brian Trammell wrote: >>> Greetings, all, >>>=20 >>> On the floor of my home directory, there are notes for a paper we >>> never finished called "The Perfect Passive Adversary"; intended as a >>> survey of the state of the network security and measurement >>> literature and practice to explain what is possible if one assumes = an >>> adversary which can (1) observe every packet of every communication >>> at every point within a network but (2) does not have access to the >>> endpoints beyond the network interface (i.e. no keyloggers, and no >>> bulk access to user data at a service provider) and (3) cannot >>> influence packet forwarding. It grew to be rather too wide in scope >>> and too paranoid in tone to have a realistic chance at publication, >>> so we dropped it, which in retrospect seems a silly choice. >>=20 >> So publish it! As an I-D even:-) But if you have a version that >> you're happy to share, that'd be great to see. >=20 > I dusted this off and had a look at it last night, and it's in worse = shape than I'd thought as a coherent piece of work. But completing it = (to -00 I-D quality, at least) and publishing an I-D -- especially given = the scope of the conversation on this list -- seems like a great idea. = I'll get started. This is now available at = http://www.ietf.org/id/draft-trammell-perpass-ppa-00.txt; the current = revision works mainly on the definition of the threat model and the = justification thereof. There are notes on what's observable and what's = inferable and some initial guidance, but mainly the point of this = revision is to determine whether we think it's a useful definition of = the adversary and a good structure for guidance to take from that = definition. On review of RFC 6973, I see it addresses many of the points relevant to = the threat posed by pervasive surveillance. The main difference is that = its definition of surveillance (section 5.1.1.) makes an assumption that = there is a given target of surveillance, which in pervasive surveillance = is not necessarily the case: one "advantage" of pervasive surveillance = is the ability to select targets after the fact of the communications = capture. But in general, surveillance is an attack against privacy, and = 6973 presents a very good framework for talking about privacy in a = protocol design context. So, if we move forward with this document, I'd = like to see it grow as an extension of 6973. Best regards, Brian From code@funwithsoftware.org Wed Sep 4 12:34:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B84721E80EA for ; Wed, 4 Sep 2013 12:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzhBmYH7x0bA for ; Wed, 4 Sep 2013 12:34:31 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id CE89221E80CF for ; Wed, 4 Sep 2013 12:34:17 -0700 (PDT) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 621B81EE4FEF for ; Wed, 4 Sep 2013 15:34:08 -0400 (EDT) Received: (qmail 16968 invoked from network); 4 Sep 2013 19:34:07 -0000 Received: by simscan 1.4.0 ppid: 27705, pid: 13454, t: 1.4840s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 4 Sep 2013 19:34:06 -0000 Message-ID: <52278B17.30304@funwithsoftware.org> Date: Wed, 04 Sep 2013 12:33:43 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: perpass@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] TLS/SSL Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:34:37 -0000 On 9/3/13 8:55 PM, Yoav Nir wrote: > I agree with Stephen that key rollover would never be frequent enough to provide meaningful FS. It's also likely that a country where court orders for RSA keys get issued will also have laws requiring companies to retain old private keys for a certain period of time, just as there are laws requiring the retention of certain documents and correspondence. With the current CA business model, probably not. But in theory, if things were changed so that keys could be rotated every month, every day, or potentially every hour, then that could provide meaningful FS. I'm not aware of any laws in the US that require old keys to be kept. So if the NSA came knocking, they could compel you to turn over current (and possibly future) keys, but if one had already erased one's previous keys, that would keep prior communication safe. Also, legal means are not the only way a state actor (or non-state actor) could acquire a private key. They could use zero-day exploits to break into a computer in another country (or, depending on their morality, in their own country) and obtain the private key. Frequent key rotation would ensure that any communication that had happened prior to the break-in would be safe. > Is seems to me that using ciphersuites with PFS, whether ECDHE or DHE, would be a better way. Google is not implementing it at scale on their servers. All browsers support some ECDHE ciphersuites, and they're also supported in libraries such as OpenSSL. So PFS is just a configuration away. Easier than manually or automatically rotating certificates often, no? Yes, I do think PFS ciphersuites are a better way. Although sometimes I've heard "performance" given as a reason for not enabling PFS. In that case, frequent key rotation (if the CAs cooperate) would allow much of the benefit of PFS, at essentially no additional computational cost. --Patrick From code@funwithsoftware.org Wed Sep 4 12:41:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1900411E8129 for ; Wed, 4 Sep 2013 12:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu3D4Alh6hDs for ; Wed, 4 Sep 2013 12:41:00 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id DB39711E8103 for ; Wed, 4 Sep 2013 12:40:55 -0700 (PDT) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.50]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 10E791EE50B4 for ; Wed, 4 Sep 2013 15:40:53 -0400 (EDT) Received: (qmail 450 invoked from network); 4 Sep 2013 19:40:53 -0000 Received: by simscan 1.4.0 ppid: 25965, pid: 20823, t: 1.2577s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 4 Sep 2013 19:40:52 -0000 Message-ID: <52278CC3.5090002@funwithsoftware.org> Date: Wed, 04 Sep 2013 12:40:51 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: perpass@ietf.org References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> In-Reply-To: <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 19:41:06 -0000 On 9/4/13 2:14 AM, Brian Trammell wrote: > I presume each chunk is (1) encrypted and (2) non-contiguous? Otherwise you have the problem that the information density and interesting-information-density in most email messages is unevenly distributed, and then you only really need some subset of the content to get the interesting information out. This reminds me a little bit of what Tahoe-LAFS is doing, since they encrypt, then do erasure coding, and send the pieces out to different servers. The only difference is that you're doing it with email instead of files. On the other hand, if you don't want to encrypt, then you could solve the information density problem by using an AONT: https://en.wikipedia.org/wiki/All-or-nothing_transform Then each piece would mean nothing unless you had all the pieces. --Patrick From randy@psg.com Wed Sep 4 15:21:29 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4385A11E80D9 for ; Wed, 4 Sep 2013 15:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp50aUBH4EsR for ; Wed, 4 Sep 2013 15:21:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 7638821F9C1D for ; Wed, 4 Sep 2013 15:21:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VHLRm-0005w9-Vg; Wed, 04 Sep 2013 22:21:11 +0000 Date: Thu, 05 Sep 2013 07:21:09 +0900 Message-ID: From: Randy Bush To: Patrick Pelletier In-Reply-To: <52278B17.30304@funwithsoftware.org> References: <52278B17.30304@funwithsoftware.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass Subject: Re: [perpass] TLS/SSL Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 22:21:30 -0000 > Yes, I do think PFS ciphersuites are a better way. Although sometimes > I've heard "performance" given as a reason for not enabling PFS. In > that case, frequent key rotation (if the CAs cooperate) would allow > much of the benefit of PFS, at essentially no additional computational > cost. the operational cost, and room for mistakes, should not be discounted. randy From randy@psg.com Wed Sep 4 15:56:20 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AC911E810D for ; Wed, 4 Sep 2013 15:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l75Dq2UbzhV5 for ; Wed, 4 Sep 2013 15:56:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 4611721F98D8 for ; Wed, 4 Sep 2013 15:56:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VHLzK-0005yp-Nu; Wed, 04 Sep 2013 22:55:51 +0000 Date: Thu, 05 Sep 2013 07:55:49 +0900 Message-ID: From: Randy Bush To: Patrick Pelletier In-Reply-To: <52278CC3.5090002@funwithsoftware.org> References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> <52278CC3.5090002@funwithsoftware.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 22:56:20 -0000 > This reminds me a little bit of what Tahoe-LAFS is doing, since they > encrypt, then do erasure coding, and send the pieces out to different > servers. The only difference is that you're doing it with email instead > of files. in berlin, jean lorchat, one of my fellow iij researchers demoed an app layer (calendar, but could be anything) on top of a layer of a strong identity, sharing, capabilities system on top of a distributed (to a bunch of volunteers homes) tahoe-lafs think diaspora on a secure understructure with strong identity i would also note the bittorrent sync cousin of these approaches i like the space randy From singer@apple.com Wed Sep 4 16:26:39 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3FB11E8208 for ; Wed, 4 Sep 2013 16:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGdwK-CoUIPq for ; Wed, 4 Sep 2013 16:26:33 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id F406A11E8144 for ; Wed, 4 Sep 2013 16:26:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSM00EDBJS3MIW0@mail-out.apple.com> for perpass@ietf.org; Wed, 04 Sep 2013 16:26:31 -0700 (PDT) X-AuditID: 11807166-b7fd66d000006a64-b2-5227c1a7d76c Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id A8.66.27236.7A1C7225; Wed, 04 Sep 2013 16:26:31 -0700 (PDT) Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MSM007WPJS6NF20@spicerack.apple.com> for perpass@ietf.org; Wed, 04 Sep 2013 16:26:31 -0700 (PDT) From: David Singer In-reply-to: <52278CC3.5090002@funwithsoftware.org> Date: Wed, 04 Sep 2013 16:26:38 -0700 Message-id: References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> <52278CC3.5090002@funwithsoftware.org> To: perpass@ietf.org X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUi2FCsobv8oHqQwcGf8hZ3L3WwODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+oZp4LlPBW3Wx8yNjC2cnUxcnJICJhITN2+jA3CFpO4cG89 kM3FISQwmUli1rRTzBDOGiaJu2smsINUMQtoSazfeZwJxOYV0JPYPOMFWFxYwEri9e5LLCA2 m4CqxIM5xxhBbE4BY4nG5deZQWwWoPieCc9ZIOZoSzx5d4EVYo6NxLsXJ5kglk1llLi09xBY QkRARGLRqmdANgfQebISO38nTWDkn4XkjFlIzpiFZOwCRuZVjAJFqTmJlRZ6iQUFOal6yfm5 mxjBAVaYtoOxabnVIUYBDkYlHt4GY/UgIdbEsuLK3EOMEhzMSiK8FiuBQrwpiZVVqUX58UWl OanFhxilOViUxHkPpAGlBNITS1KzU1MLUotgskwcnFINjA3PndctZbayvSekw+zMKJGUYH/J 8biYPcu6g5zcAZYbjD+7z934qP+RQv1Pdp3TD7cqmO5iF3D52PXdZba98j7zcOMfUlun8N0p Dfxifo6taWlI+urZ0kIsdVn8b1UESme/Ol+ZMl2HZVsiW0XT5wSFzf56bHy1wSlpvfdf6Oc2 XtP8e4RFiaU4I9FQi7moOBEAzD93iSwCAAA= Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 23:26:39 -0000 I fear this solution may suffer easily from the 'apparently separate channels problem'. I recall some incident where people had bought triple-redundant links from different long-haul providers -- who all used the same underlying fiber. One backhoe did them all in. Similarly, if the client can easily identify which pieces go together, so can a snooper. On Sep 4, 2013, at 12:40 , Patrick Pelletier wrote: > On 9/4/13 2:14 AM, Brian Trammell wrote: > >> I presume each chunk is (1) encrypted and (2) non-contiguous? Otherwise you have the problem that the information density and interesting-information-density in most email messages is unevenly distributed, and then you only really need some subset of the content to get the interesting information out. > > This reminds me a little bit of what Tahoe-LAFS is doing, since they encrypt, then do erasure coding, and send the pieces out to different servers. The only difference is that you're doing it with email instead of files. > > On the other hand, if you don't want to encrypt, then you could solve the information density problem by using an AONT: > > https://en.wikipedia.org/wiki/All-or-nothing_transform > > Then each piece would mean nothing unless you had all the pieces. > > --Patrick > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass David Singer Multimedia and Software Standards, Apple Inc. From russw@riw.us Wed Sep 4 16:41:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6F211E8130 for ; Wed, 4 Sep 2013 16:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Bujh3UY8H6 for ; Wed, 4 Sep 2013 16:40:50 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id F1C1E21F9A4C for ; Wed, 4 Sep 2013 16:40:49 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=RussPC) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1VHMgq-0006tn-CO; Wed, 04 Sep 2013 16:40:48 -0700 From: "Russ White" To: "'David Singer'" , References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> <52278CC3.5090002@funwithsoftware.org> In-Reply-To: Date: Wed, 4 Sep 2013 19:41:01 -0400 Message-ID: <00e001cea9c8$37701a10$a6504e30$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIR6KI5VPGSlnCYcdzgGTryK4XgWAGiPwBwAZieJHkBzDYTwZkHha1g Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 23:41:03 -0000 > I recall some incident where people had bought triple-redundant links from > different long-haul providers -- who all used the same underlying fiber. One > backhoe did them all in. Similarly, if the client can easily identify which pieces > go together, so can a snooper. Shared common fate --but that's a different thing, I think. If you specifically use a shared secret or something along those lines to break the chunks up, then I think it might be pretty hard to put the pieces back together. In this case, you might be able to use something like a "side channel" to send a one time pad that's used as a hash to break the messiage up, send each piece along a separate channel, and then put it all back together on the other end... Of course, this all assumes a completely new email transport system, and it assumes the server where the pieces are put back together is secure, or you use a more POP-like system, where there is no storage of the complete message on anything other than a local system... I think this is all possible/doable. The question is --is the world ready for a new email transport? Do we try and build it, to see if they will come? Russ From stephen.farrell@cs.tcd.ie Thu Sep 5 03:32:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6553D21E80B3 for ; Thu, 5 Sep 2013 03:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2JQ6xqUXIKN for ; Thu, 5 Sep 2013 03:32:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 595D421E80AF for ; Thu, 5 Sep 2013 03:32:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BE9E6BE4C; Thu, 5 Sep 2013 11:32:15 +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 C5veiG93OXtw; Thu, 5 Sep 2013 11:32:15 +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 96586BE49; Thu, 5 Sep 2013 11:32:15 +0100 (IST) Message-ID: <52285DB1.2060506@cs.tcd.ie> Date: Thu, 05 Sep 2013 11:32:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Trammell References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie> <436E1732-663B-42BF-8CA9-DFE48724D1F6@tik.ee.ethz.ch> <948B6E8A-8BD5-4776-BC7C-41D12C6F7537@tik.ee.ethz.ch> In-Reply-To: <948B6E8A-8BD5-4776-BC7C-41D12C6F7537@tik.ee.ethz.ch> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] On the perfect passive adversary X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 10:32:24 -0000 Hi Brian, Great start, thanks! On 09/04/2013 03:28 PM, Brian Trammell wrote: >> I dusted this off and had a look at it last night, and it's in >> worse shape than I'd thought as a coherent piece of work. But >> completing it (to -00 I-D quality, at least) and publishing an I-D >> -- especially given the scope of the conversation on this list -- >> seems like a great idea. I'll get started. > > This is now available at > http://www.ietf.org/id/draft-trammell-perpass-ppa-00.txt; the current > revision works mainly on the definition of the threat model and the > justification thereof. There are notes on what's observable and > what's inferable and some initial guidance, but mainly the point of > this revision is to determine whether we think it's a useful > definition of the adversary and a good structure for guidance to take > from that definition. Can others on this list read and comment? I'd say that suggested chunks of text for sections 5 and 6 would be really great to get. If we can get a bunch of those then maybe Brian can try to figure out how to organise 'em. (Or even better, Brian plus whoever else is willing to help, and please let Brian know if you're willing.) > On review of RFC 6973, I see it addresses many of the points relevant > to the threat posed by pervasive surveillance. The main difference is > that its definition of surveillance (section 5.1.1.) makes an > assumption that there is a given target of surveillance, which in > pervasive surveillance is not necessarily the case: one "advantage" > of pervasive surveillance is the ability to select targets after the > fact of the communications capture. But in general, surveillance is > an attack against privacy, and 6973 presents a very good framework > for talking about privacy in a protocol design context. So, if we > move forward with this document, I'd like to see it grow as an > extension of 6973. Sounds reasonable. Two initial comments on the -00 version:- 1) I guess the scope here of purely considering passive monitoring is useful enough, but maybe we need to think about that some, if we consider it likely that some of the monitoring is being done from compromised hosts. While that attacker isn't actively MITMing application traffic, they are sort of active in that they're putting their code onto devices, and some of those can be in what might otherwise be considered "trusted" parts of the network. Maybe a good scope might be to assume here that the endpoints are not compromised but that e.g. routers, switches, DHCP servers etc. might be part of the monitoring network. Would that be worth thinking about for this document or would that be better left out, or left for another document? I'm not sure but would be interested in folks' thoughts. 2) While I fully agree that the "benefits" of pervasive monitoring ought be out of scope, I'm not sure I agree that analysis of the costs of pervasive monitoring ought be entirely out of scope. Presumably our goal here includes helping protocol designers increase those costs, hopefully to the point where Yoav is no longer in the top 100k cost-effective targets:-) So some consideration of the costs of monitoring would seem to be called for. We can't of course consider that in detail, but ruling it out of scope seems a bit wrong. Maybe we can consider the kinds of protocol features and deployment choices that would noticeably increase that cost, without getting into an analysis of what those costs might be? Cheers, S. > > Best regards, > > Brian > > > _______________________________________________ perpass mailing list > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Thu Sep 5 03:41:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C0E21E80AF for ; Thu, 5 Sep 2013 03:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfw1OXA3jWeC for ; Thu, 5 Sep 2013 03:40:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D0EFE11E80E3 for ; Thu, 5 Sep 2013 03:40:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3D4C1BE39; Thu, 5 Sep 2013 11:40:57 +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 ck08ouTaPNua; Thu, 5 Sep 2013 11:40:57 +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 19161BE2F; Thu, 5 Sep 2013 11:40:57 +0100 (IST) Message-ID: <52285FBA.2000100@cs.tcd.ie> Date: Thu, 05 Sep 2013 11:40:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Bush References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> <52278CC3.5090002@funwithsoftware.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 10:41:04 -0000 Hi Randy, On 09/04/2013 11:55 PM, Randy Bush wrote: >> This reminds me a little bit of what Tahoe-LAFS is doing, since they >> encrypt, then do erasure coding, and send the pieces out to different >> servers. The only difference is that you're doing it with email instead >> of files. > > in berlin, jean lorchat, one of my fellow iij researchers demoed > an app layer (calendar, but could be anything) > on top of a layer of a strong identity, sharing, capabilities system > on top of a distributed (to a bunch of volunteers homes) tahoe-lafs > think diaspora on a secure understructure with strong identity > > i would also note the bittorrent sync cousin of these approaches > > i like the space Agreed. What's not clear to me though, is whether and how the IETF could help with such efforts. (Same for Tor related work.) If there are specific things the IETF could do to help make those kinds of things better then that'd be very interesting to know about. If there are folks on here who're working on those technologies who figure that the IETF could help, then having 'em say how they think we could help would be great. I'd love to see a bunch of threads like that on this list. S. > > randy > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From russw@riw.us Thu Sep 5 04:10:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2C921E80B3 for ; Thu, 5 Sep 2013 04:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTHsFK7rIYQh for ; Thu, 5 Sep 2013 04:10:21 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9711C21E80B2 for ; Thu, 5 Sep 2013 04:10:21 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=RussPC) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1VHXS6-0005hj-Nc; Thu, 05 Sep 2013 04:10:19 -0700 From: "Russ White" To: "'Stephen Farrell'" , "'Randy Bush'" References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> <52278CC3.5090002@funwithsoftware.org> <52285FBA.2000100@cs.tcd.ie> In-Reply-To: <52285FBA.2000100@cs.tcd.ie> Date: Thu, 5 Sep 2013 07:10:32 -0400 Message-ID: <014701ceaa28$8a1aa9a0$9e4ffce0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIR6KI5VPGSlnCYcdzgGTryK4XgWAGiPwBwAZieJHkA4N60dAJ2a2R8mPvuPaA= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: 'perpass' Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 11:10:27 -0000 > Agreed. What's not clear to me though, is whether and how the IETF could > help with such efforts. (Same for Tor related work.) If there are specific > things the IETF could do to help make those kinds of things better then that'd > be very interesting to know about. Building a new bitorrent like protocol as an email transport? Russ From trammell@tik.ee.ethz.ch Thu Sep 5 05:17:43 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A63411E8190 for ; Thu, 5 Sep 2013 05:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g1AVkItu26P for ; Thu, 5 Sep 2013 05:17:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E607111E818F for ; Thu, 5 Sep 2013 05:17:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 163F3D9303; Thu, 5 Sep 2013 14:17:36 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3xA0asIfTB9W; Thu, 5 Sep 2013 14:17:35 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D071BD9300; Thu, 5 Sep 2013 14:17:35 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <52285DB1.2060506@cs.tcd.ie> Date: Thu, 5 Sep 2013 14:17:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1407E07D-05FA-4299-98C1-ECDBC488F759@tik.ee.ethz.ch> References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie> <436E1732-663B-42BF-8CA9-DFE48724D1F6@tik.ee.ethz.ch> <948B6E8A-8BD5-4776-BC7C-41D12C6F7537@tik.ee.ethz.ch> <52285DB1.2060506@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] On the perfect passive adversary X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 12:17:43 -0000 hi Stephen, On 5 Sep 2013, at 12:32 , Stephen Farrell = wrote: > Two initial comments on the -00 version:- >=20 > 1) I guess the scope here of purely considering passive monitoring > is useful enough, but maybe we need to think about that some, if > we consider it likely that some of the monitoring is being done > from compromised hosts. While that attacker isn't actively MITMing > application traffic, they are sort of active in that they're > putting their code onto devices, and some of those can be in what > might otherwise be considered "trusted" parts of the network. Maybe > a good scope might be to assume here that the endpoints are not > compromised but that e.g. routers, switches, DHCP servers etc. > might be part of the monitoring network. Would that be worth > thinking about for this document or would that be better left > out, or left for another document? I'm not sure but would be > interested in folks' thoughts. There's a very minor difference in terms of detectability between: (1) someone who can look at any of the packets on their way into and/or = out of any of the endpoints on the network between the initiator and = recipient, and (2) someone who can do that plus can observe internal state / stored = messages at any of the intermediate systems. The main practical difference is that confidentiality from eavesdropping = from adversary (2) requires end-to-end encryption, while transport = encryption is sufficient against adversary (1) assuming you use it = everywhere. Since we're already discussing this on the list, it seems = like we believe the additional threats in (2) to be in scope. I think that if we assume any capabilities beyond that (e.g., DNS cache = poisoning, selective modification of traffic at an intermediate system), = we're not really talking about surveillance anymore. > 2) While I fully agree that the "benefits" of pervasive monitoring > ought be out of scope, I'm not sure I agree that analysis of the costs > of pervasive monitoring ought be entirely out of scope. Presumably > our goal here includes helping protocol designers increase those > costs, hopefully to the point where Yoav is no longer in the top > 100k cost-effective targets:-) So some consideration of the costs > of monitoring would seem to be called for. The text here is poorly phrased; what I want to say is "we assume this = to be bad a priori and therefore advice protocol designers to do the = following to avoid it; we're not going to examine the (social) = cost-benefit analysis." i.e., we agree completely here. :) > We can't of course consider > that in detail, but ruling it out of scope seems a bit wrong. Maybe > we can consider the kinds of protocol features and deployment > choices that would noticeably increase that cost, without getting > into an analysis of what those costs might be? Indeed, the document already kind of does this by noting if you want = packets, you need to buy new 4TB disk per 10G link every 50+ minutes. Cheers, Brian From llynch@civil-tongue.net Thu Sep 5 15:03:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D6421F9034 for ; Thu, 5 Sep 2013 15:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqQxBcb9GHaQ for ; Thu, 5 Sep 2013 15:03:29 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id B59B521F8EC3 for ; Thu, 5 Sep 2013 15:03:29 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id r85M3S1h052906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 5 Sep 2013 15:03:29 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id r85M3SSB052903 for ; Thu, 5 Sep 2013 15:03:28 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Thu, 5 Sep 2013 15:03:28 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: perpass@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Subject: [perpass] stronger crypto requirements X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:03:31 -0000 may be in order: https://www.propublica.org/article/the-nsas-secret-campaign-to-crack-undermine-internet-encryption says in part: " Simultaneously, the N.S.A. has been deliberately weakening the international encryption standards adopted by developers. One goal in the agency’s 2013 budget request was to “influence policies, standards and specifications for commercial public key technologies,†the most common encryption method. Cryptographers have long suspected that the agency planted vulnerabilities in a standard adopted in 2006 by the National Institute of Standards and Technology, the United States’ encryption standards body, and later by the International Organization for Standardization, which has 163 countries as members. Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.†“Eventually, N.S.A. became the sole editor,†the memo says. " - Lucy From randy@psg.com Thu Sep 5 16:45:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8209211E8216 for ; Thu, 5 Sep 2013 16:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MY552NfIjzAS for ; Thu, 5 Sep 2013 16:45:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAFA11E8259 for ; Thu, 5 Sep 2013 16:45:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VHjF2-0008Cb-7O; Thu, 05 Sep 2013 23:45:36 +0000 Date: Fri, 06 Sep 2013 08:45:34 +0900 Message-ID: From: Randy Bush To: Lucy Lynch In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass@ietf.org Subject: Re: [perpass] stronger crypto requirements X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 23:45:41 -0000 > may be in order: so who do we trust to evaluate what is usable today, and who to design forward? randy From llynch@civil-tongue.net Thu Sep 5 16:51:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257DB11E825D for ; Thu, 5 Sep 2013 16:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBxfxQg3jSia for ; Thu, 5 Sep 2013 16:51:53 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id 441B711E825C for ; Thu, 5 Sep 2013 16:51:52 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id r85Npq4J063736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Sep 2013 16:51:52 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id r85NpqLH063733; Thu, 5 Sep 2013 16:51:52 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Thu, 5 Sep 2013 16:51:52 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Randy Bush In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] stronger crypto requirements X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 23:51:54 -0000 missed one - nice critique of the BH talk http://blog.cryptographyengineering.com/2013/08/is-cryptopocalypse-nigh.html - Lucy On Fri, 6 Sep 2013, Randy Bush wrote: >> may be in order: > > so who do we trust to evaluate what is usable today, and who to design > forward? > > randy > From code@funwithsoftware.org Thu Sep 5 17:54:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93F521E808C for ; Thu, 5 Sep 2013 17:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XECgJv0dPgJ for ; Thu, 5 Sep 2013 17:54:16 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 165F821E8084 for ; Thu, 5 Sep 2013 17:54:15 -0700 (PDT) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.50]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 63CAE1EE4F69 for ; Thu, 5 Sep 2013 20:54:14 -0400 (EDT) Received: (qmail 23446 invoked from network); 6 Sep 2013 00:54:13 -0000 Received: by simscan 1.4.0 ppid: 8320, pid: 16353, t: 1.4464s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 6 Sep 2013 00:54:12 -0000 Message-Id: From: Patrick Pelletier To: perpass@ietf.org In-Reply-To: <66BFDF4E-52DE-407B-8BF7-928F848CB149@funwithsoftware.org> Content-Type: multipart/alternative; boundary=Apple-Mail-13-689692160 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 5 Sep 2013 17:54:10 -0700 References: <66BFDF4E-52DE-407B-8BF7-928F848CB149@funwithsoftware.org> X-Mailer: Apple Mail (2.936) Subject: Re: [perpass] TLS/SSL Perfect Forward Secrecy and Key Rotation X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 00:54:22 -0000 --Apple-Mail-13-689692160 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 2, 2013, at 11:41 PM, Patrick Pelletier wrote: > But besides a TLS extension, I think what you suggest is good, some > sort of informational RFC that would recommend "best practices" for > PFS, e. g. something along the lines of "put ECDHE cipher suites > first (for performance and so Java won't choke on DHE), make sure > you support at least secp256r1 and secp384r1, put DHE cipher suites > second, use a prime size of 2176 bits (largest multiple of 64 less > than 2236)" or whatever. Well, in light of Bruce Schneier's recommendations today, maybe DHE should be prioritized over ECDHE: http://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 Although there is still the issue that DHE is slower than ECDHE. Is Curve25519 the answer? --Patrick --Apple-Mail-13-689692160 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Sep 2, 2013, at = 11:41 PM, Patrick Pelletier wrote:

But besides a TLS = extension, I think what you suggest is good, some sort of informational = RFC that would recommend "best practices" for PFS, e. g. something along = the lines of "put ECDHE cipher suites first (for performance and so Java = won't choke on DHE), make sure you support at least secp256r1 and = secp384r1, put DHE cipher suites second, use a prime size of 2176 = bits (largest multiple of 64 less than 2236)" or = whatever.

Well, in light of = Bruce Schneier's recommendations today, maybe DHE should be prioritized = over ECDHE:


Although there is still the = issue that DHE is slower than ECDHE.  Is Curve25519 the = answer?

--Patrick

= --Apple-Mail-13-689692160-- From dean.willis@softarmor.com Thu Sep 5 18:24:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F138921E8092 for ; Thu, 5 Sep 2013 18:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYGNa0K2-jI7 for ; Thu, 5 Sep 2013 18:24:01 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0C70711E8129 for ; Thu, 5 Sep 2013 18:24:00 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so2796104obc.26 for ; Thu, 05 Sep 2013 18:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mB3V8e3HlUn7GKnE8JG/rnwWPDJucAqldp1pVedNzyM=; b=ax5eh5heTmVkgjnhbBq1Aq1lyONNKBXsdV4fGMpltgYnRzA5fkLHql2zypWpvkR6Y8 ttERCCCxQ8K1n9ZA+D/f6NAbTN4J83/bTC0G071RJfBAvKSD+TzLLHSl9DrNLIhDpEII iCCshvqsk4S0Sz65st2W7iT7K0InGGY4oOu+I= 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=mB3V8e3HlUn7GKnE8JG/rnwWPDJucAqldp1pVedNzyM=; b=WDmzQqytvc7swckKJnKSusH8HkyVenmG9Opg1u0BP42ICSZ4JB5G1yaHmYXrVkuGHg axdPHI+FNdHzC36PXuqIl9nqtVd9WbWcJRccANxw/c+b98JdN5CHIkzJcn62gaYUjVGw /zls+Ets+ru80loizMOWMSzuSS545RyUMBBkfyqByTZq0ySmVcJbeAMF0ZWytTHuhifo lMxPlh18E4cWH4qA5pUTZjB/zZIW4Yua/Dpmll19E41lApnHWuJT95EhBhkfzsg2lLwj zqJUqyiJLWjm+8faOJpPZ/a0CxaLXyCBNf54E9/F9ZSnuWaClixxC8BR+2QRDdMHuA1g rEXw== X-Gm-Message-State: ALoCoQmNFHFhP7/s7jBXTYMDyOxuZWg0PLXqf1IcP2Xm/pveSXTsEKdbF4Hc97x+OkqcpbJ6pePE X-Received: by 10.60.131.3 with SMTP id oi3mr37343oeb.104.1378430640340; Thu, 05 Sep 2013 18:24:00 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id u3sm69156oeq.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Sep 2013 18:23:59 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: <5224DF25.60503@cs.tcd.ie> Date: Thu, 5 Sep 2013 20:23:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> References: <5224DF25.60503@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 01:24:02 -0000 On Sep 2, 2013, at 1:55 PM, Stephen Farrell = wrote: >=20 > So, given you've been thinking about this for maybe longer than most > I'm wondering if you have any specific protocol changes or additions > you'd suggest, or descriptions of new threat models that could be = useful > to WGs developing or maintaining protocols? IMO, things like that = would > be most useful for now. >=20 I think there are a couple of principles that we need to adopt = IETF-wide. Part of the definition of "good Internet citizen" for a protocol or = application is that not only does that protocol/application include = anti-surveillance principles for itself, but that it helps OTHER = protocols avoid surveillance. Surveillance-resistance is MORE IMPORTANT = than optimizing transport efficiency. So, a couple of rules, probably badly organized: 1) Everything SHOULD be encrypted, unless there is an absolute = operational requirement not to. This means "encryption by default" in = new protocols, and not even specifying unencrypted operations modes = unless necessary. Older protocol specs still in use should be revised to = require encryption. Deprecate the non "s" versions of protocols. 2) Well-known ports should be avoided. Or overloaded to the point where = the port number is no longer a significant indicator to the application. = This gives rise to the "everything over 443" mentality, which we need to = find a way to handle gracefully. Demuxing the service within the channel = is a better idea than I used to think. 3) Packet sizes should be variable, preferably random. This is the = opposite of the "discover the MTU and fill every packet" model of = efficiency. Or, we could make all packets the same fixed size by padding = small ones. I like random better, but there might well be some hardware = optimizations around fixed packet sizes. 4) Every protocol spec needs to include a pseudonymous usage model, and = most should include an anonymous usage model. 5) New protocols should be built around end-to-end crypto rather than = relying on transport-level wrappers for everything. It's too easy to use = a compromised CA-cert to dynamically build a TLS proxy cert. Some level = of key delivery out-of-band, coupled to in-band footprint verification, = is probably needed. zRTP is a good model. 6) Randomizing interpacket timing is useful. This does all sorts of = horrible things to both TCP optimization and the jitter buffers in = real-time communications. But it's worth it. Remember, = surveillance-resistance is MORE IMPORTANT than efficiency. 7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have = lessons we should learn. So does TOR. 8) Every piece of crypto-advice needs serious, multiparty, = international, and aggressive review. No more documents authored by NSA = shills (which Schneier says we seem to have). -- Dean From bortzmeyer@nic.fr Fri Sep 6 00:40:57 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDCC11E8122 for ; Fri, 6 Sep 2013 00:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.14 X-Spam-Level: X-Spam-Status: No, score=-101.14 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTtWbsYLjbjn for ; Fri, 6 Sep 2013 00:40:51 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 547F111E8121 for ; Fri, 6 Sep 2013 00:40:51 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5DACF28023F; Fri, 6 Sep 2013 09:40:16 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 590EA2801C0; Fri, 6 Sep 2013 09:40:16 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay2.nic.fr (Postfix) with ESMTP id 4CEECB3805C; Fri, 6 Sep 2013 09:39:46 +0200 (CEST) Date: Fri, 6 Sep 2013 09:39:46 +0200 From: Stephane Bortzmeyer To: Lucy Lynch Message-ID: <20130906073946.GB14077@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 7.1 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: perpass@ietf.org Subject: Re: [perpass] stronger crypto requirements X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 07:40:57 -0000 On Thu, Sep 05, 2013 at 03:03:28PM -0700, Lucy Lynch wrote a message of 23 lines which said: > may be in order: > > https://www.propublica.org/article/the-nsas-secret-campaign-to-crack-undermine-internet-encryption Well, it seems this story (a better presentation of the standardization problem is ) is a strong argument in favor of the IETF practices: openness of standardization (even security standardization), "show me the code", "explain what your proposal does or I won't consider it", do not blindly believe the authority, etc. From ynir@checkpoint.com Fri Sep 6 01:18:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9C021E80C6 for ; Fri, 6 Sep 2013 01:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.63 X-Spam-Level: X-Spam-Status: No, score=-10.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQekslDp+rs8 for ; Fri, 6 Sep 2013 01:17:53 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ABE7721E81C4 for ; Fri, 6 Sep 2013 01:17:48 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r868HE4C014986; Fri, 6 Sep 2013 11:17:18 +0300 X-CheckPoint: {52298F8A-7-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Fri, 6 Sep 2013 11:17:14 +0300 From: Yoav Nir To: Lucy Lynch Thread-Topic: [perpass] stronger crypto requirements Thread-Index: AQHOqoPHDZqswMnTBkataY9P9+vqEJm3nLQAgAABwwCAAI0yAA== Date: Fri, 6 Sep 2013 08:17:14 +0000 Message-ID: <12D49322-D986-4758-A90E-DD839AC2C52D@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.197] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Randy Bush , "" Subject: Re: [perpass] stronger crypto requirements X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 08:18:07 -0000 Such sanity has no place on this mailing list. On Sep 6, 2013, at 2:51 AM, Lucy Lynch wrote: > missed one - >=20 > nice critique of the BH talk >=20 > http://blog.cryptographyengineering.com/2013/08/is-cryptopocalypse-nigh.h= tml >=20 > - Lucy >=20 > On Fri, 6 Sep 2013, Randy Bush wrote: >=20 >>> may be in order: >>=20 >> so who do we trust to evaluate what is usable today, and who to design >> forward? >>=20 >> randy From ynir@checkpoint.com Fri Sep 6 01:31:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F61E21E80A6 for ; Fri, 6 Sep 2013 01:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.329 X-Spam-Level: X-Spam-Status: No, score=-9.329 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x8=0.8, SARE_BAYES_6x8=0.8, SARE_BAYES_7x8=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idS7KQ6aTqrL for ; Fri, 6 Sep 2013 01:31:35 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 667D611E8179 for ; Fri, 6 Sep 2013 01:31:23 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r868V4ir021089; Fri, 6 Sep 2013 11:31:10 +0300 X-CheckPoint: {522992C8-21-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Fri, 6 Sep 2013 11:31:04 +0300 From: Yoav Nir To: Stephane Bortzmeyer Thread-Topic: [perpass] stronger crypto requirements Thread-Index: AQHOqoPHDZqswMnTBkataY9P9+vqEJm4ITIAgAAOVQA= Date: Fri, 6 Sep 2013 08:31:04 +0000 Message-ID: References: <20130906073946.GB14077@nic.fr> In-Reply-To: <20130906073946.GB14077@nic.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.197] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Lucy Lynch , "" Subject: Re: [perpass] stronger crypto requirements X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 08:31:45 -0000 On Sep 6, 2013, at 10:39 AM, Stephane Bortzmeyer wrote: > On Thu, Sep 05, 2013 at 03:03:28PM -0700, > Lucy Lynch wrote=20 > a message of 23 lines which said: >=20 >> may be in order: >>=20 >> https://www.propublica.org/article/the-nsas-secret-campaign-to-crack-und= ermine-internet-encryption >=20 > Well, it seems this story (a better presentation of the > standardization problem is > ) > is a strong argument in favor of the IETF practices: openness of > standardization (even security standardization), "show me the code", > "explain what your proposal does or I won't consider it", do not > blindly believe the authority, etc. This works OK for protocols. But does this really work for parameters? Tak= e a look at section 3 in RFC 3526 ( http://tools.ietf.org/html/rfc3526#sect= ion-3 ) or similar sections in RFC 5114. I'll quote it in full here: 3. 2048-bit MODP Group This group is assigned id 14. This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 } Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF The generator is: 2. How do we know that these are good parameters? We have Tero's word that he = checked them, and those who know enough can repeat the test, while the rest= of us can only wonder where those numbers came from, what a real number (p= i) is doing there, and whether it's OK that the top and bottom 64 bits are = all set. And this is for MODP which is well understood. For EC, we mostly u= se the NIST curves, which we know are OK because NIST said so. Luckily we h= ave NIST to protect us from the NSA. Oh, wait=85 So I have a lot of faith in the IETF process for analyzing protocols, but I= think the actual pool of people who understand cryptography well enough to= make comments about the security of algorithms and the safety of parameter= s is rather small. Yoav From nick@lupine.me.uk Fri Sep 6 02:29:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881A111E8181 for ; Fri, 6 Sep 2013 02:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK6RGpDQhQS8 for ; Fri, 6 Sep 2013 02:29:30 -0700 (PDT) Received: from oak.forest.a5775.uk0.bigv.io (lupine.me.uk [IPv6:2001:41c8:51:8:feff:ff:fe01:101]) by ietfa.amsl.com (Postfix) with ESMTP id 5990A11E8285 for ; Fri, 6 Sep 2013 02:29:26 -0700 (PDT) Received: from [213.138.102.178] by oak.forest.a5775.uk0.bigv.io with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VHsLw-0003bF-5I; Fri, 06 Sep 2013 10:29:20 +0100 Message-ID: <5229A06F.5070800@lupine.me.uk> Date: Fri, 06 Sep 2013 10:29:19 +0100 From: Nick Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 MIME-Version: 1.0 To: perpass@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [perpass] encrypted PPP X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 09:29:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, PPP gets a lot of use still, especially between EUs and access ISPs, where it's generally not encrypted. RFC1968 exists, but doesn't actually seem useful any more. I'm envisioning a PPP enhancement where EU and ISP can exchange public keys beforehand, out-of-band if necessary, but it's all extremely fuzzy at the moment. My access ISP, who I have considerable trust in, has no real control over the infrastructure between my house and their access node near London - all that's BT-operated, and they just get to terminate PPP over it. Thoughts-in-general? /Nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREIAAYFAlIpoG8ACgkQREz3uGI6tdxMOAD/a4H50Sblj3uVtfS1tIavREG3 LURTnjr+97rFi6UTV3gA/1JuIjyCj1o/9Ej/+IxY8R29mMLxKGoe0isXprQpNyGK =9mt9 -----END PGP SIGNATURE----- From paul@cypherpunks.ca Fri Sep 6 09:25:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4BF21F9B8C for ; Fri, 6 Sep 2013 09:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVfv9wU1rDZN for ; Fri, 6 Sep 2013 09:25:08 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id C726A21E8063 for ; Fri, 6 Sep 2013 09:25:07 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cWkdC23s2zC3r; Fri, 6 Sep 2013 12:25:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 7OCTFT01-PLj; Fri, 6 Sep 2013 12:25:02 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 6 Sep 2013 12:25:02 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 8D3B2848E3; Fri, 6 Sep 2013 12:25:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6E97E848E2; Fri, 6 Sep 2013 12:25:02 -0400 (EDT) Date: Fri, 6 Sep 2013 12:25:02 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Nick Thomas In-Reply-To: <5229A06F.5070800@lupine.me.uk> Message-ID: References: <5229A06F.5070800@lupine.me.uk> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: perpass@ietf.org Subject: Re: [perpass] encrypted PPP X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 16:25:14 -0000 On Fri, 6 Sep 2013, Nick Thomas wrote: [ note, using "EU" for "end user" is _very_ confusing ] > PPP gets a lot of use still, especially between EUs and access ISPs, > where it's generally not encrypted. RFC1968 exists, but doesn't actually > seem useful any more. > > I'm envisioning a PPP enhancement where EU and ISP can exchange public > keys beforehand, out-of-band if necessary, but it's all extremely fuzzy > at the moment. My access ISP, who I have considerable trust in, has no > real control over the infrastructure between my house and their access > node near London - all that's BT-operated, and they just get to > terminate PPP over it. Any ISP that does not trust the last-mile providers should offer their customers VPN access via IPsec. Actually, they should offer it regardless so their users can use a VPN to connect to the ISPs infrastructure when the user is roaming on his laptop/phone as well. There is no "ppp encryption" the ISP can add, because the last-mile provider usually terminates the PPP(OE) session. They need to add encryption on the resulting IP layer, not below it. Paul From dean.willis@softarmor.com Fri Sep 6 12:14:31 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5AD21F9FAE for ; Fri, 6 Sep 2013 12:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QA+4uXuX-zW for ; Fri, 6 Sep 2013 12:14:30 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id C71F811E81BF for ; Fri, 6 Sep 2013 12:14:09 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so3875861obp.36 for ; Fri, 06 Sep 2013 12:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=twqdvlCjQYXx4UTDsySX9CYBsoV1zKXEa5V934+doC8=; b=WLOgP5f6/wHMDwtMfzXQIi7Ht928A6TXz23q8hwKUV7hc8o2H79EXSxWAQMifKW0DA fp1SYTdUDKMkVQNcc7T3pYI1S1D/dL7GF6vp66Kh0bizP8nx7sbgWtELFAUDuca1sHKX FWfIPf11uNvxWeRH8fxAj6qeTINEdB63t++08= 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=twqdvlCjQYXx4UTDsySX9CYBsoV1zKXEa5V934+doC8=; b=mQANOxTv7tNJMl1knFdNxWg6erZI0T5bbnzmEt289nBfRWV/x4Qxfe/Wd4qK9oBS7M qpr76nibZVS3Plxu0lBLEbzP3ySydpHxp70C0NQbJJ4m6nFi0Q3RUubm2ggTAMaDaQOs SKvsOGHqer5w3prKsfePDa//0JDCiGjQ+FZ0jYxLeEyaJkcMGkZ4NPAOIzo4LdAwwNAi uOlC03TW+aMwCbH7RUCn40kZ2m9ocIRVfXTKAyGgCvOEp+UkG9/U1QuOTd8M0Ub4MgoC aWw9GDsn4kVc4F7i+5VNcrWfylOV2XLp+qz2tvVUjhbCMj9/9zoF28ZJ8o+pQd03vsU4 3LNw== X-Gm-Message-State: ALoCoQmMm9HyDDzU+t2YyPA4CENd78ShDw4VfWYDCY8cwC53x9eWKnMClJ9tDAX8MhM2AbAu9mj8 X-Received: by 10.60.63.68 with SMTP id e4mr2976464oes.23.1378494849371; Fri, 06 Sep 2013 12:14:09 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id d3sm4099131oek.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 12:14:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: Date: Fri, 6 Sep 2013 14:14:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6AAE1E94-2DFD-4302-A207-2974BA89740B@softarmor.com> References: <5229A06F.5070800@lupine.me.uk> To: Paul Wouters X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org, Nick Thomas Subject: Re: [perpass] encrypted PPP X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 19:14:31 -0000 On Sep 6, 2013, at 11:25 AM, Paul Wouters wrote: > On Fri, 6 Sep 2013, Nick Thomas wrote: >=20 > [ note, using "EU" for "end user" is _very_ confusing ] >=20 >> PPP gets a lot of use still, especially between EUs and access ISPs, >> where it's generally not encrypted. RFC1968 exists, but doesn't = actually >> seem useful any more. >>=20 >> I'm envisioning a PPP enhancement where EU and ISP can exchange = public >> keys beforehand, out-of-band if necessary, but it's all extremely = fuzzy >> at the moment. My access ISP, who I have considerable trust in, has = no >> real control over the infrastructure between my house and their = access >> node near London - all that's BT-operated, and they just get to >> terminate PPP over it. >=20 > Any ISP that does not trust the last-mile providers should offer their > customers VPN access via IPsec. Actually, they should offer it > regardless so their users can use a VPN to connect to the ISPs > infrastructure when the user is roaming on his laptop/phone as well. >=20 > There is no "ppp encryption" the ISP can add, because the last-mile > provider usually terminates the PPP(OE) session. They need to add > encryption on the resulting IP layer, not below it. I concur completely, but might add that TLS-style VPNs (OpenVPN, for = example) can be useful here too. But in either case, there's a = significant opex cost for the ISP. This also means, probably, having VPN software in your router. And the = code in your router is probably compromised by NSA, MSS, or both. -- Dean From nick@lupine.me.uk Fri Sep 6 12:49:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC9621E80E2 for ; Fri, 6 Sep 2013 12:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbIvzN1PeuKo for ; Fri, 6 Sep 2013 12:49:57 -0700 (PDT) Received: from oak.forest.a5775.uk0.bigv.io (lupine.me.uk [IPv6:2001:41c8:51:8:feff:ff:fe01:101]) by ietfa.amsl.com (Postfix) with ESMTP id E2F8511E8193 for ; Fri, 6 Sep 2013 12:49:55 -0700 (PDT) Received: from [213.138.102.179] by oak.forest.a5775.uk0.bigv.io with esmtpsa (SSL3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VI22I-0005Ab-9M; Fri, 06 Sep 2013 20:49:42 +0100 Message-ID: <1378496967.1832.15.camel@nlwork> From: Nick Thomas To: Paul Wouters Date: Fri, 06 Sep 2013 20:49:27 +0100 In-Reply-To: References: <5229A06F.5070800@lupine.me.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.8.5 (3.8.5-2.fc19) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] encrypted PPP X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 19:49:58 -0000 On Fri, 2013-09-06 at 12:25 -0400, Paul Wouters wrote: > Any ISP that does not trust the last-mile providers should offer their > customers VPN access via IPsec. Actually, they should offer it > regardless so their users can use a VPN to connect to the ISPs > infrastructure when the user is roaming on his laptop/phone as well. > > There is no "ppp encryption" the ISP can add, because the last-mile > provider usually terminates the PPP(OE) session. They need to add > encryption on the resulting IP layer, not below it. > > Paul Having discussed this with my access ISP, they've confirmed that they are responsible for terminating the PPP session, and could implement encrypted PPP in principle. Maybe this is ridiculously uncommon, I don't know. IPsec is great, and what I'm using over the last mile at the moment, but encrypting PPP appeals to me a lot. And maybe all that's needed is updating the list of crypto schemes in RFC1968? /Nick From stephen.farrell@cs.tcd.ie Fri Sep 6 12:52:53 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C554511E80FF for ; Fri, 6 Sep 2013 12:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rJAaaVHDk04 for ; Fri, 6 Sep 2013 12:52:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 49B9511E80EE for ; Fri, 6 Sep 2013 12:52:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 63F17BE4D; Fri, 6 Sep 2013 20:52:45 +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 YcbymkcecKs6; Fri, 6 Sep 2013 20:52:43 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.18.116]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2268ABE3F; Fri, 6 Sep 2013 20:52:43 +0100 (IST) Message-ID: <522A328A.5060008@cs.tcd.ie> Date: Fri, 06 Sep 2013 20:52:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dean Willis References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> In-Reply-To: <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 19:52:53 -0000 Hi Dean, My bet would be that some some but not all of those might fly. Others opinions? S. On 09/06/2013 02:23 AM, Dean Willis wrote: > > On Sep 2, 2013, at 1:55 PM, Stephen Farrell wrote: > >> >> So, given you've been thinking about this for maybe longer than most >> I'm wondering if you have any specific protocol changes or additions >> you'd suggest, or descriptions of new threat models that could be useful >> to WGs developing or maintaining protocols? IMO, things like that would >> be most useful for now. >> > > I think there are a couple of principles that we need to adopt IETF-wide. > > Part of the definition of "good Internet citizen" for a protocol or application is that not only does that protocol/application include anti-surveillance principles for itself, but that it helps OTHER protocols avoid surveillance. Surveillance-resistance is MORE IMPORTANT than optimizing transport efficiency. > > So, a couple of rules, probably badly organized: > > 1) Everything SHOULD be encrypted, unless there is an absolute operational requirement not to. This means "encryption by default" in new protocols, and not even specifying unencrypted operations modes unless necessary. Older protocol specs still in use should be revised to require encryption. Deprecate the non "s" versions of protocols. > > 2) Well-known ports should be avoided. Or overloaded to the point where the port number is no longer a significant indicator to the application. This gives rise to the "everything over 443" mentality, which we need to find a way to handle gracefully. Demuxing the service within the channel is a better idea than I used to think. > > 3) Packet sizes should be variable, preferably random. This is the opposite of the "discover the MTU and fill every packet" model of efficiency. Or, we could make all packets the same fixed size by padding small ones. I like random better, but there might well be some hardware optimizations around fixed packet sizes. > > 4) Every protocol spec needs to include a pseudonymous usage model, and most should include an anonymous usage model. > > 5) New protocols should be built around end-to-end crypto rather than relying on transport-level wrappers for everything. It's too easy to use a compromised CA-cert to dynamically build a TLS proxy cert. Some level of key delivery out-of-band, coupled to in-band footprint verification, is probably needed. zRTP is a good model. > > 6) Randomizing interpacket timing is useful. This does all sorts of horrible things to both TCP optimization and the jitter buffers in real-time communications. But it's worth it. Remember, surveillance-resistance is MORE IMPORTANT than efficiency. > > 7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have lessons we should learn. So does TOR. > > 8) Every piece of crypto-advice needs serious, multiparty, international, and aggressive review. No more documents authored by NSA shills (which Schneier says we seem to have). > > -- > Dean > > > > > From kathleen.moriarty@emc.com Fri Sep 6 13:02:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBE521F9EAE for ; Fri, 6 Sep 2013 13:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXtHxEqHw1DK for ; Fri, 6 Sep 2013 13:02:33 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9C41C11E80EE for ; Fri, 6 Sep 2013 13:02:30 -0700 (PDT) Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r86K2DUZ018150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Sep 2013 16:02:15 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com r86K2DUZ018150 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1378497735; bh=r30ZqGETAFe6/ZevE4/HxGAcE8o=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=wmna5MQwyh6crgztuYcLf85mrnRE2HJRjwtvooGYYnqciml1KRrdyIVeQjZVdJDCE JdP0Y3PxzU44LLfN7IvXN6SjSs5mdqLczA/27RFpsDvbGL/h4U4r9YoqJ6m4+jbW9F 6Rm+fAVw5OYVNhArn8UGInkWOWLe8TSfRMVHSMaw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com r86K2DUZ018150 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd53.lss.emc.com (RSA Interceptor); Fri, 6 Sep 2013 16:02:00 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r86K1vRa024466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Sep 2013 16:02:00 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Fri, 6 Sep 2013 16:01:58 -0400 From: "Moriarty, Kathleen" To: Stephen Farrell , Dean Willis Date: Fri, 6 Sep 2013 16:01:56 -0400 Thread-Topic: [perpass] Howdy! Thread-Index: Ac6rOrMmHbMKw99NQbah4syTAb3YJwAAFmvA Message-ID: References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> In-Reply-To: <522A328A.5060008@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-EMM-GWVC: 1 X-EMM-McAfeeVC: 1 X-RSA-Classifications: DLM_1, public Cc: "perpass@ietf.org" Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 20:02:37 -0000 Hi, I agree, some are great suggestions. However, I don't think the use of wel= l-known ports matter that much. Proxy firewalls know how to detect and dec= ipher protocols regardless of the port the protocol is sent over. We have = been aware of those capabilities as well as the MITM capabilities of produc= ts (firewalls, load balancers, etc.) for quite some time, but just accepted= them in corporate settings or limited what we do/did from those environmen= ts. I am also thinking more about information sharing and object level security= since I co-chair MILE. In RID, RFC6545 Section 9.1, it describes how to a= pply object level security specific to traffic over RID. Many of us know t= hat you can cite sections of an RFC, but not everyone knows that. I am won= dering if it would be helpful for me to write a generic version of that sec= tion (updating it where needed) to apply to any XML schema and any form of = transport. If so, I'll get that ready for the cut off. This could be used= by SACM as well, maybe other groups too. The draft Matt Miller is working on addresses object level security for XMP= P, so you may not need what I described for XMPP... Thanks, Kathleen -----Original Message----- From: perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Behalf = Of Stephen Farrell Sent: Friday, September 06, 2013 3:53 PM To: Dean Willis Cc: perpass@ietf.org Subject: Re: [perpass] Howdy! Hi Dean, My bet would be that some some but not all of those might fly. Others opinions? S. On 09/06/2013 02:23 AM, Dean Willis wrote: >=20 > On Sep 2, 2013, at 1:55 PM, Stephen Farrell w= rote: >=20 >> >> So, given you've been thinking about this for maybe longer than most=20 >> I'm wondering if you have any specific protocol changes or additions=20 >> you'd suggest, or descriptions of new threat models that could be=20 >> useful to WGs developing or maintaining protocols? IMO, things like=20 >> that would be most useful for now. >> >=20 > I think there are a couple of principles that we need to adopt IETF-wide. >=20 > Part of the definition of "good Internet citizen" for a protocol or appli= cation is that not only does that protocol/application include anti-surveil= lance principles for itself, but that it helps OTHER protocols avoid survei= llance. Surveillance-resistance is MORE IMPORTANT than optimizing transport= efficiency. >=20 > So, a couple of rules, probably badly organized: >=20 > 1) Everything SHOULD be encrypted, unless there is an absolute operationa= l requirement not to. This means "encryption by default" in new protocols, = and not even specifying unencrypted operations modes unless necessary. Olde= r protocol specs still in use should be revised to require encryption. Depr= ecate the non "s" versions of protocols. >=20 > 2) Well-known ports should be avoided. Or overloaded to the point where t= he port number is no longer a significant indicator to the application. Thi= s gives rise to the "everything over 443" mentality, which we need to find = a way to handle gracefully. Demuxing the service within the channel is a be= tter idea than I used to think. >=20 > 3) Packet sizes should be variable, preferably random. This is the opposi= te of the "discover the MTU and fill every packet" model of efficiency. Or,= we could make all packets the same fixed size by padding small ones. I lik= e random better, but there might well be some hardware optimizations around= fixed packet sizes. >=20 > 4) Every protocol spec needs to include a pseudonymous usage model, and m= ost should include an anonymous usage model. >=20 > 5) New protocols should be built around end-to-end crypto rather than rel= ying on transport-level wrappers for everything. It's too easy to use a com= promised CA-cert to dynamically build a TLS proxy cert. Some level of key d= elivery out-of-band, coupled to in-band footprint verification, is probably= needed. zRTP is a good model. >=20 > 6) Randomizing interpacket timing is useful. This does all sorts of horri= ble things to both TCP optimization and the jitter buffers in real-time com= munications. But it's worth it. Remember, surveillance-resistance is MORE I= MPORTANT than efficiency. >=20 > 7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have lessons= we should learn. So does TOR. >=20 > 8) Every piece of crypto-advice needs serious, multiparty, international,= and aggressive review. No more documents authored by NSA shills (which Sch= neier says we seem to have). >=20 > -- > Dean >=20 >=20 >=20 >=20 >=20 _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass From stephen.farrell@cs.tcd.ie Fri Sep 6 13:04:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D58911E80EE for ; Fri, 6 Sep 2013 13:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3BfORXkG-SQ for ; Fri, 6 Sep 2013 13:04:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4529111E80E7 for ; Fri, 6 Sep 2013 13:04:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 72DB8BE38; Fri, 6 Sep 2013 21:04:05 +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 GKWtBoDXI5-V; Fri, 6 Sep 2013 21:04:02 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.18.116]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 541F2BE4D; Fri, 6 Sep 2013 21:04:02 +0100 (IST) Message-ID: <522A3532.1080505@cs.tcd.ie> Date: Fri, 06 Sep 2013 21:04:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Trammell References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie> <436E1732-663B-42BF-8CA9-DFE48724D1F6@tik.ee.ethz.ch> <948B6E8A-8BD5-4776-BC7C-41D12C6F7537@tik.ee.ethz.ch> <52285DB1.2060506@cs.tcd.ie> <1407E07D-05FA-4299-98C1-ECDBC488F759@tik.ee.ethz.ch> In-Reply-To: <1407E07D-05FA-4299-98C1-ECDBC488F759@tik.ee.ethz.ch> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] On the perfect passive adversary X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 20:04:11 -0000 Hi Brian, On 09/05/2013 01:17 PM, Brian Trammell wrote: > hi Stephen, > > On 5 Sep 2013, at 12:32 , Stephen Farrell > wrote: > >> Two initial comments on the -00 version:- >> >> 1) I guess the scope here of purely considering passive monitoring >> is useful enough, but maybe we need to think about that some, if we >> consider it likely that some of the monitoring is being done from >> compromised hosts. While that attacker isn't actively MITMing >> application traffic, they are sort of active in that they're >> putting their code onto devices, and some of those can be in what >> might otherwise be considered "trusted" parts of the network. >> Maybe a good scope might be to assume here that the endpoints are >> not compromised but that e.g. routers, switches, DHCP servers etc. >> might be part of the monitoring network. Would that be worth >> thinking about for this document or would that be better left out, >> or left for another document? I'm not sure but would be interested >> in folks' thoughts. > > There's a very minor difference in terms of detectability between: > > (1) someone who can look at any of the packets on their way into > and/or out of any of the endpoints on the network between the > initiator and recipient, and > > (2) someone who can do that plus can observe internal state / stored > messages at any of the intermediate systems. > > The main practical difference is that confidentiality from > eavesdropping from adversary (2) requires end-to-end encryption, > while transport encryption is sufficient against adversary (1) > assuming you use it everywhere. Since we're already discussing this > on the list, it seems like we believe the additional threats in (2) > to be in scope. > > I think that if we assume any capabilities beyond that (e.g., DNS > cache poisoning, selective modification of traffic at an intermediate > system), we're not really talking about surveillance anymore. I'm not sure how that maps to my comment, sorry;-) So maybe there's a thing to discuss here and maybe we need a bit of new terminology. Part (by no means all) of the work here I think it to consider an attacker who: 1) passively records traffic from loads of places, including some that are within any security boundary you care to mention 2) can sometimes get access to e.g. an RSA private key and then decrypt recorded TLS non-PFS traffic For (1) and/or (2), the passive monitoring may have to have been preceded or succeeded by an active break-in to the nodes that subsequently become part of the monitoring network. (As a side question - maybe we should consider how much monitoring a subverted node could really do without breaking or otherwise getting caught.) But the attacker doesn't MITM the traffic we're trying to protect. Does that fit with your model? I hope so:-) > >> 2) While I fully agree that the "benefits" of pervasive monitoring >> ought be out of scope, I'm not sure I agree that analysis of the >> costs of pervasive monitoring ought be entirely out of scope. >> Presumably our goal here includes helping protocol designers >> increase those costs, hopefully to the point where Yoav is no >> longer in the top 100k cost-effective targets:-) So some >> consideration of the costs of monitoring would seem to be called >> for. > > The text here is poorly phrased; what I want to say is "we assume > this to be bad a priori and therefore advice protocol designers to do > the following to avoid it; we're not going to examine the (social) > cost-benefit analysis." > > i.e., we agree completely here. :) Cool, S. > >> We can't of course consider that in detail, but ruling it out of >> scope seems a bit wrong. Maybe we can consider the kinds of >> protocol features and deployment choices that would noticeably >> increase that cost, without getting into an analysis of what those >> costs might be? > > Indeed, the document already kind of does this by noting if you want > packets, you need to buy new 4TB disk per 10G link every 50+ > minutes. > > Cheers, > > Brian > > _______________________________________________ perpass mailing list > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > From rstruik.ext@gmail.com Fri Sep 6 13:40:51 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C4C11E80F7 for ; Fri, 6 Sep 2013 13:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWVUehhY4gEL for ; Fri, 6 Sep 2013 13:40:50 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id F193311E80F4 for ; Fri, 6 Sep 2013 13:40:48 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so8172658ieb.0 for ; Fri, 06 Sep 2013 13:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EBS9famQb2r/uxCK4348jPM6aeNrCVjIJYK21qo2TWQ=; b=Y2Pnn+m3JD756dvJ2HuHj2L+QYG4AX1hnlyYl2PfV2eqN73GvR4N1HhEHbwn+Tj4Ar aCrU9K1epAv3FpUKEOO6olMHYr0WF9dotCV/ETobVkOj/cP63lwEeKGB3Atn/F/aCSlG EekN84VpMcH4c1zqMglX0apNtZBid6PoAh5w3a9wSC1pJDnCl+nikMuzbH1OBfxl6rxz UB7H9PUcfzDZSYcMXbkVwLRhr+XBZi5sw9ZRBg1k/htu3bdqaYFQSuvaTo2stZV9fAIH lKFTq1VGQL3XLbx2CboJ+4Dv1lTbcg+rq+jmjLnlBXmyDxydzoDQPGda15dNhX4hdByG K96Q== X-Received: by 10.42.26.73 with SMTP id e9mr2711473icc.40.1378500047704; Fri, 06 Sep 2013 13:40:47 -0700 (PDT) Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPSA id ka5sm253250igb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Sep 2013 13:40:47 -0700 (PDT) Message-ID: <522A3DC1.6010901@gmail.com> Date: Fri, 06 Sep 2013 16:40:33 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> In-Reply-To: <522A328A.5060008@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Dean Willis Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 20:40:51 -0000 Hi Stephen: The list below does not necessarily consider trade-offs that may be less relevant for unconstrained networks, but that could be very important for constrained networks (where most devices can be expected to be longer term). Some general notes: - Randomizing packet length would be prohibitively expensive in energy-starved environments [e.g., with devices that depend on energy harvesting for their operation] and, perhaps, from a global climate change perspective [with about 2% of world energy consumption currently due to internet-related operations]). - One has to consider that each device may have to transgress from a state where it does not having any shared state with the network towards a state where it would (e.g., when joining a new network). So, one can expect differentiation in delivered security services to stay. - Inline or online centralized network management functionality may have to be traded for more decentralized/distributed network functionality. This may have major repercussions for OCSP, CRLs, DNS, etc, etc. The list goes on and on ... I speculate that the largest risks would not so much with the crypto constructs themselves, but more so with security policy management, initial keying and certification of device keys (esp. if key pairs are generated outside the device), privacy/traceability concerns, and concerns re implementation attacks (side channel and fault attacks). As a final note: even with changes to IETF protocols incorporating ideas from the list, this would not have stopped problems with some existing IETF protocols, where changes to unfortunate choices (case in point: invited talk Crypto 2013 on "why the world is still running on RC4") are slow. This is just to say that any change to the status quo is hard (and not all is of NSA's making). Rene On 9/6/2013 3:52 PM, Stephen Farrell wrote: > Hi Dean, > > My bet would be that some some but not all of those might fly. > > Others opinions? > > S. > > On 09/06/2013 02:23 AM, Dean Willis wrote: >> On Sep 2, 2013, at 1:55 PM, Stephen Farrell wrote: >> >>> So, given you've been thinking about this for maybe longer than most >>> I'm wondering if you have any specific protocol changes or additions >>> you'd suggest, or descriptions of new threat models that could be useful >>> to WGs developing or maintaining protocols? IMO, things like that would >>> be most useful for now. >>> >> I think there are a couple of principles that we need to adopt IETF-wide. >> >> Part of the definition of "good Internet citizen" for a protocol or application is that not only does that protocol/application include anti-surveillance principles for itself, but that it helps OTHER protocols avoid surveillance. Surveillance-resistance is MORE IMPORTANT than optimizing transport efficiency. >> >> So, a couple of rules, probably badly organized: >> >> 1) Everything SHOULD be encrypted, unless there is an absolute operational requirement not to. This means "encryption by default" in new protocols, and not even specifying unencrypted operations modes unless necessary. Older protocol specs still in use should be revised to require encryption. Deprecate the non "s" versions of protocols. RS>> One always needs to accommodate devices that may have to transgress from the state of having no shared state to having this shared state, e.g., when a fresh device wishes to join a new network. Using ephemeral aliases of Identifiers of communicating parties would make collecting traffic patterns much harder. <> >> 2) Well-known ports should be avoided. Or overloaded to the point where the port number is no longer a significant indicator to the application. This gives rise to the "everything over 443" mentality, which we need to find a way to handle gracefully. Demuxing the service within the channel is a better idea than I used to think. >> >> 3) Packet sizes should be variable, preferably random. This is the opposite of the "discover the MTU and fill every packet" model of efficiency. Or, we could make all packets the same fixed size by padding small ones. I like random better, but there might well be some hardware optimizations around fixed packet sizes. RS>> This might significantly increase the energy cost of packet transmissions in constrained network data and would be uneconomical in constrained networks, esp. if devices are powered using energy harvesting. <> Obviously, use of cryptographic techniques should be conditional on proper review and careful analysis of Well, all change may harm vested interests (see the Crypto/CHES invited talk on "why the world is still using RC4"). < _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From yaronf.ietf@gmail.com Sat Sep 7 06:39:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEA221E80A8 for ; Sat, 7 Sep 2013 06:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY8O-Q1-3R2k for ; Sat, 7 Sep 2013 06:39:23 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 11FBC11E812B for ; Sat, 7 Sep 2013 06:39:20 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so1454660wgh.3 for ; Sat, 07 Sep 2013 06:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=TVvqfQwfijBGc6X4aB+6XOJ15Y9JImAxUzMM8njgAQU=; b=M+x+pOWQ2z4oFucqtn7FaB8UwipQ+TXJBg0kbkB3If+eHZsd6VNsJIq5hn9te5z1Le 0Vix75HYEYyd63d26YigRCBLih++2fE0j9QmBb2qYXDOD0dFP8igdKapSYvfallu1YLi yq60l0brpKZ6/aiwjB3I97L0kgE7a5MWGG2ZJn1MI26If9PiPgTg/XiNdVlkiOFFijPX j9Yi3zgkBaN0aAm6Pqml30LL8uev8CWjo3juUxE1TThGwrpjm6kagZHihm2CpCgkbKFR r3D8B7weyu9g1at2MNeEoW8f0ob1CXfnjwouiiaBn01notS0nuESucqBUcS0L1VCIsev V9Yg== X-Received: by 10.180.37.164 with SMTP id z4mr2242607wij.30.1378561160278; Sat, 07 Sep 2013 06:39:20 -0700 (PDT) Received: from [10.0.0.8] (bzq-79-182-222-201.red.bezeqint.net. [79.182.222.201]) by mx.google.com with ESMTPSA id ey2sm3750196wib.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Sep 2013 06:39:19 -0700 (PDT) Message-ID: <522B2C86.7020300@gmail.com> Date: Sat, 07 Sep 2013 16:39:18 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 13:39:24 -0000 Hi, I have wanted to get my company on S/MIME for a while, and the recent=20 noise was the final motivator I needed. We are a small company doing=20 security, however (like anywhere else) not everybody can be considered a = security "expert". So Outlook and Thunderbird have good support for S/MIME. This is a good=20 starting point, right? Personally I am using Thunderbird running on=20 Linux, which has very convenient S/MIME support. I had actually used it=20 in the past. Below I will show that in today's market you simply cannot use S/MIME,=20 because of a combination of bad security practices, silly web-site=20 design, lousy CA support on Linux and probably a few more factors. * Started with the free options. The Web is full with tutorials on how to install the free Comodo email cert in your mail client. It turns out, with InstantSSL (Comodo) you cannot register twice with same email address (e.g. if the cert is lost for some reason or you just want to use two different machine without shuttling private keys around). The same is true for StartSSL. * Next tried Symantec: this is $22 per year, the UI is not very good (says cert is installed but then has a button to install cert). TB says the certificate could not be validated "for unknown reasons". I guess there is no valid certificate chain. Well, Symantec doesn't appear in either the Chromium/Linux or Firefox/Linux cert stores. * GlobalSign: EUR 12 for 1 yr, 29 for 3 yrs. Not too bad. So you go into their wizard. The default is that the private key is generated by the CA! Which means this product is not (securely) usable for multiple users in an organization. Most of them will probably leak their private key. * CACert: Free and open source. Probably still struggling (the server is extremely slow). Surprisingly, the CAcert root CA is known by Chromium/Linux but not by TB/Linux (stock Thunderbird on Ubuntu 12.04= ). * Entrust: pricing is only for US, UK and Canada. Other customers are referred to a small number of resellers (none for my geography). They still let you order the cert though. And then surprise! The $20 price that appears on the "Buy Now" page turns into $30 when you complete filling the form. This covers all I could find on the first 4 Google search pages for=20 "email certificates". I will try again in a year or two. Thanks, Yaron From stephen.farrell@cs.tcd.ie Sat Sep 7 08:00:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D33511E8142 for ; Sat, 7 Sep 2013 08:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkUE+j-08DGH for ; Sat, 7 Sep 2013 08:00:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3D84611E814C for ; Sat, 7 Sep 2013 08:00:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 111FEBE6E; Sat, 7 Sep 2013 16:00: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 LGDfTVB5zygx; Sat, 7 Sep 2013 16:00:34 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.18.116]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A2929BE68; Sat, 7 Sep 2013 16:00:34 +0100 (IST) Message-ID: <522B3F92.1090702@cs.tcd.ie> Date: Sat, 07 Sep 2013 16:00:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yaron Sheffer References: <522B2C86.7020300@gmail.com> In-Reply-To: <522B2C86.7020300@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 15:00:45 -0000 Fully agree with you. S/MIME as-is is not usable in the wild. PGP is better, but I doubt its usable by an entire organisation or set of home-users for most mail messages. Let's posit an end goal where a large proportion of email ends up with ciphertext bodies at least, but typically without a high level of assurance that the right public key was used. My questions: 1) Would we like to get there? 2) If we would, should we start from a) S/MIME or b) PGP or c) yet another mail-security clean slate? 3) If we got as far as having IETF consensus on something we think could do the above (i.e. we completed the RFCs for (2)), do we think there's any real chance that that could be deployed and end up widely used? FWIW, my answers would be 1) yes, 2) (c), reluctantly, since it'd only be worthwhile if it covered headers, and 3) "I very much doubt it unfortunately." I'd be surprised (but pleased) if we had a rough consensus on these questions. And even more surprised and pleased if that consensus indicated that there's an obvious thing that we should start doing in the near future. Sorry to be pessimistic, and I'd really love to be wrong, but I can't see a realistic way to get e2e email confidentiality out there as of now. If the top-tier email providers got their act together on something that didn't allow 'em to scan mail content (without launching a MITM) then that'd change my pessimism. I guess there is some chance of that, but I suspect that the initiative for such a service-provider driven effort would start outside the IETF (same as DKIM/DMARC). S. PS: Clarifications: SMTP/TLS with DANE is still worth doing and is being done. S/MIME and PGP are quite usable within a community or even large enterprise, but not on the big-I Internet. e2e mail message signing is maybe more easily doable but is uselessly boring IMO and not relevant for perpass, so that's not a goal at all. And by e2e confid. I mean that in almost all cases the private decryption keys are only really usable/available to an MUA on the user's machine and almost never on the MTA/MS. On 09/07/2013 02:39 PM, Yaron Sheffer wrote: > Hi, > > I have wanted to get my company on S/MIME for a while, and the recent > noise was the final motivator I needed. We are a small company doing > security, however (like anywhere else) not everybody can be considered a > security "expert". > > So Outlook and Thunderbird have good support for S/MIME. This is a good > starting point, right? Personally I am using Thunderbird running on > Linux, which has very convenient S/MIME support. I had actually used it > in the past. > > Below I will show that in today's market you simply cannot use S/MIME, > because of a combination of bad security practices, silly web-site > design, lousy CA support on Linux and probably a few more factors. > > * Started with the free options. The Web is full with tutorials on how > to install the free Comodo email cert in your mail client. It turns > out, with InstantSSL (Comodo) you cannot register twice with same > email address (e.g. if the cert is lost for some reason or you just > want to use two different machine without shuttling private keys > around). The same is true for StartSSL. > * Next tried Symantec: this is $22 per year, the UI is not very good > (says cert is installed but then has a button to install cert). TB > says the certificate could not be validated "for unknown reasons". I > guess there is no valid certificate chain. Well, Symantec doesn't > appear in either the Chromium/Linux or Firefox/Linux cert stores. > * GlobalSign: EUR 12 for 1 yr, 29 for 3 yrs. Not too bad. So you go > into their wizard. The default is that the private key is generated > by the CA! Which means this product is not (securely) usable for > multiple users in an organization. Most of them will probably leak > their private key. > * CACert: Free and open source. Probably still struggling (the server > is extremely slow). Surprisingly, the CAcert root CA is known by > Chromium/Linux but not by TB/Linux (stock Thunderbird on Ubuntu 12.04). > * Entrust: pricing is only for US, UK and Canada. Other customers are > referred to a small number of resellers (none for my geography). > They still let you order the cert though. And then surprise! The $20 > price that appears on the "Buy Now" page turns into $30 when you > complete filling the form. > > This covers all I could find on the first 4 Google search pages for > "email certificates". I will try again in a year or two. > > > Thanks, > > Yaron > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From hallam@gmail.com Sat Sep 7 08:43:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133F011E814B for ; Sat, 7 Sep 2013 08:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXxMyzxswkbR for ; Sat, 7 Sep 2013 08:43:08 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4794711E8149 for ; Sat, 7 Sep 2013 08:43:08 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ea20so3656891lab.41 for ; Sat, 07 Sep 2013 08:43:04 -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; bh=rWvGxyiZ72+qKkzxl0vfDHLDqV9wLMRxwniNCGjFr4U=; b=fc8dooebG5lQnvPUEHv5+TyaFoBW5pqBJDP/HsKJpEiMeYiI7Wnn33d/e85vdVKgK4 5n947LPovY3AbVcHvHXuQfFy9uylS5OfsfB6OseHWPIAIk9y2rhRTNiWSrw9WuJLnE7T NBDlvstbBXjlXtq8R+4YewWuXydhyyIwcxXhyEDsAqfPjWrGrtBHIv9j7TzHXSL2/pss iakHcPNjza//tpfeXN+kIVmUkcxLCzu9tyA+o5WxgGkxbQSNBKBzldUnFq6KYImZHkd3 zOxCSkI2Pd518n18smk9TxCWGTBSolg2Trujs08+dnaV4Vh+NmxtTB6zVgODjB2thtyU z7bA== MIME-Version: 1.0 X-Received: by 10.112.167.3 with SMTP id zk3mr7785899lbb.23.1378568584264; Sat, 07 Sep 2013 08:43:04 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Sat, 7 Sep 2013 08:43:04 -0700 (PDT) In-Reply-To: <522B3F92.1090702@cs.tcd.ie> References: <522B2C86.7020300@gmail.com> <522B3F92.1090702@cs.tcd.ie> Date: Sat, 7 Sep 2013 11:43:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c264a4c3825604e5cd0229 Cc: Yaron Sheffer , perpass@ietf.org Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 15:43:10 -0000 --001a11c264a4c3825604e5cd0229 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 7, 2013 at 11:00 AM, Stephen Farrell wrote: > > Fully agree with you. S/MIME as-is is not usable in the wild. > PGP is better, but I doubt its usable by an entire organisation > or set of home-users for most mail messages. > > Let's posit an end goal where a large proportion of email ends > up with ciphertext bodies at least, but typically without a high > level of assurance that the right public key was used. > As it happens I have been working on a draft on Prism-Proofing email for a couple of weeks now and was hoping to get an ID out with the idea of proposing a BOF or something to the Security AD. > My questions: > > 1) Would we like to get there? > I think we can do better than that. I have been looking at CT applying the concept (but not the exact spec) to email. But being able to send encrypted mail easily and being able to trust the keys are two separable concerns. Separating those concerns is what I was trying to do with XKMS but we never got it hooked into email clients and now the fashion is for JSON rather than XML (which I think is a good thing) > 2) If we would, should we start from a) S/MIME or b) PGP or > c) yet another mail-security clean slate? > Please lets not rehash the message format. S/MIME has won the encrypted mail message format and PKIX the key packaging format. I don't see any advantage to revisiting either. We can build any trust model we like with PKIX packaged public keys and the S/MIME packaging model isn't really a constraint. The real problems are in UI and in particular key distribution. The model is not automatic and it should be. I have pushed for using SRV records to make automated discovery possible but that is not really enough. Perry Metzeger has pointed out that any mechanism has to be deployable without administrator intervention (which I have a quibble on, I think the DNS domain administrator should be able to direct all queries to a lookup of their choice and block unauthorized sources). > 3) If we got as far as having IETF consensus on something > we think could do the above (i.e. we completed the RFCs > for (2)), do we think there's any real chance that that > could be deployed and end up widely used? > Well His Bruce-ship has made a call for action. Perhaps some of the people who hear it will write code. It would be really nice if there was at least one client (e.g. Thunderbird) that supported encrypted email native without any bolt ins. But even if we can't do that we can apply security by funneling the outbound traffic through a SUBMIT proxy that takes an email, sees if it can discover a key and if so encrypts. The reason I want to stick with S/MIME is that it means that I don't need to worry about the other half of the problem. I can free-ride on existing S/MIME clients for the decryption side of things. -- Website: http://hallambaker.com/ --001a11c264a4c3825604e5cd0229 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Sep 7, 2013 at 11:00 AM, Stephen Farrell = <stephen.= farrell@cs.tcd.ie> wrote:

Fully agree with you. S/MIME as-is is not usable in the wild.
PGP is better, but I doubt its usable by an entire organisation
or set of home-users for most mail messages.

Let's posit an end goal where a large proportion of email ends
up with ciphertext bodies at least, but typically without a high
level of assurance that the right public key was used.

As it happens I have been working on a draft on Prism-Proof= ing email for a couple of weeks now and was hoping to get an ID out with th= e idea of proposing a BOF or something to the Security AD.

=A0
My questions:

1) Would we like to get there?

I think = we can do better than that. I have been looking at CT applying the concept = (but not the exact spec) to email.=A0

But being ab= le to send encrypted mail easily and being able to trust the keys are two s= eparable concerns.

Separating those concerns is what I was trying to do wi= th XKMS but we never got it hooked into email clients and now the fashion i= s for JSON rather than XML (which I think is a good thing)

=A0
2) If we would, should we start from a) S/MIME or b) PGP or
=A0 =A0c) yet another mail-security clean slate?

<= /div>
Please lets not rehash the message format. S/MIME has won the enc= rypted mail message format and PKIX the key packaging format. I don't s= ee any advantage to revisiting either.=A0

We can build any trust model we like with PKIX packaged= public keys and the S/MIME packaging model isn't really a constraint.<= /div>

The real problems are in UI and in particular key = distribution. The model is not automatic and it should be. I have pushed fo= r using SRV records to make automated discovery possible but that is not re= ally enough. Perry Metzeger has pointed out that any mechanism has to be de= ployable without administrator intervention (which I have a quibble on, I t= hink the DNS domain administrator should be able to direct all queries to a= lookup of their choice and block unauthorized sources).

=A0
3) If we got as far as having IETF consensus on something
=A0 =A0we think could do the above (i.e. we completed the RFCs
=A0 =A0for (2)), do we think there's any real chance that that
=A0 =A0could be deployed and end up widely used?

<= /div>
Well His Bruce-ship has made a call for action. Perhaps some of t= he people who hear it will write code.

It would be= really nice if there was at least one client (e.g. Thunderbird) that suppo= rted encrypted email native without any bolt ins. But even if we can't = do that we can apply security by funneling the outbound traffic through a S= UBMIT proxy that takes an email, sees if it can discover a key and if so en= crypts.


The reason I want to stick with S/MIME i= s that it means that I don't need to worry about the other half of the = problem. I can free-ride on existing S/MIME clients for the decryption side= of things.



--
Website: http://hallambaker.com/
--001a11c264a4c3825604e5cd0229-- From yaronf.ietf@gmail.com Sat Sep 7 10:49:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1E421F9AC1 for ; Sat, 7 Sep 2013 10:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDH5kcA4uAlI for ; Sat, 7 Sep 2013 10:49:00 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6782A21F8E97 for ; Sat, 7 Sep 2013 10:49:00 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cb5so2025713wib.10 for ; Sat, 07 Sep 2013 10:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pMS47g0YdQKqfwPQik6Y7Ds7kP1BUP+PMO+hQgifj6E=; b=SzTCvBRZIAo2MkT11Jqy2cbookKez4L4icyK+WPvZzHLTnDH/CPlryAAGJ8ocZmmC/ RhvwJDrqOhcMUaq45d+iGFh9irX0uwTmuUzIea8ASjP8ZyUSGBP7frg2ZGOH4x+7S4DO EiVjDJF1WMAofQmwcpzgfBJ/F5yu1azcwC/nq4XUvrmVBIR+SRq+wNwyCKUbJeSLWKPn KW+VeMElwCQvQRliq9Fknq5hwfXEtvd9f4gopD5lCFRDOgf1dUAdeQNRFrBtSm5j/wR2 HhvYsno4cuQAOH5d283rXaymDtvBnIruGyKlJBhU8pkHybdyUm3BGPdfKFoGLRtxZ3Q2 cPHQ== X-Received: by 10.194.201.202 with SMTP id kc10mr6777131wjc.1.1378576139530; Sat, 07 Sep 2013 10:48:59 -0700 (PDT) Received: from [10.0.0.8] (bzq-79-182-222-201.red.bezeqint.net. [79.182.222.201]) by mx.google.com with ESMTPSA id i3sm5135830wiw.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Sep 2013 10:48:59 -0700 (PDT) Message-ID: <522B6709.4070009@gmail.com> Date: Sat, 07 Sep 2013 20:48:57 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <522B2C86.7020300@gmail.com> <522B3F92.1090702@cs.tcd.ie> In-Reply-To: <522B3F92.1090702@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 17:49:01 -0000 Hi Stephen, In fact I believe S/MIME is not usable today for economical reasons, rather than technical ones. - Big mail providers are in the business *because* they can snoop your mail. - They have enough resources to make the user experience of Web mail better than that of dedicated email clients, even though from a technical point of view this is absurd. - People are happy with Web mail, and are not interested enough in e2e encryption to create a market. - Thus the sorry state of the market for email certs, as my experiment shows. From a technical point of view, I think S/MIME is a very good starting point. I have no idea how to break out of the economical bind. I just hope that the current situation will create enough demand to inject some life into this market. BTW, S/MIME is not even usable for small enterprises, for two reasons: First because you'd need to install the CA cert on all sorts of mobile devices, which is hard when you don't have dedicated IT. And second, because you don't want an email that you send outside the enterprise to generate scary "unknown certificate" warnings on the recipient's client. S/MIME with DANE would alleviate this problem if organizations were allowed to generate their own certificates, including email certs, and have them chained to the DNS root of trust. I don't know if DANE supports this usage scenario by default. Thanks, Yaron On 09/07/2013 06:00 PM, Stephen Farrell wrote: > > Fully agree with you. S/MIME as-is is not usable in the wild. > PGP is better, but I doubt its usable by an entire organisation > or set of home-users for most mail messages. > > Let's posit an end goal where a large proportion of email ends > up with ciphertext bodies at least, but typically without a high > level of assurance that the right public key was used. > > My questions: > > 1) Would we like to get there? > 2) If we would, should we start from a) S/MIME or b) PGP or > c) yet another mail-security clean slate? > 3) If we got as far as having IETF consensus on something > we think could do the above (i.e. we completed the RFCs > for (2)), do we think there's any real chance that that > could be deployed and end up widely used? > > FWIW, my answers would be 1) yes, 2) (c), reluctantly, since > it'd only be worthwhile if it covered headers, and 3) "I very > much doubt it unfortunately." > > I'd be surprised (but pleased) if we had a rough consensus on > these questions. And even more surprised and pleased if that > consensus indicated that there's an obvious thing that we > should start doing in the near future. > > Sorry to be pessimistic, and I'd really love to be wrong, but > I can't see a realistic way to get e2e email confidentiality > out there as of now. > > If the top-tier email providers got their act together on > something that didn't allow 'em to scan mail content (without > launching a MITM) then that'd change my pessimism. I guess > there is some chance of that, but I suspect that the > initiative for such a service-provider driven effort would > start outside the IETF (same as DKIM/DMARC). > > S. > > PS: Clarifications: SMTP/TLS with DANE is still worth doing > and is being done. S/MIME and PGP are quite usable within a > community or even large enterprise, but not on the big-I > Internet. e2e mail message signing is maybe more easily > doable but is uselessly boring IMO and not relevant for > perpass, so that's not a goal at all. And by e2e confid. > I mean that in almost all cases the private decryption > keys are only really usable/available to an MUA on the > user's machine and almost never on the MTA/MS. > > > > > On 09/07/2013 02:39 PM, Yaron Sheffer wrote: >> Hi, >> >> I have wanted to get my company on S/MIME for a while, and the recent >> noise was the final motivator I needed. We are a small company doing >> security, however (like anywhere else) not everybody can be considered a >> security "expert". >> >> So Outlook and Thunderbird have good support for S/MIME. This is a good >> starting point, right? Personally I am using Thunderbird running on >> Linux, which has very convenient S/MIME support. I had actually used it >> in the past. >> >> Below I will show that in today's market you simply cannot use S/MIME, >> because of a combination of bad security practices, silly web-site >> design, lousy CA support on Linux and probably a few more factors. >> >> * Started with the free options. The Web is full with tutorials on how >> to install the free Comodo email cert in your mail client. It turns >> out, with InstantSSL (Comodo) you cannot register twice with same >> email address (e.g. if the cert is lost for some reason or you just >> want to use two different machine without shuttling private keys >> around). The same is true for StartSSL. >> * Next tried Symantec: this is $22 per year, the UI is not very good >> (says cert is installed but then has a button to install cert). TB >> says the certificate could not be validated "for unknown reasons". I >> guess there is no valid certificate chain. Well, Symantec doesn't >> appear in either the Chromium/Linux or Firefox/Linux cert stores. >> * GlobalSign: EUR 12 for 1 yr, 29 for 3 yrs. Not too bad. So you go >> into their wizard. The default is that the private key is generated >> by the CA! Which means this product is not (securely) usable for >> multiple users in an organization. Most of them will probably leak >> their private key. >> * CACert: Free and open source. Probably still struggling (the server >> is extremely slow). Surprisingly, the CAcert root CA is known by >> Chromium/Linux but not by TB/Linux (stock Thunderbird on Ubuntu 12.04). >> * Entrust: pricing is only for US, UK and Canada. Other customers are >> referred to a small number of resellers (none for my geography). >> They still let you order the cert though. And then surprise! The $20 >> price that appears on the "Buy Now" page turns into $30 when you >> complete filling the form. >> >> This covers all I could find on the first 4 Google search pages for >> "email certificates". I will try again in a year or two. >> >> >> Thanks, >> >> Yaron >> >> >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> >> From hallam@gmail.com Sat Sep 7 12:58:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AAE11E80EF for ; Sat, 7 Sep 2013 12:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OL38mgCQPZv for ; Sat, 7 Sep 2013 12:58:06 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E94BA11E80E9 for ; Sat, 7 Sep 2013 12:57:54 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ea20so3814013lab.13 for ; Sat, 07 Sep 2013 12:57:54 -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; bh=23knMEBbiBZG+gwF9Nqa8AgYOP4eZ3WHSwWaqi2HDUc=; b=gDdCGaHuJdzEHQCNX3uGSUHXGyjhsepRQStnZwgudBhtuty/KoAAJ8gH0QNKo7/+W+ NKXfMmT5MaDj2zANEIZviTqWa23Wn3k0XaV66aWu1dO+sR3TCX1j2usZpHvs8v7is0Pr FkiSzIW7l67juZvbnrzH8tcNJDZVPqEoXy6WttkKdIwH0ftOVKFOQ8Xh+3lrSixvah7k Ng8elxm6GQZam31Nf1E109qC8sT9sTJOY9AeyYltsLyaF23/iyy2eAE8d8K90zNMvcbS 3eL2c1mWsjtRo2NQOtW4Od4A6xgU982iJJMK/35Z15DnJd77SZ8Xr/eLyKyIcUX29qkL LyIQ== MIME-Version: 1.0 X-Received: by 10.152.19.1 with SMTP id a1mr8169456lae.8.1378583872770; Sat, 07 Sep 2013 12:57:52 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Sat, 7 Sep 2013 12:57:52 -0700 (PDT) In-Reply-To: <522B6709.4070009@gmail.com> References: <522B2C86.7020300@gmail.com> <522B3F92.1090702@cs.tcd.ie> <522B6709.4070009@gmail.com> Date: Sat, 7 Sep 2013 15:57:52 -0400 Message-ID: From: Phillip Hallam-Baker To: Yaron Sheffer Content-Type: multipart/alternative; boundary=089e01493e4207981f04e5d0926d Cc: perpass@ietf.org, Stephen Farrell Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 19:58:07 -0000 --089e01493e4207981f04e5d0926d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 7, 2013 at 1:48 PM, Yaron Sheffer wrote: > Hi Stephen, > > In fact I believe S/MIME is not usable today for economical reasons, > rather than technical ones. > > - Big mail providers are in the business *because* they can snoop your > mail. > - They have enough resources to make the user experience of Web mail > better than that of dedicated email clients, even though from a technical > point of view this is absurd. > - People are happy with Web mail, and are not interested enough in e2e > encryption to create a market. > - Thus the sorry state of the market for email certs, as my experiment > shows. > > From a technical point of view, I think S/MIME is a very good starting > point. > > I have no idea how to break out of the economical bind. I just hope that > the current situation will create enough demand to inject some life into > this market. > > BTW, S/MIME is not even usable for small enterprises, for two reasons: > First because you'd need to install the CA cert on all sorts of mobile > devices, which is hard when you don't have dedicated IT. And second, > because you don't want an email that you send outside the enterprise to > generate scary "unknown certificate" warnings on the recipient's client. > > S/MIME with DANE would alleviate this problem if organizations were > allowed to generate their own certificates, including email certs, and have > them chained to the DNS root of trust. I don't know if DANE supports this > usage scenario by default. > DANE and any DNS based scheme is going to require a level of administrative action that is infeasible for a per-user based approach. DANE with STARTTLS is very different because the mail server DANE records can be configured at the same time as the MX, SPF and DKIM records. -- Website: http://hallambaker.com/ --089e01493e4207981f04e5d0926d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Sep 7, 2013 at 1:48 PM, Yaron Sheffer <= ;yaronf.ietf@gma= il.com> wrote:
Hi Stephen,

In fact I believe S/MIME is not usable today for economical reasons, rather= than technical ones.

- Big mail providers are in the business *because* they can snoop your mail= .
- They have enough resources to make the user experience of Web mail better= than that of dedicated email clients, even though from a technical point o= f view this is absurd.
- People are happy with Web mail, and are not interested enough in e2e encr= yption to create a market.
- Thus the sorry state of the market for email certs, as my experiment show= s.

>From a technical point of view, I think S/MIME is a very good starting poin= t.

I have no idea how to break out of the economical bind. I just hope that th= e current situation will create enough demand to inject some life into this= market.

BTW, S/MIME is not even usable for small enterprises, for two reasons: Firs= t because you'd need to install the CA cert on all sorts of mobile devi= ces, which is hard when you don't have dedicated IT. And second, becaus= e you don't want an email that you send outside the enterprise to gener= ate scary "unknown certificate" warnings on the recipient's c= lient.

S/MIME with DANE would alleviate this problem if organizations were allowed= to generate their own certificates, including email certs, and have them c= hained to the DNS root of trust. I don't know if DANE supports this usa= ge scenario by default.


DANE and any DNS based sche= me is going to require a level of administrative action that is infeasible = for a per-user based approach.

DANE with STARTTLS = is very different because the mail server DANE records can be configured at= the same time as the MX, SPF and DKIM records.


--
Website: http://hallambaker.com/
--089e01493e4207981f04e5d0926d-- From code@funwithsoftware.org Sun Sep 8 18:39:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64BB21F99E9 for ; Sun, 8 Sep 2013 18:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMbBwGhnxSgL for ; Sun, 8 Sep 2013 18:39:10 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7BF21F938E for ; Sun, 8 Sep 2013 18:39:10 -0700 (PDT) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 9B8F21EE4FBC for ; Sun, 8 Sep 2013 21:39:08 -0400 (EDT) Received: (qmail 503 invoked from network); 9 Sep 2013 01:39:08 -0000 Received: by simscan 1.4.0 ppid: 24876, pid: 17595, t: 1.7054s scanners: clamav: 0.88.2/m:52/d:13495 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Sep 2013 01:39:06 -0000 Message-ID: <522D26B8.80107@funwithsoftware.org> Date: Sun, 08 Sep 2013 18:39:04 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: tls@ietf.org, perpass@ietf.org References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com> In-Reply-To: <522C3497.9020301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 01:39:15 -0000 One thing which I feel is missing is recommendations on the size of Diffie-Hellman parameters. It seems generally accepted that 1024-bit Diffie-Hellman is no longer secure, and yet that's what most folks are still using. How about something along the lines of "Diffie-Hellman parameters of at least 2048 bits SHOULD be chosen"? --Patrick On 9/8/13 1:25 AM, Yaron Sheffer wrote: > This is an early version of my proposal for a BCP-like document, to > inform the industry on what can be done with existing implementations, > while TLS 1.3 is still not ready. > > I would appreciate your comments of course. Specifically, > I would like to fill in the Implementation Status table (Sec. 5) and > would be glad to receive solid information (dates, planned dates, > version numbers) from implementers. > > Thanks, > Yaron > > -------- Original Message -------- > Subject: New Version Notification for draft-sheffer-tls-bcp-00.txt > Date: Sat, 07 Sep 2013 15:46:38 -0700 > From: internet-drafts@ietf.org > To: Yaron Sheffer > > > A new version of I-D, draft-sheffer-tls-bcp-00.txt > has been successfully submitted by Yaron Sheffer and posted to the > IETF repository. > > Filename: draft-sheffer-tls-bcp > Revision: 00 > Title: Recommendations for Secure Use of TLS and DTLS > Creation date: 2013-09-08 > Group: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-sheffer-tls-bcp-00.txt > Status: http://datatracker.ietf.org/doc/draft-sheffer-tls-bcp > Htmlized: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 > > > Abstract: > Over the last few years there have been several serious attacks on > TLS, including attacks on its most commonly used ciphers and modes of > operation. This document offers recommendations on securely using > the TLS and DTLS protocols, given existing standards and > implementations. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From code@funwithsoftware.org Sun Sep 8 22:47:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128C521E813B for ; Sun, 8 Sep 2013 22:47:03 -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=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYB0m1Srtey1 for ; Sun, 8 Sep 2013 22:46:51 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id E057221E809F for ; Sun, 8 Sep 2013 22:46:47 -0700 (PDT) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 2EDEA1EE4FB8 for ; Mon, 9 Sep 2013 01:46:44 -0400 (EDT) Received: (qmail 19651 invoked from network); 9 Sep 2013 05:46:43 -0000 Received: by simscan 1.4.0 ppid: 8977, pid: 30391, t: 1.6383s scanners: clamav: 0.88.2/m:52/d:13495 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 9 Sep 2013 05:46:42 -0000 Message-Id: <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> From: Patrick Pelletier To: Peter Gutmann , perpass@ietf.org, tls@ietf.org In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> Content-Type: multipart/alternative; boundary=Apple-Mail-15-966441861 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 8 Sep 2013 22:46:40 -0700 References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> X-Mailer: Apple Mail (2.936) Subject: Re: [perpass] [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 05:47:03 -0000 --Apple-Mail-15-966441861 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 8, 2013, at 8:16 PM, Peter Gutmann wrote: > Patrick Pelletier writes: > >> It seems generally accepted that 1024-bit Diffie-Hellman is no >> longer secure, > > Really? DLP != factoring. I'm an engineer, not a cryptographer, and I don't claim to understand the math. But I've seen statements to that effect here, for example: http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html The IETF's own RFC 3766/BCP 86 indicates that 1024-bit Diffie-Hellman would fall in between a 70 and 80 bit symmetric key: +-------------+-----------+--------------+--------------+ | System | | | | | requirement | Symmetric | RSA or DH | DSA subgroup | | for attack | key size | modulus size | size | | resistance | (bits) | (bits) | (bits) | | (bits) | | | | +-------------+-----------+--------------+--------------+ | 70 | 70 | 947 | 129 | | 80 | 80 | 1228 | 148 | | 90 | 90 | 1553 | 167 | | 100 | 100 | 1926 | 186 | | 150 | 150 | 4575 | 284 | | 200 | 200 | 8719 | 383 | | 250 | 250 | 14596 | 482 | +-------------+-----------+--------------+--------------+ and other such tables come to similar conclusions. For example, ECRYPT II says a 1248-bit discrete log group only provides protection until 2015: http://www.keylength.com/en/3/ >> How about something along the lines of "Diffie-Hellman parameters >> of at least >> 2048 bits SHOULD be chosen"? > > Why at least 2048 bits? What's wrong with 1280, or 1536, which will > be quite > a lot faster. It seems like a good ballpark from looking at these tables, but I'm certainly not claiming 2048 exactly the right number. My point was merely that the draft should say something about DH group size. If 1024 is in fact good enough, then it should say that, rather than being silent on the subject. --Patrick --Apple-Mail-15-966441861 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Sep 8, 2013, at = 8:16 PM, Peter Gutmann wrote:

Patrick= Pelletier <code@funwithsoftware.org> = writes:

It seems generally accepted = that 1024-bit Diffie-Hellman is no longer = secure,

Really?  DLP !=3D = factoring.

I'm an engineer, = not a cryptographer, and I don't claim to understand the math.  But = I've seen statements to that effect here, for = example:


The IETF's own RFC 3766/BCP 86 = indicates that 1024-bit Diffie-Hellman would fall in between a 70 and 80 = bit symmetric key:

  =  +-------------+-----------+--------------+--------------+
=    | System      |         =   |              |     =          |
   | requirement = | Symmetric | RSA or DH    | DSA subgroup |
  =  | for attack  | key size  | modulus size | size   =       |
   | resistance  | = (bits)    | (bits)       | (bits)     =   |
   | (bits)      |   =         |             =  |             =  |
  =  +-------------+-----------+--------------+--------------+
=    |     70      |     70 =    |      947     |     129 =      |
   |     80   =    |     80    |     1228   =   |     148      |
  =  |     90      |     90   =  |     1553     |     167   =    |
   |    100     =  |    100    |     1926     = |     186      |
   | =    150      |    150    | =     4575     |     284     =  |
   |    200      | =    200    |     8719     | =     383      |
   |   =  250      |    250    |   =  14596     |     482     =  |
  =  +-------------+-----------+--------------+--------------+
=
and other such tables come to similar conclusions. =  For example, ECRYPT II says a 1248-bit discrete log group only = provides protection until 2015:


How about something along the lines of "Diffie-Hellman = parameters of at least
2048 = bits SHOULD be chosen"?

Why at least 2048 bits? =  What's wrong with 1280, or 1536, which will be quite
a lot = faster.

It seems like a good = ballpark from looking at these tables, but I'm certainly not claiming = 2048 exactly the right number.  My point was merely that the draft = should say something about DH group size.  If 1024 is in fact good = enough, then it should say that, rather than being silent on the = subject.

--Patrick

= --Apple-Mail-15-966441861-- From ynir@checkpoint.com Sun Sep 8 23:59:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5E21E8159; Sun, 8 Sep 2013 23:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wBBMCqqD5Ve; Sun, 8 Sep 2013 23:59:28 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2D21E8143; Sun, 8 Sep 2013 23:59:27 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r896x18I029156; Mon, 9 Sep 2013 09:59:01 +0300 X-CheckPoint: {522D71B5-6-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Mon, 9 Sep 2013 09:59:01 +0300 From: Yoav Nir To: Patrick Pelletier Thread-Topic: [perpass] [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt Thread-Index: AQHOrSAT7vhu+KgFPUyyfi4xkQQkepm8x56A Date: Mon, 9 Sep 2013 06:59:01 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> In-Reply-To: <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.29] x-kse-antivirus-interceptor-info: protection disabled Content-Type: multipart/alternative; boundary="_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_" MIME-Version: 1.0 Cc: "" , "" , Peter Gutmann Subject: Re: [perpass] [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 06:59:40 -0000 --_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Patrick. Those tables are mostly quoting NIST publications, so while it seems like t= here's many sources, they're not really independent. There are academic results in factoring 768-bit numbers, so with sufficient= thrust (and the NSA has more thrust than most academics), it's perfectly l= ogical to suspect that the NSA can factor 1024-bit numbers. That would be a= breakage of RSA, not D-H or DSA. There seems to be an assumption behind th= ose tables that the strength of RSA and DSA for the same bit length is abou= t equal. I don't know what this is based on, but then, IANAC. BTW: If the entire Internet was using 768-bit RSA keying and single-DES enc= ryption, then the NSA could decrypt any connection they wanted, but they wo= uld only have the resources to spy on very few people. Even if we used anon= ymous D-H for TLS, which would allow the NSA to trivially MITM any connecti= on, just having the encryption there means that the same hardware can inter= cept far fewer connections. I suspect that with enough TOR traffic scrambled hard enough that you can't= decrypt a particular one without decrypting a significant portion of the c= onnections, 1024-bit DHE is plenty strong enough. Sure, upgrading to 2048-b= it makes it harder to crack, but the TOR network is already way too slow. Yoav On Sep 9, 2013, at 8:46 AM, Patrick Pelletier > wrote: On Sep 8, 2013, at 8:16 PM, Peter Gutmann wrote: Patrick Pelletier > writes: It seems generally accepted that 1024-bit Diffie-Hellman is no longer secur= e, Really? DLP !=3D factoring. I'm an engineer, not a cryptographer, and I don't claim to understand the m= ath. But I've seen statements to that effect here, for example: http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html The IETF's own RFC 3766/BCP 86 indicates that 1024-bit Diffie-Hellman would= fall in between a 70 and 80 bit symmetric key: +-------------+-----------+--------------+--------------+ | System | | | | | requirement | Symmetric | RSA or DH | DSA subgroup | | for attack | key size | modulus size | size | | resistance | (bits) | (bits) | (bits) | | (bits) | | | | +-------------+-----------+--------------+--------------+ | 70 | 70 | 947 | 129 | | 80 | 80 | 1228 | 148 | | 90 | 90 | 1553 | 167 | | 100 | 100 | 1926 | 186 | | 150 | 150 | 4575 | 284 | | 200 | 200 | 8719 | 383 | | 250 | 250 | 14596 | 482 | +-------------+-----------+--------------+--------------+ and other such tables come to similar conclusions. For example, ECRYPT II = says a 1248-bit discrete log group only provides protection until 2015: http://www.keylength.com/en/3/ How about something along the lines of "Diffie-Hellman parameters of at lea= st 2048 bits SHOULD be chosen"? Why at least 2048 bits? What's wrong with 1280, or 1536, which will be qui= te a lot faster. It seems like a good ballpark from looking at these tables, but I'm certain= ly not claiming 2048 exactly the right number. My point was merely that th= e draft should say something about DH group size. If 1024 is in fact good = enough, then it should say that, rather than being silent on the subject. --Patrick _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass --_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8F13BD361FD30E41A1E47BEB75AF84A6@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi Patrick. 

Those tables are mostly quoting NIST publications, so while it seems l= ike there's many sources, they're not really independent. 

There are academic results in factoring 768-bit numbers, so with suffi= cient thrust (and the NSA has more thrust than most academics), it's perfec= tly logical to suspect that the NSA can factor 1024-bit numbers. That would= be a breakage of RSA, not D-H or DSA. There seems to be an assumption behind those tables that the strength= of RSA and DSA for the same bit length is about equal. I don't know what t= his is based on, but then, IANAC.

BTW: If the entire Internet was using 768-bit RSA keying and single-DE= S encryption, then the NSA could decrypt any connection they wanted, but th= ey would only have the resources to spy on very few people. Even if we used= anonymous D-H for TLS, which would allow the NSA to trivially MITM any connection, just having the encryption= there means that the same hardware can intercept far fewer connections.

I suspect that with enough TOR traffic scrambled hard enough that you = can't decrypt a particular one without decrypting a significant portion of = the connections, 1024-bit DHE is plenty strong enough. Sure, upgrading to 2= 048-bit makes it harder to crack, but the TOR network is already way too slow.

Yoav

On Sep 9, 2013, at 8:46 AM, Patrick Pelletier <code@funwithsoftware.org> wrote:

On Sep 8, 2013, at 8:16 PM, Peter Gutmann wrote:

Patrick Pelletier <code@funwithsoftware.org> writes:

It seems generally accepted that 1024-bit Diffie-= Hellman is no longer secure,

Really?  DLP !=3D factoring.

I'm an engineer, not a cryptographer, and I don't claim to understand = the math.  But I've seen statements to that effect here, for example:<= /div>


The IETF's own RFC 3766/BCP 86 indicates that 1024-bit Diffie-Hellman = would fall in between a 70 and 80 bit symmetric key:

   +-------------+-----------+--------------+= ;--------------+
   | System      |        = ;   |              |     =          |
   | requirement | Symmetric | RSA or DH    | DSA = subgroup |
   | for attack  | key size  | modulus size | size=         |
   | resistance  | (bits)    | (bits)   =     | (bits)       |
   | (bits)      |        = ;   |              |     =          |
   +-------------+-----------+--------------+= ;--------------+
   |     70      |     70=    |      947     |     129 &= nbsp;    |
   |     80      |     80=    |     1228     |     148  =    |
   |     90      |     90=    |     1553     |     167  =    |
   |    100      |    100=    |     1926     |     186  =    |
   |    150      |    150=    |     4575     |     284  =    |
   |    200      |    200=    |     8719     |     383  =    |
   |    250      |    250=    |    14596     |     482  =    |
   +-------------+-----------+--------------+= ;--------------+

and other such tables come to similar conclusions.  For example, = ECRYPT II says a 1248-bit discrete log group only provides protection until= 2015:


How about something along the lines of "Diff= ie-Hellman parameters of at least
2048 bits SHOULD be chosen"?

Why at least 2048 bits?  What's wrong with 1280, or 1536, which will b= e quite
a lot faster.

It seems like a good ballpark from looking at these tables, but I'm ce= rtainly not claiming 2048 exactly the right number.  My point was mere= ly that the draft should say something about DH group size.  If 1024 i= s in fact good enough, then it should say that, rather than being silent on the subject.

--Patrick

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

--_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_-- From hannes.tschofenig@gmx.net Mon Sep 9 01:27:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D310221F89A6 for ; Mon, 9 Sep 2013 01:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.365 X-Spam-Level: X-Spam-Status: No, score=-101.365 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7L7+GKbKE+i for ; Mon, 9 Sep 2013 01:26:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id D9FED11E8189 for ; Mon, 9 Sep 2013 01:26:50 -0700 (PDT) Received: from [10.255.133.212] ([194.251.119.201]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MKIEQ-1VIOJI0PNG-001jRc for ; Mon, 09 Sep 2013 10:26:50 +0200 Message-ID: <522D863F.10903@gmx.net> Date: Mon, 09 Sep 2013 11:26:39 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: perpass@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sKi4gqwc59k30puZmaosrgWA9bF1fk/XiIKuQJnRgpfzssxN+8e RioaqZ1yFB0SOZkLOh5pxUKUsHBBAZ+DV6w7qHD7Mn/hLtNnE5lG7qmeDL/tsIZNANnVpmb yHiY8/HN5O/ANRX0kEv8M9dC2dXgauYq8Ky+jogl1XH5OBUfSzlDOMUrfMbBatUFdze9gbz sxO1ywa/Tnm8XZAHF/Nhw== Cc: hannes.tschofenig@gmx.net Subject: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 08:27:02 -0000 Hi all, I gave a presentation last week to a group of international data protection authorities about VoIP security & privacy. I produced a blog post about the presentation and put it here: http://www.tschofenig.priv.at/wp/?p=997 It contains a number of recommendations, which are addressed to VoIP providers and vendors but have to be enforced by data protection authorities. The recommendations unfortunately highlight some challenges... Would be interesting to hear your thoughts. Ciao Hannes From pgut001@cs.auckland.ac.nz Sun Sep 8 20:17:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1BF21E8132; Sun, 8 Sep 2013 20:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnTx+h+4IhrN; Sun, 8 Sep 2013 20:17:31 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84721E8126; Sun, 8 Sep 2013 20:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378696651; x=1410232651; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=iZsUKKFcMmEzCJuM2dS/YGablXQY/riA+GFNHPOFz00=; b=jWzTNjbSPMw9RJ0q0hfPPLuMKsP4cuPN4xw4vuzk8p+wrGAaIAnAatnk Cz1HHIMLKwpeEcjnJo00osTPoN6Ox+zI1CImTHBIDP9jIkpOrOuUyPiFN 3rM3GkOK/bDLf/5pSWzNzz+KVgjN58YyOTufXWwTI94LxfLTf/rin66Kd M=; X-IronPort-AV: E=Sophos;i="4.90,866,1371038400"; d="scan'208";a="211192053" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Sep 2013 15:17:28 +1200 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 9 Sep 2013 15:16:42 +1200 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.48]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 15:16:41 +1200 From: Peter Gutmann To: "code@funwithsoftware.org" , "perpass@ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt Thread-Index: Ac6tCwDuNtvHI0CwR7yKfQrIPEIkOA== Date: Mon, 9 Sep 2013 03:16:41 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Sep 2013 02:20:59 -0700 Subject: Re: [perpass] [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 03:17:37 -0000 Patrick Pelletier writes:=0A= =0A= >It seems generally accepted that 1024-bit Diffie-Hellman is no longer secu= re,=0A= =0A= Really? DLP !=3D factoring.=0A= =0A= >How about something along the lines of "Diffie-Hellman parameters of at le= ast=0A= >2048 bits SHOULD be chosen"?=0A= =0A= Why at least 2048 bits? What's wrong with 1280, or 1536, which will be qui= te=0A= a lot faster.=0A= =0A= Peter.=0A= From n.mavrogiannopoulos@gmail.com Mon Sep 9 01:36:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D3911E8111; Mon, 9 Sep 2013 01:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL8wCbjiBaQJ; Mon, 9 Sep 2013 01:36:02 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 472F021F8793; Mon, 9 Sep 2013 01:36:02 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b15so2978036eek.40 for ; Mon, 09 Sep 2013 01:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=f/tFwJrB6NM4OTPJNLFEPlse6lYyPkSS7CJHWmu/ai8=; b=jzy3wnnvynKji5oScJtsI7m2SsTzaqC/A58xjvO99KSfnn5YOFZ2gzI+47H1XZpy/1 qeTGvqLHb7YRYbGzFxQlkdudNZk0l1tzY3j8X+YTIQ+/BOdwOK4vcrAET2Xdam6XSBUr TdUQaL5bXzvfmu7oVRtSMECmAIHEzZtbzIxW2V0+invcuY7R8EF2HX0XIOj09zw5wr1I RI0GlpTnk6cgOUVeWNRo0ZGVSO7OjqQxKkfJaC7Td8KBPp6QOaIuMHttdpMnyOwIvR2H hNFXYwBZJ5Z6PQb5IGLbvgY/tfENYuSNVAxQxmhW4HKw05B0APRQ+fgVrPkBDrz75auh fjDA== X-Received: by 10.15.43.13 with SMTP id w13mr28300641eev.37.1378715760818; Mon, 09 Sep 2013 01:36:00 -0700 (PDT) Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id y47sm19955816eew.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 01:36:00 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <522D886F.4040903@gnutls.org> Date: Mon, 09 Sep 2013 10:35:59 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 09 Sep 2013 02:20:58 -0700 Cc: "" , Patrick Pelletier , "" Subject: Re: [perpass] [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 08:36:10 -0000 On 09/09/2013 08:59 AM, Yoav Nir wrote: > Those tables are mostly quoting NIST publications, so while it seems > like there's many sources, they're not really independent. There are > academic results in factoring 768-bit numbers, so with sufficient > thrust (and the NSA has more thrust than most academics), it's > perfectly logical to suspect that the NSA can factor 1024-bit > numbers. That would be a breakage of RSA, not D-H or DSA. Hello, While I am not in par with the advances in solving the DLOG problem, the ECRYPT 2010 report on key sizes mentions in section 6.1: "According to the state of the art the difficulty of solving DLOG in prime order fields of size 2^n is, up to constants, asymptotically equivalent to that of breaking n-bit RSA". Given that all reports on key sizes agree on that (ECRYPT is not related to NIST in any way), I wouldn't ignore these recommendations. regards, Nikos From linus@nordberg.se Mon Sep 9 04:31:48 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FBE21E817E for ; Mon, 9 Sep 2013 04:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXSFtNIndtmA for ; Mon, 9 Sep 2013 04:31:34 -0700 (PDT) Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by ietfa.amsl.com (Postfix) with ESMTP id 4741021F8DE3 for ; Mon, 9 Sep 2013 04:31:26 -0700 (PDT) Received: from tool.nordberg.se (h158n2-asp-a13.ias.bredband.telia.com [217.210.64.158]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.nordberg.se (Postfix) with ESMTPSA id 11CA01152C; Mon, 9 Sep 2013 13:31:24 +0200 (CEST) From: Linus Nordberg To: Hannes Tschofenig References: <522D863F.10903@gmx.net> Date: Mon, 09 Sep 2013 13:31:23 +0200 In-Reply-To: <522D863F.10903@gmx.net> (Hannes Tschofenig's message of "Mon, 09 Sep 2013 11:26:39 +0300") Message-ID: <87ioyaz0xg.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: perpass@ietf.org Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:31:49 -0000 Hannes Tschofenig wrote Mon, 09 Sep 2013 11:26:39 +0300: | http://www.tschofenig.priv.at/wp/?p=997 | | It contains a number of recommendations, which are addressed to VoIP | providers and vendors but have to be enforced by data protection | authorities. | | The recommendations unfortunately highlight some challenges... Indeed. And still, I miss any mention on protection against collecting data about who's talking to who. Without claiming any expertise at all in this area, the closest thing to something implementing this that I've heard of is Mumble over Tor. Mumble [0] is not standardised AFAICT. The Guardian Project wrote [1] about this earlier this year. Some people seem to use it [2]. [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 [1] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble [2] https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/ From hannes.tschofenig@gmx.net Mon Sep 9 04:53:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B385121E8181 for ; Mon, 9 Sep 2013 04:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.918 X-Spam-Level: X-Spam-Status: No, score=-101.918 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKGTvflqEUFz for ; Mon, 9 Sep 2013 04:53:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B2D6221E8198 for ; Mon, 9 Sep 2013 04:44:12 -0700 (PDT) Received: from [10.255.133.212] ([194.251.119.201]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMkDH-1VKMXI258h-008bzb for ; Mon, 09 Sep 2013 13:44:07 +0200 Message-ID: <522DB47D.5080400@gmx.net> Date: Mon, 09 Sep 2013 14:43:57 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Linus Nordberg References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> In-Reply-To: <87ioyaz0xg.fsf@nordberg.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qH+9kiJfya84pce7C1HFq9y6VludNfy+CmBioAxADqkceQTFEXm FZTJlxvzwDm9n/BgKFpBvEDlUkOkfNYx6ABOe/DY2JqHq5asJ618vBSA/3xjQpS5LSGHWdR 7CMYs8X5qSklhlNS6R8K8Gh74hphN/jxTS0VViyuIRfzSlQcg+BOYD3wu579YAj5XVq/IKN 83gJEUwWubjMTihmdM8xA== Cc: perpass@ietf.org, Hannes Tschofenig Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:53:40 -0000 Hi Linus, thanks for the comments. I have indeed skipped that topic. I will have to read into the Mumble project to see what security and privacy guarantees it provides. My current conclusion from using VoIP/IM systems without using Tor is that you cannot really protect against collecting this transaction data (i.e., you have to at least trust the two VSPs, our own and then the VSP of your communication partner). While you can influence routing of the data traffic to a certain extend it does not work too well when your VSP is working against you. With IM you could at least set up your own server (e.g., by using an XMPP server) but with VoIP that's more complicated because nobody else will accepted your connection attempts (as explained in the interconnection part of my write-up). I will come back to you on that issue. Ciao Hannes On 09.09.2013 14:31, Linus Nordberg wrote: > Hannes Tschofenig wrote > Mon, 09 Sep 2013 11:26:39 +0300: > > | http://www.tschofenig.priv.at/wp/?p=997 > | > | It contains a number of recommendations, which are addressed to VoIP > | providers and vendors but have to be enforced by data protection > | authorities. > | > | The recommendations unfortunately highlight some challenges... > > Indeed. And still, I miss any mention on protection against collecting > data about who's talking to who. > > Without claiming any expertise at all in this area, the closest thing to > something implementing this that I've heard of is Mumble over > Tor. Mumble [0] is not standardised AFAICT. The Guardian Project wrote > [1] about this earlier this year. Some people seem to use it [2]. > > [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 > [1] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble > [2] https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From dean.willis@softarmor.com Mon Sep 9 07:55:28 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3B11E81D4 for ; Mon, 9 Sep 2013 07:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.311 X-Spam-Level: X-Spam-Status: No, score=-100.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMLfGatvZf2H for ; Mon, 9 Sep 2013 07:55:19 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC821E81D6 for ; Mon, 9 Sep 2013 07:46:46 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so3620546veb.12 for ; Mon, 09 Sep 2013 07:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o1ECTt2veJ73f7mHDXaUWoDutwNhtt5X8Vry8lEoMZ8=; b=TRNXfJqwtvaeCuzLFLAv+RW3IX2K0TBlppaJ6xclGvYBSLC5Y/gr2wjy50tBpiWllE to224dOV91werG7uX+b1C8DvwxdDeeormG4/cp24xNqpa/xSnJHqNTitiBgnmd/OJ0NT 1dIkn/7BiIH1eK9WhV5Vvo3ZPzoFpaDYwFi6s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=o1ECTt2veJ73f7mHDXaUWoDutwNhtt5X8Vry8lEoMZ8=; b=NRnPj5pPEpB0PlHuKMTdISN86u3bRlZCNNytsdaAesDTpMlRokzbYoa/1zbcnffJGY 95E+zlO3lV811XrDJYVQGevrrUSraTmtkOGk7Q0OA9bWTQRf7Ockf/EYSy5wkFfGHghj 8AJ0yqveZxZEgEvchr5Y77lIri4CHrDJJQ4VVJDy6VKU02E9Uev+NYi8fcbrBL6oclBK xW2iX2/sbbdmsfDdC85QxAovO06QBWWmpPFePe1tETGfcxOBe8Jy/rRxcUUCj1BkSltV rEnc0fBEiRnpXIbE3vMu3swESMEYUBgtPT+xBixn0yN2yzCPJJ9uoJZJDaecj6fkBtHt gYrg== X-Gm-Message-State: ALoCoQkOpJUbAhVzQBfvwZj+i77kFa3RsnExI71HxDqKx0sYsqfItkWzotwpiYX942CPhPmc1S5h MIME-Version: 1.0 X-Received: by 10.220.174.200 with SMTP id u8mr17917997vcz.6.1378738005886; Mon, 09 Sep 2013 07:46:45 -0700 (PDT) Received: by 10.58.168.180 with HTTP; Mon, 9 Sep 2013 07:46:45 -0700 (PDT) Received: by 10.58.168.180 with HTTP; Mon, 9 Sep 2013 07:46:45 -0700 (PDT) In-Reply-To: <522DB47D.5080400@gmx.net> References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> Date: Mon, 9 Sep 2013 09:46:45 -0500 Message-ID: From: Dean Willis To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e0149ca3a145eca04e5f475ac Cc: Linus Nordberg , perpass@ietf.org Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:55:28 -0000 --089e0149ca3a145eca04e5f475ac Content-Type: text/plain; charset=ISO-8859-1 I think we can mostly get there with RELOAD, but the implementations are still pretty early. On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" wrote: > Hi Linus, > > thanks for the comments. > > I have indeed skipped that topic. I will have to read into the Mumble > project to see what security and privacy guarantees it provides. > > My current conclusion from using VoIP/IM systems without using Tor is that > you cannot really protect against collecting this transaction data (i.e., > you have to at least trust the two VSPs, our own and then the VSP of your > communication partner). While you can influence routing of the data traffic > to a certain extend it does not work too well when your VSP is working > against you. > > With IM you could at least set up your own server (e.g., by using an XMPP > server) but with VoIP that's more complicated because nobody else will > accepted your connection attempts (as explained in the interconnection part > of my write-up). > > I will come back to you on that issue. > > Ciao > Hannes > > > On 09.09.2013 14:31, Linus Nordberg wrote: > >> Hannes Tschofenig> >> wrote >> Mon, 09 Sep 2013 11:26:39 +0300: >> >> | http://www.tschofenig.priv.at/**wp/?p=997 >> | >> | It contains a number of recommendations, which are addressed to VoIP >> | providers and vendors but have to be enforced by data protection >> | authorities. >> | >> | The recommendations unfortunately highlight some challenges... >> >> Indeed. And still, I miss any mention on protection against collecting >> data about who's talking to who. >> >> Without claiming any expertise at all in this area, the closest thing to >> something implementing this that I've heard of is Mumble over >> Tor. Mumble [0] is not standardised AFAICT. The Guardian Project wrote >> [1] about this earlier this year. Some people seem to use it [2]. >> >> [0] https://en.wikipedia.org/wiki/**Mumble_%28software%29 >> [1] https://trac.torproject.org/**projects/tor/wiki/doc/** >> TorifyHOWTO/Mumble >> [2] https://guardianproject.info/**2013/01/31/anonymous-cb-radio-** >> with-mumble-and-tor/ >> ______________________________**_________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/**listinfo/perpass >> > > ______________________________**_________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/**listinfo/perpass > --089e0149ca3a145eca04e5f475ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I think we can mostly get there with RELOAD, but the impleme= ntations are still pretty early.

On Sep 9, 2013 6:53 AM, "Hannes Tschofenig&= quot; <hannes.tschofenig@gm= x.net> wrote:
Hi Linus,

thanks for the comments.

I have indeed skipped that topic. I will have to read into the Mumble proje= ct to see what security and privacy guarantees it provides.

My current conclusion from using VoIP/IM systems without using Tor is that = you cannot really protect against collecting this transaction data (i.e., y= ou have to at least trust the two VSPs, our own and then the VSP of your co= mmunication partner). While you can influence routing of the data traffic t= o a certain extend it does not work too well when your VSP is working again= st you.

With IM you could at least set up your own server (e.g., by using an XMPP s= erver) but with VoIP that's more complicated because nobody else will a= ccepted your connection attempts (as explained in the interconnection part = of my write-up).

I will come back to you on that issue.

Ciao
Hannes


On 09.09.2013 14:31, Linus Nordberg wrote:
Hannes Tschofenig<hannes.tschofenig@gmx.net> =A0wrote
Mon, 09 Sep 2013 11:26:39 +0300:

| h= ttp://www.tschofenig.priv.at/wp/?p=3D997
|
| It contains a number of recommendations, which are addressed to VoIP
| providers and vendors but have to be enforced by data protection
| authorities.
|
| The recommendations unfortunately highlight some challenges...

Indeed. And still, I miss any mention on protection against collecting
data about who's talking to who.

Without claiming any expertise at all in this area, the closest thing to something implementing this that I've heard of is Mumble over
Tor. Mumble [0] is not standardised AFAICT. The Guardian Project wrote
[1] about this earlier this year. Some people seem to use it [2].

[0] https://en.wikipedia.org/wiki/Mumble_%28software%29<= br> [1] https://trac.torproject.org/projects/tor= /wiki/doc/TorifyHOWTO/Mumble
[2] https://guardianproject.info/= 2013/01/31/anonymous-cb-radio-with-mumble-and-tor/
_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass
--089e0149ca3a145eca04e5f475ac-- From br@brianrosen.net Mon Sep 9 08:21:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBA821F9FF2 for ; Mon, 9 Sep 2013 08:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.932 X-Spam-Level: X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWDZFg4AYmt8 for ; Mon, 9 Sep 2013 08:21:01 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id B27AB21F9B85 for ; Mon, 9 Sep 2013 08:09:48 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 3so1926880qeb.17 for ; Mon, 09 Sep 2013 08:09:48 -0700 (PDT) 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:message-id:references:to; bh=1Flvap/Y1nKmgjdw21/d6kDheFlY0a0bHt8ZyDbnmAc=; b=YvvMs1YQT1bCBaz5SwJYYGeKv70p95I0CfVcvZwFdKYCzvSKlWv90tsT+tUAx3erU3 85o5/e9vpw+MgvZeqL19UHtT2VAZRyXPz6patnnGuirceJBzLDB5UmTPIITnv5dQF413 xItdjD3GUGpM7YTQu8DTIkg594M7ixVs/sqXRiQW7N/hh/n4KVXoPfn52WaVsMeWxYqO E4jEUAGsFjsJOLYeGt3KUiy4UVNItSBTvAkDPUXSz3gnOW2Fd8+/2Dm9cU8WATNw+2j6 5PYHyz4CMqszn/2bsIPL3yFRywv0MSW4Q55vC25DERTOwIg524nGfI/hh0a6fcGuz20C p20A== X-Gm-Message-State: ALoCoQmEuS3A3soFUX+kUJSse42UlVZjHpqS3QL0I5ZWG1N/+BE1L+TFsyKrR4cK+RCFBu6cKbAH X-Received: by 10.224.12.16 with SMTP id v16mr2112237qav.12.1378739388093; Mon, 09 Sep 2013 08:09:48 -0700 (PDT) Received: from [10.33.193.10] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id w9sm2073705qad.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 08:09:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5E7A078B-11DE-4A20-B3EB-BC1DD08BEE68" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: Date: Mon, 9 Sep 2013 11:09:45 -0400 Message-Id: <6C08F669-75F6-441B-A7C5-85C0DBD8DB07@brianrosen.net> References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> To: Dean Willis X-Mailer: Apple Mail (2.1508) Cc: Linus Nordberg , perpass@ietf.org, Hannes Tschofenig Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:21:12 -0000 --Apple-Mail=_5E7A078B-11DE-4A20-B3EB-BC1DD08BEE68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I'm still worried about the role of the enrollment server. If it got = compromised, then mischief would be possible (you may not know who you = are talking to). I think MITM would be hard. I think we need to come up with a new way to come up with credentials = that is less dependent on servers that are subject to co-opting by the = authorities. It's a HECK of a lot better than conventional VoIP though. Brian On Sep 9, 2013, at 10:46 AM, Dean Willis = wrote: > I think we can mostly get there with RELOAD, but the implementations = are still pretty early. >=20 > On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" = wrote: > Hi Linus, >=20 > thanks for the comments. >=20 > I have indeed skipped that topic. I will have to read into the Mumble = project to see what security and privacy guarantees it provides. >=20 > My current conclusion from using VoIP/IM systems without using Tor is = that you cannot really protect against collecting this transaction data = (i.e., you have to at least trust the two VSPs, our own and then the VSP = of your communication partner). While you can influence routing of the = data traffic to a certain extend it does not work too well when your VSP = is working against you. >=20 > With IM you could at least set up your own server (e.g., by using an = XMPP server) but with VoIP that's more complicated because nobody else = will accepted your connection attempts (as explained in the = interconnection part of my write-up). >=20 > I will come back to you on that issue. >=20 > Ciao > Hannes >=20 >=20 > On 09.09.2013 14:31, Linus Nordberg wrote: > Hannes Tschofenig wrote > Mon, 09 Sep 2013 11:26:39 +0300: >=20 > | http://www.tschofenig.priv.at/wp/?p=3D997 > | > | It contains a number of recommendations, which are addressed to VoIP > | providers and vendors but have to be enforced by data protection > | authorities. > | > | The recommendations unfortunately highlight some challenges... >=20 > Indeed. And still, I miss any mention on protection against collecting > data about who's talking to who. >=20 > Without claiming any expertise at all in this area, the closest thing = to > something implementing this that I've heard of is Mumble over > Tor. Mumble [0] is not standardised AFAICT. The Guardian Project wrote > [1] about this earlier this year. Some people seem to use it [2]. >=20 > [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 > [1] = https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble > [2] = https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and= -tor/ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_5E7A078B-11DE-4A20-B3EB-BC1DD08BEE68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I'm = still worried about the role of the enrollment server.  If it got = compromised, then mischief would be possible (you may not know who you = are talking to).  I think MITM would be hard.

I = think we need to come up with a new way to come up with credentials that = is less dependent on servers that are subject to co-opting by the = authorities.

It's a HECK of a lot better than = conventional VoIP = though.

Brian

On Sep 9, = 2013, at 10:46 AM, Dean Willis <dean.willis@softarmor.com>= ; wrote:

I think we can mostly get there with = RELOAD, but the implementations are still pretty early.

On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" = <hannes.tschofenig@gmx.net>= ; wrote:
Hi Linus,

thanks for the comments.

I have indeed skipped that topic. I will have to read into the Mumble = project to see what security and privacy guarantees it provides.

My current conclusion from using VoIP/IM systems without using Tor is = that you cannot really protect against collecting this transaction data = (i.e., you have to at least trust the two VSPs, our own and then the VSP = of your communication partner). While you can influence routing of the = data traffic to a certain extend it does not work too well when your VSP = is working against you.

With IM you could at least set up your own server (e.g., by using an = XMPP server) but with VoIP that's more complicated because nobody else = will accepted your connection attempts (as explained in the = interconnection part of my write-up).

I will come back to you on that issue.

Ciao
Hannes


On 09.09.2013 14:31, Linus Nordberg wrote:
Hannes Tschofenig<hannes.tschofenig@gmx.net> =  wrote
Mon, 09 Sep 2013 11:26:39 +0300:

| http://www.tschofenig.priv.at/wp/?p=3D997
= |
| It contains a number of recommendations, which are addressed to = VoIP
| providers and vendors but have to be enforced by data protection
| authorities.
|
| The recommendations unfortunately highlight some challenges...

Indeed. And still, I miss any mention on protection against = collecting
data about who's talking to who.

Without claiming any expertise at all in this area, the closest thing = to
something implementing this that I've heard of is Mumble over
Tor. Mumble [0] is not standardised AFAICT. The Guardian Project = wrote
[1] about this earlier this year. Some people seem to use it [2].

[0] https://en.wikipedia.org/wiki/Mumble_%28software%= 29
[1] https://trac.torproject.org/projects/tor/wiki/doc= /TorifyHOWTO/Mumble
[2] https://guardianproject.info/2013/01/31/anonymous= -cb-radio-with-mumble-and-tor/
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass=

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

= --Apple-Mail=_5E7A078B-11DE-4A20-B3EB-BC1DD08BEE68-- From stephen.farrell@cs.tcd.ie Mon Sep 9 08:46:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BC521E81C3 for ; Mon, 9 Sep 2013 08:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVXC+O1TtEZZ for ; Mon, 9 Sep 2013 08:46:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D478B11E80E4 for ; Mon, 9 Sep 2013 08:30:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 459F0BE4D; Mon, 9 Sep 2013 16:30:33 +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 lkDD-lAExpbs; Mon, 9 Sep 2013 16:30:33 +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 2A968BE2F; Mon, 9 Sep 2013 16:30:33 +0100 (IST) Message-ID: <522DE999.9010100@cs.tcd.ie> Date: Mon, 09 Sep 2013 16:30:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Rosen , Dean Willis References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> <6C08F669-75F6-441B-A7C5-85C0DBD8DB07@brianrosen.net> In-Reply-To: <6C08F669-75F6-441B-A7C5-85C0DBD8DB07@brianrosen.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Linus Nordberg , perpass@ietf.org, Hannes Tschofenig Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:46:41 -0000 Hi Brian, Dean, RELOAD [1] is a bit of a gigantic spec though but I agree could be promising in this space. I wonder if anyone might be interested enough to write a draft saying how to use RELOAD to be more privacy friendly? I've no idea if that'd be easy or a huge amount of effort for someone who already knows the protocol, but I'm pretty sure it'd be a major task for someone starting from scratch. S. [1] http://tools.ietf.org/wg/p2psip/draft-ietf-p2psip-base/ On 09/09/2013 04:09 PM, Brian Rosen wrote: > I'm still worried about the role of the enrollment server. If it got compromised, then mischief would be possible (you may not know who you are talking to). I think MITM would be hard. > > I think we need to come up with a new way to come up with credentials that is less dependent on servers that are subject to co-opting by the authorities. > > It's a HECK of a lot better than conventional VoIP though. > > Brian > > On Sep 9, 2013, at 10:46 AM, Dean Willis wrote: > >> I think we can mostly get there with RELOAD, but the implementations are still pretty early. >> >> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" wrote: >> Hi Linus, >> >> thanks for the comments. >> >> I have indeed skipped that topic. I will have to read into the Mumble project to see what security and privacy guarantees it provides. >> >> My current conclusion from using VoIP/IM systems without using Tor is that you cannot really protect against collecting this transaction data (i.e., you have to at least trust the two VSPs, our own and then the VSP of your communication partner). While you can influence routing of the data traffic to a certain extend it does not work too well when your VSP is working against you. >> >> With IM you could at least set up your own server (e.g., by using an XMPP server) but with VoIP that's more complicated because nobody else will accepted your connection attempts (as explained in the interconnection part of my write-up). >> >> I will come back to you on that issue. >> >> Ciao >> Hannes >> >> >> On 09.09.2013 14:31, Linus Nordberg wrote: >> Hannes Tschofenig wrote >> Mon, 09 Sep 2013 11:26:39 +0300: >> >> | http://www.tschofenig.priv.at/wp/?p=997 >> | >> | It contains a number of recommendations, which are addressed to VoIP >> | providers and vendors but have to be enforced by data protection >> | authorities. >> | >> | The recommendations unfortunately highlight some challenges... >> >> Indeed. And still, I miss any mention on protection against collecting >> data about who's talking to who. >> >> Without claiming any expertise at all in this area, the closest thing to >> something implementing this that I've heard of is Mumble over >> Tor. Mumble [0] is not standardised AFAICT. The Guardian Project wrote >> [1] about this earlier this year. Some people seem to use it [2]. >> >> [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 >> [1] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble >> [2] https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/ >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From marc@petit-huguenin.org Mon Sep 9 08:48:22 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8672121E81E6 for ; Mon, 9 Sep 2013 08:48:22 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+p1omXQNdsB for ; Mon, 9 Sep 2013 08:48:14 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 4A47B11E823C for ; Mon, 9 Sep 2013 08:32:35 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:13:29f2:a5f4:3045:c53e] (unknown [IPv6:2601:9:4bc0:13:29f2:a5f4:3045:c53e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 60FD020EA2; Mon, 9 Sep 2013 17:32:33 +0200 (CEST) Message-ID: <522DEA10.6050400@petit-huguenin.org> Date: Mon, 09 Sep 2013 08:32:32 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8 MIME-Version: 1.0 To: Brian Rosen References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> <6C08F669-75F6-441B-A7C5-85C0DBD8DB07@brianrosen.net> In-Reply-To: <6C08F669-75F6-441B-A7C5-85C0DBD8DB07@brianrosen.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Linus Nordberg , perpass@ietf.org, Hannes Tschofenig , Dean Willis Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:48:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/09/2013 08:09 AM, Brian Rosen wrote: > I'm still worried about the role of the enrollment server. If it got > compromised, then mischief would be possible (you may not know who you are > talking to). I think MITM would be hard. > > I think we need to come up with a new way to come up with credentials that > is less dependent on servers that are subject to co-opting by the > authorities. Yes. If anyone has a knowledge of some method (even theoretical research) that could be used for that, I would be more than happy to help adapt it to RELOAD. > > It's a HECK of a lot better than conventional VoIP though. > > Brian > > On Sep 9, 2013, at 10:46 AM, Dean Willis > wrote: > >> I think we can mostly get there with RELOAD, but the implementations are >> still pretty early. >> >> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" > > wrote: >> >> Hi Linus, >> >> thanks for the comments. >> >> I have indeed skipped that topic. I will have to read into the Mumble >> project to see what security and privacy guarantees it provides. >> >> My current conclusion from using VoIP/IM systems without using Tor is >> that you cannot really protect against collecting this transaction data >> (i.e., you have to at least trust the two VSPs, our own and then the VSP >> of your communication partner). While you can influence routing of the >> data traffic to a certain extend it does not work too well when your VSP >> is working against you. >> >> With IM you could at least set up your own server (e.g., by using an >> XMPP server) but with VoIP that's more complicated because nobody else >> will accepted your connection attempts (as explained in the >> interconnection part of my write-up). >> >> I will come back to you on that issue. >> >> Ciao Hannes >> >> >> On 09.09.2013 14:31, Linus Nordberg wrote: >> >> Hannes Tschofenig> > wrote Mon, 09 Sep 2013 11:26:39 >> +0300: >> >> | http://www.tschofenig.priv.at/__wp/?p=997 >> | | It contains a number of >> recommendations, which are addressed to VoIP | providers and vendors but >> have to be enforced by data protection | authorities. | | The >> recommendations unfortunately highlight some challenges... >> >> Indeed. And still, I miss any mention on protection against collecting >> data about who's talking to who. >> >> Without claiming any expertise at all in this area, the closest thing to >> something implementing this that I've heard of is Mumble over Tor. Mumble >> [0] is not standardised AFAICT. The Guardian Project wrote [1] about this >> earlier this year. Some people seem to use it [2]. >> >> [0] https://en.wikipedia.org/wiki/__Mumble_%28software%29 >> [1] >> https://trac.torproject.org/__projects/tor/wiki/doc/__TorifyHOWTO/Mumble >> >> [2] >> https://guardianproject.info/__2013/01/31/anonymous-cb-radio-__with-mumble-and-tor/ >> >> - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSLeoMAAoJECnERZXWan7Ez2MP/ieorluowEjef33uWOvHnAxq rdz0u40hm43mkgDwWkVgPbs3yfzjo3ihGktUuJ26E3Jc8I/yLl2kvtBXIf5OOkb3 BfrjpDpfSMXUJarSZIk1/obH4ydClXZV7xPby3hg6qvBPYzHe6duTtYo5mI6L0TA vKCukG1aZqDcvfwnXRLt8RtizN7hsrqXGkarzKr70FVG53PmIMULjEqAst/zeU8c wUfp2nXoQz56bmop2SRONA+ivAqMmRMgPMVFNE7444ckymYlXUjWUO/i9GFEDAAe Oij9Fmos9WUkzX6yV3BysP7ro8/9g+usRRF5nhOmnAwkgaJ1ZOOXexytNLpiRMJL ualBjmAmKDrRnk2+M8/nlpP0RO1fw3FgTLi6ydO56iZBlMp0QtkJS0E7tJoCNKcw 4/ILK4ZCJHyO2dbGPjxUMQFq0xDzLg8pjbZn6aGDfwPKDq9IarcsVVup+D0MRO/6 hDbLYDIqOx4Kwzr/YBG/IT/3PMXRLEK7yVATy2Vt3/4CEEkQcjYyEyXeIUOFiutF cadMfCuJoooMKWmcJJe5C4UYArr2LVz8OBe+gqCBr24hRQ4ybehWHXjquWxbOlfM Tnn5COU7r8E1CkBBt4oAXqEM3Fz1jN1JR9Zx3P8zAEPKx7rF6IHoZACUauxDPWIh yus8YslnMJb8RKf5jl6S =7pYq -----END PGP SIGNATURE----- From marc@petit-huguenin.org Mon Sep 9 09:15:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730D221F9FBE for ; Mon, 9 Sep 2013 09:15:47 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ofqc1RVIXF8L for ; Mon, 9 Sep 2013 09:15:46 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9F20421E805F for ; Mon, 9 Sep 2013 08:56:17 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:13:60af:d04b:5e82:55bc] (unknown [IPv6:2601:9:4bc0:13:60af:d04b:5e82:55bc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id CA5AD20454; Mon, 9 Sep 2013 17:55:51 +0200 (CEST) Message-ID: <522DEF86.3030609@petit-huguenin.org> Date: Mon, 09 Sep 2013 08:55:50 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> <6C08F669-75F6-441B-A7C5-85C0DBD8DB07@brianrosen.net> <522DE999.9010100@cs.tcd.ie> In-Reply-To: <522DE999.9010100@cs.tcd.ie> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Hannes Tschofenig , Linus Nordberg , perpass@ietf.org, Dean Willis , Brian Rosen Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:15:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/09/2013 08:30 AM, Stephen Farrell wrote: > > Hi Brian, Dean, > > RELOAD [1] is a bit of a gigantic spec though but I agree could be > promising in this space. I wonder if anyone might be interested enough to > write a draft saying how to use RELOAD to be more privacy friendly? I wrote a draft adapting some of the ideas of TOR to RELOAD: http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-anonymous-02 That was presented in Atlanta: http://www.ietf.org/proceedings/85/slides/slides-85-p2psip-1.pdf Interestingly the reason for this draft was not end-user privacy, but to prevent commercial entities to discovers competitors' customers in the context of VIPR. > > I've no idea if that'd be easy or a huge amount of effort for someone who > already knows the protocol, but I'm pretty sure it'd be a major task for > someone starting from scratch. > > S. > > [1] http://tools.ietf.org/wg/p2psip/draft-ietf-p2psip-base/ > > On 09/09/2013 04:09 PM, Brian Rosen wrote: >> I'm still worried about the role of the enrollment server. If it got >> compromised, then mischief would be possible (you may not know who you >> are talking to). I think MITM would be hard. >> >> I think we need to come up with a new way to come up with credentials >> that is less dependent on servers that are subject to co-opting by the >> authorities. >> >> It's a HECK of a lot better than conventional VoIP though. >> >> Brian >> >> On Sep 9, 2013, at 10:46 AM, Dean Willis >> wrote: >> >>> I think we can mostly get there with RELOAD, but the implementations >>> are still pretty early. >>> >>> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" >>> wrote: Hi Linus, >>> >>> thanks for the comments. >>> >>> I have indeed skipped that topic. I will have to read into the Mumble >>> project to see what security and privacy guarantees it provides. >>> >>> My current conclusion from using VoIP/IM systems without using Tor is >>> that you cannot really protect against collecting this transaction data >>> (i.e., you have to at least trust the two VSPs, our own and then the >>> VSP of your communication partner). While you can influence routing of >>> the data traffic to a certain extend it does not work too well when >>> your VSP is working against you. >>> >>> With IM you could at least set up your own server (e.g., by using an >>> XMPP server) but with VoIP that's more complicated because nobody else >>> will accepted your connection attempts (as explained in the >>> interconnection part of my write-up). >>> >>> I will come back to you on that issue. >>> >>> Ciao Hannes >>> >>> >>> On 09.09.2013 14:31, Linus Nordberg wrote: Hannes >>> Tschofenig wrote Mon, 09 Sep 2013 11:26:39 >>> +0300: >>> >>> | http://www.tschofenig.priv.at/wp/?p=997 | | It contains a number of >>> recommendations, which are addressed to VoIP | providers and vendors >>> but have to be enforced by data protection | authorities. | | The >>> recommendations unfortunately highlight some challenges... >>> >>> Indeed. And still, I miss any mention on protection against collecting >>> data about who's talking to who. >>> >>> Without claiming any expertise at all in this area, the closest thing >>> to something implementing this that I've heard of is Mumble over Tor. >>> Mumble [0] is not standardised AFAICT. The Guardian Project wrote [1] >>> about this earlier this year. Some people seem to use it [2]. >>> >>> [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 [1] >>> https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble >>> [2] >>> https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/ - -- >>> Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSLe90AAoJECnERZXWan7Es9IQAMoFgmtizT8jr/3B6QiD2v7B wKAGTMCW13MdiTXPBl7hOR2gLTwNzDDA4GYGe0o+HMLKCvaIvLeV8W0CnNdFBRll LXPxiTAm5A6t+aNTOi5Bl+GhA/ilvJZjXAyOHC8rUbhdIK46VQTNoEBixGIaC+BK /n6+1qngQ7FMxktSwBzpHcxU5ACm0UM0jU7bGS1xACVgxJyBxGg3tk818lYD+4P9 mMlOC/vp/bNdYoOlBq0IaTpcAKuLWme3xsfavaTG7zk5PQHhfgs9ZWkx0YYSUepk z3tDeKM54/8OB4ZXgfWWBvAOd4gaquH3CXmX1rr4saqE5lrtc49meYzPwU9thn2J iSGet3/K+3PylgG5gmKtNzyk4cp4MBV+If1ypsy9k1T3I93eaV7YV2r0+Xs3q+tw oVTQrKr6oISDlEDfj1/O9CHoF7RflN88dXHI+ZBn/hzLKAAb73/qlyZ5QAP4L1dK xxMrTob0X/ZPO9lVZc6kAZVcgfRJqNkBNG5kfqr18Fh1+5Apeek370ta/4SSQI8X 7PmQFSyE7rZbphkEZxdpz2Dyncss5arbakyLgd3i2ekSC44AX5pf/B8z/li69YHA Bu3QwfwYZWdKUseaPoyYaE6VqDndiOTHOxc04/XaJogARbZCg59fkQgArtOBPATw IwJcEkoA7TOI+YFLKTXK =/F/b -----END PGP SIGNATURE----- From br@brianrosen.net Mon Sep 9 09:16:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8EE21F99EC for ; Mon, 9 Sep 2013 09:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=0.834, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNCjWjzY4GXQ for ; Mon, 9 Sep 2013 09:16:42 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id C0EDD21E81EB for ; Mon, 9 Sep 2013 08:48:24 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id nd7so2442394qeb.7 for ; Mon, 09 Sep 2013 08:48:24 -0700 (PDT) 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=0F9XQJhTvESKVGroeT1E3obgO/PmjT5wQA7jAdbHpz8=; b=DKf43tW9oBNrumhF+66XWADS7LBfRDlNRC3EXszKU+f4yi/XlN9KRbcBOGM2SjKceB C/I3MRcHrSc1xUERszGhQENkkDmGxR+lB+8ptoaJ+05khK0l3DH8KbZhvMpwapfs9Dg8 4BuuEzn7eRS6iyoLELUpRl3sTFv6EbHtebjaV3EYy0YOUpdAXUXD62yZ0yOfck4QMW+C XWt4WCs7hpI5r+bSf5RXUmcW/XMhAKH04j1QvZYzGnZLxlb1+QeBQFAIGrp/jXdLXPXZ poyn3+BboGd6yeWk8M0kZPYzOT/sDLkH+4irvRSIyu/amlvRgbbLM73ZrUWoVhK1MKzh nlPw== X-Gm-Message-State: ALoCoQmdZe+3hmlIK2jVsfgQLojdMHxrFqUxXQWYuLnpIDDLIoDwLUOXz2ycCJSwUSFNVjDkXmIG X-Received: by 10.49.50.198 with SMTP id e6mr12177362qeo.76.1378741704169; Mon, 09 Sep 2013 08:48:24 -0700 (PDT) Received: from [10.33.193.10] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id b9sm2295802qad.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 08:48:23 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <522DE999.9010100@cs.tcd.ie> Date: Mon, 9 Sep 2013 11:48:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> <6C08F669-75F6-441B-A7C5-85C0DBD8DB07@brianrosen.net> <522DE999.9010100@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: Linus Nordberg , perpass@ietf.org, Hannes Tschofenig , Dean Willis Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:16:47 -0000 RELOAD is a rendezvous protocol - it yields a URI to send SIP messages = to in order to establish a p2p connection. =20 It uses an algorithm (the RELOAD spec is designed around a pluggable = algorithm) of which Distributed Hash Table examples like Chord are good = candidates. The algorithm defines how a p2p distributed databases of = these URIs is created, and how you query the DHT to find the URI of the = party you want to talk to. You start with an identifier, query the DHT = and get the URI. =20 Then you send a normal SIP INVITE to that URI. This means the SIP = signaling itself does not go through any intermediaries, nor does the = media (assuming a TURN relay is not needed). Contrast this with how normal SIP calling works, where you send the = INVITE to a proxy server in your local domain (carrier) who routes it = through some set of proxy servers to the destination domain (possibly = including a transit domain) who routes it to the destination. Along the = way, as implemented, any number of changes to the SIP INVITE are made, = including changing the media end point IP addresses, so the media is = forced through middle boxes in the carrier network. So RELOAD is privacy friendly by turning calling into true p2p with = signaling and media not transiting any third party. The concern I have is that to get credentials enabling you to store your = URI in the DHT, you interact with an enrollment server. That server = only issues credentials, it's not in the path of the call, but if it = was co-opted, it could create mischief with those credentials. Brian On Sep 9, 2013, at 11:30 AM, Stephen Farrell = wrote: >=20 > Hi Brian, Dean, >=20 > RELOAD [1] is a bit of a gigantic spec though but I agree could > be promising in this space. I wonder if anyone might be interested > enough to write a draft saying how to use RELOAD to be more > privacy friendly? >=20 > I've no idea if that'd be easy or a huge amount of effort for > someone who already knows the protocol, but I'm pretty sure it'd > be a major task for someone starting from scratch. >=20 > S. >=20 > [1] http://tools.ietf.org/wg/p2psip/draft-ietf-p2psip-base/ >=20 > On 09/09/2013 04:09 PM, Brian Rosen wrote: >> I'm still worried about the role of the enrollment server. If it got = compromised, then mischief would be possible (you may not know who you = are talking to). I think MITM would be hard. >>=20 >> I think we need to come up with a new way to come up with credentials = that is less dependent on servers that are subject to co-opting by the = authorities. >>=20 >> It's a HECK of a lot better than conventional VoIP though. >>=20 >> Brian >>=20 >> On Sep 9, 2013, at 10:46 AM, Dean Willis = wrote: >>=20 >>> I think we can mostly get there with RELOAD, but the implementations = are still pretty early. >>>=20 >>> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" = wrote: >>> Hi Linus, >>>=20 >>> thanks for the comments. >>>=20 >>> I have indeed skipped that topic. I will have to read into the = Mumble project to see what security and privacy guarantees it provides. >>>=20 >>> My current conclusion from using VoIP/IM systems without using Tor = is that you cannot really protect against collecting this transaction = data (i.e., you have to at least trust the two VSPs, our own and then = the VSP of your communication partner). While you can influence routing = of the data traffic to a certain extend it does not work too well when = your VSP is working against you. >>>=20 >>> With IM you could at least set up your own server (e.g., by using an = XMPP server) but with VoIP that's more complicated because nobody else = will accepted your connection attempts (as explained in the = interconnection part of my write-up). >>>=20 >>> I will come back to you on that issue. >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> On 09.09.2013 14:31, Linus Nordberg wrote: >>> Hannes Tschofenig wrote >>> Mon, 09 Sep 2013 11:26:39 +0300: >>>=20 >>> | http://www.tschofenig.priv.at/wp/?p=3D997 >>> | >>> | It contains a number of recommendations, which are addressed to = VoIP >>> | providers and vendors but have to be enforced by data protection >>> | authorities. >>> | >>> | The recommendations unfortunately highlight some challenges... >>>=20 >>> Indeed. And still, I miss any mention on protection against = collecting >>> data about who's talking to who. >>>=20 >>> Without claiming any expertise at all in this area, the closest = thing to >>> something implementing this that I've heard of is Mumble over >>> Tor. Mumble [0] is not standardised AFAICT. The Guardian Project = wrote >>> [1] about this earlier this year. Some people seem to use it [2]. >>>=20 >>> [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 >>> [1] = https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble >>> [2] = https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and= -tor/ >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>>=20 >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >>=20 From stephen.farrell@cs.tcd.ie Mon Sep 9 09:17:51 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2269821E80F8 for ; Mon, 9 Sep 2013 09:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10u4mDFOCSi0 for ; Mon, 9 Sep 2013 09:17:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 871BA21F8895 for ; Mon, 9 Sep 2013 08:58:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C9037BE5D for ; Mon, 9 Sep 2013 16:58:15 +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 Xm0uTN8Rdh1f for ; Mon, 9 Sep 2013 16:58:15 +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 AD3A0BE56 for ; Mon, 9 Sep 2013 16:58:15 +0100 (IST) Message-ID: <522DF017.2030504@cs.tcd.ie> Date: Mon, 09 Sep 2013 16:58:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:17:51 -0000 Hiya, In case folks here aren't on the main IETF discuss list, there's been a flood of mail [1,2,3] there on this topic, and Jari and I wrote a bloggy thing [4] as well. The IAB are considering how to deal with some of this stuff as part of the tech plenary in Vancouver. [5] I guess we'll hear more about that as it firms up. But since a tech plenary is probably not the best place to try get work (or plans for work) done, the IESG and IAB also discussed having a BoF-like session for more detailed discussion of the topic and what the IETF could or should be doing. Current thinking is to have a session based around the discussion on this list, so that'd probably be called the perpass BoF but as with the list, there's no plan for this to be a WG forming BoF. So, this is a call for: a) suggestions as to how to best use some face-to-face time, b) agenda proposals, and, c) folks who are willing to volunteer to do stuff (e.g. lead a discussion on topic foo, write an I-D about bar,...). I guess (a) and (b) are better done on the list, but feel free to send me offlist mail about (c). As the next IETF meeting [6] is coming up quite soon, please try respond to this in the next week or so if you're going to. The IESG/IAB call where we agree what BoFs to have is on Sep 24th and it'd be nice to have a reasonable idea about how we'll handle this before then, so this isn't a hard deadline and there'll be further calls for input before we get near to having a worked out agenda. My initial idea for this would be a 2/2.5 hour session where we have someone scene-set, then some open-mic, then a set of short presentations about specific problems or things the IETF could do, and then more open-mic. Hopefully we'd wrap up with a list of actionable things and associated victims^H^H^H^H^H^Hvolunteers. I think the drafts that Brian [7] and Yaron [8] have written are fine examples of the kind of specific thing for which we'd want to have short presentations. (BTW: As always, more drafts are welcome.) I don't think we want overly fuzzy or broad presentations and we don't want to have presentations that merely complain about the state of the universe, so please do keep in mind that the IETF cannot fully "solve" whatever it is you think the problem is, and that what we're after here is to identify specific pieces of IETF work that are doable and that can help mitigate the threat of pervasive monitoring. But I'm very open to other suggestions if you have 'em or to being told the above is crazy, if that's what you think. In the meantime please continue to use this list for discussion of specific things the IETF could or should be doing and if you intend to write up an I-D on this topic, just fire ahead and do that and then send a link to the list, same as always. Thanks, S. [1] http://www.ietf.org/mail-archive/web/ietf/current/msg82071.html [2] http://www.ietf.org/mail-archive/web/ietf/current/msg82073.html [3] http://www.ietf.org/mail-archive/web/ietf/current/msg82167.html [4] http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/ [5] http://www.ietf.org/mail-archive/web/ietf/current/msg82266.html [6] http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88 [7] http://tools.ietf.org/html/draft-trammell-perpass-ppa [8] http://tools.ietf.org/html/draft-sheffer-tls-bcp [9] what a lot of references :-) From stpeter@stpeter.im Mon Sep 9 09:40:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3E821F9D65 for ; Mon, 9 Sep 2013 09:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Utpx9dTTLACc for ; Mon, 9 Sep 2013 09:40:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 752FC21F9C9A for ; Mon, 9 Sep 2013 09:39:55 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1638B414CF; Mon, 9 Sep 2013 10:44:16 -0600 (MDT) Message-ID: <522DF9D8.10607@stpeter.im> Date: Mon, 09 Sep 2013 10:39:52 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <522DF017.2030504@cs.tcd.ie> In-Reply-To: <522DF017.2030504@cs.tcd.ie> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:40:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/9/13 9:58 AM, Stephen Farrell wrote: > So, this is a call for: > > a) suggestions as to how to best use some face-to-face time, b) > agenda proposals, and, We'll want to use the high-bandwidth time wisely, and we know that security-related discussions (well, all discussions) can easily go off track. Staying focused on the core issues, and on problems that might have engineering solutions, will be paramount. > c) folks who are willing to volunteer to do stuff (e.g. lead a > discussion on topic foo, write an I-D about bar,...). I'm willing to lead a session, write I-Ds, etc. Indeed, while you were writing your email message, I was writing an I-D about the use of TLS in XMPP: https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLfnYAAoJEOoGpJErxa2pC5wQAJ1NvPFAm5xKcsw+uQyWKEqY E2nVXNI5VSuG7/1EQd7omXSeXTCDExlMa+B2ffBSy6/uN8/S7rd39qxgov9t8Bm4 hP5KbKuJL5rLMlnNWONENKyYGbaqt/9QBy27haAdWCfWfOkw+PM+elyTwBTwU+YQ KoKGgmmaj1cn3PdbkJXQKgHY/riSJ5z9J9hrb8Izsq8DdPS6oL3CNh38VbHCmv7f bY9+n2QKCjlwDgnF4erBgK9Iw1wPdkqnS7JCgNejU67xvrOS5FmxUdm5JD6ux6Um xW4FnsvOBV2v3gdydwNzWOeX2ps10pkL0L7Mg2SMUx9SgZRfQo5O3h4O6rs4DAcr qwi45j86igMXlmfgTIIvKeEYL3FxApdTGNiMX8A+JJmoXwNz4AR78u7BSac4Jsso svg2f2HPtISjksP11uTz4EtEkANiGkDC0iVlqFu936ccGlcP5v9UERHGZxj9XnO5 WXFXo137nqLGkWdNIvGMDSRvjs+qoalLbi7+8hyd3rGWudYkuq5ehH8Wbac2R0Eb THrKJYTIR259Up+PthKs9C2PDuIKL9w39eIoJBRkE2/JOxovZFv01q0A2J+6f8no 36G9Lq5EMVAQ+DCVBjP1v2+w2CIc5U1aBAz/DRu21t68CQjs2RFXkCb3pkeOU4+I O746eFtURZyMGDDRRV6Z =R9s5 -----END PGP SIGNATURE----- From scott.brim@gmail.com Mon Sep 9 09:48:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9655511E81D5 for ; Mon, 9 Sep 2013 09:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.111 X-Spam-Level: X-Spam-Status: No, score=-101.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYHUnZPM9pya for ; Mon, 9 Sep 2013 09:48:25 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABAC11E81F4 for ; Mon, 9 Sep 2013 09:48:25 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h1so6613893oag.24 for ; Mon, 09 Sep 2013 09:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3rD2+1+OCQAo6hvzZ/Wk/P5W7fVVMcPXM0hxvF2gLjo=; b=nfVo3kNlRsvmjv0RX543EBYwFL1rMLb4GdK7BEtsRdqcz98VyawXsjMg1sfr/TT8+n gvldwhio5OeIer8S4VFudItQXUzqufIj7OgfSugl5d5wKzU2y9Xr8996oBL6caM4P+Or E0nNpkF9PGrNakHLV9gX+ju8FWKkEmBcdwpbtYVvCw5S27bjd+jzTKYbchtlF0Bl2QhH C5vEDGZiV6FD/UOS7S305xXZjp9EWm8er2qO5cINsdf0xJxybkbz9x+r/XDoVeVVN1e/ yGRpv/7U9CV/x3MjNUkRIKKcjJ5Pr38D/tOv3WarqZRojvLO6AcBxxmMvHN3GrPQd6b8 FrAw== X-Received: by 10.182.117.164 with SMTP id kf4mr11694060obb.104.1378745304802; Mon, 09 Sep 2013 09:48:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.134 with HTTP; Mon, 9 Sep 2013 09:48:04 -0700 (PDT) In-Reply-To: <522DF9D8.10607@stpeter.im> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> From: Scott Brim Date: Mon, 9 Sep 2013 12:48:04 -0400 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:48:25 -0000 As long as you reserve a room that can hold 400 people and some reporters, I think a BOF is a fabulous idea. :-) Scott From dhc@dcrocker.net Mon Sep 9 10:52:39 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9469821E805F for ; Mon, 9 Sep 2013 10:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QNXZRSAeCDY for ; Mon, 9 Sep 2013 10:52:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8192911E80E7 for ; Mon, 9 Sep 2013 10:52:34 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r89HqKEb031303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Sep 2013 10:52:29 -0700 Message-ID: <522E0AC0.6040808@dcrocker.net> Date: Mon, 09 Sep 2013 10:52:00 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <522DF017.2030504@cs.tcd.ie> In-Reply-To: <522DF017.2030504@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 09 Sep 2013 10:52:31 -0700 (PDT) Cc: perpass Subject: [perpass] plenary vs BOF: (was Re: BoFing in Vancouver) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 17:52:39 -0000 On 9/9/2013 8:58 AM, Stephen Farrell wrote: > The IAB are considering how to deal with some of this stuff as > part of the tech plenary in Vancouver. [5] I guess we'll hear > more about that as it firms up. > > But since a tech plenary is probably not the best place to try > get work (or plans for work) done, the IESG and IAB also discussed > having a BoF-like session for more detailed discussion of the > topic and what the IETF could or should be doing. The plenary could be an excellent venue for a tutorial on operational and technical privacy issues at Internet-scale systems level. The current furor is over "monitoring", where that seems to have less to do with simple, link-level wiretapping and more to do with compromised intermediaries. (It's fine if I have that wrong; I'm interested in having the tutorial offer clarity about the actual threats we should be focusing on and, perhaps, comment on basic techniques for mitigating them.) The purpose of the plenary, then, would be to get the IETF onto the same page about the problem space we should be considering and the technical toolset available for dealing with it. If it happens that there is simple, low-hanging fruit, such as improving random-number implementations, or the like that's obviously good and needs to be pursued, but I doubt that's the serious and substantive part of the work that needs to be done. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From trammell@tik.ee.ethz.ch Mon Sep 9 10:55:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A78321E80A5 for ; Mon, 9 Sep 2013 10:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmDqxWR+Eb0f for ; Mon, 9 Sep 2013 10:54:40 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3C48711E8126 for ; Mon, 9 Sep 2013 10:54:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EF7D0D9309; Mon, 9 Sep 2013 19:54:33 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YIS4aOHnIWRr; Mon, 9 Sep 2013 19:54:33 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 81E96D9308; Mon, 9 Sep 2013 19:54:33 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_7A7FB0BA-DF0C-47A1-A289-CA4EAF1FD394"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <522DF017.2030504@cs.tcd.ie> Date: Mon, 9 Sep 2013 19:54:32 +0200 Message-Id: <124B6A7F-D686-46E4-A9DC-994D895FAC9E@tik.ee.ethz.ch> References: <522DF017.2030504@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: perpass Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 17:55:09 -0000 --Apple-Mail=_7A7FB0BA-DF0C-47A1-A289-CA4EAF1FD394 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Stephen, I'm certainly happy to do a quick presentation on the threat model = outlined in -perpass-ppa, as well as leading a discussion on next steps = with the model and where we see it being useful, in Vancouver.=20 I expect I'll have time to get a -01 revision out soon, as well; = certainly before the meeting. Cheers, Brian On Sep 9, 2013, at 5:58 PM, Stephen Farrell = wrote: >=20 > Hiya, >=20 > In case folks here aren't on the main IETF discuss list, there's > been a flood of mail [1,2,3] there on this topic, and Jari and I > wrote a bloggy thing [4] as well. >=20 > The IAB are considering how to deal with some of this stuff as > part of the tech plenary in Vancouver. [5] I guess we'll hear > more about that as it firms up. >=20 > But since a tech plenary is probably not the best place to try > get work (or plans for work) done, the IESG and IAB also discussed > having a BoF-like session for more detailed discussion of the > topic and what the IETF could or should be doing. >=20 > Current thinking is to have a session based around the discussion > on this list, so that'd probably be called the perpass BoF but as > with the list, there's no plan for this to be a WG forming BoF. >=20 > So, this is a call for: >=20 > a) suggestions as to how to best use some face-to-face time, > b) agenda proposals, and, > c) folks who are willing to volunteer to do stuff (e.g. lead > a discussion on topic foo, write an I-D about bar,...). >=20 > I guess (a) and (b) are better done on the list, but feel free > to send me offlist mail about (c). >=20 > As the next IETF meeting [6] is coming up quite soon, please > try respond to this in the next week or so if you're going to. > The IESG/IAB call where we agree what BoFs to have is on > Sep 24th and it'd be nice to have a reasonable idea about > how we'll handle this before then, so this isn't a hard > deadline and there'll be further calls for input before we get > near to having a worked out agenda. >=20 > My initial idea for this would be a 2/2.5 hour session where we > have someone scene-set, then some open-mic, then a set of short > presentations about specific problems or things the IETF could > do, and then more open-mic. Hopefully we'd wrap up with a list > of actionable things and associated victims^H^H^H^H^H^Hvolunteers. >=20 > I think the drafts that Brian [7] and Yaron [8] have written > are fine examples of the kind of specific thing for which > we'd want to have short presentations. (BTW: As always, more > drafts are welcome.) I don't think we want overly fuzzy or > broad presentations and we don't want to have presentations > that merely complain about the state of the universe, so > please do keep in mind that the IETF cannot fully "solve" > whatever it is you think the problem is, and that what we're > after here is to identify specific pieces of IETF work that > are doable and that can help mitigate the threat of pervasive > monitoring. >=20 > But I'm very open to other suggestions if you have 'em or to > being told the above is crazy, if that's what you think. >=20 > In the meantime please continue to use this list for discussion > of specific things the IETF could or should be doing and if > you intend to write up an I-D on this topic, just fire ahead > and do that and then send a link to the list, same as always. >=20 > Thanks, > S. >=20 > [1] http://www.ietf.org/mail-archive/web/ietf/current/msg82071.html > [2] http://www.ietf.org/mail-archive/web/ietf/current/msg82073.html > [3] http://www.ietf.org/mail-archive/web/ietf/current/msg82167.html > [4] = http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/ > [5] http://www.ietf.org/mail-archive/web/ietf/current/msg82266.html > [6] http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88 > [7] http://tools.ietf.org/html/draft-trammell-perpass-ppa > [8] http://tools.ietf.org/html/draft-sheffer-tls-bcp > [9] what a lot of references :-) >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_7A7FB0BA-DF0C-47A1-A289-CA4EAF1FD394 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSLgtYAAoJENt3nsOmbNJckvgIANEy95oeSshphUWkmJ9pfDV5 4HSirPpUE/eW0jBBCS2/5PytOPr/K5p8eryhJQE8pFhWsdDbhdVCczu7rmROBidL ZgbWa50QeKN1gLcJA3EBQigcSoyQLeQACIS+K++QYDdVn5u12IwkY9JsYFL5wZQZ sNf8shpySj57FFIqBP3OMGmeJSLOCcPG0KpKLUUJpsq1JdFQXKIalGgL/mgZnt3+ 2ArhstSvykzX8Gi88AfX4FG7f4xr/qjVU3xSyNaxqiFHOJ5K/sXbqtA5CUrviMl0 3Q6pMagSsuK73zqvXeZcM2SG99uTqJDsdW5JxoVA0qhDld9djklU4SosXWJwaxw= =ti0o -----END PGP SIGNATURE----- --Apple-Mail=_7A7FB0BA-DF0C-47A1-A289-CA4EAF1FD394-- From hallam@gmail.com Mon Sep 9 11:15:17 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8CF21F9AF8 for ; Mon, 9 Sep 2013 11:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlqCDjtJ3mSY for ; Mon, 9 Sep 2013 11:15:17 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 85FDA21F9A65 for ; Mon, 9 Sep 2013 11:15:16 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id c11so5273148lbj.41 for ; Mon, 09 Sep 2013 11:15:15 -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; bh=Hv7tLkKW9qMSGrcivh/XsGfeOlQKZ1lIqrIvqPw1xXc=; b=DCjxLMnPc0S+qNf8T+4SRIc1UBiNtD9e2YxcL1RM4U1YMN1XpFVq7NQziaN8nhWebL BWQ6dPxUAZ3wIywgNGQ1DTuL9E/4mL8nRO1sm0lAyNkaXaIvvW37dWQl1dAMiOUjktGM FEJa24/j8KXRQfIBAlUEBcakgy5UrirafdLyo2wkt8GW6E5n57J4wXewMbNX24X4IbeJ M+vSNtxkEPBLOvJjMu+4O0YX3evFrrE1uAQc1Ig8DV4yeSbN/lhpQOgUADs86OP91eRl 2g0kkqardNsiu2Hx560hWJPsyzmf4tBniiYNVN4slaEUQUYemb6fveRqMs4WCD07sqyI HItQ== MIME-Version: 1.0 X-Received: by 10.112.146.33 with SMTP id sz1mr17163209lbb.14.1378750515205; Mon, 09 Sep 2013 11:15:15 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Mon, 9 Sep 2013 11:15:15 -0700 (PDT) In-Reply-To: <522E0AC0.6040808@dcrocker.net> References: <522DF017.2030504@cs.tcd.ie> <522E0AC0.6040808@dcrocker.net> Date: Mon, 9 Sep 2013 14:15:15 -0400 Message-ID: From: Phillip Hallam-Baker To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7b3441d0b15c8404e5f75e3f Cc: perpass , Stephen Farrell Subject: Re: [perpass] plenary vs BOF: (was Re: BoFing in Vancouver) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:15:18 -0000 --047d7b3441d0b15c8404e5f75e3f Content-Type: text/plain; charset=ISO-8859-1 I would like to keep discussion of NSA capabilities out of the BOF as well. For the sake of having a focused and effective discussion I think we should just stipulate the list of possible compromises and focus on what we can do to address them. Speculation as to the nature of the NSA capabilities is probably best done in the bars and on mailing lists. What we discovered over the weekend should cause a lot of the assumptions as to how PRISM works to be reviewed. When we first heard of PRISM it was assumed that the data was being voluntarily disclosed by Google etc. It now appears that it is plaintext traffic on the Internet trunks that is being intercepted. While it is true that the NSA probably can't do the intercepts without any help, we can't build an Internet without intermediaries either. The question at issue should be not whether an intermediary can default but whether that default could be detected. Ben Laurie's Certificate Transparency demonstrates a way to keep one set of intermediaries under constant observation making default unlikely to succeed unobserved. We need to start looking for equivalent schemes for all the intermediaries we are forced to trust. These include: 1) Generation of ECC Curves 2) Cryptographic Hardware, in particular SSL accelerators 2a) Kleptography as described by Motti Young to encode random seeds in the modulus 2b) Disclosing private key through TLS covert channel 3) CAs 4) Standards organizations On (4) the folk who I am suspicious of are not so much the direct participants but the folk who I have never met that pop up and send me private emails telling me that they agree wholeheartedly on some proposal I am making and I should resist attempts to make some change. --047d7b3441d0b15c8404e5f75e3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would like to keep discussion of NSA capabilities out of= the BOF as well.

For the sake of having a focused and e= ffective discussion I think we should just stipulate the list of possible c= ompromises and focus on what we can do to address them.

Speculation as to the nature of the NSA capabilities is= probably best done in the bars and on mailing lists. What we discovered ov= er the weekend should cause a lot of the assumptions as to how PRISM works = to be reviewed.

When we first heard of PRISM it was assumed that the da= ta was being voluntarily disclosed by Google etc. It now appears that it is= plaintext traffic on the Internet trunks that is being intercepted.


While it is true that the NSA probably c= an't do the intercepts without any help, we can't build an Internet= without intermediaries either. The question at issue should be not whether= an intermediary can default but whether that default could be detected.

Ben Laurie's Certificate Transparency demonstrates = a way to keep one set of intermediaries under constant observation making d= efault unlikely to succeed unobserved. We need to start looking for equival= ent schemes for all the intermediaries we are forced to trust.

These include:

1) Generation o= f ECC Curves

2) Cryptographic Hardware, in particu= lar SSL accelerators
2a) Kleptography as described by Motti Young= to encode random seeds in the modulus
2b) Disclosing private key through TLS covert channel

3) CAs

4) Standards organizations

On (4) the folk who I am suspicious of are not so much th= e direct participants but the folk who I have never met that pop up and sen= d me private emails telling me that they agree wholeheartedly on some propo= sal I am making and I should resist attempts to make some change.
--047d7b3441d0b15c8404e5f75e3f-- From leifj@mnt.se Mon Sep 9 11:20:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36BB21F9ADA for ; Mon, 9 Sep 2013 11:20:19 -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=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Pf7PaPusHf for ; Mon, 9 Sep 2013 11:20:14 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8138D21F9C20 for ; Mon, 9 Sep 2013 11:20:10 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so5332702lbh.33 for ; Mon, 09 Sep 2013 11:20:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MP6HmZn1SrBdqEDaSaj4XdyzcxmE2ida6qe3rrjy19U=; b=DK0lmho4MXjGSgxv9igfzRNPLwI2nH+lwFwBGMUk4BMCrlnHwuQy2C2mzJe18hBoRY +/NpDUsXMUNf8QTKtbh8UInGBikwjJK4bhlZGNX3iUemtxuQOCZWWeafYP0QOmU0WGEG CAgkbLK6ELY5zpqkik/Zb9VlF8hcRluW6956WQBu9en7UrNhAEgPwaufD41N/dzG/+HY mK+AQmMbMLSU+DEQcGNAl8/N8vPMNV5x+WPJl/n09p6Ix9N3r7rHWfa1ALVd+nopXJhG +RuDIkpVJIu0+88A8cD12v1iiAT6yJEt6kelfEDdrag/3M3tcLqUsJazocCO5Fg4MQju piqw== X-Gm-Message-State: ALoCoQl5VfjQVX1H57PDVkEBfGGaj+NHF6Il708a4kHk+hBm6FcpGFc2YVlINA3kTnCiCxAP+I3a X-Received: by 10.152.116.7 with SMTP id js7mr17505585lab.11.1378750809395; Mon, 09 Sep 2013 11:20:09 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id ac2sm6572593lbc.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 11:20:08 -0700 (PDT) Message-ID: <522E1156.9030307@mnt.se> Date: Mon, 09 Sep 2013 20:20:06 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <522DF017.2030504@cs.tcd.ie> <522E0AC0.6040808@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] plenary vs BOF: (was Re: BoFing in Vancouver) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:20:19 -0000 On 09/09/2013 08:15 PM, Phillip Hallam-Baker wrote: > I would like to keep discussion of NSA capabilities out of the BOF as > well. > > We shouldn't get bogged down by politics but lets agree that we need a clear understanding of our ... ahem... design goals? right? Cheers Leif From dhc@dcrocker.net Mon Sep 9 11:40:29 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9907921E80AB for ; Mon, 9 Sep 2013 11:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II-9wXuertd5 for ; Mon, 9 Sep 2013 11:40:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70A1721F99D0 for ; Mon, 9 Sep 2013 11:40:17 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r89IeAFK032097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Sep 2013 11:40:14 -0700 Message-ID: <522E15F8.8090503@dcrocker.net> Date: Mon, 09 Sep 2013 11:39:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <522DF017.2030504@cs.tcd.ie> In-Reply-To: <522DF017.2030504@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 09 Sep 2013 11:40:14 -0700 (PDT) Cc: perpass Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:40:29 -0000 On 9/9/2013 8:58 AM, Stephen Farrell wrote: > a) suggestions as to how to best use some face-to-face time, On this list or the plenary or both: List topics worthy of pursuit; develop the explanation of them as much as possible. Hence, avoid tutorials during the BOF. So, use the BOF to debate priorities and possible lines of development. I'll suggest a baseline and then three major 'bins' to put topics into, and they probably can be explored in parallel: 0. Establish the Baseline In effect, this would be documenting real-world exposures, based on operational data and not just conjecture. What are the actual threats that are relevant here? I'd also lobby for settling on a definition of privacy that helps us pursue the current concerns. I couldn't convince the authors of RFC 6973 to choose a definition, but still feel that an effort claiming to be about privacy needs to define it in technical and/or operational terms. 1. Implementation & Deployment Cleanup Some problems are due to poor implementation of otherwise-well documented and understood issues. For example, I've heard that random number generation is one of those, with failures to fully appreciate RFC 1750. IETF work could be to: a) document common implementation problems and their best fixes; b) BCP(s) for integrated deployment of the relevant capabilities; that is, noting all the necessary pieces and how they fit together, to mitigate specific privacy-related concerns. 2. Component Robustness For pieces of relevant technology, such as specific functional algorithms: a) review relevant IETF docs for sufficiency and tweak or replace where needed; b) identify missing components and develop them. 3. Internet-Scale Systems Issues Document end-to-end privacy-related concerns and specify the integrated set of mechanisms that will reasonably mitigate them. Here's where concern about compromised intermediaries would factor in, for example; TLS is useless for that, for any intermediary at, or above, transport level. Another line would be meta-data vs. content analysis. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kent@bbn.com Mon Sep 9 11:48:34 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6504D11E8137 for ; Mon, 9 Sep 2013 11:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaJ+nnAngQIW for ; Mon, 9 Sep 2013 11:48:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 67ED211E8123 for ; Mon, 9 Sep 2013 11:48:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34558 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VJ6Ve-0008OY-6Y for perpass@ietf.org; Mon, 09 Sep 2013 14:48:26 -0400 Message-ID: <522E17F9.4000206@bbn.com> Date: Mon, 09 Sep 2013 14:48:25 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> In-Reply-To: <522A328A.5060008@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:48:34 -0000 Stephen, Since you solicited feedback ... We have had considerable, recent, experience with the need to avoid adding delay to a user's web experience (e.g., "Happy Eyeballs") in the v4/v6 transition context. Suggestions that we increase delay in favor of security are not likely to be well received by users or service providers. >> I think there are a couple of principles that we need to adopt IETF-wide. >> >> Part of the definition of "good Internet citizen" for a protocol or application is that not only does that protocol/application include anti-surveillance principles for itself, but that it helps OTHER protocols avoid surveillance. Surveillance-resistance is MORE IMPORTANT than optimizing transport efficiency. given the quantity of meta-data (and personal data) collected by Google, Facebook, and many other commercial entities, and the willingness of users to supply such data, it's hard to believe that most users would agree with this statement. >> 1) Everything SHOULD be encrypted, unless there is an absolute operational requirement not to. This means "encryption by default" in new protocols, and not even specifying unencrypted operations modes unless necessary. Older protocol specs still in use should be revised to require encryption. Deprecate the non "s" versions of protocols. One of the reasons many enterprises decline to employ e-t-e encryption within their nets is because it interferes with debugging and scanning of traffic for malware. While I am in favor of mandatory to implement encryption for our protocols, mandatory to use is not a good idea in all cases. >> 2) Well-known ports should be avoided. Or overloaded to the point where the port number is no longer a significant indicator to the application. This gives rise to the "everything over 443" mentality, which we need to find a way to handle gracefully. Demuxing the service within the channel is a better idea than I used to think. others have already noted that this is a bad idea from a protocol perspective. in an era when many folks try to minimize the number of round trips needed to provide a service to a user, this add to the total. again, while security folks might see this as attractive, I doubt that many users and service providers wold agree. >> 3) Packet sizes should be variable, preferably random. This is the opposite of the "discover the MTU and fill every packet" model of efficiency. Or, we could make all packets the same fixed size by padding small ones. I like random better, but there might well be some hardware optimizations around fixed packet sizes. we have long understood what it takes to provide TFS, and nobody has wanted to waste the bandwidth to do it properly. I doubt that this view has changed. >> 4) Every protocol spec needs to include a pseudonymous usage model, and most should include an anonymous usage model. Use of pseudonyms is applicable to very few of our protocols, and most of the ones where it is applicable, it is already satisfied. Anonymous use, depending on the definition one uses, may be easy or nearly impossible. >> 5) New protocols should be built around end-to-end crypto rather than relying on transport-level wrappers for everything. It's too easy to use a compromised CA-cert to dynamically build a TLS proxy cert. Some level of key delivery out-of-band, coupled to in-band footprint verification, is probably needed. zRTP is a good model. see comments above re #1. >> 6) Randomizing interpacket timing is useful. This does all sorts of horrible things to both TCP optimization and the jitter buffers in real-time communications. But it's worth it. Remember, surveillance-resistance is MORE IMPORTANT than efficiency. not, it's not worth it. see comment above re #3. >> 7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have lessons we should learn. So does TOR. DTN is great for the interplanetary Internet. I prefer realtime performance for almost all of my Earth-bound Internet apps. I suspect other users fell the same way. P2P is fine for some apps, but not all, maybe not even many. >> 8) Every piece of crypto-advice needs serious, multiparty, international, and aggressive review. No more documents authored by NSA shills (which Schneier says we seem to have). I think we have generally good review for the algs we choose; we periodically review algs and key sizes and make revisions as deemed necessary. We have folks like David McGrew (Cisco) providing much of this expert review. I think we have operated in this mode for many years. Steve From hallam@gmail.com Mon Sep 9 13:32:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A116021E80CC for ; Mon, 9 Sep 2013 13:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBlUOXtXCPQ9 for ; Mon, 9 Sep 2013 13:32:48 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 67FF221E80C6 for ; Mon, 9 Sep 2013 13:32:48 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so5405455lbh.19 for ; Mon, 09 Sep 2013 13:32:47 -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; bh=gnCdZyBdkaL/jOygSIWG7ffFHLxUwWWftILybKhVUCs=; b=jjFGzpdHhryYCF78bD3IVJ/gWFg11PIMsabvfekjMvgKxV3EwvTLBSZFwDEPz9nkLq JamoqoHglSmFhUl0+vTFGdkZbrJg3DmEENU9Ljq0qObUu6DR2uq2h7H28VGRGLWDUuTt wpiK9abDoaPJcupU900giUXE5MYqjXsOeiYJqGqygMJe7WNYJf+YEDPl2lRmuLiS9Ke6 9pdUQsmCK3H9Gct410vy1cixYd4TAavq9geYIfqBlJcKg1o9toBkSxGsd0gqmGCad8Or gkQ3wffseTO6rkSJlz+DerXziWTz+PTXJ/HP7904DM4xiYPK/w/AFIJZTC1toGzGAG3V rBxw== MIME-Version: 1.0 X-Received: by 10.112.14.3 with SMTP id l3mr3780919lbc.27.1378758767383; Mon, 09 Sep 2013 13:32:47 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Mon, 9 Sep 2013 13:32:47 -0700 (PDT) In-Reply-To: <522E1156.9030307@mnt.se> References: <522DF017.2030504@cs.tcd.ie> <522E0AC0.6040808@dcrocker.net> <522E1156.9030307@mnt.se> Date: Mon, 9 Sep 2013 16:32:47 -0400 Message-ID: From: Phillip Hallam-Baker To: Leif Johansson Content-Type: multipart/alternative; boundary=001a11c37a088f9f2e04e5f94ade Cc: perpass Subject: Re: [perpass] plenary vs BOF: (was Re: BoFing in Vancouver) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:32:49 -0000 --001a11c37a088f9f2e04e5f94ade Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 9, 2013 at 2:20 PM, Leif Johansson wrote: > On 09/09/2013 08:15 PM, Phillip Hallam-Baker wrote: > > I would like to keep discussion of NSA capabilities out of the BOF as > > well. > > > > > We shouldn't get bogged down by politics but lets agree that we need a > clear understanding of our ... ahem... design goals? right? > Yes, and I think we can get those thrashed out on the list before the BOF. -- Website: http://hallambaker.com/ --001a11c37a088f9f2e04e5f94ade Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 9, 2013 at 2:20 PM, Leif Johansson &l= t;leifj@mnt.se> wrote:
On 09/09/2013 08:15 PM, Ph= illip Hallam-Baker wrote:
> I would like to keep discussion of NSA capabilities out of the BOF as<= br> > well.
>
>
We shouldn't get bogged down by politics but lets agree that we n= eed a
clear understanding of our ... ahem... design goals? right?

Yes, and I think we can get those thrashed out on the = list before the BOF.=A0

--
Website: http://hallambaker.com/
--001a11c37a088f9f2e04e5f94ade-- From scott.brim@gmail.com Tue Sep 10 05:19:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73C21E808F for ; Tue, 10 Sep 2013 05:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQCbRl+mCVlh for ; Tue, 10 Sep 2013 05:18:59 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 71CE321E8053 for ; Tue, 10 Sep 2013 05:18:59 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id es8so7129042obc.0 for ; Tue, 10 Sep 2013 05:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=fTHDEaIeqsy0D5qriuSUxEXzLMliqNVBmUj+OoQJmLM=; b=QRQMAiZ2a81RBZ8fScYGtzkoTjBly5wswdoDc/so/CJVcdI14Blbb3vgOCW91ElAVn nBNs8iTxQ00ERYuESp/zuLF+dAE5mm44tQ4Y00EIKDK8XWVbjyRPyUzPrP5n35tdZUuc t2TCkh+yCDxnwFXHwN76MU8AOYhgDp/Bia2CT/O1T58C+NmS4ZncTqNtjLWfv670kDeX bDzAKI5nUwBzJEWL0ftkwzgP7SmrkhNpwrUpW/MGmczpK1SG3dsG8iPcCi3Q3cP2oEC4 b9529/En8ghrcHmNjo7Fymx0/4X8kDv0iKFk9RlXLvcV3N0IZFJxX4hmrFVPX4ZDh2WI eNLQ== X-Received: by 10.60.15.234 with SMTP id a10mr5041052oed.53.1378815539007; Tue, 10 Sep 2013 05:18:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.134 with HTTP; Tue, 10 Sep 2013 05:18:38 -0700 (PDT) In-Reply-To: References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> <6C08F669-75F6-441B-A7C5-85C0DBD8DB07@brianrosen.net> <522DE999.9010100@cs.tcd.ie> From: Scott Brim Date: Tue, 10 Sep 2013 08:18:38 -0400 Message-ID: To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Linus Nordberg , perpass@ietf.org, Hannes Tschofenig , Dean Willis , Stephen Farrell Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 12:19:00 -0000 On Mon, Sep 9, 2013 at 11:48 AM, Brian Rosen wrote: > So RELOAD is privacy friendly by turning calling into true p2p with signa= ling and media not transiting any third party. > > The concern I have is that to get credentials enabling you to store your = URI in the DHT, you interact with an enrollment server. That server only i= ssues credentials, it's not in the path of the call, but if it was co-opte= d, it could create mischief with those credentials. There could be multiple enrollment servers, so all you need is an enrollment server that you both trust (but then we go around that loop again). Also, a grassroots system doesn't have to be under legal obligation to reveal information. From dean.willis@softarmor.com Tue Sep 10 10:31:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DDD11E80A2 for ; Tue, 10 Sep 2013 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.454 X-Spam-Level: X-Spam-Status: No, score=-101.454 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXhXB2m0ScCS for ; Tue, 10 Sep 2013 10:31:43 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 674A421F92E7 for ; Tue, 10 Sep 2013 10:31:43 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id j10so8356459oah.27 for ; Tue, 10 Sep 2013 10:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jc1GY5IHWY0FyMGE8DFi1KbH0qEKzmcFVuxiHWXV62s=; b=hqeXoNhglByeGAh92xYphgeBkM+B5C/GhjxSyOITFKzSqjVWhgewSnFRcayi+iNvuT QFWOaztmG/F5LPyV4mV4tzX2hDB57Bx2dF8gTR9fBGhu26vuTyP2fnq6R4kAxC1rYNpS 16LEMNbUhZI7dqAsfEPOCrDN5gXek24kiAdsY= 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:message-id:references:to; bh=jc1GY5IHWY0FyMGE8DFi1KbH0qEKzmcFVuxiHWXV62s=; b=YM3RJISreVNyx9+zJYGI1sPTCH3H6O2fxU1BHqsMj0YWIHahz9O4QqHR3z/UXA88le BnO8F15odkOwvSBIMK3rpxsave45j3A8iRRhq80mqjjV2DYR3+qBR5BpXTC/Fyd2ahK4 hPqulPUuPnXWKthG/lzaDEYXY/bT0Rn2Tj9NPHY132ve1OdLxoQqnTendDsdK2Jhd6Vy f10jqLbVAdXYsMEM/t+j7jn7dn3JLpYkY4wqFdW+l3sNwVuFCcVcfjZUnI38TfA74FWw Ra9gCxpPUaTXrE5+/+BXn7wwrlT3Sugi4W1Uku5K4pDNsoRjwIrxQt0q59AKIjfaygo9 65ag== X-Gm-Message-State: ALoCoQmfL8W9rShw5rOKm5t/DYOmqKn3PnsG1Bq5z97a1I7PUL/eRD2DjjWVKoOHoNTfUAh1eFa/ X-Received: by 10.182.81.99 with SMTP id z3mr3111580obx.64.1378834302499; Tue, 10 Sep 2013 10:31:42 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id bq4sm21665606obb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 10:31:41 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_70C0F902-8213-4D77-B401-23F25549CE44"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: <522DF9D8.10607@stpeter.im> Date: Tue, 10 Sep 2013 12:31:40 -0500 Message-Id: <915DB25F-5ACC-4CB3-847D-8E86D46BBC8E@softarmor.com> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: perpass , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:31:44 -0000 --Apple-Mail=_70C0F902-8213-4D77-B401-23F25549CE44 Content-Type: multipart/alternative; boundary="Apple-Mail=_C586B2C7-605F-4399-A47D-EBAF70094504" --Apple-Mail=_C586B2C7-605F-4399-A47D-EBAF70094504 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 9, 2013, at 11:39 AM, Peter Saint-Andre = wrote: > Signed PGP part > On 9/9/13 9:58 AM, Stephen Farrell wrote: >=20 > > So, this is a call for: > >=20 > > a) suggestions as to how to best use some face-to-face time, b) > > agenda proposals, and, >=20 > We'll want to use the high-bandwidth time wisely, and we know that > security-related discussions (well, all discussions) can easily go off > track. Staying focused on the core issues, and on problems that might > have engineering solutions, will be paramount. That makes me wonder if a second session should be allocated for the = obligatory hand-wringing and mic-ranting, or if we're planning to do = that at the plenary level. You know http://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model ... Denial, anger, bargaining, depression, acceptance. We don't have a surveillance problem.=20 I'm angry that we've been surveilled and that they planted people in our = organization to make it easier.=20 Maybe if we just use TLS everywhere, it'll be OK.=20 This isn't going to work, and I'm sad and giving up on the Internet.=20 Oh well, the NSA reads my email, so I don't have to. Beer! -- Dean --Apple-Mail=_C586B2C7-605F-4399-A47D-EBAF70094504 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 stpeter@stpeter.im> = wrote:

Signed PGP part
On 9/9/13 9:58 AM, Stephen Farrell = wrote:

> So, this is a call for:
>
> a) = suggestions as to how to best use some face-to-face time, b)
> = agenda proposals, and,

We'll want to use the high-bandwidth time = wisely, and we know that
security-related discussions (well, all = discussions) can easily go off
track. Staying focused on the core = issues, and on problems that might
have engineering solutions, will = be paramount.

That makes = me wonder if a second session should be allocated for the obligatory = hand-wringing and mic-ranting, or if we're planning to do that at the = plenary level.


= Denial, anger, bargaining, depression, = acceptance.

We don't have a surveillance = problem. 
I'm angry that we've been surveilled and that = they planted people in our organization to make it = easier. 
Maybe if we just use TLS everywhere, it'll be = OK. 
This isn't going to work, and I'm sad and giving up = on the Internet. 
Oh well, the NSA reads my email, so I = don't have to. = Beer!

--
Dean
= --Apple-Mail=_C586B2C7-605F-4399-A47D-EBAF70094504-- --Apple-Mail=_70C0F902-8213-4D77-B401-23F25549CE44 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSL1d8AAoJENG95ttGtcqrRZEP/398CV3pdhJOujYnbfux7AC/ RLXlKaByibUkn2nIwCS9eomPCqP3X9R5tclJVKewSVKxhZsNSZcUMwtCY8+lRlyM B1ejQi7cjuar8gmOo6YGTFq3iXpYES4VFiHrb3NaR3lu73BDC4My9QTV6YEIWRGt TIBSkPp2CXZMTQ5MMTxoFpIlvpnSrLvjdD1Qr2lRr+GSmhpywN+2Wylh99Qf83Tm 8WNkHnAcY3Eg+Sjb7qdX2v+/V6C6dYRf6f5uWHAYuoz/8138N4gPvrd/WGJAl6m+ fesyKgz5m0s8x6VgrO3w+ta3xsSMyFZebewyJFk/t1WV3IU032fcXAaB4MwJAjYC Ri5fyHsmZAahOCcHzoPlsOBKAJqvObjPlb7NZsQqTWgxNj8JVa/P21mPutOt4H8N g/QrThW6HHL0WXqDNPJzhIAzK8Kk+YJ38OXR56gZhnfQ9zfqPIwc2W5xJxVlcHpi 8EA95MwxFLUQ0/hJ5KtqnBMWPprcwaFG/zEvUc7QQBf7ZMiGakrIob9RtdWpvhCI nA7P/mCzhx4Rnz+HrcAQkYFhaYHPFVNvNpeM6uIzfIPEaLUfaiM6c+wPO5DsmeDR TcdLmRUVqHVtUG7Gea5eFqmoL0Uq9YfqfPqJlqaFj3XcnKKN0CgkHiZA4/U1nDBL oTEXqBC4EbLXKXXUdG51 =xZfh -----END PGP SIGNATURE----- --Apple-Mail=_70C0F902-8213-4D77-B401-23F25549CE44-- From hallam@gmail.com Tue Sep 10 10:57:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1176C21E8157 for ; Tue, 10 Sep 2013 10:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HpYc-QslG1z for ; Tue, 10 Sep 2013 10:56:59 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4D38B21E8127 for ; Tue, 10 Sep 2013 10:56:59 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eo20so6523692lab.17 for ; Tue, 10 Sep 2013 10:56:58 -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; bh=hir3Q2ft2S+vDOXZ/BDxzoEGlNNnepTWWVFEvuryYVU=; b=iBXuMCeMh/ZiDd7CeSGEH9mvjGCDf8vueQkVyzoT22VW7dQb7Epiw9T9NUqPFG03m2 SFFW7Kfdo6NlfIZFUnp2Oc9X6O+qvPXhMAqpDpkjjwT0GUjDldeIal/syfIfJb75xgJ8 gMDZsCs044ZkPq+8s6KE2pTjy/OEw3km9SqyMEFRj4PyOnzlH2/vrAZuAPy3V5Yj5nhG Yv8ZZSLv9uuc4+K8uWJRNJzJT6zJWF4UtlMbl2eBaOz9kzMVzxBK0w2Tqw1yLglKzTio s0HChKu6iwwHwb7fCTJ4ggw39IGxNKv1xFMkeu7azCseSPIyORsVdBGIZLdhbOFsVPdI 6IkQ== MIME-Version: 1.0 X-Received: by 10.152.6.97 with SMTP id z1mr8067618laz.26.1378835818141; Tue, 10 Sep 2013 10:56:58 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Tue, 10 Sep 2013 10:56:58 -0700 (PDT) In-Reply-To: <915DB25F-5ACC-4CB3-847D-8E86D46BBC8E@softarmor.com> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <915DB25F-5ACC-4CB3-847D-8E86D46BBC8E@softarmor.com> Date: Tue, 10 Sep 2013 13:56:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Dean Willis Content-Type: multipart/alternative; boundary=089e0149396424deae04e60b3bed Cc: perpass , Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:57:01 -0000 --089e0149396424deae04e60b3bed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 10, 2013 at 1:31 PM, Dean Willis wro= te: > > On Sep 9, 2013, at 11:39 AM, Peter Saint-Andre wrote= : > > Signed PGP part > On 9/9/13 9:58 AM, Stephen Farrell wrote: > > > So, this is a call for: > > > > a) suggestions as to how to best use some face-to-face time, b) > > agenda proposals, and, > > We'll want to use the high-bandwidth time wisely, and we know that > security-related discussions (well, all discussions) can easily go off > track. Staying focused on the core issues, and on problems that might > have engineering solutions, will be paramount. > > > That makes me wonder if a second session should be allocated for the > obligatory hand-wringing and mic-ranting, or if we're planning to do that > at the plenary level. > > You know http://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model > ... > > Denial, anger, bargaining, depression, acceptance. > > We don't have a surveillance problem. > I'm angry that we've been surveilled and that they planted people in our > organization to make it easier. > Maybe if we just use TLS everywhere, it'll be OK. > This isn't going to work, and I'm sad and giving up on the Internet. > Oh well, the NSA reads my email, so I don't have to. Beer! > Well welcome to the club. But another point that makes me rather angrier is that we are all now potential NSA plants. Or rather would if not for the fact that pretty much everyone feels free to accuse CAs of being tools of the NSA anyway. The point is that everyone is now in the same boat I have been in these past 20 years. And just as nobody ever thinks much about my feelings when accusing me of being an NSA plant I am going to feel free to throw it all back. I really don't think it likely the NSA cryptanalytic capabilities are based on CA compromise because I really can't see how the EFF and co could have missed the evidence of a program as large as the one revealed by Snowden. Even without CT, a CA compromise leaves marks. I don't think the point of compromise is in Google etc. either. Too many people would have to know. But I certainly won't rule out that as a possibility. Looks to me as if PRISM is an old school attack and involves back hoes and splicing fiber optic cables. That would certainly be consistent with what we know of the cost of bringing companies into the program. It is the way I would do it. --=20 Website: http://hallambaker.com/ --089e0149396424deae04e60b3bed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 10, 2013 at 1:31 PM, Dean Willis <= dean.willis@= softarmor.com> wrote:

On Sep 9, 2013, at 11:39 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
Signed PGP part
On 9/9/13 9:58 AM, Stephen Farrell wrote:

> So, this is a call for:
>
> a) suggestions as to how = to best use some face-to-face time, b)
> agenda proposals, and,
We'll want to use the high-bandwidth time wisely, and we know that security-related discussions (well, all discussions) can easily go off
t= rack. Staying focused on the core issues, and on problems that might
hav= e engineering solutions, will be paramount.

That makes me wonder if a second session should be allocated= for the obligatory hand-wringing and mic-ranting, or if we're planning= to do that at the plenary level.


Denial, anger, bargaining, depression, acceptance.

We don't have a surveillance problem.=A0
I'm angry that we've been surveilled and that they planted people = in our organization to make it easier.=A0
Maybe if we just use TLS everywhere, it'll be OK.=A0
Thi= s isn't going to work, and I'm sad and giving up on the Internet.= =A0
Oh well, the NSA reads my email, so I don't have to. Beer= !

Well welcome to the club.=A0


But another point that makes me rather ang= rier is that we are all now potential NSA plants. Or rather would if not fo= r the fact that pretty much everyone feels free to accuse CAs of being tool= s of the NSA anyway.

The point is that everyone is now in the same boat I ha= ve been in these past 20 years. And just as nobody ever thinks much about m= y feelings when accusing me of being an NSA plant I am going to feel free t= o throw it all back.


I really don't think it likely the N= SA cryptanalytic capabilities are based on CA compromise because I really c= an't see how the EFF and co could have missed the evidence of a program= as large as the one revealed by Snowden. Even without CT, a CA compromise = leaves marks.=A0

I don't think the point of compromise is in Google = etc. either. Too many people would have to know. But I certainly won't = rule out that as a possibility.

Looks to me as if = PRISM is an old school attack and involves back hoes and splicing fiber opt= ic cables. That would certainly be consistent with what we know of the cost= of bringing companies into the program. It is the way I would do it.
=A0

--
Website: http://hallambaker.com/
--089e0149396424deae04e60b3bed-- From scott.brim@gmail.com Tue Sep 10 11:03:28 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B07921E8127 for ; Tue, 10 Sep 2013 11:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.352 X-Spam-Level: X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh3+XjzfgGJN for ; Tue, 10 Sep 2013 11:03:27 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6E72B21E811D for ; Tue, 10 Sep 2013 11:03:27 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id va7so2514826obc.25 for ; Tue, 10 Sep 2013 11:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6cFgdoBMAV+qF+7+x+MQU3cGvOPOJ4rrxVi3blmIjP0=; b=PH+UxW2HVbFcygmQxAHihjGf1D4o+syG8AJj+Da+LYpwkOKgKs00u3/5uT1zexHiHs IJe2FZVdwiEo7QdzVfp/fXc07ruPdOMsqvd7a8ajVddidKj51cgk9pD5W5qT+BsCBMZD Lj5+4TDEW8uGBBhYhx02Sn7okPie4WMBa2YS5K/HlVBqgFCVlsduokxao4mA76DhI5dP ntV67ohfD+AWf1ASHJKlj4ySzIOzj2M2QqU5/d8jkN+4/dDGMSXNYAjS64W/kzkHbImS AwobxwxhfbP118Z+DN53ZgX8abKg8c87uI5EqYvLuMc559CXaA64zIjjD7v4vpK2Ur8s YU6A== X-Received: by 10.60.15.234 with SMTP id a10mr6622461oed.53.1378836204318; Tue, 10 Sep 2013 11:03:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.134 with HTTP; Tue, 10 Sep 2013 11:03:03 -0700 (PDT) In-Reply-To: <522DF9D8.10607@stpeter.im> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> From: Scott Brim Date: Tue, 10 Sep 2013 14:03:03 -0400 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:03:28 -0000 On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre wrote: > We'll want to use the high-bandwidth time wisely, and we know that > security-related discussions (well, all discussions) can easily go off > track. Staying focused on the core issues, and on problems that might > have engineering solutions, will be paramount. This is a scope question. How do we decide what to focus on? I suggest that we start by saying it's not security, and it's not surveillance, it's privacy, i.e. the ability to control the flow of one's personal information (there's your definition, Dave). Security is too large a scope, while surveillance is too small. From hannes.tschofenig@gmx.net Tue Sep 10 11:27:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D421F8DA3 for ; Tue, 10 Sep 2013 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV6TzxeoBUlf for ; Tue, 10 Sep 2013 11:26:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAEA21E80A5 for ; Tue, 10 Sep 2013 11:26:54 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MSZ6u-1VR3Kn2gmi-00Ra5K for ; Tue, 10 Sep 2013 20:26:50 +0200 Message-ID: <522F645D.2080609@gmx.net> Date: Tue, 10 Sep 2013 21:26:37 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Scott Brim References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:PnV0GvaAk8HQKuEhZjZ/5vVS7BwaO9Gj9knMDtRj4d1o9xZxZdw M8lCa/W3I/igD3GBV8Fj1e9V1G0CGQso9FRh30Zb6ivWVgRcCX1v6/n7aHmTe6n6lvETN+C tdUJOvGb+kIqE+ftmcOBdcYhHVXuNkPzsVfGLu67fj9JXceXnfG9X3s8jBLyrXR6Kz63UXN NZQFFpSOVVqU9jAMzFK3A== Cc: perpass , hannes.tschofenig@gmx.net, Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:27:03 -0000 I suggested within the IAB to do a workshop* (before the meeting), which would give us an extra day of intense discussion time. Unfortunately, it is a bit close to the next meeting (which complicates travel planning) and some folks have booked their trip already... Despite all the discussions I fear that a BOF slot will make it very difficult to discuss such a broad topic and to make some progress. Ciao Hannes (*): I know that it is not the first time I have suggested a workshop. On 10.09.2013 21:03, Scott Brim wrote: > On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre wrote: >> We'll want to use the high-bandwidth time wisely, and we know that >> security-related discussions (well, all discussions) can easily go off >> track. Staying focused on the core issues, and on problems that might >> have engineering solutions, will be paramount. > > This is a scope question. How do we decide what to focus on? I > suggest that we start by saying it's not security, and it's not > surveillance, it's privacy, i.e. the ability to control the flow of > one's personal information (there's your definition, Dave). Security > is too large a scope, while surveillance is too small. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From dhc@dcrocker.net Tue Sep 10 11:35:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB9C11E81DE for ; Tue, 10 Sep 2013 11:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JszU2GI+fq4 for ; Tue, 10 Sep 2013 11:35:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9941E11E811B for ; Tue, 10 Sep 2013 11:35:07 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r8AIYq5K029472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Sep 2013 11:35:00 -0700 Message-ID: <522F6637.2080700@dcrocker.net> Date: Tue, 10 Sep 2013 11:34:31 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Brim References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 10 Sep 2013 11:35:02 -0700 (PDT) Cc: perpass , Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:35:30 -0000 On 9/10/2013 11:03 AM, Scott Brim wrote: > On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre wrote: >> Staying focused on the core issues, and on problems that might >> have engineering solutions, will be paramount. > This is a scope question. How do we decide what to focus on? 1. I agree with Peter's call for focusing on core issues 2. I'll suggest that deciding on what those are is, itself, the most core issue. Much of what has been getting posted pertains to component mechanisms. They are pretty obviously useful mechanisms, but we have no foundation for determining whether they are relevant -- or more importantly, essential -- to the scope of perpass work. We need to make sure that we are not merely looking for our keys under the lamppost. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spencerdawkins.ietf@gmail.com Tue Sep 10 11:35:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F3621F9B66 for ; Tue, 10 Sep 2013 11:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxR0zK-KgGcZ for ; Tue, 10 Sep 2013 11:35:54 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id DB87221F9CC6 for ; Tue, 10 Sep 2013 11:35:53 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id k11so4128974eaj.0 for ; Tue, 10 Sep 2013 11:35:53 -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; bh=EhXcOjYwbyC9JRE7jcxnRn6HGA5e0XDN/ebRO6vQClI=; b=pIHUYNg4JSt8QaEenqI0QFW8lNjU8RgKZcB+tvSU+My/dXVUXAr5kLivSjwKHyZxFQ B5EfyUDP4roixotR0kMlRBf3GuP2n/o6R0Bs+YlUODRDIhXEtJ+3bTpbbSPpRzWBSGJM mhp74zmP5LAbqdLXg5JDlHXef9T0JuDf22kT8AdKS+7MkGsCmonm7a8fZ2K0JHbufjln Vrl6it/RLGbqYIeBk4Kq29XEThG67HDN1qA193lvVbBs69DPxkaiSYMXXkkkSm0K04M1 skNcMC9yK9Xt6KuP6QpIm+yXRmfGO7itlaYULVxi9QyPiU6TlcZ9UvEoF6tngD2E6/8S qTDQ== MIME-Version: 1.0 X-Received: by 10.14.199.3 with SMTP id w3mr40766336een.33.1378838153046; Tue, 10 Sep 2013 11:35:53 -0700 (PDT) Received: by 10.223.181.8 with HTTP; Tue, 10 Sep 2013 11:35:52 -0700 (PDT) In-Reply-To: <522F645D.2080609@gmx.net> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F645D.2080609@gmx.net> Date: Tue, 10 Sep 2013 13:35:52 -0500 Message-ID: From: Spencer Dawkins at IETF To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7b3440c850ce1904e60bc678 Cc: perpass , Scott Brim , Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:35:55 -0000 --047d7b3440c850ce1904e60bc678 Content-Type: text/plain; charset=ISO-8859-1 Hannes, if we have not solved all the problems such a workshop(*) would address by December, I would certainly support a workshop in something like the London IETF timeframe :-) Spencer (*) and this is not the first time I've said something snarky and then supported a workshop you've proposed, either! On Tuesday, September 10, 2013, Hannes Tschofenig wrote: > I suggested within the IAB to do a workshop* (before the meeting), which > would give us an extra day of intense discussion time. Unfortunately, it is > a bit close to the next meeting (which complicates travel planning) and > some folks have booked their trip already... > > Despite all the discussions I fear that a BOF slot will make it very > difficult to discuss such a broad topic and to make some progress. > > Ciao > Hannes > > (*): I know that it is not the first time I have suggested a workshop. > > On 10.09.2013 21:03, Scott Brim wrote: > >> On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre >> wrote: >> >>> We'll want to use the high-bandwidth time wisely, and we know that >>> security-related discussions (well, all discussions) can easily go off >>> track. Staying focused on the core issues, and on problems that might >>> have engineering solutions, will be paramount. >>> >> >> This is a scope question. How do we decide what to focus on? I >> suggest that we start by saying it's not security, and it's not >> surveillance, it's privacy, i.e. the ability to control the flow of >> one's personal information (there's your definition, Dave). Security >> is too large a scope, while surveillance is too small. >> ______________________________**_________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/**listinfo/perpass >> > > ______________________________**_________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/**listinfo/perpass > --047d7b3440c850ce1904e60bc678 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hannes, if we have not solved all the problems such a workshop(*) would add= ress by December, I would certainly support a workshop in something like th= e London IETF timeframe :-)

Spencer

(*) and this is not the first time I've said something s= narky and then supported a workshop you've proposed, either!

On = Tuesday, September 10, 2013, Hannes Tschofenig wrote:
I suggested within the IAB to do a workshop* (before the meeting), which wo= uld give us an extra day of intense discussion time. Unfortunately, it is a= bit close to the next meeting (which =A0complicates travel planning) and s= ome folks have booked their trip already...

Despite all the discussions I fear that a BOF slot will make it very diffic= ult to discuss such a broad topic and to make some progress.

Ciao
Hannes

(*): I know that it is not the first time I have suggested a workshop.

On 10.09.2013 21:03, Scott Brim wrote:
On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre<stpeter@stpeter.im= > =A0wrote:
We'll want to use the high-bandwidth time wisely, and we know that
security-related discussions (well, all discussions) can easily go off
track. Staying focused on the core issues, and on problems that might
have engineering solutions, will be paramount.

This is a scope question. =A0How do we decide what to focus on? =A0I
suggest that we start by saying it's not security, and it's not
surveillance, it's privacy, i.e. the ability to control the flow of
one's personal information (there's your definition, Dave). =A0Secu= rity
is too large a scope, while surveillance is too small.
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
--047d7b3440c850ce1904e60bc678-- From hannes.tschofenig@gmx.net Tue Sep 10 11:44:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9844C21E809E for ; Tue, 10 Sep 2013 11:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3crxSBsAgmsw for ; Tue, 10 Sep 2013 11:43:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8F85011E8101 for ; Tue, 10 Sep 2013 11:43:53 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lqhaw-1VwfcS3XLG-00eN9d for ; Tue, 10 Sep 2013 20:43:51 +0200 Message-ID: <522F685B.8040106@gmx.net> Date: Tue, 10 Sep 2013 21:43:39 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dean Willis References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> In-Reply-To: <522E17F9.4000206@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5Qzz8sMjVni2mSJL+vOzy9T85fjfcPwXW7r394+l/TcL6JGypyx UKf846QQQDRx30/hVzhIC4zmTfG0g2zNLiBQ2MAzIQpBBtWkoHxAcaMywgIxjW/iH0+WEkT jSwDsBN1LxToM3iWOHJso3+Rl0dETBSHPGh8+9rkeasOUPmThmFl9ZY0K3yDVNH79ET+lwV oQ6Zhk5t95HEcY3TpM2lw== Cc: perpass@ietf.org, hannes.tschofenig@gmx.net Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:44:00 -0000 Hi Dean, I wanted to comment on your suggestions: > 1) Everything SHOULD be encrypted, unless there is an absolute operational requirement not to. This means "encryption by default" in new protocols, and not even specifying unencrypted operations modes unless necessary. Older protocol specs still in use should be revised to require encryption. Deprecate the non "s" versions of protocols. I guess there are two issues here, namely: * End-to-end vs. Hop-by-hop (or stuff in between) * Encryption itself is often not the problem but rather the key management As you have seen my post about the VoIP stuff it is actually not so easy to say what exactly has to be done in what situations since our protocols are a bit more complex... So, you will have to expand a bit. Maybe you also want to explain the SHOULD vs. a MUST. > > 2) Well-known ports should be avoided. Or overloaded to the point where the port number is no longer a significant indicator to the application. This gives rise to the "everything over 443" mentality, which we need to find a way to handle gracefully. Demuxing the service within the channel is a better idea than I used to think. That does not make sense. We are heading in the direction of everything running on 443 with TLS (from a standardization point of view) -- not necessarily on the deployment side (since otherwise we wouldn't need efforts like those from EFF). You might also find it interesting to hear that the ability for demultiplexing HTTP 2.0 and earlier version will be done based on information in the TLS handshake and that the TLS group had decided that they prefer a solution that reveals the type of application and rejected a proposal for hiding it. Here are the two proposals: http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04 Maybe it would be worthwhile to revisit the decision? (A side remark: I was at that meeting and pointed out that this is a privacy decision and folks in the room said that this has nothing to do with privacy....) > > 3) Packet sizes should be variable, preferably random. This is the opposite of the "discover the MTU and fill every packet" model of efficiency. Or, we could make all packets the same fixed size by padding small ones. I like random better, but there might well be some hardware optimizations around fixed packet sizes. Ok. Sounds reasonable to have that option. I know that IPsec has the ability to add padding. > > 4) Every protocol spec needs to include a pseudonymous usage model, and most should include an anonymous usage model. Makes sense to me (at least for protocols that are potentially run by end devices). For some protocols I guess it is less useful (thinking about routing protocols). Here is the challenge: If I look at SIP then we certainly have that option but a) you will have to get providers to implement it, and b) the functionality often conflicts with other privacy features. For example, you may not want to get interrupted with a phone call when you do not know the person on the other end. > > 5) New protocols should be built around end-to-end crypto rather than relying on transport-level wrappers for everything. It's too easy to use a compromised CA-cert to dynamically build a TLS proxy cert. Some level of key delivery out-of-band, coupled to in-band footprint verification, is probably needed. zRTP is a good model. I think they should have both since the functions provided are actually different. ZRTP is not a good model if you don't know the voice of the other person. Not all communication is (a) between persons, (b) between persons who use voice communication, and (b) persons who know each other. > > 6) Randomizing interpacket timing is useful. This does all sorts of horrible things to both TCP optimization and the jitter buffers in real-time communications. But it's worth it. Remember, surveillance-resistance is MORE IMPORTANT than efficiency. Need to think about that. > > 7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have lessons we should learn. So does TOR. In case of Tor we could certainly learn something about fingerprinting avoidance. I am not sure about the lessons you have learned from the other efforts. Our IETF p2p efforts are still in a dying state since the entire industry has unfortunately changed their preferred communication model in the meanwhile from p2p to client-to-server for pretty much everything. In my VoIP blog post I argued that TURN doesn't actually give you any additional privacy protection if the adversary is a powerful eavesdropper or the VoIP provider itself. It only helps when you want to hide your IP address towards the communication party, as Shida explained in his SIP privacy RFC. > > 8) Every piece of crypto-advice needs serious, multiparty, international, and aggressive review. No more documents authored by NSA shills (which Schneier says we seem to have). I agree with you about the standardization aspects (regarding openness and transparency). The problem is that with the Web world we are unfortunately heading into a different direction, as we (=IAB) tried to explain some time ago with the 'post standardization' plenary (+document). I am not sure yet how to best tackle that story (and I am unfortunately not entirely alone with my lack of suggestions). On the second suggestion I don't think you are serious. We obviously have documents co-authored by NSA employees (see http://www.arkko.com/tools/allstats/c_nsa.html) but first I dislike to exclude people (since that's the whole point of having an open standards process) and second where do you stop excluding? We have people who are contracting for the NSA, we have people who work at government organizations (like NIST), we have companies who work on government contracts (like BBN). Ciao Hannes > From hannes.tschofenig@gmx.net Tue Sep 10 11:47:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB921F9B7F for ; Tue, 10 Sep 2013 11:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vI6fJXY-0CA2 for ; Tue, 10 Sep 2013 11:47:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5776D21F9BDB for ; Tue, 10 Sep 2013 11:47:10 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lxu7U-1W4ot5277s-015Ky3 for ; Tue, 10 Sep 2013 20:47:08 +0200 Message-ID: <522F691E.3010101@gmx.net> Date: Tue, 10 Sep 2013 21:46:54 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F6637.2080700@dcrocker.net> In-Reply-To: <522F6637.2080700@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:oNSQ7sCiuVCEOjDyRlpY8gKbtYZn9/I5WsrlgGvmUyMOQY//1Qg 5u6Tvm3yyViafSwi0w8pdrY1h05Exnq7GEnjEdVF51Fskl4kdpe/EGh/RQqKu0CK+0pcCUt gGKI+4bBBuvXpkrp4nnaD7wqAM6laTjT2Xz7QV5AaEOGg+CbpgWkSvhP81PkPOF2axQpJ0X mBTjDfRuhpKgzlgAYO9yg== Cc: Dave Crocker , perpass , Scott Brim , Peter Saint-Andre , hannes.tschofenig@gmx.net, Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:47:16 -0000 One approach to focus the discussion is to limit it to what the IETF can do. Within that category one could also focus on specific applications to make it (a) down-to-earth and (b) have a bit time for preparation. On 10.09.2013 21:34, Dave Crocker wrote: > On 9/10/2013 11:03 AM, Scott Brim wrote: >> On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre >> wrote: >>> Staying focused on the core issues, and on problems that might >>> have engineering solutions, will be paramount. >> This is a scope question. How do we decide what to focus on? > > > 1. I agree with Peter's call for focusing on core issues > > 2. I'll suggest that deciding on what those are is, itself, the most > core issue. > > Much of what has been getting posted pertains to component mechanisms. > They are pretty obviously useful mechanisms, but we have no foundation > for determining whether they are relevant -- or more importantly, > essential -- to the scope of perpass work. > > We need to make sure that we are not merely looking for our keys under > the lamppost. > > d/ From hannes.tschofenig@gmx.net Tue Sep 10 11:49:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4951711E80EE for ; Tue, 10 Sep 2013 11:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAnlal-QaBuP for ; Tue, 10 Sep 2013 11:49:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9417D21E815E for ; Tue, 10 Sep 2013 11:49:12 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LkTSx-1VplkJ1syp-00cPJ9 for ; Tue, 10 Sep 2013 20:49:06 +0200 Message-ID: <522F6994.1020307@gmx.net> Date: Tue, 10 Sep 2013 21:48:52 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Scott Brim References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:x20cFRRh6UkDyvFDFIlu6qQm5Zl/CSIkNynFz2Zwf1HxG3wCSmP hMniu/lmgDkxXYIedGUECp0guvCgqK3z2yDcgThszOHCI/EUcy9fUzFrajXh1KlFJzllzfG Ek4TsB+MAHBeBmfPz2Dguq29sfbB53ja+opwWElRaEPqhYE1tHnL7fHbU5DSoVCM2ziXXJO qc6R+zuCZoPPmikTOvrTg== Cc: perpass , hannes.tschofenig@gmx.net, Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:49:18 -0000 Hi Scott, as you know we have been working on this privacy tutorial (and you have given feedback on the trial run). Maybe some information from the privacy tutorial would be useful in the discussion to better understand the range of privacy related threats and some of the terminology. Since we (IAB Privacy Program) had planned to re-run the tutorial for a wider audience that might actually be useful preparation. What do you think? Ciao Hannes On 10.09.2013 21:03, Scott Brim wrote: > On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre wrote: >> We'll want to use the high-bandwidth time wisely, and we know that >> security-related discussions (well, all discussions) can easily go off >> track. Staying focused on the core issues, and on problems that might >> have engineering solutions, will be paramount. > > This is a scope question. How do we decide what to focus on? I > suggest that we start by saying it's not security, and it's not > surveillance, it's privacy, i.e. the ability to control the flow of > one's personal information (there's your definition, Dave). Security > is too large a scope, while surveillance is too small. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From tytso@thunk.org Tue Sep 10 11:56:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178E321F9675 for ; Tue, 10 Sep 2013 11:56:01 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-i8aGAgD5wi for ; Tue, 10 Sep 2013 11:55:52 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id 82E6621F92B8 for ; Tue, 10 Sep 2013 11:55:46 -0700 (PDT) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1VJT6H-0005zm-D1; Tue, 10 Sep 2013 18:55:45 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id B042E580876; Tue, 10 Sep 2013 14:55:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1378839344; bh=Q5y6Nil9iMxv7+8g76nXBWk8JA1nZxljz0ydJIAk/WQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BQmzqT99UFWiOSqdS8lqWuE3xu7WUVZrP0QRkAbHE9rgPuZKGtVViMYORiT9TAQc2 6LYTRbv+Kl/s3xaV7wbjQHFeL4nwnE7yHyiRTaX7g5yOACzQumGf/G49ZwgR3X4IEu AsHHxT0HIJEk5tNFPkiKv/57EsHiu0TcRbxWKYWA= Date: Tue, 10 Sep 2013 14:55:44 -0400 From: Theodore Ts'o To: Hannes Tschofenig Message-ID: <20130910185544.GF29237@thunk.org> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <522F685B.8040106@gmx.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: perpass@ietf.org, Dean Willis Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:56:13 -0000 On Tue, Sep 10, 2013 at 09:43:39PM +0300, Hannes Tschofenig wrote: > > > 1) Everything SHOULD be encrypted, unless there is an absolute > operational requirement not to. This means "encryption by default" > in new protocols, and not even specifying unencrypted operations > modes unless necessary.... > > I guess there are two issues here, namely: > > * End-to-end vs. Hop-by-hop (or stuff in between) > > * Encryption itself is often not the problem but rather the key management Also, perfect forward secrecy (PFS) versus non-PFS. If we are going to make encryption a SHOULD or a MUST, so should be PFS. Even if the key management is a problem, or worse, let's suppose the NSA has the private keys for a number of the major CA's, if everything is using PFS, then an attacker who is interested in doing bulk surveillance will have to MITM all of the traffic. That will take a large amount of power and cooling, so it becomes a lot more expensive to do bulk surveillance, and it will also be much, MUCH harder to do it covertly (you can't just hide a box in a telephone closet somewhere; but rather racks and racks of servers at Tier 1 NAP's will be required). OF course, there will be some things where encryption is simply not needed, and but data integrity is is needed. Example: time (NTP) and routing protocols. So we need to be careful how we specify MUST. :-) - Ted From scott.brim@gmail.com Tue Sep 10 12:00:09 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE1F21E8166 for ; Tue, 10 Sep 2013 11:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j54uhB3SKGrM for ; Tue, 10 Sep 2013 11:59:33 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6783D11E80EE for ; Tue, 10 Sep 2013 11:59:11 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id eh20so7632832obb.15 for ; Tue, 10 Sep 2013 11:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2nS6eWjTjOa6mHp98D4a7p9WZMh0OsgaTktRqc8z1Sw=; b=tL2iIf7+x82u5Cwd0gfMLmIXXoPE6dlidbtXwaurGHbFqyl5ax1WsLJT3F+drgLtNF +z59AWHXGMFhuWmwMAaJFXY5bP1Peu3Il38sVEPhYAXDid4kcD45omWKqlL5GheQhjXW 5JMoARJJnWXt0eCA5XyQo/fmYA8Er4ng+Ie3/t3sxivOpa9blY3jmB+IZXB1EV2tq50X NLKe1L1VP0qZr3MQsDcZFbYHxlfQ8CxJ9tppZIoTreDQ64jU0I6BUPrBcwIJt+n+OofK CbC03iznLLGnxiwkUSTgy4/P0/NzIKIUVI6ugqI0JmQfznNW0UtNSaCS/+LqYJ9A6/y9 85Og== X-Received: by 10.182.158.42 with SMTP id wr10mr2103071obb.92.1378839546348; Tue, 10 Sep 2013 11:59:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.134 with HTTP; Tue, 10 Sep 2013 11:58:46 -0700 (PDT) In-Reply-To: <522F6994.1020307@gmx.net> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F6994.1020307@gmx.net> From: Scott Brim Date: Tue, 10 Sep 2013 14:58:46 -0400 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:00:10 -0000 On Tue, Sep 10, 2013 at 2:48 PM, Hannes Tschofenig wrote: > Hi Scott, > > as you know we have been working on this privacy tutorial (and you have > given feedback on the trial run). Maybe some information from the privacy > tutorial would be useful in the discussion to better understand the range of > privacy related threats and some of the terminology. > > Since we (IAB Privacy Program) had planned to re-run the tutorial for a > wider audience that might actually be useful preparation. > > What do you think? Yes, that would be great as a foundation for the privacy discussion. You should add material about surveillance. If you're willing, I suggest you "flip" it as in flipping education: when you think the deck is ready, send it out, have a bit of discussion in lieu of presentation, and then have a real discussion of it at the BOF. You would be revealing it earlier than planned but not too much earlier. I think everyone would win. From scott.brim@gmail.com Tue Sep 10 12:01:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF1221E8185 for ; Tue, 10 Sep 2013 12:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHvNlUE6o2-w for ; Tue, 10 Sep 2013 12:01:46 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC121F95DC for ; Tue, 10 Sep 2013 12:01:20 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id j10so8366699oah.13 for ; Tue, 10 Sep 2013 12:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9zv5Tg9JEtAtFnADbcyajTsXw4bGAYuVVUnqMId5YDI=; b=aQufxRqEkzTr48PH1VBmpTy6O0/wc0wdOIfBAugQ5EUpKEY6iE1CXHoaAJBL9d+otw 07QY6jH4JzwCPEbJHUzlBT/CbrUpN/hvmTk/rJQmkmF1g2Vg1JO+d5JSMWwsLmumTCsI r2G0Iscu2kA4YJE89hJ46kXQiuOOhFOyMMuctcVz95Iy0Fl0plzA38qujPPx4/RjwQms mtPGKiwsFO5EKpu8NgvN8hTSVWk1I/bLWz+1+2YBviIuwnPcIYIob65xOXHCYMRt5TmB w/WlkBPK2RTUhaPr8waiPN/n+KgQU7nXMnwjkdd7lp9AXXErtopH0aogddCUsN6uklIU a0Yw== X-Received: by 10.182.158.42 with SMTP id wr10mr2111688obb.92.1378839674103; Tue, 10 Sep 2013 12:01:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.134 with HTTP; Tue, 10 Sep 2013 12:00:54 -0700 (PDT) In-Reply-To: <522F691E.3010101@gmx.net> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F6637.2080700@dcrocker.net> <522F691E.3010101@gmx.net> From: Scott Brim Date: Tue, 10 Sep 2013 15:00:54 -0400 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Dave Crocker , Crocker Dave , Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:01:47 -0000 On Tue, Sep 10, 2013 at 2:46 PM, Hannes Tschofenig wrote: > One approach to focus the discussion is to limit it to what the IETF can do. Sounds good. > Within that category one could also focus on specific applications to make > it (a) down-to-earth and (b) have a bit time for preparation. Want to start with the drafts recently discussed here? From hannes.tschofenig@gmx.net Tue Sep 10 12:03:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E4711E8127 for ; Tue, 10 Sep 2013 12:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm9XQLMo6kOd for ; Tue, 10 Sep 2013 12:03:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id ADBBF11E81CC for ; Tue, 10 Sep 2013 12:03:16 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M4o41-1WBAIc1u05-00ywKu for ; Tue, 10 Sep 2013 21:03:11 +0200 Message-ID: <522F6CE1.8070605@gmx.net> Date: Tue, 10 Sep 2013 22:02:57 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: perpass Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:yGxbhaXvRaGZ9GBy+yRLGumFiSACZwRNVhT48WFDVggCgP/yFfU UBQCpctARwhWMgFJ3b8IIB81PwEG4PHVuAOXT/fdANVTh/CMPRXqetxJewjaJQlEE7QMd7n YfxSV+f+Z9sxSOeMrTzy3sF2lxMAhrwO8Ki5YC/PbK2WUuc6iZRM/4Bf3O5Yzspj9ybFSVQ K98tJ8vzaQcLlga1R4wOg== Cc: hannes.tschofenig@gmx.net Subject: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:03:44 -0000 Hi all, as I replied to Dave about the scope of the discussions at the next IETF meeting I was wondering about the following issue. Bruce Schneier asked the IETF for help and, as we have noticed in the discussions there are certain limits to what we can do in the IETF (as a standardization body). The wider Internet community, however, has somewhat different options and we have in other cases reached out to that community to impact the deployment of Internet technologies. A recent example is the IPv6 day. Why should we turn around and ask the Internet community to help us out with some of the issues we cannot solve alone, such as those related to the deployment of various security extensions. I am sure many open source developers are at this moment trying to figure out what they should be improving but they may not have the same level of expertise as we have. Needless to say that we first have to figure out what we want to ask for and this requires some investigation in what is currently available (like Yaron did for S/MIME and Jim Gettys did for his DNSSEC case). What do you think? Ciao Hannes From marc.blanchet@viagenie.ca Tue Sep 10 12:13:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2710F11E81D6 for ; Tue, 10 Sep 2013 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.99 X-Spam-Level: X-Spam-Status: No, score=-101.99 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbDfB5W7eCaC for ; Tue, 10 Sep 2013 12:13:26 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 35E4311E81B0 for ; Tue, 10 Sep 2013 12:13:26 -0700 (PDT) Received: from [IPv6:2620:0:230:2002::1001] (unknown [IPv6:2620:0:230:2002::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 04F9046FC3; Tue, 10 Sep 2013 15:13:24 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Marc Blanchet In-Reply-To: <522F6CE1.8070605@gmx.net> Date: Tue, 10 Sep 2013 15:13:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> References: <522F6CE1.8070605@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Cc: perpass Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:13:27 -0000 my take on this debate is that there is much more to do _not in the = protocols specifications_ than enhancing what our protocol specs. = Deployment, implementations, etc... shall be more targetted to be = enhanced. Therefore I agree with your idea. And opensource is just one = market. Marc. Le 2013-09-10 =E0 15:02, Hannes Tschofenig a = =E9crit : > Hi all, >=20 > as I replied to Dave about the scope of the discussions at the next = IETF meeting I was wondering about the following issue. >=20 > Bruce Schneier asked the IETF for help and, as we have noticed in the = discussions there are certain limits to what we can do in the IETF (as a = standardization body). >=20 > The wider Internet community, however, has somewhat different options = and we have in other cases reached out to that community to impact the = deployment of Internet technologies. A recent example is the IPv6 day. >=20 > Why should we turn around and ask the Internet community to help us = out with some of the issues we cannot solve alone, such as those related = to the deployment of various security extensions. >=20 > I am sure many open source developers are at this moment trying to = figure out what they should be improving but they may not have the same = level of expertise as we have. >=20 > Needless to say that we first have to figure out what we want to ask = for and this requires some investigation in what is currently available = (like Yaron did for S/MIME and Jim Gettys did for his DNSSEC case). >=20 > What do you think? >=20 > Ciao > Hannes > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From hannes.tschofenig@gmx.net Tue Sep 10 12:27:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6F321F9DDB for ; Tue, 10 Sep 2013 12:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI38F94HWmNC for ; Tue, 10 Sep 2013 12:27:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9A521F99BF for ; Tue, 10 Sep 2013 12:27:39 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lxxrw-1W4nJq1SAW-015G0d for ; Tue, 10 Sep 2013 21:27:34 +0200 Message-ID: <522F729A.4050102@gmx.net> Date: Tue, 10 Sep 2013 22:27:22 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Scott Brim References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F6637.2080700@dcrocker.net> <522F691E.3010101@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:BS8j/vFfykN/NEv3TY/sOxDHWHCUkGWavGQbgG/KiBTVBgaoNOt sA6xX6pN1lSIw0w+BKXrbkNdJUKnEppTTbpk+ECfL8tUqkBkyT3vJxkQNU8aD8ojGzmt8pJ PYuvyNBqcH3JfAv+b/I4wedDG0CYqz6qw3r+0SntXLBKfpXBfxHAbZ0HyKPeo/M9qIxsCE4 FMCP5+/q6We8i1oD1lepg== Cc: Dave Crocker , perpass , Crocker Dave , Peter Saint-Andre , Hannes Tschofenig , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:27:45 -0000 On 10.09.2013 22:00, Scott Brim wrote: > On Tue, Sep 10, 2013 at 2:46 PM, Hannes Tschofenig > wrote: >> One approach to focus the discussion is to limit it to what the IETF can do. > > Sounds good. > >> Within that category one could also focus on specific applications to make >> it (a) down-to-earth and (b) have a bit time for preparation. > > Want to start with the drafts recently discussed here? Do you think that the drafts need some face-to-face discussion time? We should be able to finalize them before the IETF meeting. draft-sheffer-tls-bcp-00.txt lists well-known attacks and makes reasonable suggestions. Of course there is always room for improvement in the write-up. draft-trammell-perpass-ppa-00.txt introduces the terminology for a new adversary model and that looks good to me. draft-saintandre-xmpp-tls-00.txt is a bit related to Yaron's document but also makes sense. Maybe there is room for alignment with draft-sheffer-tls-bcp-00.txt. I personally believe that the difficult aspects are elsewhere, namely * mandating an secure protocol design only (e.g. HTTP 2.0 with TLS-on always) * choice of trust models (think about ZRTP vs. DTLS-SRTP; PGP vs. S/MIME) * limiting ourselves to fewer choices (unlike in the SIP world where we have documents like http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-13) * avoiding standardization of security solutions that are designed to support lawful intercept. Ciao Hannes From hannes.tschofenig@gmx.net Tue Sep 10 12:31:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B674D21E80A9 for ; Tue, 10 Sep 2013 12:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAP3nc4zaNDe for ; Tue, 10 Sep 2013 12:31:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id A7F5321F9A40 for ; Tue, 10 Sep 2013 12:31:08 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MSutp-1VQnkg3QbV-00RmG3 for ; Tue, 10 Sep 2013 21:31:04 +0200 Message-ID: <522F736C.5060701@gmx.net> Date: Tue, 10 Sep 2013 22:30:52 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Marc Blanchet References: <522F6CE1.8070605@gmx.net> <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> In-Reply-To: <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:1uSzO30PbGrPdNeQdwJWpht20mtUNAFdy4BZs1hfTR1BmHgzTGl XWSdjUPrZYEG2Q3H5Wn1ZZsj4i2W2b9DjFyJkENRiXdGnH6TJOBtK2k9dFAwDQNYTC6p7yO dOEbeN3bc+ScIvO+FpzevXxcShFDFU71dgYCWZ3skb0uNPK0fbl7LseD96NWWBS8F3VJk+q jhjWJj6k4F62GLanUYHCg== Cc: perpass , Hannes Tschofenig Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:31:14 -0000 Open source is certainly only one market, although important in the security context when I think about all the libraries. Needless to say that many products are not open source and we would want to encourage them to get better as well (as we did with the IPv6 day). Maybe we need a "Crypto Day". On 10.09.2013 22:13, Marc Blanchet wrote: > my take on this debate is that there is much more to do _not in the protocols specifications_ than enhancing what our protocol specs. Deployment, implementations, etc... shall be more targetted to be enhanced. Therefore I agree with your idea. And opensource is just one market. > > Marc. > > Le 2013-09-10 à 15:02, Hannes Tschofenig a écrit : > >> Hi all, >> >> as I replied to Dave about the scope of the discussions at the next IETF meeting I was wondering about the following issue. >> >> Bruce Schneier asked the IETF for help and, as we have noticed in the discussions there are certain limits to what we can do in the IETF (as a standardization body). >> >> The wider Internet community, however, has somewhat different options and we have in other cases reached out to that community to impact the deployment of Internet technologies. A recent example is the IPv6 day. >> >> Why should we turn around and ask the Internet community to help us out with some of the issues we cannot solve alone, such as those related to the deployment of various security extensions. >> >> I am sure many open source developers are at this moment trying to figure out what they should be improving but they may not have the same level of expertise as we have. >> >> Needless to say that we first have to figure out what we want to ask for and this requires some investigation in what is currently available (like Yaron did for S/MIME and Jim Gettys did for his DNSSEC case). >> >> What do you think? >> >> Ciao >> Hannes >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From hallam@gmail.com Tue Sep 10 12:37:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03DC21E80A9 for ; Tue, 10 Sep 2013 12:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd4LVIcqbXID for ; Tue, 10 Sep 2013 12:37:05 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8C41621F90CC for ; Tue, 10 Sep 2013 12:37:05 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ep20so6653705lab.16 for ; Tue, 10 Sep 2013 12:37:04 -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; bh=TvBplF5ANTllmOkIwPuoDZrHMjvfVUs1M9QHlZXNb/M=; b=Z1HzpW8k358sXAZRuw2tPbFcDp/L8Ujk7cMxD7fd6otDc9pT5A9vKnztT5q1rW9eEj beYRUVdNTWyRAHPeAOxpY30W4WlJm6UbmMbRnv3QS1pqtatIUUkm4tGsL83L/1HHVaky 0ATDfPghK0oKrXGUM2mgom777PpfzcaT5LqDgU1mACV4dwfm8HAUAw2DMIjcvMSg+R8Q piXzoZybpOOWDUvv/raM9tT/VK8IORBl9v/3HWp9632vuGxZsi32xsYJGocY4uGbHd2t rjwBl9Z/HaY4rnrWDu/L1r7nPz/5fa25M8cDCaahf2rZv3F0LQLx8qU4o/plAlAn5Ntk Lpug== MIME-Version: 1.0 X-Received: by 10.152.37.103 with SMTP id x7mr7910483laj.28.1378841824286; Tue, 10 Sep 2013 12:37:04 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Tue, 10 Sep 2013 12:37:04 -0700 (PDT) In-Reply-To: <522F736C.5060701@gmx.net> References: <522F6CE1.8070605@gmx.net> <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> <522F736C.5060701@gmx.net> Date: Tue, 10 Sep 2013 15:37:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e0160b5e423732d04e60ca1bb Cc: Marc Blanchet , perpass Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:37:06 -0000 --089e0160b5e423732d04e60ca1bb Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 10, 2013 at 3:30 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Open source is certainly only one market, although important in the > security context when I think about all the libraries. > > Needless to say that many products are not open source and we would want > to encourage them to get better as well (as we did with the IPv6 day). > > Maybe we need a "Crypto Day". My proposal is to turn 'PRISM-Proof' into a marketing seal for products and services that can demonstrate that they are free from intercept capabilities. -- Website: http://hallambaker.com/ --089e0160b5e423732d04e60ca1bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 10, 2013 at 3:30 PM, Hannes Tschofenig <hannes= .tschofenig@gmx.net> wrote:
Open source is certainly only one market, al= though important in the security context when I think about all the librari= es.

Needless to say that many products are not open source and we would want to= encourage them to get better as well (as we did with the IPv6 day).

Maybe we need a "Crypto Day".

My proposal is to turn 'PRISM-Proof' into a marketing seal fo= r products and services that can demonstrate that they are free from interc= ept capabilities.


--
Website: http://hallambaker.com/
--089e0160b5e423732d04e60ca1bb-- From mark@townsley.net Tue Sep 10 12:42:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1821E8183 for ; Tue, 10 Sep 2013 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUr6EGM8t6XR for ; Tue, 10 Sep 2013 12:41:59 -0700 (PDT) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7C421E817E for ; Tue, 10 Sep 2013 12:41:59 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id b10so4056721eae.24 for ; Tue, 10 Sep 2013 12:41:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IHHgoNSPGoXGmp830SjM5j9UwuQH6vVETODMtHENQ6Q=; b=QifExtg2G4OJAO33vGkFMvyH66h5y4qUa/g5lXPx32qHxf3Xsu1K0LkWWUshVl4Rbi uaOOSPgfJp0LE7+7crldQUKtg2GuS+PSAMcJF0U883l5fyvxEYWHGFr/kr3G6UA1Zoid 47vp+77NT7cjdAkiEfVGxOOC0bbuiGsZUmjNC5t5Hq+pHz4kgsHXySQlQDDDE0YJLl7c MDAInb1EFPpOxwlie1gWAXuK8Dxxkg0RNQCLFcgQXYPnhmQgcLrJNEus2fx6TVIIjROQ qBTrGV5ixE0Rfdr+6hzfRFv7ju0/q7WFeQdP2fui+p7MKVYgoSAqNeAS210Qs0L7z9Z1 +wug== X-Gm-Message-State: ALoCoQkQRBrhPPE6gNgr7/N4co4yAlRcjgFh9AwzdRyyCcXioQvbwrDFmGoHrgEbdU90qEf+pfno X-Received: by 10.14.246.11 with SMTP id p11mr41595756eer.9.1378842117744; Tue, 10 Sep 2013 12:41:57 -0700 (PDT) Received: from ams-townsley-8913.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id n48sm33977552eeg.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 12:41:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <522F736C.5060701@gmx.net> Date: Tue, 10 Sep 2013 21:41:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16594CD0-7341-4044-AF84-09ED5C06FF74@townsley.net> References: <522F6CE1.8070605@gmx.net> <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> <522F736C.5060701@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1283) Cc: Marc Blanchet , perpass Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 19:42:04 -0000 Critical aspects of the World IPv6 Day/Launch activity were clear goals = as to what it meant to be "in", as well as independent measurement of = those that signed up (at first AAAAs in the DNS, later 1% traffic from = an ISP as measured by a set of content providers). The nature of what's = being considered here might make this tricky (e.g., monitoring of = techniques that themselves are aimed at averting the ability to = monitor!). In any case, if we try and do something like this and want to = follow the World Day/Launch model, I'd encourage thinking about what the = metrics and analysis should be. - Mark PS. As someone working to see IPv6 deployed, increased use of SSL is a = boost as https leads to more global IPv4 address demand and more need = for IPv6. Go crypto. On Sep 10, 2013, at 9:30 PM, Hannes Tschofenig wrote: > Open source is certainly only one market, although important in the = security context when I think about all the libraries. >=20 > Needless to say that many products are not open source and we would = want to encourage them to get better as well (as we did with the IPv6 = day). >=20 > Maybe we need a "Crypto Day". >=20 >=20 > On 10.09.2013 22:13, Marc Blanchet wrote: >> my take on this debate is that there is much more to do _not in the = protocols specifications_ than enhancing what our protocol specs. = Deployment, implementations, etc... shall be more targetted to be = enhanced. Therefore I agree with your idea. And opensource is just one = market. >>=20 >> Marc. >>=20 >> Le 2013-09-10 =E0 15:02, Hannes Tschofenig = a =E9crit : >>=20 >>> Hi all, >>>=20 >>> as I replied to Dave about the scope of the discussions at the next = IETF meeting I was wondering about the following issue. >>>=20 >>> Bruce Schneier asked the IETF for help and, as we have noticed in = the discussions there are certain limits to what we can do in the IETF = (as a standardization body). >>>=20 >>> The wider Internet community, however, has somewhat different = options and we have in other cases reached out to that community to = impact the deployment of Internet technologies. A recent example is the = IPv6 day. >>>=20 >>> Why should we turn around and ask the Internet community to help us = out with some of the issues we cannot solve alone, such as those related = to the deployment of various security extensions. >>>=20 >>> I am sure many open source developers are at this moment trying to = figure out what they should be improving but they may not have the same = level of expertise as we have. >>>=20 >>> Needless to say that we first have to figure out what we want to ask = for and this requires some investigation in what is currently available = (like Yaron did for S/MIME and Jim Gettys did for his DNSSEC case). >>>=20 >>> What do you think? >>>=20 >>> Ciao >>> Hannes >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From hannes.tschofenig@gmx.net Tue Sep 10 13:01:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1C711E8115 for ; Tue, 10 Sep 2013 13:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vz1RMYZpOi4h for ; Tue, 10 Sep 2013 13:01:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 407F521F8C11 for ; Tue, 10 Sep 2013 13:01:03 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MGzwE-1VETu51E02-00Ds7y for ; Tue, 10 Sep 2013 22:00:27 +0200 Message-ID: <522F7A4F.2080300@gmx.net> Date: Tue, 10 Sep 2013 23:00:15 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mark Townsley References: <522F6CE1.8070605@gmx.net> <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> <522F736C.5060701@gmx.net> <16594CD0-7341-4044-AF84-09ED5C06FF74@townsley.net> In-Reply-To: <16594CD0-7341-4044-AF84-09ED5C06FF74@townsley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:0AbOPNA8S+6za+iwptPTEJWw9gLGRcA7sfxKKQ05IpIFaxqCm7d 9bJ2pX3eZ+IjeLHcwKMTUJWGCG4PmZaqkMwCFdER4BOdnyX5ja1m4AXWqHQvI/xtdWAbfUE ykNrquZe8qpmtaB1DeoSrP9nTzanT22ulMoFFaKeHxK5GFAdwoYWaYR8rzgDyS3rTtV1nCL gWWvkVEPG0WY42Em5jxBg== Cc: Marc Blanchet , perpass , Hannes Tschofenig Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:01:30 -0000 Hi Mark, you are certainly right on the clear goals and metrics. Just as one example consider a topic like "HTTPS everywhere". We had this IAB technical plenary about Web Security not too long ago (IETF#83) and Ekr gave a talk with the title "How do we get to TLS Everywhere?". On slide 5 of his talk (see http://www.ietf.org/proceedings/83/slides/slides-83-iab-9-technical-plenary.pdf) he quotes Cullen. Even with such a topic there would already be enough work (such as guidelines for how to get certificates, how to configure various Web servers and use different hosting providers), etc. The good thing about such a topic is that we are not the first group to look at it. There is also EFF and others. There the goal could be to get from the current 1% TLS usage to something like 10% in 3 years (or so). Measuring the TLS usage is also easier (as a number of projects, like EFF with their SSL Observatory demonstrated). Is that would you roughly had in mind (of course with much more detail)? Ciao Hannes On 10.09.2013 22:41, Mark Townsley wrote: > > Critical aspects of the World IPv6 Day/Launch activity were clear > goals as to what it meant to be "in", as well as independent > measurement of those that signed up (at first AAAAs in the DNS, later > 1% traffic from an ISP as measured by a set of content providers). > The nature of what's being considered here might make this tricky > (e.g., monitoring of techniques that themselves are aimed at averting > the ability to monitor!). In any case, if we try and do something > like this and want to follow the World Day/Launch model, I'd > encourage thinking about what the metrics and analysis should be. > > - Mark > > PS. As someone working to see IPv6 deployed, increased use of SSL is > a boost as https leads to more global IPv4 address demand and more > need for IPv6. Go crypto. > > > On Sep 10, 2013, at 9:30 PM, Hannes Tschofenig wrote: > >> Open source is certainly only one market, although important in the >> security context when I think about all the libraries. >> >> Needless to say that many products are not open source and we would >> want to encourage them to get better as well (as we did with the >> IPv6 day). >> >> Maybe we need a "Crypto Day". >> >> >> On 10.09.2013 22:13, Marc Blanchet wrote: >>> my take on this debate is that there is much more to do _not in >>> the protocols specifications_ than enhancing what our protocol >>> specs. Deployment, implementations, etc... shall be more >>> targetted to be enhanced. Therefore I agree with your idea. And >>> opensource is just one market. >>> >>> Marc. >>> >>> Le 2013-09-10 à 15:02, Hannes >>> Tschofenig a écrit : >>> >>>> Hi all, >>>> >>>> as I replied to Dave about the scope of the discussions at the >>>> next IETF meeting I was wondering about the following issue. >>>> >>>> Bruce Schneier asked the IETF for help and, as we have noticed >>>> in the discussions there are certain limits to what we can do >>>> in the IETF (as a standardization body). >>>> >>>> The wider Internet community, however, has somewhat different >>>> options and we have in other cases reached out to that >>>> community to impact the deployment of Internet technologies. A >>>> recent example is the IPv6 day. >>>> >>>> Why should we turn around and ask the Internet community to >>>> help us out with some of the issues we cannot solve alone, such >>>> as those related to the deployment of various security >>>> extensions. >>>> >>>> I am sure many open source developers are at this moment trying >>>> to figure out what they should be improving but they may not >>>> have the same level of expertise as we have. >>>> >>>> Needless to say that we first have to figure out what we want >>>> to ask for and this requires some investigation in what is >>>> currently available (like Yaron did for S/MIME and Jim Gettys >>>> did for his DNSSEC case). >>>> >>>> What do you think? >>>> >>>> Ciao Hannes _______________________________________________ >>>> perpass mailing list perpass@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perpass >>> >>> _______________________________________________ perpass mailing >>> list perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >> >> _______________________________________________ perpass mailing >> list perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ perpass mailing list > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass From hannes.tschofenig@gmx.net Tue Sep 10 13:02:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA2B21F9974 for ; Tue, 10 Sep 2013 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCdK2JrUR8i1 for ; Tue, 10 Sep 2013 13:02:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id F343621F8E85 for ; Tue, 10 Sep 2013 13:02:08 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mecqq-1VdBo602Ho-00OJut for ; Tue, 10 Sep 2013 22:02:06 +0200 Message-ID: <522F7AB1.9050306@gmx.net> Date: Tue, 10 Sep 2013 23:01:53 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <522F6CE1.8070605@gmx.net> <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> <522F736C.5060701@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DlgGCGfMlps60wVAndB2+RX5gPZ904CMDZQkBvE3bVt9tjztt7+ rGOI6Yff9DOTSXjci0AEJ6S6C5WV4pifI9w7my3/JO7R5XRVb4wLQ8WiuzylTtB/phjFKMz CruMgDYA6SX4GR1ERxF8lALfAwy4+P5tWUne+TISRNooAcIjneLQewxWlU3hdfFDMvsMmXt l8rftAE2XuBL6d9zupXTw== Cc: Marc Blanchet , perpass , Hannes Tschofenig Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:02:14 -0000 On 10.09.2013 22:37, Phillip Hallam-Baker wrote: > > > > On Tue, Sep 10, 2013 at 3:30 PM, Hannes Tschofenig > > wrote: > > Open source is certainly only one market, although important in the > security context when I think about all the libraries. > > Needless to say that many products are not open source and we would > want to encourage them to get better as well (as we did with the > IPv6 day). > > Maybe we need a "Crypto Day". > > > My proposal is to turn 'PRISM-Proof' into a marketing seal for products > and services that can demonstrate that they are free from intercept > capabilities. I have no expertise with designing seals. What specifically would that mean? Would a Webpage or a smart phone app show such a seal? Who would verify it? Would there be some assessment? If so, by whom? Who would pay for it? Ciao Hannes > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From ross.snider@gmail.com Tue Sep 10 14:42:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F9121F9A4A for ; Tue, 10 Sep 2013 14:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHVfY0SvNCsy for ; Tue, 10 Sep 2013 14:42:10 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 48E5921F90C3 for ; Tue, 10 Sep 2013 14:42:10 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id cb5so1342556wib.3 for ; Tue, 10 Sep 2013 14:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=L+OANRrQibFZKG1TA+cLNaGp7sT6NZPZDAkn3YCrTKk=; b=TMWfYe2bMZympiWuPb+5uWss2lYtjMU5UGtrFnjdBZirumJrToJB+BDHUKcg8sZMMI ++UuGr4FV7lDR8LD3M6Yng9uoLBMZk7qpk8KTo7dTaKIVlc64ZRoE9Mp6MoIv6JGDOsI EoaVhcelYMzeBIHJ/EqLaZSQ27M9plcEFF9hNemsb1SVPJUuSLn8OjBCrntF3WY0p0je etnGDaKGb4EqCdghw1TsxwvMrLi1w6D17nPFZFfO6soyqzZEnOhOkrP7XmAuCSfLnPcW Lkm7Z5jnED9kdP6nM9MWMnOrMQXq+Gg7lV/Nz4qJ9aumzA+ctwl7ie0KqR2EZ3bbbyyR ALzg== X-Received: by 10.180.198.79 with SMTP id ja15mr14638976wic.36.1378849329365; Tue, 10 Sep 2013 14:42:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.119.6 with HTTP; Tue, 10 Sep 2013 14:41:39 -0700 (PDT) From: Ross Snider Date: Tue, 10 Sep 2013 14:41:39 -0700 Message-ID: To: perpass@ietf.org Content-Type: multipart/alternative; boundary=047d7b62425279ca5204e60e608a Subject: [perpass] Creating confidence in endpoints with protocols. X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 21:54:02 -0000 --047d7b62425279ca5204e60e608a Content-Type: text/plain; charset=ISO-8859-1 Apologies in advance for the length of the proposal. There is no TL;DR. Request for comment. A large issue with widespread surveillance is that we are unable to trust even endpoints with some data, no matter the security of the container for that data in transit between clients, as endpoints may be pressured financially or politically into cooperation or may be compromised. Many stakeholders have called for the effort to involve not only engineering but some amount of legal and policy reform. It may at first seem unfortunate that all we have influence over are protocol standards. More hopeless still is to realize that passing the right policies and laws in North America won't fix our problem as agencies and companies under the jurisdiction of the United States are not the only players in the surveillance game, nor will they be in the future. Furthermore there will likely be escape clauses around policies and laws, especially where there may be international cooperation between countries with unique mandates. I'd like to bring up the fact that there *are* some things we can do to limit the damage that untrusted endpoints can do from a protocol perspective (far above and beyond authorization/authentication). Secure Multiparty Communication is now, and has been, a feasible technology - it's merely lacked a standardized protocol. I argue that its lack of adoption so far is due to said lack of a standard. With SMC, parties can interact to solve problems like: - Personalized advertisements without the advertising company getting raw access to preferences, browsing history or target demographics. - Search or database results without the service provider obtaining unencrypted access to the query. - Determine the winner of auction without revealing what price was paid (or compute a fair price of an auction market whilst keeping financial information of participants secure, as was done with sugar beets by the Danish) - Look up sex predators in an area without revealing an address. - Transfer money from a customer to a merchant without revealing the customer's credit card number to the merchant or the merchant's business ID to the customer. That is to say with SMC there can be a finer gauged level of control over what data gets shared with what endpoints. It is a way to engage in cooperative computation without giving up permanent control of personal data. Furthermore there are many protocols to consider that have been vetted by academics and peer review, some of which are *unconditionally* secure so that there is no need to worry at the possibility of cryptographic backdoors. Nothing comes for free: there is communication and computation overhead that is induced by participating in such a protocol. Thankfully the constants and communication rates involved in modern SMC are small enough to make many applications practical. We argue that now is the time to consider creating a standard for SMC, as underlying cryptographic gadgets will only become more efficient after standardization and because it's applications have become significantly more important. Soliciting feedback. Best, Ross Snider --047d7b62425279ca5204e60e608a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Apologies in advance for the length of the proposal. There= is no TL;DR. Request for comment.

A large issue with widespread sur= veillance is that we are unable to trust even endpoints with some data, no = matter the security of the container for that data in transit between clien= ts, as endpoints may be pressured financially or politically into cooperati= on or may be compromised. Many stakeholders have called for the effort to i= nvolve not only engineering but some amount of legal and policy reform.

It may at first seem unfortunate that all we have influence over are pr= otocol standards. More hopeless still is to realize that passing the right = policies and laws in North America won't fix our problem as agencies an= d companies under the jurisdiction of the United States are not the only pl= ayers in the surveillance game, nor will they be in the future.=A0Furthermo= re there will likely be escape clauses around policies and laws, especially= where there may be international cooperation between countries with unique= mandates.

I'd like to bring up the fact that there are= some things we can do to limit the damage that untrusted endpoints can do = from a protocol perspective (far above and beyond authorization/authenticat= ion).

Secure Multiparty Communication is now, and has been, a= feasible technology - it's merely lacked a standardized protocol. I ar= gue that its lack of adoption so far is due to said lack of a standard.

With SMC, parties can interact to solve problems like:<= br>- Personalized advertisements without the advertising company getting ra= w access to preferences, browsing history or target demographics.
- Search or database results without the service provider obtaining un= encrypted access to the query.
- Determine the winner of auction = without revealing what price was paid (or compute a fair price of an auctio= n market whilst keeping financial information of participants secure, as wa= s done with sugar beets by the Danish)
- Look up sex predators in an area without revealing an address.
=
- Transfer money from a customer to a merchant without revealing the c= ustomer's credit card number to the merchant or the merchant's busi= ness ID to the customer.

That is to say with SMC there can be a finer gauged lev= el of control over what data gets shared with what endpoints. It is a way t= o engage in cooperative computation without giving up permanent control of = personal data.

Furthermore there are many protocols to consider that h= ave been vetted by academics and peer review, some of which are uncondit= ionally secure so that there is no need to worry at the possibility of = cryptographic backdoors.

Nothing comes for free: there is communication and computati= on overhead that is induced by participating in such a protocol. Thankfully= the constants and communication rates involved in modern SMC are small eno= ugh to make many applications practical.

We argue that now is the time to consider creating a st= andard for SMC, as underlying cryptographic gadgets will only become more e= fficient after standardization and because it's applications have becom= e significantly more important.

Soliciting feedback.

Best,
Ross Snider
--047d7b62425279ca5204e60e608a-- From stephen.farrell@cs.tcd.ie Tue Sep 10 14:55:32 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3B611E81DB for ; Tue, 10 Sep 2013 14:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOoucS-xCqJV for ; Tue, 10 Sep 2013 14:55:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C7EA511E81CC for ; Tue, 10 Sep 2013 14:55:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EF31EBE4D for ; Tue, 10 Sep 2013 22:55:06 +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 ZN5edDYzsHJP for ; Tue, 10 Sep 2013 22:55:06 +0100 (IST) Received: from [10.87.48.10] (unknown [86.41.52.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 596F6BE4C for ; Tue, 10 Sep 2013 22:55:06 +0100 (IST) Message-ID: <522F9537.5070605@cs.tcd.ie> Date: Tue, 10 Sep 2013 22:55:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F6637.2080700@dcrocker.net> <522F691E.3010101@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 21:55:33 -0000 Good to see all the discussion. Keep it up! Couple of points: - I entirely agree that the BoF, other than scene setting (and the usual ranting which we'll keep to a minimum:-) needs to be focused on what the IETF can do. (Broader list discussion, e.g. about the open-source community, seems fine and who knows might lead to some concrete stuff we would like to talk about at the BoF.) - I think that "privacy" is too broad and not sufficiently focused as a topic for a BoF session. Much as I'd like to see more progress on corporate privacy-busting, I think this session will be better kept more focused on recent pervasive monitoring attacks and what we can do in the IETF to mitigate those attacks. - I agree with Dave that it'd be good to have a better idea of what other protocols/areas of the IETF might be affected and/or part of the answer. For example, the LISP WG list have an active discussion now about encrypting encapsulated packet content. That wasn't one that would have occurred to me but if the LISP folks are up for it then it seems like a fine addition to their protocol. I'd be keen to get more examples of IETF protocols where we could do stuff to counter pervasive monitoring. The protocols where we improve things btw don't need to have been part of current news stories - I don't think LISP has featured for example:-) So keep the discussion flowing and we'll organise more as we go. Ta, S. From trammell@tik.ee.ethz.ch Tue Sep 10 14:59:22 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1A311E811D for ; Tue, 10 Sep 2013 14:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fybF+3sYowl for ; Tue, 10 Sep 2013 14:59:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 830E521F99F4 for ; Tue, 10 Sep 2013 14:59:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 03FB5D930C; Tue, 10 Sep 2013 23:59:16 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2PDiFEuLkkTu; Tue, 10 Sep 2013 23:59:15 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A5167D9302; Tue, 10 Sep 2013 23:59:15 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_B7158173-E6C7-4EEB-86A4-F9B2BA40B8FA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: Date: Tue, 10 Sep 2013 23:59:13 +0200 Message-Id: <81B4D129-8BE6-4865-BCAB-6159C0633E3F@tik.ee.ethz.ch> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> To: Scott Brim X-Mailer: Apple Mail (2.1508) Cc: perpass , Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 21:59:22 -0000 --Apple-Mail=_B7158173-E6C7-4EEB-86A4-F9B2BA40B8FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 10, 2013, at 8:03 PM, Scott Brim wrote: > On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre = wrote: >> We'll want to use the high-bandwidth time wisely, and we know that >> security-related discussions (well, all discussions) can easily go = off >> track. Staying focused on the core issues, and on problems that might >> have engineering solutions, will be paramount. >=20 > This is a scope question. How do we decide what to focus on? I > suggest that we start by saying it's not security, and it's not > surveillance, it's privacy, i.e. the ability to control the flow of > one's personal information (there's your definition, Dave). Yep. > Security is too large a scope, Absolutely. > while surveillance is too small. A key difference between "privacy" and "privacy against pervasive = surveillance" is that most models of privacy (including that in 6973) = implicitly or explicitly assume that the attacker has a specific target = in mind, and that the object of the game is identifying that target; in = pervasive surveillance, this is not the case. This is indeed one of the = reasons it's above and beyond (targeted) lawful intercept in terms of = the threat it presents. Practically speaking, being uninteresting is no defense (not that it's = ever really a _good_ defense, "but I have nothing to hide" = notwithstanding). Nor is being indistinguishable, if k-anonymity merely = means you're lumped into a k-member group, such that that k-member group = has defining characteristics that themselves may prove to be = interesting.=20 So, "privacy", but with a focus on pervasive surveillance as the = specific threat. Best regards, Brian > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_B7158173-E6C7-4EEB-86A4-F9B2BA40B8FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSL5YxAAoJENt3nsOmbNJcKnwH/0l8ur4IHmePSBMOLT05T5+J bBVanBTXNPucfOWqNTLUB4v8fpDDtxaV67pZNjZMFtAK1+sEMxLldOFiZMDYarbZ afUU7ru1XKsYAF5p89p7vuQoRtyBBWPIkTpdQ/RBiOvz6FD9QwX8ldH1BQG1khl4 g/r7q0KpM1xtKQL/d+LBHIIw+w+f0t5kbQ1mbhCxM+AGzbjx0GlfNqG+Pqi14G7P 6d4wbZ07GbI9DmJ9NCBrIHz3BFnsIwLKdlHfOo1aaeU6aCWKfn1CyEUcd892BFqu 3ZxPEbvY2bkMtLzZeEkNMZcPmNK50im2J1NQJ3MkIX0o2nm1zJpFOcIYy7Q5xU4= =huqV -----END PGP SIGNATURE----- --Apple-Mail=_B7158173-E6C7-4EEB-86A4-F9B2BA40B8FA-- From stephen.farrell@cs.tcd.ie Tue Sep 10 15:10:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEA321E80B3 for ; Tue, 10 Sep 2013 15:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fBb8aNlnvhE for ; Tue, 10 Sep 2013 15:10:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E04D421E80A1 for ; Tue, 10 Sep 2013 15:10:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 00829BE4D; Tue, 10 Sep 2013 23:10:01 +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 GhAuxpiQ1vMB; Tue, 10 Sep 2013 23:10:00 +0100 (IST) Received: from [10.87.48.10] (unknown [86.41.52.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 90E57BE4C; Tue, 10 Sep 2013 23:10:00 +0100 (IST) Message-ID: <522F98B8.60704@cs.tcd.ie> Date: Tue, 10 Sep 2013 23:10:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ross Snider References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Creating confidence in endpoints with protocols. X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 22:10:08 -0000 Hiya, If that's approaching being computationally practical then I'd say write an I-D describing how it works and pursue it in the usual IETF style. If it works and gets adopted then I agree it could be useful. Cheers, S. On 09/10/2013 10:41 PM, Ross Snider wrote: > Apologies in advance for the length of the proposal. There is no TL;DR. > Request for comment. > > A large issue with widespread surveillance is that we are unable to trust > even endpoints with some data, no matter the security of the container for > that data in transit between clients, as endpoints may be pressured > financially or politically into cooperation or may be compromised. Many > stakeholders have called for the effort to involve not only engineering but > some amount of legal and policy reform. > > It may at first seem unfortunate that all we have influence over are > protocol standards. More hopeless still is to realize that passing the > right policies and laws in North America won't fix our problem as agencies > and companies under the jurisdiction of the United States are not the only > players in the surveillance game, nor will they be in the > future. Furthermore there will likely be escape clauses around policies and > laws, especially where there may be international cooperation between > countries with unique mandates. > > I'd like to bring up the fact that there *are* some things we can do to > limit the damage that untrusted endpoints can do from a protocol > perspective (far above and beyond authorization/authentication). > > Secure Multiparty Communication is now, and has been, a feasible technology > - it's merely lacked a standardized protocol. I argue that its lack of > adoption so far is due to said lack of a standard. > > With SMC, parties can interact to solve problems like: > - Personalized advertisements without the advertising company getting raw > access to preferences, browsing history or target demographics. > - Search or database results without the service provider obtaining > unencrypted access to the query. > - Determine the winner of auction without revealing what price was paid (or > compute a fair price of an auction market whilst keeping financial > information of participants secure, as was done with sugar beets by the > Danish) > - Look up sex predators in an area without revealing an address. > - Transfer money from a customer to a merchant without revealing the > customer's credit card number to the merchant or the merchant's business ID > to the customer. > > That is to say with SMC there can be a finer gauged level of control over > what data gets shared with what endpoints. It is a way to engage in > cooperative computation without giving up permanent control of personal > data. > > Furthermore there are many protocols to consider that have been vetted by > academics and peer review, some of which are *unconditionally* secure so > that there is no need to worry at the possibility of cryptographic > backdoors. > > Nothing comes for free: there is communication and computation overhead > that is induced by participating in such a protocol. Thankfully the > constants and communication rates involved in modern SMC are small enough > to make many applications practical. > > We argue that now is the time to consider creating a standard for SMC, as > underlying cryptographic gadgets will only become more efficient after > standardization and because it's applications have become significantly > more important. > > Soliciting feedback. > > Best, > Ross Snider > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Tue Sep 10 15:12:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C3411E815B for ; Tue, 10 Sep 2013 15:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzuyFaCTpEOQ for ; Tue, 10 Sep 2013 15:12:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F1E2B11E8128 for ; Tue, 10 Sep 2013 15:12:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24B96BE4D; Tue, 10 Sep 2013 23:12:25 +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 KdEE8O2iK5Gt; Tue, 10 Sep 2013 23:12:24 +0100 (IST) Received: from [10.87.48.10] (unknown [86.41.52.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5FBD7BE4C; Tue, 10 Sep 2013 23:12:24 +0100 (IST) Message-ID: <522F9948.1050407@cs.tcd.ie> Date: Tue, 10 Sep 2013 23:12:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Trammell References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <81B4D129-8BE6-4865-BCAB-6159C0633E3F@tik.ee.ethz.ch> In-Reply-To: <81B4D129-8BE6-4865-BCAB-6159C0633E3F@tik.ee.ethz.ch> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , Scott Brim , Peter Saint-Andre Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 22:12:40 -0000 On 09/10/2013 10:59 PM, Brian Trammell wrote: > > So, "privacy", but with a focus on pervasive surveillance as the specific threat. +1, that seems right to me. S. From pkyzivat@alum.mit.edu Tue Sep 10 15:23:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3910C21F9E11 for ; Tue, 10 Sep 2013 15:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM0kSBcm6wWa for ; Tue, 10 Sep 2013 15:22:56 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 40C4921F9E0D for ; Tue, 10 Sep 2013 15:22:55 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id PNvm1m00117dt5G53aNuxL; Tue, 10 Sep 2013 22:22:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id PaNu1m0123ZTu2S3ZaNuo5; Tue, 10 Sep 2013 22:22:54 +0000 Message-ID: <522F9BBD.2040005@alum.mit.edu> Date: Tue, 10 Sep 2013 18:22:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <522F6CE1.8070605@gmx.net> <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> <522F736C.5060701@gmx.net> <522F7AB1.9050306@gmx.net> In-Reply-To: <522F7AB1.9050306@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378851774; bh=94CIawGIRdvOTgjsDJn12faT6iVopouU30Ej07GPSrk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=d7D7k08Xn7b2ScOlR6TkIU7nKOulDUXmjIJnuzxzah0BTzRBVte6jvzz+dgso116+ 7mYdukciJGgp7qiFVneU3PjTS17WhdhB0rkEC8CX+rVA76DOxa8nQz99UAGDuC+onK GkVgJ9QVJeOqtrmpIO5SsWjVafoof2mvbtVMYCnZSeZ6C09mLmbODyuejbNg3z/dL+ lMAKlwCAmLlD+S8URIdYKRhUHlPI/OoWovYYi6ktMR9qtSYE4aiTMoeJdsPdv3tEA5 TkXyUjTRTr4ttqMKMLIOUQQzuTfmdHWqseI92cKBDzTLxQ0mIlxkavuv5xXrakqVlD aRVzJpxePBuFQ== Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 22:23:02 -0000 On 9/10/13 4:01 PM, Hannes Tschofenig wrote: > On 10.09.2013 22:37, Phillip Hallam-Baker wrote: >> >> >> >> On Tue, Sep 10, 2013 at 3:30 PM, Hannes Tschofenig >> > wrote: >> >> Open source is certainly only one market, although important in the >> security context when I think about all the libraries. >> >> Needless to say that many products are not open source and we would >> want to encourage them to get better as well (as we did with the >> IPv6 day). >> >> Maybe we need a "Crypto Day". >> >> >> My proposal is to turn 'PRISM-Proof' into a marketing seal for products >> and services that can demonstrate that they are free from intercept >> capabilities. > > I have no expertise with designing seals. What specifically would that > mean? Would a Webpage or a smart phone app show such a seal? Who would > verify it? Would there be some assessment? If so, by whom? Who would pay > for it? Me either. ISTM that you need to convince the NSA to give out these seals. :-) Thanks, Paul From hallam@gmail.com Tue Sep 10 15:30:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8AA11E8102 for ; Tue, 10 Sep 2013 15:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYO+C7qva4fl for ; Tue, 10 Sep 2013 15:29:59 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4844121F8168 for ; Tue, 10 Sep 2013 15:29:58 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id el20so6705198lab.40 for ; Tue, 10 Sep 2013 15:29:47 -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; bh=mRTEMmjHorITHob92aL98rX9JzSGxp92M7Hgd6CPDVk=; b=Yso7PMDzJ7VZ/UvF+4Y/KmF4t6R3wFlMhQg+caImPBPoWnaNVrtrBEi3VRH//7nmTl knk0SmcEafAy4jrgaLWHIpyem538+vxLKM86gS5kDswNwoURciPxGjFM0uCgmjxBmWBW ES2cdPV6FXMy2667jRPjy5Ris21sLCyGkHrUR4pO4Pa5aO5aWg0bXEt7/Hk3vF4HQ7Mm 8ZH8aUAugWm4V7152zDHa8WdlhcuW/Fm9z6h5pK3qCpRuos1dE1kr1iUn/svIkoZ3HlL DWMkFjcA5zC2PHm7EwrjeyMrIXMZeVpdQggm72IoEqenczGptYcz1cPq4UyYeSd5qSfb JCZw== MIME-Version: 1.0 X-Received: by 10.112.158.225 with SMTP id wx1mr53374lbb.37.1378852187010; Tue, 10 Sep 2013 15:29:47 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Tue, 10 Sep 2013 15:29:46 -0700 (PDT) In-Reply-To: <522F7AB1.9050306@gmx.net> References: <522F6CE1.8070605@gmx.net> <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> <522F736C.5060701@gmx.net> <522F7AB1.9050306@gmx.net> Date: Tue, 10 Sep 2013 18:29:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c34932cdfce004e60f0a6a Cc: Marc Blanchet , perpass Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 22:30:00 -0000 --001a11c34932cdfce004e60f0a6a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 10, 2013 at 4:01 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > On 10.09.2013 22:37, Phillip Hallam-Baker wrote: > >> >> >> >> On Tue, Sep 10, 2013 at 3:30 PM, Hannes Tschofenig >> >> >> wrote: >> >> Open source is certainly only one market, although important in the >> security context when I think about all the libraries. >> >> Needless to say that many products are not open source and we would >> want to encourage them to get better as well (as we did with the >> IPv6 day). >> >> Maybe we need a "Crypto Day". >> >> >> My proposal is to turn 'PRISM-Proof' into a marketing seal for products >> and services that can demonstrate that they are free from intercept >> capabilities. >> > > I have no expertise with designing seals. What specifically would that > mean? Would a Webpage or a smart phone app show such a seal? Who would > verify it? Would there be some assessment? If so, by whom? Who would pay > for it? > Step one would be to establish a set of standards that PRISM-Proof tech would have to meet. For example a PRISM-Proof email scheme would have to meet the key generation criteria that I outlined and support S/MIME message format with some new key discovery mechanism with Certificate Transparency properties (spec to follow). The composition of a board to decide on the properties etc. is secondary since any such set of specs would have to meet the usability criteria and at least some of the tin foil hat criteria. -- Website: http://hallambaker.com/ --001a11c34932cdfce004e60f0a6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 10, 2013 at 4:01 PM, Hannes Tschofenig <hannes= .tschofenig@gmx.net> wrote:
On 10.09.2013 22:37, Phill= ip Hallam-Baker wrote:



On Tue, Sep 10, 2013 at 3:30 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
=A0 =A0 Open source is certainly only one market, although important in the=
=A0 =A0 security context when I think about all the libraries.

=A0 =A0 Needless to say that many products are not open source and we would=
=A0 =A0 want to encourage them to get better as well (as we did with the =A0 =A0 IPv6 day).

=A0 =A0 Maybe we need a "Crypto Day".


My proposal is to turn 'PRISM-Proof' into a marketing seal for prod= ucts
and services that can demonstrate that they are free from intercept
capabilities.

I have no expertise with designing seals. What specifically would that mean= ? Would a Webpage or a smart phone app show such a seal? Who would verify i= t? Would there be some assessment? If so, by whom? Who would pay for it?

Step one would be to establish a set of standards th= at PRISM-Proof tech would have to meet.
For example a PRISM-Proof email scheme wo= uld have to meet the key generation criteria that I outlined and support S/= MIME message format with some new key discovery mechanism with Certificate = Transparency properties (spec to follow).


<= div class=3D"gmail_extra">The composition of a board to decide on the prope= rties etc. is secondary since any such set of specs would have to meet the = usability criteria and at least some of the tin foil hat criteria.=A0


--
Website: http://hallambaker.com/
--001a11c34932cdfce004e60f0a6a-- From hallam@gmail.com Tue Sep 10 15:34:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E79E21F9E45 for ; Tue, 10 Sep 2013 15:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+CGBmO0-XMY for ; Tue, 10 Sep 2013 15:34:20 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BCCDD21F9D3B for ; Tue, 10 Sep 2013 15:34:19 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id y6so6780042lbh.20 for ; Tue, 10 Sep 2013 15:34:15 -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; bh=KjLmRfm8KNlp5Q7CLIso2BdEPrS4dcc286rwmfTP2h4=; b=qfJCyVJvpuPrNg+GlZCdY7cSqQygtt7rvzVthO2rlucyidYaeANmB2E21r5/Tp3/lj EwMlqH5iRLW3KhMBjjqtgg7ty9QccA30VzX8yPBS7hKzs18Oi8/KhtMmzMRXxWU7W38c TD+6o9YOEECwPCNu9kMSf9AMKIFdDHVuBwbsvSHcwHFf2Wpe/bEpxKzvqeN7o36b6Zmj fn4DUbMy4YEDIHPSvOe9Z0O0xx2X+LEiyKZrqv6L8BvVsUm/gh9jVbUSK5yf66k7PqRG UpxXbPA+WhK6zBIq17z6zs9SAioKdxUqAnmyWOhtW64jxfrbvxBaTZ+8hDi7F7t7oYkg Bs9Q== MIME-Version: 1.0 X-Received: by 10.112.138.194 with SMTP id qs2mr30963lbb.87.1378852455462; Tue, 10 Sep 2013 15:34:15 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Tue, 10 Sep 2013 15:34:15 -0700 (PDT) In-Reply-To: <522F9BBD.2040005@alum.mit.edu> References: <522F6CE1.8070605@gmx.net> <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> <522F736C.5060701@gmx.net> <522F7AB1.9050306@gmx.net> <522F9BBD.2040005@alum.mit.edu> Date: Tue, 10 Sep 2013 18:34:15 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e01182b28ce6e9d04e60f1a7a Cc: perpass Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 22:34:21 -0000 --089e01182b28ce6e9d04e60f1a7a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 10, 2013 at 6:22 PM, Paul Kyzivat wrote: > On 9/10/13 4:01 PM, Hannes Tschofenig wrote: > >> On 10.09.2013 22:37, Phillip Hallam-Baker wrote: >> >>> >>> >>> >>> On Tue, Sep 10, 2013 at 3:30 PM, Hannes Tschofenig >>> >> >>> wrote: >>> >>> Open source is certainly only one market, although important in the >>> security context when I think about all the libraries. >>> >>> Needless to say that many products are not open source and we would >>> want to encourage them to get better as well (as we did with the >>> IPv6 day). >>> >>> Maybe we need a "Crypto Day". >>> >>> >>> My proposal is to turn 'PRISM-Proof' into a marketing seal for products >>> and services that can demonstrate that they are free from intercept >>> capabilities. >>> >> >> I have no expertise with designing seals. What specifically would that >> mean? Would a Webpage or a smart phone app show such a seal? Who would >> verify it? Would there be some assessment? If so, by whom? Who would pay >> for it? >> > > Me either. > ISTM that you need to convince the NSA to give out these seals. :-) > Anyone who could show that there was a vulnerability should be listened to. But as I pointed out to my government contacts, at this point it is clear that the NSA has completely failed at its mission to protect US government secrets. They have lax internal controls and people like Snowden have access way above their rank and need to know. So I would bet the information assurance side of NSA is actually quite interested in fixing their problem and the intercept side is going to be in so much confusion and disarray that they are unlikely to be in a position to influence matters for many years. -- Website: http://hallambaker.com/ --089e01182b28ce6e9d04e60f1a7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 10, 2013 at 6:22 PM, Paul Kyzivat <= ;pkyzivat@alum.m= it.edu> wrote:
On 9/10/13 4:01 PM, Hannes= Tschofenig wrote:
On 10.09.2013 22:37, Phillip Hallam-Baker wrote:



On Tue, Sep 10, 2013 at 3:30 PM, Hannes Tschofenig
<hannes.t= schofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
=A0 =A0 Open source is certainly only one market, although important in the=
=A0 =A0 security context when I think about all the libraries.

=A0 =A0 Needless to say that many products are not open source and we would=
=A0 =A0 want to encourage them to get better as well (as we did with the =A0 =A0 IPv6 day).

=A0 =A0 Maybe we need a "Crypto Day".


My proposal is to turn 'PRISM-Proof' into a marketing seal for prod= ucts
and services that can demonstrate that they are free from intercept
capabilities.

I have no expertise with designing seals. What specifically would that
mean? Would a Webpage or a smart phone app show such a seal? Who would
verify it? Would there be some assessment? If so, by whom? Who would pay for it?

Me either.
ISTM that you need to convince the NSA to give out these seals. :-)

Anyone who could show that there was a vulnera= bility should be listened to.

But as I pointed out= to my government contacts, at this point it is clear that the NSA has comp= letely failed at its mission to protect US government secrets. They have la= x internal controls and people like Snowden have access way above their ran= k and need to know.

So I would bet the information assurance side of NSA is= actually quite interested in fixing their problem and the intercept side i= s going to be in so much confusion and disarray that they are unlikely to b= e in a position to influence matters for many years.=A0


--
Website: http://hallambaker.com/
--089e01182b28ce6e9d04e60f1a7a-- From dwing@cisco.com Tue Sep 10 16:17:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC4011E813F for ; Tue, 10 Sep 2013 16:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q3Q5QqpYzx9 for ; Tue, 10 Sep 2013 16:17:17 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7A27511E8116 for ; Tue, 10 Sep 2013 16:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=794; q=dns/txt; s=iport; t=1378855026; x=1380064626; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CtZ7ry+MxcCD0/JnNBZfHzfIuaNyZ4PMVxL6hD3q+Jo=; b=XLZUbFAqAuONl3dG/O7lZxu/+NqpiqnQuWacnjEhchgVD/AOtueBvgLo wxZkMqMO2K0eGpxrhztvws+XknfhTkWoedrman0+z4KtUlggKfughbZ6T NB9IRjGRKxxghjAR0fCywgM2Gt5J71VYCNcO5G60F30LbRWyazsmYhByR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8FAE6nL1KrRDoH/2dsb2JhbABbgwc4gzS/fYEjFnSCJQEBAQMBOj8FCwtGVwYTFIdcAwkFDcMbjHCCODMHgx2BAAOJNo5AkWuDQBw X-IronPort-AV: E=Sophos;i="4.90,881,1371081600"; d="scan'208";a="91558286" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 10 Sep 2013 23:17:03 +0000 Received: from dhcp-10-155-84-136.cisco.com (dhcp-10-155-84-136.cisco.com [10.155.84.136]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8ANH2PX008878; Tue, 10 Sep 2013 23:17:02 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <522F6CE1.8070605@gmx.net> Date: Tue, 10 Sep 2013 16:17:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <934E719A-498F-480E-87D4-ADE81314E039@cisco.com> References: <522F6CE1.8070605@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Cc: perpass Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 23:17:21 -0000 On Sep 10, 2013, at 12:02 PM, Hannes Tschofenig = wrote: > The wider Internet community, however, has somewhat different options = and we have in other cases reached out to that community to impact the = deployment of Internet technologies. A recent example is the IPv6 day. Self-selection, like was done by ISOC for World IPv6 Launch, = http://www.worldipv6launch.org/participants/?q=3D1, and grade the hosts = by the quality of their TLS handshake for their entire web page. = Forward secrecy is something we might want to measure, for example. An = example of a grade is what ssllabs does. See for example=20 https://www.ssllabs.com/ssltest/analyze.html?d=3Dwww.ietf.org https://www.ssllabs.com/ssltest/analyze.html?d=3Dwww.nsa.gov). -d From ynir@checkpoint.com Tue Sep 10 16:18:46 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A7411E8116 for ; Tue, 10 Sep 2013 16:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.338 X-Spam-Level: X-Spam-Status: No, score=-9.338 tagged_above=-999 required=5 tests=[AWL=1.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEgdejSRyron for ; Tue, 10 Sep 2013 16:18:40 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C8A7811E815F for ; Tue, 10 Sep 2013 16:18:36 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8ANIWfR027312; Wed, 11 Sep 2013 02:18:32 +0300 X-CheckPoint: {522FA8C8-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 11 Sep 2013 02:18:32 +0300 From: Yoav Nir To: Phillip Hallam-Baker Thread-Topic: [perpass] Bruce Schneier - A different approach? Thread-Index: AQHOrljxyu9XDQEvZEyqeFGJgdW8d5m/JKUAgAAE4wCAAAG8AIAABu+AgAAnZYCAAAMtgIAADGOA Date: Tue, 10 Sep 2013 23:18:32 +0000 Message-ID: <16937D30-E72C-4CCD-9215-41BA38D9F710@checkpoint.com> References: <522F6CE1.8070605@gmx.net> <82F315C7-4DD7-4D81-B229-382F59591CA3@viagenie.ca> <522F736C.5060701@gmx.net> <522F7AB1.9050306@gmx.net> <522F9BBD.2040005@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.65] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass , Paul Kyzivat Subject: Re: [perpass] Bruce Schneier - A different approach? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 23:18:46 -0000 On Sep 11, 2013, at 1:34 AM, Phillip Hallam-Baker wrote: > Anyone who could show that there was a vulnerability should be listened t= o. >=20 > But as I pointed out to my government contacts, at this point it is clear= that the NSA has completely failed at its mission to protect US government= secrets. They have lax internal controls and people like Snowden have acce= ss way above their rank and need to know. Agree. This is especially disturbing considering that this is only 3 years = after Pfc Manning turned out to have access to a huge pile of documents. > So I would bet the information assurance side of NSA is actually quite in= terested in fixing their problem and the intercept side is going to be in s= o much confusion and disarray that they are unlikely to be in a position to= influence matters for many years.=20 I wish I shared your optimism. I don't think the NSA is in any disarray. Yoav= From sm@resistor.net Tue Sep 10 17:15:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C681B21F9CF3 for ; Tue, 10 Sep 2013 17:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBvJUPmaV10T for ; Tue, 10 Sep 2013 17:15:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FE321F9CED for ; Tue, 10 Sep 2013 17:15:46 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8B0FcGa010972; Tue, 10 Sep 2013 17:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378858543; bh=KbMqO/aOAHI+rxn1ZH+xd7Qc2mfC7kwxaQUu0QsWOaQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xCmTiCBqMRHoMPqeVXmRIyaV5z21C6ciCy0htuaJC55zktqSkE/c8Xx4Dac2VxZQU DnPD8qal5w2preuU0cYOH3exKdvUPvMLiuOzB2zljPn5KNVtAAV4eR5nULQ0cY4KmC Rtk8GMuw0dCnX+vNKD2JvcjH7AB8ECvoxpQdfsTY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1378858543; i=@resistor.net; bh=KbMqO/aOAHI+rxn1ZH+xd7Qc2mfC7kwxaQUu0QsWOaQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JJOwrMzxpMsfgqJbbdb5HMjnxWA2PUCzvAnyEzOADd9U2LtGoGeWphUbvbyzFggGj luURevRfXRLKjgVUVMU1jnN1jBmSB1Sr1qooG5P58++K+zxBYz69yiv/s/fZNEVCUD nbFgSZOs4Wp0pZ/1QGlAp8XhWy9Y1UIvu8vmGaJE= Message-Id: <6.2.5.6.2.20130910164150.0cbac7b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Sep 2013 16:59:30 -0700 To: Hannes Tschofenig From: SM In-Reply-To: <522D863F.10903@gmx.net> References: <522D863F.10903@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 00:15:48 -0000 Hi Hannes, At 01:26 09-09-2013, Hannes Tschofenig wrote: >I gave a presentation last week to a group of international data >protection authorities about VoIP security & privacy. I produced a >blog post about the presentation and put it here: >http://www.tschofenig.priv.at/wp/?p=997 > >It contains a number of recommendations, which are addressed to VoIP >providers and vendors but have to be enforced by data protection authorities. There seems to be an agreement between a country which you can guess and a country in Europe which bypasses data protection requirements. I did not verify the information. I suggest looking at the 3GPP use-case in respect to SIP identity. One of the issues with transparency is that it is overruled by "in accordance with the law". Lawful intercept seems to be quite broad in a country even though the legislation says otherwise. The list of recommendations is a good start. Regards, -sm From bmanning@isi.edu Tue Sep 10 19:56:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8857221F9A98 for ; Tue, 10 Sep 2013 19:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0bld4MVTQkT for ; Tue, 10 Sep 2013 19:56:14 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 93B1221F997B for ; Tue, 10 Sep 2013 19:56:14 -0700 (PDT) Received: from [192.168.0.3] (cpe-24-24-228-167.socal.res.rr.com [24.24.228.167]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r8B2rqRJ005828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Sep 2013 19:53:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: Date: Tue, 10 Sep 2013 19:53:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D7E70B7-4EB1-4933-A673-7B4BADD24127@isi.edu> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F645D.2080609@gmx.net> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: perpass , Hannes Tschofenig , Scott Brim , Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 02:56:21 -0000 yvr is out for me, but i would gladly participate in a workshop. i'm = concerned about the blanket use of security/crypto pixie dust to ensure privacy=85 some things, as Ted mentioned in another thread, = don't need privacy - like time or routing. /bill On 10September2013Tuesday, at 11:35, Spencer Dawkins at IETF wrote: > Hannes, if we have not solved all the problems such a workshop(*) = would address by December, I would certainly support a workshop in = something like the London IETF timeframe :-) >=20 > Spencer >=20 > (*) and this is not the first time I've said something snarky and then = supported a workshop you've proposed, either! >=20 > On Tuesday, September 10, 2013, Hannes Tschofenig wrote: > I suggested within the IAB to do a workshop* (before the meeting), = which would give us an extra day of intense discussion time. = Unfortunately, it is a bit close to the next meeting (which complicates = travel planning) and some folks have booked their trip already... >=20 > Despite all the discussions I fear that a BOF slot will make it very = difficult to discuss such a broad topic and to make some progress. >=20 > Ciao > Hannes >=20 > (*): I know that it is not the first time I have suggested a workshop. >=20 > On 10.09.2013 21:03, Scott Brim wrote: > On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre = wrote: > We'll want to use the high-bandwidth time wisely, and we know that > security-related discussions (well, all discussions) can easily go off > track. Staying focused on the core issues, and on problems that might > have engineering solutions, will be paramount. >=20 > This is a scope question. How do we decide what to focus on? I > suggest that we start by saying it's not security, and it's not > surveillance, it's privacy, i.e. the ability to control the flow of > one's personal information (there's your definition, Dave). Security > is too large a scope, while surveillance is too small. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From david.lloydjones@gmail.com Tue Sep 10 22:54:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A7D11E8166 for ; Tue, 10 Sep 2013 22:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVhmrlxHnJAe for ; Tue, 10 Sep 2013 22:54:07 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 39FB821F9344 for ; Tue, 10 Sep 2013 22:54:06 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u57so6584235wes.9 for ; Tue, 10 Sep 2013 22:54:06 -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; bh=D/KheQ/rxatpvEuTcAUM8cPmMgmBog+tiM7fVJW4+G8=; b=QQ/ale/X6KnYxGLXm8auvMIfLIGIOQWIxBhFLn+XZ3pV9MiRIn8dHaa+VsrTaVW3ie 2rLFqhMMvTVPxC+FzBFAvcQ3YLRPMz0VrG1bDTHevbgfsZor47a3Xr+fxNNsN1QhJgUX uMJcTkZgeNqw+laLL0//guJ+nGwILutC2HV7SSbec42w6PBLKeUkx6ZPjxHGrneKVYQs ebjV2zej9v1+4nkDkzZjiu2UwzK8bJrz08+cQ55305LCw8CSSbr6eFXyFo2MsuU40BlG O1SeSg+6N1RVHJ3PvCQLNkG8pno/cg8wmMFtJmvwLKrCwD9hYrkkTn3HrrYRvfd+sVmp DbXQ== MIME-Version: 1.0 X-Received: by 10.194.240.129 with SMTP id wa1mr10071732wjc.31.1378878846341; Tue, 10 Sep 2013 22:54:06 -0700 (PDT) Received: by 10.194.110.169 with HTTP; Tue, 10 Sep 2013 22:54:06 -0700 (PDT) In-Reply-To: <522F9537.5070605@cs.tcd.ie> References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F6637.2080700@dcrocker.net> <522F691E.3010101@gmx.net> <522F9537.5070605@cs.tcd.ie> Date: Wed, 11 Sep 2013 01:54:06 -0400 Message-ID: From: David Lloyd-Jones To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e013d1db2d31b7104e6153f68 Cc: perpass Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 05:54:08 -0000 --089e013d1db2d31b7104e6153f68 Content-Type: text/plain; charset=UTF-8 I'm not up to speed on these issues, so I have nothing much to say in any specific way ... yet. :-) I do think, however, that the IETF release is an awfully good piece of work: mature, thoughtful and appropriate in tone. and I want the authors to have my personal congratulations: good work. Well done. Cheers, -dlj. On 10 September 2013 17:55, Stephen Farrell wrote: > > Good to see all the discussion. Keep it up! > > Couple of points: > > - I entirely agree that the BoF, other than scene setting (and the > usual ranting which we'll keep to a minimum:-) needs to be focused > on what the IETF can do. (Broader list discussion, e.g. about the > open-source community, seems fine and who knows might lead to some > concrete stuff we would like to talk about at the BoF.) > > - I think that "privacy" is too broad and not sufficiently focused > as a topic for a BoF session. Much as I'd like to see more progress > on corporate privacy-busting, I think this session will be better > kept more focused on recent pervasive monitoring attacks and what > we can do in the IETF to mitigate those attacks. > > - I agree with Dave that it'd be good to have a better idea of what > other protocols/areas of the IETF might be affected and/or part of > the answer. For example, the LISP WG list have an active discussion > now about encrypting encapsulated packet content. That wasn't one > that would have occurred to me but if the LISP folks are up for it > then it seems like a fine addition to their protocol. I'd be keen > to get more examples of IETF protocols where we could do stuff to > counter pervasive monitoring. The protocols where we improve things > btw don't need to have been part of current news stories - I don't > think LISP has featured for example:-) > > So keep the discussion flowing and we'll organise more as we go. > Ta, > S. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --089e013d1db2d31b7104e6153f68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not up to speed on these issues, so I have nothing= much to say in any specific way ... yet. =C2=A0:-)
=C2=A0
I = do think, however, that the IETF release is an awfully good piece of work: = mature, thoughtful and appropriate in tone. and I want the authors to have = my personal congratulations: good work. Well done.
=C2=A0
Cheers,
=C2=A0
-dlj.
<= div class=3D"gmail_extra">

On 10 Septembe= r 2013 17:55, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Good to see all the discussion. Keep it up!

Couple of points:

- I entirely agree that the BoF, other than scene setting (and the
usual ranting which we'll keep to a minimum:-) needs to be focused
on what the IETF can do. (Broader list discussion, e.g. about the
open-source community, seems fine and who knows might lead to some
concrete stuff we would like to talk about at the BoF.)

- I think that "privacy" is too broad and not sufficiently focuse= d
as a topic for a BoF session. Much as I'd like to see more progress
on corporate privacy-busting, I think this session will be better
kept more focused on recent pervasive monitoring attacks and what
we can do in the IETF to mitigate those attacks.

- I agree with Dave that it'd be good to have a better idea of what
other protocols/areas of the IETF might be affected and/or part of
the answer. For example, the LISP WG list have an active discussion
now about encrypting encapsulated packet content. That wasn't one
that would have occurred to me but if the LISP folks are up for it
then it seems like a fine addition to their protocol. I'd be keen
to get more examples of IETF protocols where we could do stuff to
counter pervasive monitoring. The protocols where we improve things
btw don't need to have been part of current news stories - I don't<= br> think LISP has featured for example:-)

So keep the discussion flowing and we'll organise more as we go.
Ta,
S.
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--089e013d1db2d31b7104e6153f68-- From housley@vigilsec.com Wed Sep 11 09:05:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3313F21E8051; Wed, 11 Sep 2013 09:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sv5lW-lLN62; Wed, 11 Sep 2013 09:05:30 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA1B11E81C8; Wed, 11 Sep 2013 09:04:47 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 6579EF241EB; Wed, 11 Sep 2013 12:05:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id bm1MdwRSFQfA; Wed, 11 Sep 2013 12:04:08 -0400 (EDT) Received: from [192.168.2.100] (pool-96-231-164-210.washdc.fios.verizon.net [96.231.164.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 20153F240FD; Wed, 11 Sep 2013 12:05:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Wed, 11 Sep 2013 12:04:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com> References: To: Nick Mathewson X-Mailer: Apple Mail (2.1085) Cc: perpass@ietf.org, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 16:05:37 -0000 The tlsdate program (with origins in the TOR project) makes use of this = value in the nonce portion of the handshake. I think that the time is an important part of the nonce. Even if the = implementation has a crappy random number generator, the time value does = a good job of ensuring that the nonce value is not repeated. Obviously, = the time value does not help with the unpredictability, but the random = value is supposed to do that. Russ On Sep 11, 2013, at 11:43 AM, Nick Mathewson wrote: > Hi, all. >=20 > Here's something I wrote about removing a fingerprinting opportunity > from the current TLS protocol. I was going to just send it to the tls > list, but Ben Laurie suggested that I send it to the perpass list as > well. >=20 > I have little standards-body experience; if this ought to turn into an > RFC or something, I'd be happy to write a draft if need be. >=20 >=20 > (Tor currently plans to implement this by patching OpenSSL; any > feedback or advice would be appreciated. The first three approaches > below are implemented in OpenSSL branches named "no_client_timestamp", > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git > repository at https://github.com/nmathewson/openssl . We have long > shipped our privacy-enhanced browser with a feature like this enabled > through an NSS patch.) >=20 >=20 > =3D=3D=3D=3D > SYNOPSIS: >=20 > In TLS as currently specified, clients and servers each send their > current view of "the time" in the clear as part of their handshake. > This provides a fingerprint that can track users in spite of other > attempts to make them untrackable. I propose several ways to stop > doing sending this cleartext timestamp; some trivial and some more > complex. >=20 >=20 > ACKNOWLEDGEMENTS: >=20 > Thanks to Adam Langley, Ben Laurie, and everybody else who gave me > feedback here. >=20 >=20 > PROBLEM: >=20 > The gmt_unix_time field in the Random field in the TLS handshake > provides a way for an observer to fingerprint clients. >=20 > Despite the late date, much of the world is still not > synchronized to the second via an ntp-like service. This means > that different clients have different views of the current time, > which provides a fingerprint that helps to track and distinguish > them. This fingerprint is useful for tracking clients as they > move around. It can also distinguish clients using a single VPN, > NAT, or privacy network. (Tor's modified firefox avoids this by > not sending the time.) >=20 > Worse, some implementations don't send the current time, but the > process time, or the computer's uptime, both of which are far > more distinguishing than the current time() value. >=20 > The information fingerprint here is strong enough to uniquely > identify some TLS users (the ones whose clocks are hours off). > Even for the ones whose clocks are mostly right (within a second > or two), the field leaks a bit of information, and it only takes > so many bits to make a user unique. >=20 > Of course, I realize that the gmt_unix_time fingerprint is not the > only way to track a typical client as it moves from network to > network, and not the only way to distinguish different clients > behind a NAT. >=20 >=20 >=20 > BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE? >=20 > According to third-hand reports (and correct me if I'm wrong!) > gmt_unix_time was introduced in SSL 3.0 to prevent complete failure > in cases where the PRNG was completely broken, by making a part of > the Random field that would definitely vary between TLS handshakes. >=20 > I doubt that this goal is really achieved, for two reasons: >=20 > * On modern desktop environments, it's not really so strange to > start two or more TLS connections within the same second. When > this occurs, the gmt_unix_time fails in its intended purpose of > preventing repeated Random values. >=20 > * Nonwithstanding the gmt_unix_time workaround, TLS in general > does not withstand broken PRNGs. For one example, if an > implementation's PRNG is prone to repeating ClientRandom > values, it is probably prone to repeating those some values as > ephemeral Diffie-Hellman private values. >=20 > Nevertheless, if the goal of providing unique-looking output >=20 >=20 >=20 > WHY ELSE IS gmt_unix_time USED? >=20 > The consensus among implementors I've asked seems to be that it's > unwise to depend on any particular value or interpretation for the > field. The TLS 1.2 standard, RFC 5246, says that "Clocks are not > required to be set correctly by the basic TLS protocol; higher-level > or application protocols may define additional requirements." >=20 > Some implementations set the entire gmt_unix_time field randomly; > this appears not to have broken TLS on the internet. >=20 > At least one tool (tlsdate) uses the server-side value of the > field as an authenticated view of the current time. >=20 >=20 >=20 > PROPOSAL 1: >=20 > Declare that implementations MAY replace gmt_unix_time either with > four more random bytes, or four bytes of zeroes. >=20 > Rationale: > * Some implementations (like TorBrowser) are already doing this > in practice. >=20 > * It's sensible and simple. Implementors are quite unlikely to > mess it up. >=20 >=20 >=20 > PROPOSAL 2: >=20 > Suppose that we do not accept the argument about the pointlessness > of gmt_unit_time that I make above, and we want to preserve the > security it allegedly provides. >=20 > In that case, we can allow the following approach instead: >=20 > Set the Random field, not to 32 bytes from your PRNG, but to the > HMAC-SHA256 of any high resolution timer that you have, using 32 > bytes from your PRNG as a key. In other words, replace this: >=20 > Random.gmt_unix_time =3D time(); > Random.random_bytes =3D get_random_bytes(28) >=20 > with this: >=20 > now =3D hires_time(); // clock_gettime(), or concatenate time() > // with a CPU timer, or process > // uptime, or whatever. > key =3D get_random_bytes(32); > Random =3D hmac_sha256(key, now); >=20 > This approach is better than the status quo on the following > counts: >=20 > * It doesn't leak your view of the current time, assuming that > your PRNG isn't busted. >=20 > * It actually fixes the problem that gmt_unix_time purported to > fix, by using a high-resolution time that's much less likely to > be used twice. Even if the PRNG is broken, the value is still > nonrepeating. >=20 > I do not think this is not worse than the status quo: >=20 > * It is unpredictable from an attacker's POV, assuming that the > PRNG works. (Because an HMAC, even of known data, with an > unknown random key is supposed to look random). >=20 >=20 > PROPOSAL 3 >=20 > As a hybrid alternative, one could set part of the ClientRandom > field (perhaps 12 bytes or so) based on the HMAC of the time, and > the rest of the ClientRandom field based on the PRNG: >=20 > N =3D 12 >=20 > now =3D hires_time(); > key =3D get_random_bytes(32); > mac =3D hmac_sha256(key, now)[0:N]; // First N bytes. > rand =3D get_random_bytes(32 - N) > Random =3D mac ++ rand // concatenate. >=20 > But this seems to be getting pointlessly baroque. >=20 >=20 >=20 > CONSIDERATIONS: >=20 > I'd personally suggest proposal 1 (just set the field at random) for > most users. Yes, it makes things a little worse if your PRNG can > generate repeat values... but nearly everything in cryptography > fails if your PRNG is broken. >=20 >=20 > We might want to apply this fix on clients only. With a few > exceptions (like hidden services) the server's view of the current > time is not sensitive. >=20 >=20 > Implementors might want to make this feature optional and > on-by-default, just in case some higher-level application protocol > really does depend on it. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nick.a.mathewson@gmail.com Wed Sep 11 09:15:20 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AD121E813F; Wed, 11 Sep 2013 09:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p9qw3w96Elp; Wed, 11 Sep 2013 09:15:10 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBC221E80B6; Wed, 11 Sep 2013 09:14:58 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id n4so2990391qcx.13 for ; Wed, 11 Sep 2013 09:14:57 -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:content-transfer-encoding; bh=0kJ9vsCEjKwxchKhmuongcbGoKhLmSVlP1J6u5wpXe4=; b=aKMrQxnEiX59F5ctAGnk9nKjb/jEIWg3g2ZeOzoOsJnnOQQsNlisZhRJXScSLkVKPA yrOVJ31e+yVlcvcJdVf6uBWkEPwMUxD/tPpXxlnaTvbn40CWGzvgdIkIdcv0/xRQ6OrQ smzpLz6ns2btfo4ssyIzHOeAOO8nknozQV+6pMSBQ82ar8algiv89bn1Pm3arx05mdTt ZsJEiIe2jhZYT3O6zSVqCERqChYJzNrfzilZf7vXijz4T77W1sBlXf0dWcbUfYOaN2lZ doIKThwkxd6BPj02PwOVNaqmCEBSkEkUndtjqr0QjVWoBZzNAkyP5ecictMblCK/JQkF 1sDA== MIME-Version: 1.0 X-Received: by 10.49.71.106 with SMTP id t10mr4765327qeu.26.1378916097643; Wed, 11 Sep 2013 09:14:57 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.140.22.81 with HTTP; Wed, 11 Sep 2013 09:14:57 -0700 (PDT) In-Reply-To: <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com> References: <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com> Date: Wed, 11 Sep 2013 12:14:57 -0400 X-Google-Sender-Auth: rF7Q4Kvo78gMWeWKIK0tSba9VYY Message-ID: From: Nick Mathewson To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: perpass@ietf.org, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 16:15:22 -0000 On Wed, Sep 11, 2013 at 12:04 PM, Russ Housley wrote= : > The tlsdate program (with origins in the TOR project) makes use of this v= alue in the nonce portion of the handshake. That's true, and it's one reason that I would propose this as a client-only change (by default). > I think that the time is an important part of the nonce. Even if the imp= lementation has a crappy random number generator, the time value does a goo= d job of ensuring that the nonce value is not repeated. Obviously, the tim= e value does not help with the unpredictability, but the random value is su= pposed to do that. I discussed that a bit in this part of my proposal: > I doubt that this goal is really achieved, for two reasons: > > * On modern desktop environments, it's not really so strange to > start two or more TLS connections within the same second. When > this occurs, the gmt_unix_time fails in its intended purpose of > preventing repeated Random values. > > * Nonwithstanding the gmt_unix_time workaround, TLS in general > does not withstand broken PRNGs. For one example, if an > implementation's PRNG is prone to repeating ClientRandom > values, it is probably prone to repeating those some values as > ephemeral Diffie-Hellman private values. In other words, sending gmt_unix_time in the clear will not save you from a bad RNG. (Later in the proposal, in the HMAC-based section, I explain how sending the gmt_unix_time in the clear is not necessary to save you from a bad RNG.) best wishes, --=20 Nick From nick.a.mathewson@gmail.com Wed Sep 11 09:32:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB60F21F9FFF; Wed, 11 Sep 2013 09:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw1tpgGlb2Nm; Wed, 11 Sep 2013 09:32:41 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9DF21F9BC3; Wed, 11 Sep 2013 09:32:40 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id ne12so5687623qeb.10 for ; Wed, 11 Sep 2013 09:32:40 -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=wirqVF+Yx86PmdTtJi1hAE+OXzeM0BKEclEh0aEKJ94=; b=FuPtkyRuJriqW1rSYlx6BNex4okopNTnml/uVhHkYi2WPL5m7yxXmXG5VsIytyUISe vtyKgFaxmueSnhvgh5Mu5K3rW2Rdk/qo7WAKNaeBp+YSK52SkYXgFqjG3Td9TBknK05M bUOKbHyg1YAyC3ByoRcAs0exCekxQEVFBSk1AmZWlsMMaEOu714bL7dxcbaLVaTyILgK ipNtAC0Rmgst5zrwZAjQZxDfgW0lWwCT5xOuoH88+i9SBI4d+DVuxdnnVZghZrNvrcLX QJLb+1bLn0EjY3249CxW2tSjlkvo0NN9Cx2LFUQtA9+WAHCf4NW2yhrOV5nsJA++MZIs J+iA== MIME-Version: 1.0 X-Received: by 10.49.25.102 with SMTP id b6mr4555274qeg.91.1378917160355; Wed, 11 Sep 2013 09:32:40 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.140.22.81 with HTTP; Wed, 11 Sep 2013 09:32:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Sep 2013 12:32:40 -0400 X-Google-Sender-Auth: INvwXlEciOoOBehffdxr1jiN6Pg Message-ID: From: Nick Mathewson To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass@ietf.org, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 16:32:41 -0000 On Wed, Sep 11, 2013 at 12:06 PM, Eric Rescorla wrote: > Before we discuss mechanisms, it would be good to verify that in general > clients and servers don't become unhappy if the timestamp is radically > wrong. Has someone done measurements to verify that this is in fact > the case at a broad scale? Tor Browser has omitted this field for over five years now to no ill effect. It would appear (assuming that I'm reading old NSS source right, which I might not be!) that from about 2000 to 2008, Firefox was sending the time since the process started, not the unix time, and nobody noticed until 2007: https://bugzilla.mozilla.org/show_bug.cgi?id=405652 So at least on the client side, there seems to be strong evidence that sending something other than the correct time does not cause obvious problems in the wild. yrs, -- Nick From ekr@rtfm.com Wed Sep 11 09:08:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B4C21E80E2 for ; Wed, 11 Sep 2013 09:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIJOVHSBo9va for ; Wed, 11 Sep 2013 09:07:54 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id AC53411E81D2 for ; Wed, 11 Sep 2013 09:07:30 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id a12so2047340wgh.0 for ; Wed, 11 Sep 2013 09:07:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PXuKTSUqLQadNnVvH8wdbDmALMGv2tY6Kzc9qnnakoI=; b=hG+0lbqN6ysHdOX9OROkz78oXioDVqO7a1opjrEONXiU7G9rOva50nsyaoMup/yUPf 5B0mKxAxz62gxsDUqoFqW0b5YypQ3Q9EqYkGzAIUB5cmvlLyeYpVTIx9nBQNeltkwS80 sNi+oqmmhwQ/9stCTS2Hiaet8P4NgtYTVZRDIM8Jp7Qn5Nj3pbIvhb81SowCeC828SUy m88wlMfq/z5Nfojq3oBOyyeRmUdXwB7NFgtxAx3jzWWVvX4IHicxJPpzdZyaVSriLVtw OBnNWZBsE0s1TXnzRLEJsG90ERkC0kZA1CX9OMb3O4eWzd7l1YyHIBwdtKH2hNKJhSHj Hbuw== X-Gm-Message-State: ALoCoQlsIbGKlHXvHRPr8CxsUugJ7pEq3w+Cw+6wwUpUuLMJH8Ix2t2wRiZpOuY64dE5WZU/yO5W X-Received: by 10.194.250.6 with SMTP id yy6mr2183669wjc.13.1378915649516; Wed, 11 Sep 2013 09:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.84.68 with HTTP; Wed, 11 Sep 2013 09:06:49 -0700 (PDT) X-Originating-IP: [63.245.220.240] In-Reply-To: References: From: Eric Rescorla Date: Wed, 11 Sep 2013 09:06:49 -0700 Message-ID: To: Alfredo Pironti Content-Type: multipart/alternative; boundary=001a11c1ba4a77093704e61dd1d7 X-Mailman-Approved-At: Wed, 11 Sep 2013 10:10:55 -0700 Cc: Nick Mathewson , perpass@ietf.org, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 16:08:21 -0000 --001a11c1ba4a77093704e61dd1d7 Content-Type: text/plain; charset=ISO-8859-1 Before we discuss mechanisms, it would be good to verify that in general clients and servers don't become unhappy if the timestamp is radically wrong. Has someone done measurements to verify that this is in fact the case at a broad scale? -Ekr On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti wrote: > I'm in favor of proposal 1, and second the considerations about it; > essentially, a broken crypto implementation cannot be fixed by a > timestamp. > > If proposal 2 (and 3) was to be implemented on a server, it would also > make DoS easier, because a cheap ClientHello (even generated with weak > randomness) would trigger an extra HMAC computation on the server, > with respect to the current server load. > > Hence, relying on PRNG on both client and server sides looks like a > reasonable way to go. I also don't particularly like the asymmetry > that proposal 2 may bring: client generating randomness with HMAC, and > servers still using the timestamp in clear. > > Cheers, > Alfredo > > On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson > wrote: > > Hi, all. > > > > Here's something I wrote about removing a fingerprinting opportunity > > from the current TLS protocol. I was going to just send it to the tls > > list, but Ben Laurie suggested that I send it to the perpass list as > > well. > > > > I have little standards-body experience; if this ought to turn into an > > RFC or something, I'd be happy to write a draft if need be. > > > > > > (Tor currently plans to implement this by patching OpenSSL; any > > feedback or advice would be appreciated. The first three approaches > > below are implemented in OpenSSL branches named "no_client_timestamp", > > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git > > repository at https://github.com/nmathewson/openssl . We have long > > shipped our privacy-enhanced browser with a feature like this enabled > > through an NSS patch.) > > > > > > ==== > > SYNOPSIS: > > > > In TLS as currently specified, clients and servers each send their > > current view of "the time" in the clear as part of their handshake. > > This provides a fingerprint that can track users in spite of other > > attempts to make them untrackable. I propose several ways to stop > > doing sending this cleartext timestamp; some trivial and some more > > complex. > > > > > > ACKNOWLEDGEMENTS: > > > > Thanks to Adam Langley, Ben Laurie, and everybody else who gave me > > feedback here. > > > > > > PROBLEM: > > > > The gmt_unix_time field in the Random field in the TLS handshake > > provides a way for an observer to fingerprint clients. > > > > Despite the late date, much of the world is still not > > synchronized to the second via an ntp-like service. This means > > that different clients have different views of the current time, > > which provides a fingerprint that helps to track and distinguish > > them. This fingerprint is useful for tracking clients as they > > move around. It can also distinguish clients using a single VPN, > > NAT, or privacy network. (Tor's modified firefox avoids this by > > not sending the time.) > > > > Worse, some implementations don't send the current time, but the > > process time, or the computer's uptime, both of which are far > > more distinguishing than the current time() value. > > > > The information fingerprint here is strong enough to uniquely > > identify some TLS users (the ones whose clocks are hours off). > > Even for the ones whose clocks are mostly right (within a second > > or two), the field leaks a bit of information, and it only takes > > so many bits to make a user unique. > > > > Of course, I realize that the gmt_unix_time fingerprint is not the > > only way to track a typical client as it moves from network to > > network, and not the only way to distinguish different clients > > behind a NAT. > > > > > > > > BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE? > > > > According to third-hand reports (and correct me if I'm wrong!) > > gmt_unix_time was introduced in SSL 3.0 to prevent complete failure > > in cases where the PRNG was completely broken, by making a part of > > the Random field that would definitely vary between TLS handshakes. > > > > I doubt that this goal is really achieved, for two reasons: > > > > * On modern desktop environments, it's not really so strange to > > start two or more TLS connections within the same second. When > > this occurs, the gmt_unix_time fails in its intended purpose of > > preventing repeated Random values. > > > > * Nonwithstanding the gmt_unix_time workaround, TLS in general > > does not withstand broken PRNGs. For one example, if an > > implementation's PRNG is prone to repeating ClientRandom > > values, it is probably prone to repeating those some values as > > ephemeral Diffie-Hellman private values. > > > > Nevertheless, if the goal of providing unique-looking output > > > > > > > > WHY ELSE IS gmt_unix_time USED? > > > > The consensus among implementors I've asked seems to be that it's > > unwise to depend on any particular value or interpretation for the > > field. The TLS 1.2 standard, RFC 5246, says that "Clocks are not > > required to be set correctly by the basic TLS protocol; higher-level > > or application protocols may define additional requirements." > > > > Some implementations set the entire gmt_unix_time field randomly; > > this appears not to have broken TLS on the internet. > > > > At least one tool (tlsdate) uses the server-side value of the > > field as an authenticated view of the current time. > > > > > > > > PROPOSAL 1: > > > > Declare that implementations MAY replace gmt_unix_time either with > > four more random bytes, or four bytes of zeroes. > > > > Rationale: > > * Some implementations (like TorBrowser) are already doing this > > in practice. > > > > * It's sensible and simple. Implementors are quite unlikely to > > mess it up. > > > > > > > > PROPOSAL 2: > > > > Suppose that we do not accept the argument about the pointlessness > > of gmt_unit_time that I make above, and we want to preserve the > > security it allegedly provides. > > > > In that case, we can allow the following approach instead: > > > > Set the Random field, not to 32 bytes from your PRNG, but to the > > HMAC-SHA256 of any high resolution timer that you have, using 32 > > bytes from your PRNG as a key. In other words, replace this: > > > > Random.gmt_unix_time = time(); > > Random.random_bytes = get_random_bytes(28) > > > > with this: > > > > now = hires_time(); // clock_gettime(), or concatenate time() > > // with a CPU timer, or process > > // uptime, or whatever. > > key = get_random_bytes(32); > > Random = hmac_sha256(key, now); > > > > This approach is better than the status quo on the following > > counts: > > > > * It doesn't leak your view of the current time, assuming that > > your PRNG isn't busted. > > > > * It actually fixes the problem that gmt_unix_time purported to > > fix, by using a high-resolution time that's much less likely to > > be used twice. Even if the PRNG is broken, the value is still > > nonrepeating. > > > > I do not think this is not worse than the status quo: > > > > * It is unpredictable from an attacker's POV, assuming that the > > PRNG works. (Because an HMAC, even of known data, with an > > unknown random key is supposed to look random). > > > > > > PROPOSAL 3 > > > > As a hybrid alternative, one could set part of the ClientRandom > > field (perhaps 12 bytes or so) based on the HMAC of the time, and > > the rest of the ClientRandom field based on the PRNG: > > > > N = 12 > > > > now = hires_time(); > > key = get_random_bytes(32); > > mac = hmac_sha256(key, now)[0:N]; // First N bytes. > > rand = get_random_bytes(32 - N) > > Random = mac ++ rand // concatenate. > > > > But this seems to be getting pointlessly baroque. > > > > > > > > CONSIDERATIONS: > > > > I'd personally suggest proposal 1 (just set the field at random) for > > most users. Yes, it makes things a little worse if your PRNG can > > generate repeat values... but nearly everything in cryptography > > fails if your PRNG is broken. > > > > > > We might want to apply this fix on clients only. With a few > > exceptions (like hidden services) the server's view of the current > > time is not sensitive. > > > > > > Implementors might want to make this feature optional and > > on-by-default, just in case some higher-level application protocol > > really does depend on it. > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c1ba4a77093704e61dd1d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Before we discuss mechanisms, it would be good to verify t= hat in general
clients and servers don't become unhappy if the time= stamp is radically
wrong. Has someone done measurements to verify= that this is in fact
the case at a broad scale?

-Ekr


= On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti <alfredo@pironti.eu&= gt; wrote:
I'm in favor of proposal 1, and second t= he considerations about it;
essentially, a broken crypto implementation cannot be fixed by a
timestamp.

If proposal 2 (and 3) was to be implemented on a server, it would also
make DoS easier, because a cheap ClientHello (even generated with weak
randomness) would trigger an extra HMAC computation on the server,
with respect to the current server load.

Hence, relying on PRNG on both client and server sides looks like a
reasonable way to go. I also don't particularly like the asymmetry
that proposal 2 may bring: client generating randomness with HMAC, and
servers still using the timestamp in clear.

Cheers,
Alfredo

On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson <nickm@torproject.org> wrote:
> Hi, all.
>
> Here's something I wrote about removing a fingerprinting opportuni= ty
> from the current TLS protocol. =A0I was going to just send it to the t= ls
> list, but Ben Laurie suggested that I send it to the perpass list as > well.
>
> I have little standards-body experience; if this ought to turn into an=
> RFC or something, I'd be happy to write a draft if need be.
>
>
> (Tor currently plans to implement this by patching OpenSSL; any
> feedback or advice would be appreciated. =A0The first three approaches=
> below are implemented in OpenSSL branches named "no_client_timest= amp",
> "no_client_timestamp_v2" , and "no_client_timestamp_v3&= quot; in the git
> repository at https://github.com/nmathewson/openssl . =A0We have long
> shipped our privacy-enhanced browser with a feature like this enabled<= br> > through an NSS patch.)
>
>
> =3D=3D=3D=3D
> SYNOPSIS:
>
> In TLS as currently specified, clients and servers each send their
> current view of "the time" in the clear as part of their han= dshake.
> This provides a fingerprint that can track users in spite of other
> attempts to make them untrackable. =A0I propose several ways to stop > doing sending this cleartext timestamp; some trivial and some more
> complex.
>
>
> ACKNOWLEDGEMENTS:
>
> Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
> feedback here.
>
>
> PROBLEM:
>
> The gmt_unix_time field in the Random field in the TLS handshake
> provides a way for an observer to fingerprint clients.
>
> Despite the late date, much of the world is still not
> synchronized to the second via an ntp-like service. This means
> that different clients have different views of the current time,
> which provides a fingerprint that helps to track and distinguish
> them. =A0This fingerprint is useful for tracking clients as they
> move around. =A0It can also distinguish clients using a single VPN, > NAT, or privacy network. =A0(Tor's modified firefox avoids this by=
> not sending the time.)
>
> Worse, some implementations don't send the current time, but the > process time, or the computer's uptime, both of which are far
> more distinguishing than the current time() value.
>
> The information fingerprint here is strong enough to uniquely
> identify some TLS users (the ones whose clocks are hours off).
> Even for the ones whose clocks are mostly right (within a second
> or two), the field leaks a bit of information, and it only takes
> so many bits to make a user unique.
>
> Of course, I realize that the gmt_unix_time fingerprint is not the
> only way to track a typical client as it moves from network to
> network, and not the only way to distinguish different clients
> behind a NAT.
>
>
>
> BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?
>
> According to third-hand reports (and correct me if I'm wrong!)
> gmt_unix_time was introduced in SSL 3.0 to prevent complete failure > in cases where the PRNG was completely broken, by making a part of
> the Random field that would definitely vary between TLS handshakes. >
> I doubt that this goal is really achieved, for two reasons:
>
> =A0 =A0* On modern desktop environments, it's not really so strang= e to
> =A0 =A0 =A0start two or more TLS connections within the same second. = =A0When
> =A0 =A0 =A0this occurs, the gmt_unix_time fails in its intended purpos= e of
> =A0 =A0 =A0preventing repeated Random values.
>
> =A0 =A0* Nonwithstanding the gmt_unix_time workaround, TLS in general<= br> > =A0 =A0 =A0does not withstand broken PRNGs. =A0For one example, if an<= br> > =A0 =A0 =A0implementation's PRNG is prone to repeating ClientRando= m
> =A0 =A0 =A0values, it is probably prone to repeating those some values= as
> =A0 =A0 =A0ephemeral Diffie-Hellman private values.
>
> Nevertheless, if the goal of providing unique-looking output
>
>
>
> WHY ELSE IS gmt_unix_time USED?
>
> The consensus among implementors I've asked seems to be that it= 9;s
> unwise to depend on any particular value or interpretation for the
> field. =A0The TLS 1.2 standard, RFC 5246, says that "Clocks are n= ot
> required to be set correctly by the basic TLS protocol; higher-level > or application protocols may define additional requirements."
>
> Some implementations set the entire gmt_unix_time field randomly;
> this appears not to have broken TLS on the internet.
>
> At least one tool (tlsdate) uses the server-side value of the
> field as an authenticated view of the current time.
>
>
>
> PROPOSAL 1:
>
> Declare that implementations MAY replace gmt_unix_time either with
> four more random bytes, or four bytes of zeroes.
>
> Rationale:
> =A0 =A0* Some implementations (like TorBrowser) are already doing this=
> =A0 =A0 =A0in practice.
>
> =A0 =A0* It's sensible and simple. =A0Implementors are quite unlik= ely to
> =A0 =A0 =A0mess it up.
>
>
>
> PROPOSAL 2:
>
> Suppose that we do not accept the argument about the pointlessness
> of gmt_unit_time that I make above, and we want to preserve the
> security it allegedly provides.
>
> In that case, we can allow the following approach instead:
>
> Set the Random field, not to 32 bytes from your PRNG, but to the
> HMAC-SHA256 of any high resolution timer that you have, using 32
> bytes from your PRNG as a key. =A0In other words, replace this:
>
> =A0 =A0Random.gmt_unix_time =3D time();
> =A0 =A0Random.random_bytes =3D get_random_bytes(28)
>
> with this:
>
> =A0 =A0now =3D hires_time(); // clock_gettime(), or concatenate time()=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// with a CPU timer, or= process
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// uptime, or whatever.=
> =A0 =A0key =3D get_random_bytes(32);
> =A0 =A0Random =3D hmac_sha256(key, now);
>
> This approach is better than the status quo on the following
> counts:
>
> =A0 =A0* It doesn't leak your view of the current time, assuming t= hat
> =A0 =A0 =A0your PRNG isn't busted.
>
> =A0 =A0* It actually fixes the problem that gmt_unix_time purported to=
> =A0 =A0 =A0fix, by using a high-resolution time that's much less l= ikely to
> =A0 =A0 =A0be used twice. =A0Even if the PRNG is broken, the value is = still
> =A0 =A0 =A0nonrepeating.
>
> I do not think this is not worse than the status quo:
>
> =A0 =A0* It is unpredictable from an attacker's POV, assuming that= the
> =A0 =A0 =A0PRNG works. =A0(Because an HMAC, even of known data, with a= n
> =A0 =A0 =A0unknown random key is supposed to look random).
>
>
> PROPOSAL 3
>
> As a hybrid alternative, one could set part of the ClientRandom
> field (perhaps 12 bytes or so) based on the HMAC of the time, and
> the rest of the ClientRandom field based on the PRNG:
>
> =A0 =A0N =3D 12
>
> =A0 =A0now =3D hires_time();
> =A0 =A0key =3D get_random_bytes(32);
> =A0 =A0mac =3D hmac_sha256(key, now)[0:N]; =A0// First N bytes.
> =A0 =A0rand =3D get_random_bytes(32 - N)
> =A0 =A0Random =3D mac ++ rand =A0 =A0 =A0 =A0 =A0 =A0 =A0 // concatena= te.
>
> But this seems to be getting pointlessly baroque.
>
>
>
> CONSIDERATIONS:
>
> I'd personally suggest proposal 1 (just set the field at random) f= or
> most users. =A0Yes, it makes things a little worse if your PRNG can > generate repeat values... but nearly everything in cryptography
> fails if your PRNG is broken.
>
>
> We might want to apply this fix on clients only. =A0With a few
> exceptions (like hidden services) the server's view of the current=
> time is not sensitive.
>
>
> Implementors might want to make this feature optional and
> on-by-default, just in case some higher-level application protocol
> really does depend on it.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a11c1ba4a77093704e61dd1d7-- From agl@google.com Wed Sep 11 09:13:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF31F21F9E7C for ; Wed, 11 Sep 2013 09:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn0SpVdIDaAe for ; Wed, 11 Sep 2013 09:13:08 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id CE33021F9E73 for ; Wed, 11 Sep 2013 09:12:23 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id va7so3660234obc.25 for ; Wed, 11 Sep 2013 09:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QcupxjvZEUZg28NlvJUT4DWfbcm6PXiHMKqm2JaZVBs=; b=RGr/RrWJ4WBx98uVAlT6eKjRNcfd2up5ZX2z08aB7af4iyCbPw5SNkQsUVmhTwxa6y EsebbKZ1cWQ5GaxlGqtYDbrPYJ/lprQXBNjIjwLDw5g18+Q4Kz4eMPD+4I/5z4886OQV IwUPIR8/gmyeHuUmzuocYHn6Rkkm09GPkWBujG6vc17AImme+t+stVigFHGZTcbwYBhY hkpqeShUmKwp+mmjn+GkREoDKgfvqN5ZCChCn55VEXvWyD1aWMH9B33g9Sse5dj1qi3W KjbhYNHV+XLXbKCwRwjZzU/DMOFt2WI0m1uNCbO188+VrwX6oLfDnDZ+W8sP8tNBuSHe 2Rww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QcupxjvZEUZg28NlvJUT4DWfbcm6PXiHMKqm2JaZVBs=; b=bWAGqF7QxZhhS4YTJdwaC1J1GrXH93GBGcbEqvomZ5G8DijN+7KF4ai2+PJwuSYHAE KXbMeHVL5AhWMLBpemwTDOTj+c7gfpZwDmOvASS5I/mTX8y3zUAQwrOvq9MlbxCEEfsj RCEsEKnrG7TQeBmtca6FgCFG/76ntzw61/y48P6Cw23gMmxovwGSvVyvU2ZU42We7/I4 6R5DR8uJsl6YJ0uHDZAspDMQf2SBH3KpNCi2/3sjNa4FhU1VIjHk2HOQmkzVDdI8q4wc i+PSSS0BijtyiruyJyH4decnT1d3OEiN6TcdJl+4sUvpyrM2KUs2iZgHYNGcLa43koSC YcuQ== X-Gm-Message-State: ALoCoQmAVjYvCee288JiSVuVumI4MwKmsWVOYqYtH8iZAJRToEltaEtWcnaofpp3U6vCB80PsD5KN0WKMCWwEbFX5wM2CEZ9t8ttydKXGurj8epX9cBHaFkaGJzsk0AGFwZwXhZbLTRdyHgJLyZuxXiLeGzUGOdQG/Z5pBj98NWSC1pOhODhNEc1NaJKQDWnQ2UZU5QN7Wfb X-Received: by 10.60.132.142 with SMTP id ou14mr2245514oeb.58.1378915938206; Wed, 11 Sep 2013 09:12:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.79.105 with HTTP; Wed, 11 Sep 2013 09:11:58 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Wed, 11 Sep 2013 12:11:58 -0400 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 11 Sep 2013 10:11:05 -0700 Cc: perpass@ietf.org, "tls@ietf.org" , Alfredo Pironti Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 16:13:09 -0000 On Wed, Sep 11, 2013 at 12:06 PM, Eric Rescorla wrote: > Before we discuss mechanisms, it would be good to verify that in general > clients and servers don't become unhappy if the timestamp is radically > wrong. Has someone done measurements to verify that this is in fact > the case at a broad scale? I've observed that some small fraction of traffic to Google puts random bytes in the first-four bytes of the nonce. It was less than 1%, but some clients clearly do this already. Cheers AGL From nick.a.mathewson@gmail.com Wed Sep 11 08:44:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5860C21E8150; Wed, 11 Sep 2013 08:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWI2VnEZzLl9; Wed, 11 Sep 2013 08:44:20 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3A121E80D6; Wed, 11 Sep 2013 08:43:58 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id nd7so4559721qeb.21 for ; Wed, 11 Sep 2013 08:43:53 -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=nadwBqowODNn1F1WLREZev2cD/GPtWb6g87ZQhWtrY0=; b=q+8McEr3GrF0HK2vPDdHpK7gyzhNs68M5cRdz2p4mSSGJkbYQEKxe2DDiCPa1RS6nx LfLrXUrQZcWHcGx9Na38d73G7oxZ5TkdcM1dKsJJvuCD02SRMA2N2UBcwX8/a0U79Xmx xmAIS8o9ZOBudUZy7t3nVEtXjQvc3j0dGGHpRYpIW5gMwA2EZaDApZzNReyZvJlsqMaR jmHTGl4+12iQ+4OHIiziFJtwrXNCsvIZbmicDf2liyvvuLpx9zQKLSbRlCSEWA9DnTMG iI28BwfbYCQWCHiGqgJA6WHmpgNYkgW2x/4c0yrhdlTkDPn6mv0SqsaOrH5FzjNN7Pkq IJWg== MIME-Version: 1.0 X-Received: by 10.49.120.72 with SMTP id la8mr4490597qeb.62.1378914233423; Wed, 11 Sep 2013 08:43:53 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.140.22.81 with HTTP; Wed, 11 Sep 2013 08:43:53 -0700 (PDT) Date: Wed, 11 Sep 2013 11:43:53 -0400 X-Google-Sender-Auth: bJai9poECwNKPn3X9boDY4XJEQQ Message-ID: From: Nick Mathewson To: "tls@ietf.org" , perpass@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 11 Sep 2013 10:10:56 -0700 Subject: [perpass] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 15:44:23 -0000 X-List-Received-Date: Wed, 11 Sep 2013 15:44:23 -0000 Hi, all. Here's something I wrote about removing a fingerprinting opportunity from the current TLS protocol. I was going to just send it to the tls list, but Ben Laurie suggested that I send it to the perpass list as well. I have little standards-body experience; if this ought to turn into an RFC or something, I'd be happy to write a draft if need be. (Tor currently plans to implement this by patching OpenSSL; any feedback or advice would be appreciated. The first three approaches below are implemented in OpenSSL branches named "no_client_timestamp", "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git repository at https://github.com/nmathewson/openssl . We have long shipped our privacy-enhanced browser with a feature like this enabled through an NSS patch.) ==== SYNOPSIS: In TLS as currently specified, clients and servers each send their current view of "the time" in the clear as part of their handshake. This provides a fingerprint that can track users in spite of other attempts to make them untrackable. I propose several ways to stop doing sending this cleartext timestamp; some trivial and some more complex. ACKNOWLEDGEMENTS: Thanks to Adam Langley, Ben Laurie, and everybody else who gave me feedback here. PROBLEM: The gmt_unix_time field in the Random field in the TLS handshake provides a way for an observer to fingerprint clients. Despite the late date, much of the world is still not synchronized to the second via an ntp-like service. This means that different clients have different views of the current time, which provides a fingerprint that helps to track and distinguish them. This fingerprint is useful for tracking clients as they move around. It can also distinguish clients using a single VPN, NAT, or privacy network. (Tor's modified firefox avoids this by not sending the time.) Worse, some implementations don't send the current time, but the process time, or the computer's uptime, both of which are far more distinguishing than the current time() value. The information fingerprint here is strong enough to uniquely identify some TLS users (the ones whose clocks are hours off). Even for the ones whose clocks are mostly right (within a second or two), the field leaks a bit of information, and it only takes so many bits to make a user unique. Of course, I realize that the gmt_unix_time fingerprint is not the only way to track a typical client as it moves from network to network, and not the only way to distinguish different clients behind a NAT. BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE? According to third-hand reports (and correct me if I'm wrong!) gmt_unix_time was introduced in SSL 3.0 to prevent complete failure in cases where the PRNG was completely broken, by making a part of the Random field that would definitely vary between TLS handshakes. I doubt that this goal is really achieved, for two reasons: * On modern desktop environments, it's not really so strange to start two or more TLS connections within the same second. When this occurs, the gmt_unix_time fails in its intended purpose of preventing repeated Random values. * Nonwithstanding the gmt_unix_time workaround, TLS in general does not withstand broken PRNGs. For one example, if an implementation's PRNG is prone to repeating ClientRandom values, it is probably prone to repeating those some values as ephemeral Diffie-Hellman private values. Nevertheless, if the goal of providing unique-looking output WHY ELSE IS gmt_unix_time USED? The consensus among implementors I've asked seems to be that it's unwise to depend on any particular value or interpretation for the field. The TLS 1.2 standard, RFC 5246, says that "Clocks are not required to be set correctly by the basic TLS protocol; higher-level or application protocols may define additional requirements." Some implementations set the entire gmt_unix_time field randomly; this appears not to have broken TLS on the internet. At least one tool (tlsdate) uses the server-side value of the field as an authenticated view of the current time. PROPOSAL 1: Declare that implementations MAY replace gmt_unix_time either with four more random bytes, or four bytes of zeroes. Rationale: * Some implementations (like TorBrowser) are already doing this in practice. * It's sensible and simple. Implementors are quite unlikely to mess it up. PROPOSAL 2: Suppose that we do not accept the argument about the pointlessness of gmt_unit_time that I make above, and we want to preserve the security it allegedly provides. In that case, we can allow the following approach instead: Set the Random field, not to 32 bytes from your PRNG, but to the HMAC-SHA256 of any high resolution timer that you have, using 32 bytes from your PRNG as a key. In other words, replace this: Random.gmt_unix_time = time(); Random.random_bytes = get_random_bytes(28) with this: now = hires_time(); // clock_gettime(), or concatenate time() // with a CPU timer, or process // uptime, or whatever. key = get_random_bytes(32); Random = hmac_sha256(key, now); This approach is better than the status quo on the following counts: * It doesn't leak your view of the current time, assuming that your PRNG isn't busted. * It actually fixes the problem that gmt_unix_time purported to fix, by using a high-resolution time that's much less likely to be used twice. Even if the PRNG is broken, the value is still nonrepeating. I do not think this is not worse than the status quo: * It is unpredictable from an attacker's POV, assuming that the PRNG works. (Because an HMAC, even of known data, with an unknown random key is supposed to look random). PROPOSAL 3 As a hybrid alternative, one could set part of the ClientRandom field (perhaps 12 bytes or so) based on the HMAC of the time, and the rest of the ClientRandom field based on the PRNG: N = 12 now = hires_time(); key = get_random_bytes(32); mac = hmac_sha256(key, now)[0:N]; // First N bytes. rand = get_random_bytes(32 - N) Random = mac ++ rand // concatenate. But this seems to be getting pointlessly baroque. CONSIDERATIONS: I'd personally suggest proposal 1 (just set the field at random) for most users. Yes, it makes things a little worse if your PRNG can generate repeat values... but nearly everything in cryptography fails if your PRNG is broken. We might want to apply this fix on clients only. With a few exceptions (like hidden services) the server's view of the current time is not sensitive. Implementors might want to make this feature optional and on-by-default, just in case some higher-level application protocol really does depend on it. From alfredo@pironti.eu Wed Sep 11 09:02:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1028111E819A for ; Wed, 11 Sep 2013 09:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCvVgCa9Z3xf for ; Wed, 11 Sep 2013 09:01:59 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 17DAF21F9EF5 for ; Wed, 11 Sep 2013 09:01:35 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so9622839oag.28 for ; Wed, 11 Sep 2013 09:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ML45jckKmiieBXUAexsO3KA4VmLZzVn/wQxfmWHXMcA=; b=XGBeb2dNTA2fgmq7dCKlTk/fba7qEGVO4I7aao0/P7znkH0UK8k8CFjFfqz8qKOJgE wYQ/UQqrQxDedRQc6wr+MqxfWRUgK7pdhW8AY+UKs53V/O+m7lHUPMW7Hc/KuowINL/g 1hnZDCKO16kzUH4/G2TaGdu0FQiZAQNIXUMR0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ML45jckKmiieBXUAexsO3KA4VmLZzVn/wQxfmWHXMcA=; b=ZLWv+YYWSiuhPwkONsbB/bSh4tRppAzsr1aFATDEhQcW2tojTjpq53gfNgPt1lX06r 7nvBQ6Pa19QBJKlYjgOSGPYZJAjsFUM9jc9Ce+ilNDgKjVjPJyTEXIfQb/D8QimBMz87 +ZCW7iQd/ZkPFdBkpP+yAY6x3/oBU3/ySeURdFue2smJnZQfcMJYQUm35b5xcULAKgeu NhJLPU2B5MSS9SOBW2V26dckR1xOlEKGyVbeo0A74Xr/nrKbgt12+WEBGYUL5p1uvV04 rSHavPdgdT6ivQTAaTwgUgRe/W+SQa8qCfp7o3TQhgXF9TMarnheY63hc+yKkFqjlbDp q+WA== X-Gm-Message-State: ALoCoQmEub32OemrVhVfDJb68cvD9+7aaOvQEV/5Hhi8D77dOFGU/4LAfeAuoGerJmJZtbUYFvji MIME-Version: 1.0 X-Received: by 10.60.120.69 with SMTP id la5mr1469659oeb.86.1378915294027; Wed, 11 Sep 2013 09:01:34 -0700 (PDT) Received: by 10.76.80.201 with HTTP; Wed, 11 Sep 2013 09:01:33 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: References: Date: Wed, 11 Sep 2013 18:01:33 +0200 Message-ID: From: Alfredo Pironti To: Nick Mathewson Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 11 Sep 2013 10:11:09 -0700 Cc: perpass@ietf.org, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 16:02:15 -0000 I'm in favor of proposal 1, and second the considerations about it; essentially, a broken crypto implementation cannot be fixed by a timestamp. If proposal 2 (and 3) was to be implemented on a server, it would also make DoS easier, because a cheap ClientHello (even generated with weak randomness) would trigger an extra HMAC computation on the server, with respect to the current server load. Hence, relying on PRNG on both client and server sides looks like a reasonable way to go. I also don't particularly like the asymmetry that proposal 2 may bring: client generating randomness with HMAC, and servers still using the timestamp in clear. Cheers, Alfredo On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson wrote: > Hi, all. > > Here's something I wrote about removing a fingerprinting opportunity > from the current TLS protocol. I was going to just send it to the tls > list, but Ben Laurie suggested that I send it to the perpass list as > well. > > I have little standards-body experience; if this ought to turn into an > RFC or something, I'd be happy to write a draft if need be. > > > (Tor currently plans to implement this by patching OpenSSL; any > feedback or advice would be appreciated. The first three approaches > below are implemented in OpenSSL branches named "no_client_timestamp", > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git > repository at https://github.com/nmathewson/openssl . We have long > shipped our privacy-enhanced browser with a feature like this enabled > through an NSS patch.) > > > ==== > SYNOPSIS: > > In TLS as currently specified, clients and servers each send their > current view of "the time" in the clear as part of their handshake. > This provides a fingerprint that can track users in spite of other > attempts to make them untrackable. I propose several ways to stop > doing sending this cleartext timestamp; some trivial and some more > complex. > > > ACKNOWLEDGEMENTS: > > Thanks to Adam Langley, Ben Laurie, and everybody else who gave me > feedback here. > > > PROBLEM: > > The gmt_unix_time field in the Random field in the TLS handshake > provides a way for an observer to fingerprint clients. > > Despite the late date, much of the world is still not > synchronized to the second via an ntp-like service. This means > that different clients have different views of the current time, > which provides a fingerprint that helps to track and distinguish > them. This fingerprint is useful for tracking clients as they > move around. It can also distinguish clients using a single VPN, > NAT, or privacy network. (Tor's modified firefox avoids this by > not sending the time.) > > Worse, some implementations don't send the current time, but the > process time, or the computer's uptime, both of which are far > more distinguishing than the current time() value. > > The information fingerprint here is strong enough to uniquely > identify some TLS users (the ones whose clocks are hours off). > Even for the ones whose clocks are mostly right (within a second > or two), the field leaks a bit of information, and it only takes > so many bits to make a user unique. > > Of course, I realize that the gmt_unix_time fingerprint is not the > only way to track a typical client as it moves from network to > network, and not the only way to distinguish different clients > behind a NAT. > > > > BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE? > > According to third-hand reports (and correct me if I'm wrong!) > gmt_unix_time was introduced in SSL 3.0 to prevent complete failure > in cases where the PRNG was completely broken, by making a part of > the Random field that would definitely vary between TLS handshakes. > > I doubt that this goal is really achieved, for two reasons: > > * On modern desktop environments, it's not really so strange to > start two or more TLS connections within the same second. When > this occurs, the gmt_unix_time fails in its intended purpose of > preventing repeated Random values. > > * Nonwithstanding the gmt_unix_time workaround, TLS in general > does not withstand broken PRNGs. For one example, if an > implementation's PRNG is prone to repeating ClientRandom > values, it is probably prone to repeating those some values as > ephemeral Diffie-Hellman private values. > > Nevertheless, if the goal of providing unique-looking output > > > > WHY ELSE IS gmt_unix_time USED? > > The consensus among implementors I've asked seems to be that it's > unwise to depend on any particular value or interpretation for the > field. The TLS 1.2 standard, RFC 5246, says that "Clocks are not > required to be set correctly by the basic TLS protocol; higher-level > or application protocols may define additional requirements." > > Some implementations set the entire gmt_unix_time field randomly; > this appears not to have broken TLS on the internet. > > At least one tool (tlsdate) uses the server-side value of the > field as an authenticated view of the current time. > > > > PROPOSAL 1: > > Declare that implementations MAY replace gmt_unix_time either with > four more random bytes, or four bytes of zeroes. > > Rationale: > * Some implementations (like TorBrowser) are already doing this > in practice. > > * It's sensible and simple. Implementors are quite unlikely to > mess it up. > > > > PROPOSAL 2: > > Suppose that we do not accept the argument about the pointlessness > of gmt_unit_time that I make above, and we want to preserve the > security it allegedly provides. > > In that case, we can allow the following approach instead: > > Set the Random field, not to 32 bytes from your PRNG, but to the > HMAC-SHA256 of any high resolution timer that you have, using 32 > bytes from your PRNG as a key. In other words, replace this: > > Random.gmt_unix_time = time(); > Random.random_bytes = get_random_bytes(28) > > with this: > > now = hires_time(); // clock_gettime(), or concatenate time() > // with a CPU timer, or process > // uptime, or whatever. > key = get_random_bytes(32); > Random = hmac_sha256(key, now); > > This approach is better than the status quo on the following > counts: > > * It doesn't leak your view of the current time, assuming that > your PRNG isn't busted. > > * It actually fixes the problem that gmt_unix_time purported to > fix, by using a high-resolution time that's much less likely to > be used twice. Even if the PRNG is broken, the value is still > nonrepeating. > > I do not think this is not worse than the status quo: > > * It is unpredictable from an attacker's POV, assuming that the > PRNG works. (Because an HMAC, even of known data, with an > unknown random key is supposed to look random). > > > PROPOSAL 3 > > As a hybrid alternative, one could set part of the ClientRandom > field (perhaps 12 bytes or so) based on the HMAC of the time, and > the rest of the ClientRandom field based on the PRNG: > > N = 12 > > now = hires_time(); > key = get_random_bytes(32); > mac = hmac_sha256(key, now)[0:N]; // First N bytes. > rand = get_random_bytes(32 - N) > Random = mac ++ rand // concatenate. > > But this seems to be getting pointlessly baroque. > > > > CONSIDERATIONS: > > I'd personally suggest proposal 1 (just set the field at random) for > most users. Yes, it makes things a little worse if your PRNG can > generate repeat values... but nearly everything in cryptography > fails if your PRNG is broken. > > > We might want to apply this fix on clients only. With a few > exceptions (like hidden services) the server's view of the current > time is not sensitive. > > > Implementors might want to make this feature optional and > on-by-default, just in case some higher-level application protocol > really does depend on it. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ryan.hurst@globalsign.com Wed Sep 11 09:20:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BAB21E8169 for ; Wed, 11 Sep 2013 09:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jf3y5gfxeyz for ; Wed, 11 Sep 2013 09:20:08 -0700 (PDT) Received: from mail-ye0-x233.google.com (mail-ye0-x233.google.com [IPv6:2607:f8b0:4002:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1721E815F for ; Wed, 11 Sep 2013 09:19:19 -0700 (PDT) Received: by mail-ye0-f179.google.com with SMTP id r6so3142334yen.38 for ; Wed, 11 Sep 2013 09:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=CW27Ym4IxTmglMMGPlvf0q8b40jRRYeo/RgW7BUgXl4=; b=O4ZDCmauhxBhNXxypY82nbLb+Mc2qDvpz50wVD34QxF21uFsowmYV2M0fzfiyqjlHD hg4q7fok7rRLwJyJVR2jd+rspZsb890G1LvSS/ZSr5D93ntnWYKNIw3ifysNfjSfdV34 Us0/aSodiKVQS0NUIXbQ5+8Um/kHs8PjJlkHk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=CW27Ym4IxTmglMMGPlvf0q8b40jRRYeo/RgW7BUgXl4=; b=ju/3oPJcazR+AJMg8AMro/9NbWiL+8EDLIrYBfMKXsk3JWBD/FMq0Mw4ujR0Tzq69G c+MEVyOfbkw5ZG6BEqqSqhfWJ/FKw01zD9sfmvway3FpuzzGRrAOLmpA4gHXgadeMQRc X1Shtwh08xJdWShleH7TnwvA5Tk1O0hrXcZ7Fs0U1HtbEiEHAJkjaZ+fDer0DD7OVgEa UvjjEwSB4P/qOKwDlVsXcvnKhgAe6GUl75+a3+Dy1aefN5sozpR6sRmxrbpJn4lXHo5M y+gHwWucHYQ5VWsGE1SVNVb4j+IcIa8YaO4i4hewWiqNYF5ytSyQaQE2sOBLKL5pC1k5 puWw== X-Gm-Message-State: ALoCoQkOxduI07cpHd2fnHEA7sBBi02F6+q8gIsZQj11jfmsv1zNXyaZxWqZlvtLu+L7sIrul4xx X-Received: by 10.236.171.195 with SMTP id r43mr2180422yhl.56.1378916354477; Wed, 11 Sep 2013 09:19:14 -0700 (PDT) Received: from [10.215.131.49] (mobile-166-147-082-236.mycingular.net. [166.147.82.236]) by mx.google.com with ESMTPSA id w42sm33505874yhb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 09:19:12 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-92561D84-7739-4029-9D31-66A0E1FC071C; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <19AD06BF-648C-43F7-A076-A98CFA0E85C7@globalsign.com> X-Mailer: iPhone Mail (10B329) From: Ryan Hurst Date: Wed, 11 Sep 2013 09:19:06 -0700 To: Eric Rescorla X-Mailman-Approved-At: Wed, 11 Sep 2013 10:10:59 -0700 Cc: "perpass@ietf.org" , "tls@ietf.org" , Alfredo Pironti Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 16:20:08 -0000 --Apple-Mail-92561D84-7739-4029-9D31-66A0E1FC071C Content-Type: multipart/alternative; boundary=Apple-Mail-6464FC36-C1BE-4E70-BAEC-A79B182D7507 Content-Transfer-Encoding: 7bit --Apple-Mail-6464FC36-C1BE-4E70-BAEC-A79B182D7507 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I have looked at this some, network appliances such as F5s Big IP use a rand= om value instead of time. I recall seeing some clients also do this but I don't recall which ones. Basically such a change should be safe. That said as Russ has pointed out TPSDATE uses this mechanism and though it d= oesn't solve a broken cryptographic subsystem it is kind of belt and suspend= ers approach. Ryan Hurst Chief Technology Officer GMO Globalsign twitter: @rmhrisk email: ryan.hurst@globalsign.com phone: 206-650-7926 Sent from my phone, please forgive the brevity. On Sep 11, 2013, at 9:06 AM, Eric Rescorla wrote: > Before we discuss mechanisms, it would be good to verify that in general > clients and servers don't become unhappy if the timestamp is radically > wrong. Has someone done measurements to verify that this is in fact > the case at a broad scale? >=20 > -Ekr >=20 >=20 >=20 > On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti wrot= e: >> I'm in favor of proposal 1, and second the considerations about it; >> essentially, a broken crypto implementation cannot be fixed by a >> timestamp. >>=20 >> If proposal 2 (and 3) was to be implemented on a server, it would also >> make DoS easier, because a cheap ClientHello (even generated with weak >> randomness) would trigger an extra HMAC computation on the server, >> with respect to the current server load. >>=20 >> Hence, relying on PRNG on both client and server sides looks like a >> reasonable way to go. I also don't particularly like the asymmetry >> that proposal 2 may bring: client generating randomness with HMAC, and >> servers still using the timestamp in clear. >>=20 >> Cheers, >> Alfredo >>=20 >> On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson wr= ote: >> > Hi, all. >> > >> > Here's something I wrote about removing a fingerprinting opportunity >> > from the current TLS protocol. I was going to just send it to the tls >> > list, but Ben Laurie suggested that I send it to the perpass list as >> > well. >> > >> > I have little standards-body experience; if this ought to turn into an >> > RFC or something, I'd be happy to write a draft if need be. >> > >> > >> > (Tor currently plans to implement this by patching OpenSSL; any >> > feedback or advice would be appreciated. The first three approaches >> > below are implemented in OpenSSL branches named "no_client_timestamp", >> > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git >> > repository at https://github.com/nmathewson/openssl . We have long >> > shipped our privacy-enhanced browser with a feature like this enabled >> > through an NSS patch.) >> > >> > >> > =3D=3D=3D=3D >> > SYNOPSIS: >> > >> > In TLS as currently specified, clients and servers each send their >> > current view of "the time" in the clear as part of their handshake. >> > This provides a fingerprint that can track users in spite of other >> > attempts to make them untrackable. I propose several ways to stop >> > doing sending this cleartext timestamp; some trivial and some more >> > complex. >> > >> > >> > ACKNOWLEDGEMENTS: >> > >> > Thanks to Adam Langley, Ben Laurie, and everybody else who gave me >> > feedback here. >> > >> > >> > PROBLEM: >> > >> > The gmt_unix_time field in the Random field in the TLS handshake >> > provides a way for an observer to fingerprint clients. >> > >> > Despite the late date, much of the world is still not >> > synchronized to the second via an ntp-like service. This means >> > that different clients have different views of the current time, >> > which provides a fingerprint that helps to track and distinguish >> > them. This fingerprint is useful for tracking clients as they >> > move around. It can also distinguish clients using a single VPN, >> > NAT, or privacy network. (Tor's modified firefox avoids this by >> > not sending the time.) >> > >> > Worse, some implementations don't send the current time, but the >> > process time, or the computer's uptime, both of which are far >> > more distinguishing than the current time() value. >> > >> > The information fingerprint here is strong enough to uniquely >> > identify some TLS users (the ones whose clocks are hours off). >> > Even for the ones whose clocks are mostly right (within a second >> > or two), the field leaks a bit of information, and it only takes >> > so many bits to make a user unique. >> > >> > Of course, I realize that the gmt_unix_time fingerprint is not the >> > only way to track a typical client as it moves from network to >> > network, and not the only way to distinguish different clients >> > behind a NAT. >> > >> > >> > >> > BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE? >> > >> > According to third-hand reports (and correct me if I'm wrong!) >> > gmt_unix_time was introduced in SSL 3.0 to prevent complete failure >> > in cases where the PRNG was completely broken, by making a part of >> > the Random field that would definitely vary between TLS handshakes. >> > >> > I doubt that this goal is really achieved, for two reasons: >> > >> > * On modern desktop environments, it's not really so strange to >> > start two or more TLS connections within the same second. When >> > this occurs, the gmt_unix_time fails in its intended purpose of >> > preventing repeated Random values. >> > >> > * Nonwithstanding the gmt_unix_time workaround, TLS in general >> > does not withstand broken PRNGs. For one example, if an >> > implementation's PRNG is prone to repeating ClientRandom >> > values, it is probably prone to repeating those some values as >> > ephemeral Diffie-Hellman private values. >> > >> > Nevertheless, if the goal of providing unique-looking output >> > >> > >> > >> > WHY ELSE IS gmt_unix_time USED? >> > >> > The consensus among implementors I've asked seems to be that it's >> > unwise to depend on any particular value or interpretation for the >> > field. The TLS 1.2 standard, RFC 5246, says that "Clocks are not >> > required to be set correctly by the basic TLS protocol; higher-level >> > or application protocols may define additional requirements." >> > >> > Some implementations set the entire gmt_unix_time field randomly; >> > this appears not to have broken TLS on the internet. >> > >> > At least one tool (tlsdate) uses the server-side value of the >> > field as an authenticated view of the current time. >> > >> > >> > >> > PROPOSAL 1: >> > >> > Declare that implementations MAY replace gmt_unix_time either with >> > four more random bytes, or four bytes of zeroes. >> > >> > Rationale: >> > * Some implementations (like TorBrowser) are already doing this >> > in practice. >> > >> > * It's sensible and simple. Implementors are quite unlikely to >> > mess it up. >> > >> > >> > >> > PROPOSAL 2: >> > >> > Suppose that we do not accept the argument about the pointlessness >> > of gmt_unit_time that I make above, and we want to preserve the >> > security it allegedly provides. >> > >> > In that case, we can allow the following approach instead: >> > >> > Set the Random field, not to 32 bytes from your PRNG, but to the >> > HMAC-SHA256 of any high resolution timer that you have, using 32 >> > bytes from your PRNG as a key. In other words, replace this: >> > >> > Random.gmt_unix_time =3D time(); >> > Random.random_bytes =3D get_random_bytes(28) >> > >> > with this: >> > >> > now =3D hires_time(); // clock_gettime(), or concatenate time() >> > // with a CPU timer, or process >> > // uptime, or whatever. >> > key =3D get_random_bytes(32); >> > Random =3D hmac_sha256(key, now); >> > >> > This approach is better than the status quo on the following >> > counts: >> > >> > * It doesn't leak your view of the current time, assuming that >> > your PRNG isn't busted. >> > >> > * It actually fixes the problem that gmt_unix_time purported to >> > fix, by using a high-resolution time that's much less likely to >> > be used twice. Even if the PRNG is broken, the value is still >> > nonrepeating. >> > >> > I do not think this is not worse than the status quo: >> > >> > * It is unpredictable from an attacker's POV, assuming that the >> > PRNG works. (Because an HMAC, even of known data, with an >> > unknown random key is supposed to look random). >> > >> > >> > PROPOSAL 3 >> > >> > As a hybrid alternative, one could set part of the ClientRandom >> > field (perhaps 12 bytes or so) based on the HMAC of the time, and >> > the rest of the ClientRandom field based on the PRNG: >> > >> > N =3D 12 >> > >> > now =3D hires_time(); >> > key =3D get_random_bytes(32); >> > mac =3D hmac_sha256(key, now)[0:N]; // First N bytes. >> > rand =3D get_random_bytes(32 - N) >> > Random =3D mac ++ rand // concatenate. >> > >> > But this seems to be getting pointlessly baroque. >> > >> > >> > >> > CONSIDERATIONS: >> > >> > I'd personally suggest proposal 1 (just set the field at random) for >> > most users. Yes, it makes things a little worse if your PRNG can >> > generate repeat values... but nearly everything in cryptography >> > fails if your PRNG is broken. >> > >> > >> > We might want to apply this fix on clients only. With a few >> > exceptions (like hidden services) the server's view of the current >> > time is not sensitive. >> > >> > >> > Implementors might want to make this feature optional and >> > on-by-default, just in case some higher-level application protocol >> > really does depend on it. >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-6464FC36-C1BE-4E70-BAEC-A79B182D7507 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I have looked at this some, network appliances such as F5s Big IP u= se a random value instead of time.

I recall seeing s= ome clients also do this but I don't recall which ones.

=
Basically such a change should be safe.

That s= aid as Russ has pointed out TPSDATE uses this mechanism and though it doesn'= t solve a broken cryptographic subsystem it is kind of belt and suspenders a= pproach.

Ryan Hurst

twitter: @rmhrisk
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

O= n Sep 11, 2013, at 9:06 AM, Eric Rescorla <ekr@rtfm.com> wrote:

Before we discuss mechanisms, it would be good to verify that= in general
clients and servers don't become unhappy if the timestamp is= radically
wrong. Has someone done measurements to verify that thi= s is in fact
the case at a broad scale?

-Ekr

=


On= Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti <alfredo@pironti.eu><= /span> wrote:
I'm in favor of proposal 1, and second the con= siderations about it;
essentially, a broken crypto implementation cannot be fixed by a
timestamp.

If proposal 2 (and 3) was to be implemented on a server, it would also
make DoS easier, because a cheap ClientHello (even generated with weak
randomness) would trigger an extra HMAC computation on the server,
with respect to the current server load.

Hence, relying on PRNG on both client and server sides looks like a
reasonable way to go. I also don't particularly like the asymmetry
that proposal 2 may bring: client generating randomness with HMAC, and
servers still using the timestamp in clear.

Cheers,
Alfredo

On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson <nickm@torproject.org> wrote:
> Hi, all.
>
> Here's something I wrote about removing a fingerprinting opportunity > from the current TLS protocol.  I was going to just send it to the= tls
> list, but Ben Laurie suggested that I send it to the perpass list as > well.
>
> I have little standards-body experience; if this ought to turn into an<= br> > RFC or something, I'd be happy to write a draft if need be.
>
>
> (Tor currently plans to implement this by patching OpenSSL; any
> feedback or advice would be appreciated.  The first three approach= es
> below are implemented in OpenSSL branches named "no_client_timestamp",<= br> > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git
> repository at https://github.com/nmathewson/openssl .  We have long
> shipped our privacy-enhanced browser with a feature like this enabled > through an NSS patch.)
>
>
> =3D=3D=3D=3D
> SYNOPSIS:
>
> In TLS as currently specified, clients and servers each send their
> current view of "the time" in the clear as part of their handshake.
= > This provides a fingerprint that can track users in spite of other
> attempts to make them untrackable.  I propose several ways to stop=
> doing sending this cleartext timestamp; some trivial and some more
> complex.
>
>
> ACKNOWLEDGEMENTS:
>
> Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
> feedback here.
>
>
> PROBLEM:
>
> The gmt_unix_time field in the Random field in the TLS handshake
> provides a way for an observer to fingerprint clients.
>
> Despite the late date, much of the world is still not
> synchronized to the second via an ntp-like service. This means
> that different clients have different views of the current time,
> which provides a fingerprint that helps to track and distinguish
> them.  This fingerprint is useful for tracking clients as they
= > move around.  It can also distinguish clients using a single VPN,<= br> > NAT, or privacy network.  (Tor's modified firefox avoids this by > not sending the time.)
>
> Worse, some implementations don't send the current time, but the
> process time, or the computer's uptime, both of which are far
> more distinguishing than the current time() value.
>
> The information fingerprint here is strong enough to uniquely
> identify some TLS users (the ones whose clocks are hours off).
> Even for the ones whose clocks are mostly right (within a second
> or two), the field leaks a bit of information, and it only takes
> so many bits to make a user unique.
>
> Of course, I realize that the gmt_unix_time fingerprint is not the
> only way to track a typical client as it moves from network to
> network, and not the only way to distinguish different clients
> behind a NAT.
>
>
>
> BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?
>
> According to third-hand reports (and correct me if I'm wrong!)
> gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
= > in cases where the PRNG was completely broken, by making a part of
> the Random field that would definitely vary between TLS handshakes.
= >
> I doubt that this goal is really achieved, for two reasons:
>
>    * On modern desktop environments, it's not really so stran= ge to
>      start two or more TLS connections within the same s= econd.  When
>      this occurs, the gmt_unix_time fails in its intende= d purpose of
>      preventing repeated Random values.
>
>    * Nonwithstanding the gmt_unix_time workaround, TLS in gen= eral
>      does not withstand broken PRNGs.  For one exam= ple, if an
>      implementation's PRNG is prone to repeating ClientR= andom
>      values, it is probably prone to repeating those som= e values as
>      ephemeral Diffie-Hellman private values.
>
> Nevertheless, if the goal of providing unique-looking output
>
>
>
> WHY ELSE IS gmt_unix_time USED?
>
> The consensus among implementors I've asked seems to be that it's
> unwise to depend on any particular value or interpretation for the
> field.  The TLS 1.2 standard, RFC 5246, says that "Clocks are not<= br> > required to be set correctly by the basic TLS protocol; higher-level > or application protocols may define additional requirements."
>
> Some implementations set the entire gmt_unix_time field randomly;
> this appears not to have broken TLS on the internet.
>
> At least one tool (tlsdate) uses the server-side value of the
> field as an authenticated view of the current time.
>
>
>
> PROPOSAL 1:
>
> Declare that implementations MAY replace gmt_unix_time either with
> four more random bytes, or four bytes of zeroes.
>
> Rationale:
>    * Some implementations (like TorBrowser) are already doing= this
>      in practice.
>
>    * It's sensible and simple.  Implementors are quite u= nlikely to
>      mess it up.
>
>
>
> PROPOSAL 2:
>
> Suppose that we do not accept the argument about the pointlessness
> of gmt_unit_time that I make above, and we want to preserve the
> security it allegedly provides.
>
> In that case, we can allow the following approach instead:
>
> Set the Random field, not to 32 bytes from your PRNG, but to the
> HMAC-SHA256 of any high resolution timer that you have, using 32
> bytes from your PRNG as a key.  In other words, replace this:
>
>    Random.gmt_unix_time =3D time();
>    Random.random_bytes =3D get_random_bytes(28)
>
> with this:
>
>    now =3D hires_time(); // clock_gettime(), or concatenate t= ime()
>                     &= nbsp;  // with a CPU timer, or process
>                     &= nbsp;  // uptime, or whatever.
>    key =3D get_random_bytes(32);
>    Random =3D hmac_sha256(key, now);
>
> This approach is better than the status quo on the following
> counts:
>
>    * It doesn't leak your view of the current time, assuming t= hat
>      your PRNG isn't busted.
>
>    * It actually fixes the problem that gmt_unix_time purport= ed to
>      fix, by using a high-resolution time that's much le= ss likely to
>      be used twice.  Even if the PRNG is broken, th= e value is still
>      nonrepeating.
>
> I do not think this is not worse than the status quo:
>
>    * It is unpredictable from an attacker's POV, assuming tha= t the
>      PRNG works.  (Because an HMAC, even of known d= ata, with an
>      unknown random key is supposed to look random).
= >
>
> PROPOSAL 3
>
> As a hybrid alternative, one could set part of the ClientRandom
> field (perhaps 12 bytes or so) based on the HMAC of the time, and
> the rest of the ClientRandom field based on the PRNG:
>
>    N =3D 12
>
>    now =3D hires_time();
>    key =3D get_random_bytes(32);
>    mac =3D hmac_sha256(key, now)[0:N];  // First N bytes= .
>    rand =3D get_random_bytes(32 - N)
>    Random =3D mac ++ rand           &= nbsp;   // concatenate.
>
> But this seems to be getting pointlessly baroque.
>
>
>
> CONSIDERATIONS:
>
> I'd personally suggest proposal 1 (just set the field at random) for > most users.  Yes, it makes things a little worse if your PRNG can<= br> > generate repeat values... but nearly everything in cryptography
> fails if your PRNG is broken.
>
>
> We might want to apply this fix on clients only.  With a few
> exceptions (like hidden services) the server's view of the current
> time is not sensitive.
>
>
> Implementors might want to make this feature optional and
> on-by-default, just in case some higher-level application protocol
> really does depend on it.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
http= s://www.ietf.org/mailman/listinfo/tls

____________________= ___________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/lis= tinfo/tls
= --Apple-Mail-6464FC36-C1BE-4E70-BAEC-A79B182D7507-- --Apple-Mail-92561D84-7739-4029-9D31-66A0E1FC071C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFCjCCBQYw ggPuoAMCAQICEhEhb640/F3CUxHuqwZT6bSC5TANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIEcyMB4XDTEyMDEyMzE2MzY1OVoXDTE1MDEyMzE2MzY1OVowgZQxCzAJBgNV BAYTAlVTMRYwFAYDVQQIEw1OZXcgSGFtc3BoaXJlMRMwEQYDVQQHEwpQb3J0c21vdXRoMRkwFwYD VQQKExBHbG9iYWxTaWduLCBJbmMuMRMwEQYDVQQDEwpSeWFuIEh1cnN0MSgwJgYJKoZIhvcNAQkB FhlyeWFuLmh1cnN0QGdsb2JhbHNpZ24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAuAEkk72r5rBUAKG+tLpEksDgC/Z0/7PfZbTVAgH+Xzx+YzXHjCsWkLHtpojpkUSF2spHKtaf 02yO9GbXHt/K9pmzsKgxxz1YtdxsSRMlF1oGkQbXgzLuThsljRtZHIVbBlqW7LU9GeL9JneZtQWB Z8QdtHmycjkdpVw8bBStvJ5ylfuXjI++lPAaT0OEgh+8kzBustF17Ad3AqwSq9qN0zmIBCr/qDZ2 2qDLd1MTLfZ0n/Y8iLIY6n50+QHsNwlDTGrTueYORV13SLpAMHoNWEm9ZbNOalt7FtNE93e3ULPf +zbsQoPwNnpZlSUqMvPjC0fCUhRH/2jIIzv08i4P4wIDAQABo4IBjzCCAYswDgYDVR0PAQH/BAQD AgWgME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAkBgNVHREEHTAbgRlyeWFuLmh1cnN0QGdsb2JhbHNp Z24uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3NwZXJzb25hbHNpZ24yZzIu Y3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDovL3NlY3VyZS5nbG9iYWxzaWdu LmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yZzIuY3J0MB0GA1UdDgQWBBRVohAntPy+9nlWKnFm Jy1ekko84TAfBgNVHSMEGDAWgBQ/FdJtfC/nMZ5DCgaolGwsO8XuZTANBgkqhkiG9w0BAQUFAAOC AQEAIUIuoSz3rnZn9yAReCA8wr0SNBWmHQSn6a0pPx9Dw3muL6bC21qQNLdEmoo4iWLcSo5TOGz3 ftnIW+3o2rQ3cq2SM5g1cquHN9P8TJ4pxiqJKWANdf1Xvotnb47pbuuamrK7UERsmwLrmeu5a6fy tzjBYI1eTQtwB2C87zVOA8HOEENQWjDoOis2EqymwAUWWo366Qvbonj7L+5gyFy8f7aAT8VjZWub yZuQ62XZ+7h3bwQhOpDMpGzizeaZhCtFCJcCoekIuVw9Kc5VZBGZYhZATCYLm3f3he8XoO0yj1gu ccjhafUnTKJSTOy0wt8J0jt36wQHr/qv5xrPV8cr7DGCAuowggLmAgEBMGowVDELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u YWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMAkGBSsOAwIaBQCgggFVMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDkxMTE2MTkxMVowIwYJKoZI hvcNAQkEMRYEFA9l55StJEHWXDenpxYkDBIbq2u7MHkGCSsGAQQBgjcQBDFsMGowVDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMHsGCyqGSIb3DQEJEAILMWyg ajBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIEcyAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZI hvcNAQEBBQAEggEAQrQEK8WGsJVldIBkiyuHse0q8y529bqlfeB6OtsnfDRhivnQ4eQLIbIOY6A0 KUPwBQSYYbUEGgMIU2lZ2S5TLmxltLDLcZY+2ZxPNcRj9H0jL1kMQmJXki16GeIsGxZL+Ixr7QXe dPgr68Chxs/qTTY/q559l3s4CIbxMEMwhLrIam4BaUGcWk3Xb++cGhkXqu/pKELdGHtJR2EtuOFU MgEN1uitlQKIv2ytprB9P8KQTW6c0kDesyhe8UVmdpieh8LhtS54+FQyhm/Kn2isH9Q/dCf7bhZH 4rkQVK7Pqu8JcpCSwpYa+S7LiVty0svAC+Fo3fQaEblrbzK9dyxRoAAAAAAAAA== --Apple-Mail-92561D84-7739-4029-9D31-66A0E1FC071C-- From paul@nohats.ca Wed Sep 11 09:40:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CF411E8192; Wed, 11 Sep 2013 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrpSwwPcr80N; Wed, 11 Sep 2013 09:40:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0F03E11E80FF; Wed, 11 Sep 2013 09:40:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cZpkm6Sj9z9HG; Wed, 11 Sep 2013 12:40:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bcVp358nAtXF; Wed, 11 Sep 2013 12:40:31 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 11 Sep 2013 12:40:31 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 32180848E5; Wed, 11 Sep 2013 12:40:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0A888848E4; Wed, 11 Sep 2013 12:40:31 -0400 (EDT) Date: Wed, 11 Sep 2013 12:40:31 -0400 (EDT) From: Paul Wouters To: Russ Housley In-Reply-To: <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com> Message-ID: References: <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Wed, 11 Sep 2013 10:11:07 -0700 Cc: Nick Mathewson , perpass@ietf.org, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 16:40:49 -0000 On Wed, 11 Sep 2013, Russ Housley wrote: > The tlsdate program (with origins in the TOR project) makes use of this value in the nonce portion of the handshake. > > I think that the time is an important part of the nonce. Even if the implementation has a crappy random number generator, the time value does a good job of ensuring that the nonce value is not repeated. Obviously, the time value does not help with the unpredictability, but the random value is supposed to do that. Note that tlsdate is a stowaway on board a TLS server. If we can accomodate, then fine. But we shouldn't go out of our way to support it. Between making tls less vulnerable to fingerprinting (which helps tor) and supporting tlsdate, I'd opt for the former. Paul From karl@petzent.com Wed Sep 11 10:32:05 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C4721F9477 for ; Wed, 11 Sep 2013 10:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.505 X-Spam-Level: *** X-Spam-Status: No, score=3.505 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv7X32CPBahi for ; Wed, 11 Sep 2013 10:31:58 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id AC56721F9C88 for ; Wed, 11 Sep 2013 10:31:56 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 11 Sep 2013 10:32:00 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 10:31:52 -0700 From: Karl Malbrain To: "perpass@ietf.org" Thread-Topic: proposed enhancement to TLS strong authentication protocol Thread-Index: Ac6vFM0oAaChRWR6StGXJtPmuw8x5w== Date: Wed, 11 Sep 2013 17:31:52 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E83742502A555mail2010_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Sep 2013 11:14:50 -0700 Subject: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 17:33:12 -0000 --_000_65EEC6E375AA474A847D510D5B7E83742502A555mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Goal: facilitate usage of TLS strong authentication over the internet to th= wart MITM attacks. Rather than have each TLS server receive user public certificates individua= lly for strong authentication, implement a global user public certificate l= ist hosted internationally that supplies user public certificates to TLS ho= sts and clients. The list would be read-only, indexed by GUID, and hosted a= t multiple international sites. Both TLS servers and clients could then rel= iably obtain public certificates by GUID for use in strong authentication c= hallenges per the TLS protocol. Karl Malbrain --_000_65EEC6E375AA474A847D510D5B7E83742502A555mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Goal: facilitate usage of TLS strong authentication = over the internet to thwart MITM attacks.

 

Rather than have each TLS server receive user public= certificates individually for strong authentication, implement a global us= er public certificate list hosted internationally that supplies user public= certificates to TLS hosts and clients. The list would be read-only, indexed by GUID, and hosted at multiple inter= national sites. Both TLS servers and clients could then reliably obtain pub= lic certificates by GUID for use in strong authentication challenges per th= e TLS protocol.

 

Karl Malbrain

--_000_65EEC6E375AA474A847D510D5B7E83742502A555mail2010_-- From mrex@sap.com Wed Sep 11 10:41:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C543A21F9CBF; Wed, 11 Sep 2013 10:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6-D2htg+pBb; Wed, 11 Sep 2013 10:41:37 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2151621F9A59; Wed, 11 Sep 2013 10:41:36 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8BHfZO7023037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Sep 2013 19:41:35 +0200 (MEST) In-Reply-To: To: Nick Mathewson Date: Wed, 11 Sep 2013 19:41:35 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130911174135.455A01A960@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out X-Mailman-Approved-At: Wed, 11 Sep 2013 11:14:50 -0700 Cc: perpass@ietf.org, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 17:41:43 -0000 Nick Mathewson wrote: > ==== > SYNOPSIS: > > In TLS as currently specified, clients and servers each send their > current view of "the time" in the clear as part of their handshake. > This provides a fingerprint that can track users in spite of other > attempts to make them untrackable. I propose several ways to stop > doing sending this cleartext timestamp; some trivial and some more > complex. I would really appreciate a different approach to the underlying issue, and less throwing of smoke grenades here. If you're worried about being slightly "distinguishable" from some other clients, then there are a lot more reliable identifiers available in the average TLS handshake, so claiming that sending the actual local time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting issue and sending random will solve the fingerprinting issue, is bordering on lame for >99% of the clients. Most of the time, repeated requests of the same TLS client can be identified by the network connection having the same client IP address, the TLS session proposed for resumption in ClientHello.session_id or maybe someone still using TLS session tickets (rfc5077). So rather than pointing to ClientHello.Random.gmt_unix_time as a and claiming there would be a simple fix, one will likely have to create and go through a long list of issues to determine which features facilitate fingerprinting and tracking (cipher suites and many TLS extensions (TLS caching extension, signature algorithms, Next protocol negotiation, supported elliptic curves, etc.) may all help in distinguishing clients, and would also have to be taken care of. -Martin From X.Wu@F5.com Wed Sep 11 11:23:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C465811E81F2; Wed, 11 Sep 2013 11:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cBwXX7tGCeG; Wed, 11 Sep 2013 11:23:36 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 817DA11E81D2; Wed, 11 Sep 2013 11:23:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,885,1371081600"; d="scan'208,217";a="81622733" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 11 Sep 2013 18:23:35 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 11 Sep 2013 11:23:34 -0700 From: Xiaoyong Wu To: Ryan Hurst , Eric Rescorla Thread-Topic: [TLS] Let's remove gmt_unix_time from TLS Thread-Index: AQHOrwriSahGkkxdq02hAgcmqMDbYJnA2WdA Date: Wed, 11 Sep 2013 18:23:33 +0000 Message-ID: References: <19AD06BF-648C-43F7-A076-A98CFA0E85C7@globalsign.com> In-Reply-To: <19AD06BF-648C-43F7-A076-A98CFA0E85C7@globalsign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_E774C81546D66E429BF56B1474C7EBBA010E33002ESEAEMBX01olym_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Sep 2013 11:24:44 -0700 Cc: "perpass@ietf.org" , "tls@ietf.org" , Alfredo Pironti Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:23:40 -0000 --_000_E774C81546D66E429BF56B1474C7EBBA010E33002ESEAEMBX01olym_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB3ZSBoYXZlIGJlZW4gdXNpbmcgcmFuZG9tIHZhbHVlcyBhbmQgaGF2ZSBub3QgZ290IGlu dG8gYW55IGlzc3VlcyB3aXRoIGNsaWVudHMvc2VydmVycy4NCg0KLVhpYW95b25nDQoNCkZyb206 IHRscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBSeWFuIEh1cnN0DQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMSwgMjAxMyA5 OjE5IEFNDQpUbzogRXJpYyBSZXNjb3JsYQ0KQ2M6IHBlcnBhc3NAaWV0Zi5vcmc7IHRsc0BpZXRm Lm9yZzsgQWxmcmVkbyBQaXJvbnRpDQpTdWJqZWN0OiBSZTogW1RMU10gTGV0J3MgcmVtb3ZlIGdt dF91bml4X3RpbWUgZnJvbSBUTFMNCg0KSSBoYXZlIGxvb2tlZCBhdCB0aGlzIHNvbWUsIG5ldHdv cmsgYXBwbGlhbmNlcyBzdWNoIGFzIEY1cyBCaWcgSVAgdXNlIGEgcmFuZG9tIHZhbHVlIGluc3Rl YWQgb2YgdGltZS4NCg0KSSByZWNhbGwgc2VlaW5nIHNvbWUgY2xpZW50cyBhbHNvIGRvIHRoaXMg YnV0IEkgZG9uJ3QgcmVjYWxsIHdoaWNoIG9uZXMuDQoNCkJhc2ljYWxseSBzdWNoIGEgY2hhbmdl IHNob3VsZCBiZSBzYWZlLg0KDQpUaGF0IHNhaWQgYXMgUnVzcyBoYXMgcG9pbnRlZCBvdXQgVFBT REFURSB1c2VzIHRoaXMgbWVjaGFuaXNtIGFuZCB0aG91Z2ggaXQgZG9lc24ndCBzb2x2ZSBhIGJy b2tlbiBjcnlwdG9ncmFwaGljIHN1YnN5c3RlbSBpdCBpcyBraW5kIG9mIGJlbHQgYW5kIHN1c3Bl bmRlcnMgYXBwcm9hY2guDQoNClJ5YW4gSHVyc3QNCkNoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlcg0K R01PIEdsb2JhbHNpZ24NCg0KdHdpdHRlcjogQHJtaHJpc2sNCmVtYWlsOiByeWFuLmh1cnN0QGds b2JhbHNpZ24uY29tPG1haWx0bzpyeWFuLmh1cnN0QGdsb2JhbHNpZ24uY29tPg0KcGhvbmU6IDIw Ni02NTAtNzkyNg0KDQpTZW50IGZyb20gbXkgcGhvbmUsIHBsZWFzZSBmb3JnaXZlIHRoZSBicmV2 aXR5Lg0KDQpPbiBTZXAgMTEsIDIwMTMsIGF0IDk6MDYgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBy dGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQpCZWZvcmUgd2UgZGlzY3VzcyBt ZWNoYW5pc21zLCBpdCB3b3VsZCBiZSBnb29kIHRvIHZlcmlmeSB0aGF0IGluIGdlbmVyYWwNCmNs aWVudHMgYW5kIHNlcnZlcnMgZG9uJ3QgYmVjb21lIHVuaGFwcHkgaWYgdGhlIHRpbWVzdGFtcCBp cyByYWRpY2FsbHkNCndyb25nLiBIYXMgc29tZW9uZSBkb25lIG1lYXN1cmVtZW50cyB0byB2ZXJp ZnkgdGhhdCB0aGlzIGlzIGluIGZhY3QNCnRoZSBjYXNlIGF0IGEgYnJvYWQgc2NhbGU/DQoNCi1F a3INCg0KDQpPbiBXZWQsIFNlcCAxMSwgMjAxMyBhdCA5OjAxIEFNLCBBbGZyZWRvIFBpcm9udGkg PGFsZnJlZG9AcGlyb250aS5ldTxtYWlsdG86YWxmcmVkb0BwaXJvbnRpLmV1Pj4gd3JvdGU6DQpJ J20gaW4gZmF2b3Igb2YgcHJvcG9zYWwgMSwgYW5kIHNlY29uZCB0aGUgY29uc2lkZXJhdGlvbnMg YWJvdXQgaXQ7DQplc3NlbnRpYWxseSwgYSBicm9rZW4gY3J5cHRvIGltcGxlbWVudGF0aW9uIGNh bm5vdCBiZSBmaXhlZCBieSBhDQp0aW1lc3RhbXAuDQoNCklmIHByb3Bvc2FsIDIgKGFuZCAzKSB3 YXMgdG8gYmUgaW1wbGVtZW50ZWQgb24gYSBzZXJ2ZXIsIGl0IHdvdWxkIGFsc28NCm1ha2UgRG9T IGVhc2llciwgYmVjYXVzZSBhIGNoZWFwIENsaWVudEhlbGxvIChldmVuIGdlbmVyYXRlZCB3aXRo IHdlYWsNCnJhbmRvbW5lc3MpIHdvdWxkIHRyaWdnZXIgYW4gZXh0cmEgSE1BQyBjb21wdXRhdGlv biBvbiB0aGUgc2VydmVyLA0Kd2l0aCByZXNwZWN0IHRvIHRoZSBjdXJyZW50IHNlcnZlciBsb2Fk Lg0KDQpIZW5jZSwgcmVseWluZyBvbiBQUk5HIG9uIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgc2lk ZXMgbG9va3MgbGlrZSBhDQpyZWFzb25hYmxlIHdheSB0byBnby4gSSBhbHNvIGRvbid0IHBhcnRp Y3VsYXJseSBsaWtlIHRoZSBhc3ltbWV0cnkNCnRoYXQgcHJvcG9zYWwgMiBtYXkgYnJpbmc6IGNs aWVudCBnZW5lcmF0aW5nIHJhbmRvbW5lc3Mgd2l0aCBITUFDLCBhbmQNCnNlcnZlcnMgc3RpbGwg dXNpbmcgdGhlIHRpbWVzdGFtcCBpbiBjbGVhci4NCg0KQ2hlZXJzLA0KQWxmcmVkbw0KDQpPbiBX ZWQsIFNlcCAxMSwgMjAxMyBhdCA1OjQzIFBNLCBOaWNrIE1hdGhld3NvbiA8bmlja21AdG9ycHJv amVjdC5vcmc8bWFpbHRvOm5pY2ttQHRvcnByb2plY3Qub3JnPj4gd3JvdGU6DQo+IEhpLCBhbGwu DQo+DQo+IEhlcmUncyBzb21ldGhpbmcgSSB3cm90ZSBhYm91dCByZW1vdmluZyBhIGZpbmdlcnBy aW50aW5nIG9wcG9ydHVuaXR5DQo+IGZyb20gdGhlIGN1cnJlbnQgVExTIHByb3RvY29sLiAgSSB3 YXMgZ29pbmcgdG8ganVzdCBzZW5kIGl0IHRvIHRoZSB0bHMNCj4gbGlzdCwgYnV0IEJlbiBMYXVy aWUgc3VnZ2VzdGVkIHRoYXQgSSBzZW5kIGl0IHRvIHRoZSBwZXJwYXNzIGxpc3QgYXMNCj4gd2Vs bC4NCj4NCj4gSSBoYXZlIGxpdHRsZSBzdGFuZGFyZHMtYm9keSBleHBlcmllbmNlOyBpZiB0aGlz IG91Z2h0IHRvIHR1cm4gaW50byBhbg0KPiBSRkMgb3Igc29tZXRoaW5nLCBJJ2QgYmUgaGFwcHkg dG8gd3JpdGUgYSBkcmFmdCBpZiBuZWVkIGJlLg0KPg0KPg0KPiAoVG9yIGN1cnJlbnRseSBwbGFu cyB0byBpbXBsZW1lbnQgdGhpcyBieSBwYXRjaGluZyBPcGVuU1NMOyBhbnkNCj4gZmVlZGJhY2sg b3IgYWR2aWNlIHdvdWxkIGJlIGFwcHJlY2lhdGVkLiAgVGhlIGZpcnN0IHRocmVlIGFwcHJvYWNo ZXMNCj4gYmVsb3cgYXJlIGltcGxlbWVudGVkIGluIE9wZW5TU0wgYnJhbmNoZXMgbmFtZWQgIm5v X2NsaWVudF90aW1lc3RhbXAiLA0KPiAibm9fY2xpZW50X3RpbWVzdGFtcF92MiIgLCBhbmQgIm5v X2NsaWVudF90aW1lc3RhbXBfdjMiIGluIHRoZSBnaXQNCj4gcmVwb3NpdG9yeSBhdCBodHRwczov L2dpdGh1Yi5jb20vbm1hdGhld3Nvbi9vcGVuc3NsIC4gIFdlIGhhdmUgbG9uZw0KPiBzaGlwcGVk IG91ciBwcml2YWN5LWVuaGFuY2VkIGJyb3dzZXIgd2l0aCBhIGZlYXR1cmUgbGlrZSB0aGlzIGVu YWJsZWQNCj4gdGhyb3VnaCBhbiBOU1MgcGF0Y2guKQ0KPg0KPg0KPiA9PT09DQo+IFNZTk9QU0lT Og0KPg0KPiBJbiBUTFMgYXMgY3VycmVudGx5IHNwZWNpZmllZCwgY2xpZW50cyBhbmQgc2VydmVy cyBlYWNoIHNlbmQgdGhlaXINCj4gY3VycmVudCB2aWV3IG9mICJ0aGUgdGltZSIgaW4gdGhlIGNs ZWFyIGFzIHBhcnQgb2YgdGhlaXIgaGFuZHNoYWtlLg0KPiBUaGlzIHByb3ZpZGVzIGEgZmluZ2Vy cHJpbnQgdGhhdCBjYW4gdHJhY2sgdXNlcnMgaW4gc3BpdGUgb2Ygb3RoZXINCj4gYXR0ZW1wdHMg dG8gbWFrZSB0aGVtIHVudHJhY2thYmxlLiAgSSBwcm9wb3NlIHNldmVyYWwgd2F5cyB0byBzdG9w DQo+IGRvaW5nIHNlbmRpbmcgdGhpcyBjbGVhcnRleHQgdGltZXN0YW1wOyBzb21lIHRyaXZpYWwg YW5kIHNvbWUgbW9yZQ0KPiBjb21wbGV4Lg0KPg0KPg0KPiBBQ0tOT1dMRURHRU1FTlRTOg0KPg0K PiBUaGFua3MgdG8gQWRhbSBMYW5nbGV5LCBCZW4gTGF1cmllLCBhbmQgZXZlcnlib2R5IGVsc2Ug d2hvIGdhdmUgbWUNCj4gZmVlZGJhY2sgaGVyZS4NCj4NCj4NCj4gUFJPQkxFTToNCj4NCj4gVGhl IGdtdF91bml4X3RpbWUgZmllbGQgaW4gdGhlIFJhbmRvbSBmaWVsZCBpbiB0aGUgVExTIGhhbmRz aGFrZQ0KPiBwcm92aWRlcyBhIHdheSBmb3IgYW4gb2JzZXJ2ZXIgdG8gZmluZ2VycHJpbnQgY2xp ZW50cy4NCj4NCj4gRGVzcGl0ZSB0aGUgbGF0ZSBkYXRlLCBtdWNoIG9mIHRoZSB3b3JsZCBpcyBz dGlsbCBub3QNCj4gc3luY2hyb25pemVkIHRvIHRoZSBzZWNvbmQgdmlhIGFuIG50cC1saWtlIHNl cnZpY2UuIFRoaXMgbWVhbnMNCj4gdGhhdCBkaWZmZXJlbnQgY2xpZW50cyBoYXZlIGRpZmZlcmVu dCB2aWV3cyBvZiB0aGUgY3VycmVudCB0aW1lLA0KPiB3aGljaCBwcm92aWRlcyBhIGZpbmdlcnBy aW50IHRoYXQgaGVscHMgdG8gdHJhY2sgYW5kIGRpc3Rpbmd1aXNoDQo+IHRoZW0uICBUaGlzIGZp bmdlcnByaW50IGlzIHVzZWZ1bCBmb3IgdHJhY2tpbmcgY2xpZW50cyBhcyB0aGV5DQo+IG1vdmUg YXJvdW5kLiAgSXQgY2FuIGFsc28gZGlzdGluZ3Vpc2ggY2xpZW50cyB1c2luZyBhIHNpbmdsZSBW UE4sDQo+IE5BVCwgb3IgcHJpdmFjeSBuZXR3b3JrLiAgKFRvcidzIG1vZGlmaWVkIGZpcmVmb3gg YXZvaWRzIHRoaXMgYnkNCj4gbm90IHNlbmRpbmcgdGhlIHRpbWUuKQ0KPg0KPiBXb3JzZSwgc29t ZSBpbXBsZW1lbnRhdGlvbnMgZG9uJ3Qgc2VuZCB0aGUgY3VycmVudCB0aW1lLCBidXQgdGhlDQo+ IHByb2Nlc3MgdGltZSwgb3IgdGhlIGNvbXB1dGVyJ3MgdXB0aW1lLCBib3RoIG9mIHdoaWNoIGFy ZSBmYXINCj4gbW9yZSBkaXN0aW5ndWlzaGluZyB0aGFuIHRoZSBjdXJyZW50IHRpbWUoKSB2YWx1 ZS4NCj4NCj4gVGhlIGluZm9ybWF0aW9uIGZpbmdlcnByaW50IGhlcmUgaXMgc3Ryb25nIGVub3Vn aCB0byB1bmlxdWVseQ0KPiBpZGVudGlmeSBzb21lIFRMUyB1c2VycyAodGhlIG9uZXMgd2hvc2Ug Y2xvY2tzIGFyZSBob3VycyBvZmYpLg0KPiBFdmVuIGZvciB0aGUgb25lcyB3aG9zZSBjbG9ja3Mg YXJlIG1vc3RseSByaWdodCAod2l0aGluIGEgc2Vjb25kDQo+IG9yIHR3byksIHRoZSBmaWVsZCBs ZWFrcyBhIGJpdCBvZiBpbmZvcm1hdGlvbiwgYW5kIGl0IG9ubHkgdGFrZXMNCj4gc28gbWFueSBi aXRzIHRvIG1ha2UgYSB1c2VyIHVuaXF1ZS4NCj4NCj4gT2YgY291cnNlLCBJIHJlYWxpemUgdGhh dCB0aGUgZ210X3VuaXhfdGltZSBmaW5nZXJwcmludCBpcyBub3QgdGhlDQo+IG9ubHkgd2F5IHRv IHRyYWNrIGEgdHlwaWNhbCBjbGllbnQgYXMgaXQgbW92ZXMgZnJvbSBuZXR3b3JrIHRvDQo+IG5l dHdvcmssIGFuZCBub3QgdGhlIG9ubHkgd2F5IHRvIGRpc3Rpbmd1aXNoIGRpZmZlcmVudCBjbGll bnRzDQo+IGJlaGluZCBhIE5BVC4NCj4NCj4NCj4NCj4gQkFDS0dST1VORDogV0hZIGdtdF91bml4 X3RpbWUgSU4gVEhFIEZJUlNUIFBMQUNFPw0KPg0KPiBBY2NvcmRpbmcgdG8gdGhpcmQtaGFuZCBy ZXBvcnRzIChhbmQgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmchKQ0KPiBnbXRfdW5peF90aW1lIHdh cyBpbnRyb2R1Y2VkIGluIFNTTCAzLjAgdG8gcHJldmVudCBjb21wbGV0ZSBmYWlsdXJlDQo+IGlu IGNhc2VzIHdoZXJlIHRoZSBQUk5HIHdhcyBjb21wbGV0ZWx5IGJyb2tlbiwgYnkgbWFraW5nIGEg cGFydCBvZg0KPiB0aGUgUmFuZG9tIGZpZWxkIHRoYXQgd291bGQgZGVmaW5pdGVseSB2YXJ5IGJl dHdlZW4gVExTIGhhbmRzaGFrZXMuDQo+DQo+IEkgZG91YnQgdGhhdCB0aGlzIGdvYWwgaXMgcmVh bGx5IGFjaGlldmVkLCBmb3IgdHdvIHJlYXNvbnM6DQo+DQo+ICAgICogT24gbW9kZXJuIGRlc2t0 b3AgZW52aXJvbm1lbnRzLCBpdCdzIG5vdCByZWFsbHkgc28gc3RyYW5nZSB0bw0KPiAgICAgIHN0 YXJ0IHR3byBvciBtb3JlIFRMUyBjb25uZWN0aW9ucyB3aXRoaW4gdGhlIHNhbWUgc2Vjb25kLiAg V2hlbg0KPiAgICAgIHRoaXMgb2NjdXJzLCB0aGUgZ210X3VuaXhfdGltZSBmYWlscyBpbiBpdHMg aW50ZW5kZWQgcHVycG9zZSBvZg0KPiAgICAgIHByZXZlbnRpbmcgcmVwZWF0ZWQgUmFuZG9tIHZh bHVlcy4NCj4NCj4gICAgKiBOb253aXRoc3RhbmRpbmcgdGhlIGdtdF91bml4X3RpbWUgd29ya2Fy b3VuZCwgVExTIGluIGdlbmVyYWwNCj4gICAgICBkb2VzIG5vdCB3aXRoc3RhbmQgYnJva2VuIFBS TkdzLiAgRm9yIG9uZSBleGFtcGxlLCBpZiBhbg0KPiAgICAgIGltcGxlbWVudGF0aW9uJ3MgUFJO RyBpcyBwcm9uZSB0byByZXBlYXRpbmcgQ2xpZW50UmFuZG9tDQo+ICAgICAgdmFsdWVzLCBpdCBp cyBwcm9iYWJseSBwcm9uZSB0byByZXBlYXRpbmcgdGhvc2Ugc29tZSB2YWx1ZXMgYXMNCj4gICAg ICBlcGhlbWVyYWwgRGlmZmllLUhlbGxtYW4gcHJpdmF0ZSB2YWx1ZXMuDQo+DQo+IE5ldmVydGhl bGVzcywgaWYgdGhlIGdvYWwgb2YgcHJvdmlkaW5nIHVuaXF1ZS1sb29raW5nIG91dHB1dA0KPg0K Pg0KPg0KPiBXSFkgRUxTRSBJUyBnbXRfdW5peF90aW1lIFVTRUQ/DQo+DQo+IFRoZSBjb25zZW5z dXMgYW1vbmcgaW1wbGVtZW50b3JzIEkndmUgYXNrZWQgc2VlbXMgdG8gYmUgdGhhdCBpdCdzDQo+ IHVud2lzZSB0byBkZXBlbmQgb24gYW55IHBhcnRpY3VsYXIgdmFsdWUgb3IgaW50ZXJwcmV0YXRp b24gZm9yIHRoZQ0KPiBmaWVsZC4gIFRoZSBUTFMgMS4yIHN0YW5kYXJkLCBSRkMgNTI0Niwgc2F5 cyB0aGF0ICJDbG9ja3MgYXJlIG5vdA0KPiByZXF1aXJlZCB0byBiZSBzZXQgY29ycmVjdGx5IGJ5 IHRoZSBiYXNpYyBUTFMgcHJvdG9jb2w7IGhpZ2hlci1sZXZlbA0KPiBvciBhcHBsaWNhdGlvbiBw cm90b2NvbHMgbWF5IGRlZmluZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cy4iDQo+DQo+IFNvbWUg aW1wbGVtZW50YXRpb25zIHNldCB0aGUgZW50aXJlIGdtdF91bml4X3RpbWUgZmllbGQgcmFuZG9t bHk7DQo+IHRoaXMgYXBwZWFycyBub3QgdG8gaGF2ZSBicm9rZW4gVExTIG9uIHRoZSBpbnRlcm5l dC4NCj4NCj4gQXQgbGVhc3Qgb25lIHRvb2wgKHRsc2RhdGUpIHVzZXMgdGhlIHNlcnZlci1zaWRl IHZhbHVlIG9mIHRoZQ0KPiBmaWVsZCBhcyBhbiBhdXRoZW50aWNhdGVkIHZpZXcgb2YgdGhlIGN1 cnJlbnQgdGltZS4NCj4NCj4NCj4NCj4gUFJPUE9TQUwgMToNCj4NCj4gRGVjbGFyZSB0aGF0IGlt cGxlbWVudGF0aW9ucyBNQVkgcmVwbGFjZSBnbXRfdW5peF90aW1lIGVpdGhlciB3aXRoDQo+IGZv dXIgbW9yZSByYW5kb20gYnl0ZXMsIG9yIGZvdXIgYnl0ZXMgb2YgemVyb2VzLg0KPg0KPiBSYXRp b25hbGU6DQo+ICAgICogU29tZSBpbXBsZW1lbnRhdGlvbnMgKGxpa2UgVG9yQnJvd3NlcikgYXJl IGFscmVhZHkgZG9pbmcgdGhpcw0KPiAgICAgIGluIHByYWN0aWNlLg0KPg0KPiAgICAqIEl0J3Mg c2Vuc2libGUgYW5kIHNpbXBsZS4gIEltcGxlbWVudG9ycyBhcmUgcXVpdGUgdW5saWtlbHkgdG8N Cj4gICAgICBtZXNzIGl0IHVwLg0KPg0KPg0KPg0KPiBQUk9QT1NBTCAyOg0KPg0KPiBTdXBwb3Nl IHRoYXQgd2UgZG8gbm90IGFjY2VwdCB0aGUgYXJndW1lbnQgYWJvdXQgdGhlIHBvaW50bGVzc25l c3MNCj4gb2YgZ210X3VuaXRfdGltZSB0aGF0IEkgbWFrZSBhYm92ZSwgYW5kIHdlIHdhbnQgdG8g cHJlc2VydmUgdGhlDQo+IHNlY3VyaXR5IGl0IGFsbGVnZWRseSBwcm92aWRlcy4NCj4NCj4gSW4g dGhhdCBjYXNlLCB3ZSBjYW4gYWxsb3cgdGhlIGZvbGxvd2luZyBhcHByb2FjaCBpbnN0ZWFkOg0K Pg0KPiBTZXQgdGhlIFJhbmRvbSBmaWVsZCwgbm90IHRvIDMyIGJ5dGVzIGZyb20geW91ciBQUk5H LCBidXQgdG8gdGhlDQo+IEhNQUMtU0hBMjU2IG9mIGFueSBoaWdoIHJlc29sdXRpb24gdGltZXIg dGhhdCB5b3UgaGF2ZSwgdXNpbmcgMzINCj4gYnl0ZXMgZnJvbSB5b3VyIFBSTkcgYXMgYSBrZXku ICBJbiBvdGhlciB3b3JkcywgcmVwbGFjZSB0aGlzOg0KPg0KPiAgICBSYW5kb20uZ210X3VuaXhf dGltZSA9IHRpbWUoKTsNCj4gICAgUmFuZG9tLnJhbmRvbV9ieXRlcyA9IGdldF9yYW5kb21fYnl0 ZXMoMjgpDQo+DQo+IHdpdGggdGhpczoNCj4NCj4gICAgbm93ID0gaGlyZXNfdGltZSgpOyAvLyBj bG9ja19nZXR0aW1lKCksIG9yIGNvbmNhdGVuYXRlIHRpbWUoKQ0KPiAgICAgICAgICAgICAgICAg ICAgICAgIC8vIHdpdGggYSBDUFUgdGltZXIsIG9yIHByb2Nlc3MNCj4gICAgICAgICAgICAgICAg ICAgICAgICAvLyB1cHRpbWUsIG9yIHdoYXRldmVyLg0KPiAgICBrZXkgPSBnZXRfcmFuZG9tX2J5 dGVzKDMyKTsNCj4gICAgUmFuZG9tID0gaG1hY19zaGEyNTYoa2V5LCBub3cpOw0KPg0KPiBUaGlz IGFwcHJvYWNoIGlzIGJldHRlciB0aGFuIHRoZSBzdGF0dXMgcXVvIG9uIHRoZSBmb2xsb3dpbmcN Cj4gY291bnRzOg0KPg0KPiAgICAqIEl0IGRvZXNuJ3QgbGVhayB5b3VyIHZpZXcgb2YgdGhlIGN1 cnJlbnQgdGltZSwgYXNzdW1pbmcgdGhhdA0KPiAgICAgIHlvdXIgUFJORyBpc24ndCBidXN0ZWQu DQo+DQo+ICAgICogSXQgYWN0dWFsbHkgZml4ZXMgdGhlIHByb2JsZW0gdGhhdCBnbXRfdW5peF90 aW1lIHB1cnBvcnRlZCB0bw0KPiAgICAgIGZpeCwgYnkgdXNpbmcgYSBoaWdoLXJlc29sdXRpb24g dGltZSB0aGF0J3MgbXVjaCBsZXNzIGxpa2VseSB0bw0KPiAgICAgIGJlIHVzZWQgdHdpY2UuICBF dmVuIGlmIHRoZSBQUk5HIGlzIGJyb2tlbiwgdGhlIHZhbHVlIGlzIHN0aWxsDQo+ICAgICAgbm9u cmVwZWF0aW5nLg0KPg0KPiBJIGRvIG5vdCB0aGluayB0aGlzIGlzIG5vdCB3b3JzZSB0aGFuIHRo ZSBzdGF0dXMgcXVvOg0KPg0KPiAgICAqIEl0IGlzIHVucHJlZGljdGFibGUgZnJvbSBhbiBhdHRh Y2tlcidzIFBPViwgYXNzdW1pbmcgdGhhdCB0aGUNCj4gICAgICBQUk5HIHdvcmtzLiAgKEJlY2F1 c2UgYW4gSE1BQywgZXZlbiBvZiBrbm93biBkYXRhLCB3aXRoIGFuDQo+ICAgICAgdW5rbm93biBy YW5kb20ga2V5IGlzIHN1cHBvc2VkIHRvIGxvb2sgcmFuZG9tKS4NCj4NCj4NCj4gUFJPUE9TQUwg Mw0KPg0KPiBBcyBhIGh5YnJpZCBhbHRlcm5hdGl2ZSwgb25lIGNvdWxkIHNldCBwYXJ0IG9mIHRo ZSBDbGllbnRSYW5kb20NCj4gZmllbGQgKHBlcmhhcHMgMTIgYnl0ZXMgb3Igc28pIGJhc2VkIG9u IHRoZSBITUFDIG9mIHRoZSB0aW1lLCBhbmQNCj4gdGhlIHJlc3Qgb2YgdGhlIENsaWVudFJhbmRv bSBmaWVsZCBiYXNlZCBvbiB0aGUgUFJORzoNCj4NCj4gICAgTiA9IDEyDQo+DQo+ICAgIG5vdyA9 IGhpcmVzX3RpbWUoKTsNCj4gICAga2V5ID0gZ2V0X3JhbmRvbV9ieXRlcygzMik7DQo+ICAgIG1h YyA9IGhtYWNfc2hhMjU2KGtleSwgbm93KVswOk5dOyAgLy8gRmlyc3QgTiBieXRlcy4NCj4gICAg cmFuZCA9IGdldF9yYW5kb21fYnl0ZXMoMzIgLSBOKQ0KPiAgICBSYW5kb20gPSBtYWMgKysgcmFu ZCAgICAgICAgICAgICAgIC8vIGNvbmNhdGVuYXRlLg0KPg0KPiBCdXQgdGhpcyBzZWVtcyB0byBi ZSBnZXR0aW5nIHBvaW50bGVzc2x5IGJhcm9xdWUuDQo+DQo+DQo+DQo+IENPTlNJREVSQVRJT05T Og0KPg0KPiBJJ2QgcGVyc29uYWxseSBzdWdnZXN0IHByb3Bvc2FsIDEgKGp1c3Qgc2V0IHRoZSBm aWVsZCBhdCByYW5kb20pIGZvcg0KPiBtb3N0IHVzZXJzLiAgWWVzLCBpdCBtYWtlcyB0aGluZ3Mg YSBsaXR0bGUgd29yc2UgaWYgeW91ciBQUk5HIGNhbg0KPiBnZW5lcmF0ZSByZXBlYXQgdmFsdWVz Li4uIGJ1dCBuZWFybHkgZXZlcnl0aGluZyBpbiBjcnlwdG9ncmFwaHkNCj4gZmFpbHMgaWYgeW91 ciBQUk5HIGlzIGJyb2tlbi4NCj4NCj4NCj4gV2UgbWlnaHQgd2FudCB0byBhcHBseSB0aGlzIGZp eCBvbiBjbGllbnRzIG9ubHkuICBXaXRoIGEgZmV3DQo+IGV4Y2VwdGlvbnMgKGxpa2UgaGlkZGVu IHNlcnZpY2VzKSB0aGUgc2VydmVyJ3MgdmlldyBvZiB0aGUgY3VycmVudA0KPiB0aW1lIGlzIG5v dCBzZW5zaXRpdmUuDQo+DQo+DQo+IEltcGxlbWVudG9ycyBtaWdodCB3YW50IHRvIG1ha2UgdGhp cyBmZWF0dXJlIG9wdGlvbmFsIGFuZA0KPiBvbi1ieS1kZWZhdWx0LCBqdXN0IGluIGNhc2Ugc29t ZSBoaWdoZXItbGV2ZWwgYXBwbGljYXRpb24gcHJvdG9jb2wNCj4gcmVhbGx5IGRvZXMgZGVwZW5k IG9uIGl0Lg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3Jn Pg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QN ClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90bHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExT QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg== --_000_E774C81546D66E429BF56B1474C7EBBA010E33002ESEAEMBX01olym_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCB3ZSBoYXZlIGJlZW4gdXNpbmcgcmFuZG9tIHZh bHVlcyBhbmQgaGF2ZSBub3QgZ290IGludG8gYW55IGlzc3VlcyB3aXRoIGNsaWVudHMvc2VydmVy cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi1YaWFveW9uZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiB0bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SeWFuIEh1cnN0PGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgU2VwdGVtYmVyIDExLCAyMDEzIDk6MTkgQU08YnI+DQo8Yj5Ubzo8L2I+IEVyaWMg UmVzY29ybGE8YnI+DQo8Yj5DYzo8L2I+IHBlcnBhc3NAaWV0Zi5vcmc7IHRsc0BpZXRmLm9yZzsg QWxmcmVkbyBQaXJvbnRpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBMZXQncyByZW1v dmUgZ210X3VuaXhfdGltZSBmcm9tIFRMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGxvb2tlZCBhdCB0aGlzIHNvbWUs IG5ldHdvcmsgYXBwbGlhbmNlcyBzdWNoIGFzIEY1cyBCaWcgSVAgdXNlIGEgcmFuZG9tIHZhbHVl IGluc3RlYWQgb2YgdGltZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSByZWNhbGwgc2VlaW5nIHNvbWUgY2xpZW50cyBhbHNvIGRvIHRoaXMg YnV0IEkgZG9uJ3QgcmVjYWxsIHdoaWNoIG9uZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhc2ljYWxseSBzdWNoIGEgY2hhbmdlIHNob3Vs ZCBiZSBzYWZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGF0IHNhaWQgYXMgUnVzcyBoYXMgcG9pbnRlZCBvdXQgVFBTREFURSB1c2VzIHRo aXMgbWVjaGFuaXNtIGFuZCB0aG91Z2ggaXQgZG9lc24ndCBzb2x2ZSBhIGJyb2tlbiBjcnlwdG9n cmFwaGljIHN1YnN5c3RlbSBpdCBpcyBraW5kIG9mIGJlbHQgYW5kIHN1c3BlbmRlcnMgYXBwcm9h Y2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClJ5 YW4gSHVyc3Q8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2hpZWYgVGVjaG5vbG9neSBPZmZpY2VyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HTU8gR2xvYmFsc2lnbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50d2l0dGVyOiBAcm1ocmlzazxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZW1haWw6IDxh IGhyZWY9Im1haWx0bzpyeWFuLmh1cnN0QGdsb2JhbHNpZ24uY29tIj5yeWFuLmh1cnN0QGdsb2Jh bHNpZ24uY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+cGhvbmU6IDIwNi02NTAtNzkyNjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50IGZyb20gbXkgcGhvbmUsIHBsZWFzZSBmb3Jn aXZlIHRoZSBicmV2aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KT24gU2VwIDExLCAyMDEzLCBhdCA5OjA2IEFNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBo cmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJlZm9yZSB3ZSBkaXNjdXNzIG1lY2hhbmlzbXMsIGl0IHdvdWxkIGJlIGdvb2QgdG8gdmVyaWZ5 IHRoYXQgaW4gZ2VuZXJhbDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmNsaWVudHMgYW5kIHNlcnZlcnMgZG9uJ3QgYmVjb21lIHVuaGFwcHkgaWYgdGhlIHRpbWVz dGFtcCBpcyByYWRpY2FsbHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPndyb25nLiBIYXMgc29tZW9uZSBkb25lIG1lYXN1cmVtZW50cyB0byB2ZXJp ZnkgdGhhdCB0aGlzIGlzIGluIGZhY3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBjYXNlIGF0IGEgYnJvYWQgc2NhbGU/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgU2VwIDExLCAyMDEzIGF0IDk6MDEgQU0sIEFsZnJl ZG8gUGlyb250aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZnJlZG9AcGlyb250aS5ldSIgdGFyZ2V0 PSJfYmxhbmsiPmFsZnJlZG9AcGlyb250aS5ldTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGluIGZhdm9yIG9mIHByb3Bvc2FsIDEsIGFuZCBz ZWNvbmQgdGhlIGNvbnNpZGVyYXRpb25zIGFib3V0IGl0Ozxicj4NCmVzc2VudGlhbGx5LCBhIGJy b2tlbiBjcnlwdG8gaW1wbGVtZW50YXRpb24gY2Fubm90IGJlIGZpeGVkIGJ5IGE8YnI+DQp0aW1l c3RhbXAuPGJyPg0KPGJyPg0KSWYgcHJvcG9zYWwgMiAoYW5kIDMpIHdhcyB0byBiZSBpbXBsZW1l bnRlZCBvbiBhIHNlcnZlciwgaXQgd291bGQgYWxzbzxicj4NCm1ha2UgRG9TIGVhc2llciwgYmVj YXVzZSBhIGNoZWFwIENsaWVudEhlbGxvIChldmVuIGdlbmVyYXRlZCB3aXRoIHdlYWs8YnI+DQpy YW5kb21uZXNzKSB3b3VsZCB0cmlnZ2VyIGFuIGV4dHJhIEhNQUMgY29tcHV0YXRpb24gb24gdGhl IHNlcnZlciw8YnI+DQp3aXRoIHJlc3BlY3QgdG8gdGhlIGN1cnJlbnQgc2VydmVyIGxvYWQuPGJy Pg0KPGJyPg0KSGVuY2UsIHJlbHlpbmcgb24gUFJORyBvbiBib3RoIGNsaWVudCBhbmQgc2VydmVy IHNpZGVzIGxvb2tzIGxpa2UgYTxicj4NCnJlYXNvbmFibGUgd2F5IHRvIGdvLiBJIGFsc28gZG9u J3QgcGFydGljdWxhcmx5IGxpa2UgdGhlIGFzeW1tZXRyeTxicj4NCnRoYXQgcHJvcG9zYWwgMiBt YXkgYnJpbmc6IGNsaWVudCBnZW5lcmF0aW5nIHJhbmRvbW5lc3Mgd2l0aCBITUFDLCBhbmQ8YnI+ DQpzZXJ2ZXJzIHN0aWxsIHVzaW5nIHRoZSB0aW1lc3RhbXAgaW4gY2xlYXIuPGJyPg0KPGJyPg0K Q2hlZXJzLDxicj4NCkFsZnJlZG88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gV2VkLCBTZXAgMTEsIDIwMTMgYXQgNTo0MyBQTSwgTmlj ayBNYXRoZXdzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpuaWNrbUB0b3Jwcm9qZWN0Lm9yZyI+bmlj a21AdG9ycHJvamVjdC5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEhpLCBhbGwuPGJyPg0K Jmd0Ozxicj4NCiZndDsgSGVyZSdzIHNvbWV0aGluZyBJIHdyb3RlIGFib3V0IHJlbW92aW5nIGEg ZmluZ2VycHJpbnRpbmcgb3Bwb3J0dW5pdHk8YnI+DQomZ3Q7IGZyb20gdGhlIGN1cnJlbnQgVExT IHByb3RvY29sLiAmbmJzcDtJIHdhcyBnb2luZyB0byBqdXN0IHNlbmQgaXQgdG8gdGhlIHRsczxi cj4NCiZndDsgbGlzdCwgYnV0IEJlbiBMYXVyaWUgc3VnZ2VzdGVkIHRoYXQgSSBzZW5kIGl0IHRv IHRoZSBwZXJwYXNzIGxpc3QgYXM8YnI+DQomZ3Q7IHdlbGwuPGJyPg0KJmd0Ozxicj4NCiZndDsg SSBoYXZlIGxpdHRsZSBzdGFuZGFyZHMtYm9keSBleHBlcmllbmNlOyBpZiB0aGlzIG91Z2h0IHRv IHR1cm4gaW50byBhbjxicj4NCiZndDsgUkZDIG9yIHNvbWV0aGluZywgSSdkIGJlIGhhcHB5IHRv IHdyaXRlIGEgZHJhZnQgaWYgbmVlZCBiZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg KFRvciBjdXJyZW50bHkgcGxhbnMgdG8gaW1wbGVtZW50IHRoaXMgYnkgcGF0Y2hpbmcgT3BlblNT TDsgYW55PGJyPg0KJmd0OyBmZWVkYmFjayBvciBhZHZpY2Ugd291bGQgYmUgYXBwcmVjaWF0ZWQu ICZuYnNwO1RoZSBmaXJzdCB0aHJlZSBhcHByb2FjaGVzPGJyPg0KJmd0OyBiZWxvdyBhcmUgaW1w bGVtZW50ZWQgaW4gT3BlblNTTCBicmFuY2hlcyBuYW1lZCAmcXVvdDtub19jbGllbnRfdGltZXN0 YW1wJnF1b3Q7LDxicj4NCiZndDsgJnF1b3Q7bm9fY2xpZW50X3RpbWVzdGFtcF92MiZxdW90OyAs IGFuZCAmcXVvdDtub19jbGllbnRfdGltZXN0YW1wX3YzJnF1b3Q7IGluIHRoZSBnaXQ8YnI+DQom Z3Q7IHJlcG9zaXRvcnkgYXQgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25tYXRoZXdzb24v b3BlbnNzbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9ubWF0aGV3c29uL29w ZW5zc2w8L2E+IC4gJm5ic3A7V2UgaGF2ZSBsb25nPGJyPg0KJmd0OyBzaGlwcGVkIG91ciBwcml2 YWN5LWVuaGFuY2VkIGJyb3dzZXIgd2l0aCBhIGZlYXR1cmUgbGlrZSB0aGlzIGVuYWJsZWQ8YnI+ DQomZ3Q7IHRocm91Z2ggYW4gTlNTIHBhdGNoLik8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsgPT09PTxicj4NCiZndDsgU1lOT1BTSVM6PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gVExTIGFz IGN1cnJlbnRseSBzcGVjaWZpZWQsIGNsaWVudHMgYW5kIHNlcnZlcnMgZWFjaCBzZW5kIHRoZWly PGJyPg0KJmd0OyBjdXJyZW50IHZpZXcgb2YgJnF1b3Q7dGhlIHRpbWUmcXVvdDsgaW4gdGhlIGNs ZWFyIGFzIHBhcnQgb2YgdGhlaXIgaGFuZHNoYWtlLjxicj4NCiZndDsgVGhpcyBwcm92aWRlcyBh IGZpbmdlcnByaW50IHRoYXQgY2FuIHRyYWNrIHVzZXJzIGluIHNwaXRlIG9mIG90aGVyPGJyPg0K Jmd0OyBhdHRlbXB0cyB0byBtYWtlIHRoZW0gdW50cmFja2FibGUuICZuYnNwO0kgcHJvcG9zZSBz ZXZlcmFsIHdheXMgdG8gc3RvcDxicj4NCiZndDsgZG9pbmcgc2VuZGluZyB0aGlzIGNsZWFydGV4 dCB0aW1lc3RhbXA7IHNvbWUgdHJpdmlhbCBhbmQgc29tZSBtb3JlPGJyPg0KJmd0OyBjb21wbGV4 Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBQ0tOT1dMRURHRU1FTlRTOjxicj4NCiZn dDs8YnI+DQomZ3Q7IFRoYW5rcyB0byBBZGFtIExhbmdsZXksIEJlbiBMYXVyaWUsIGFuZCBldmVy eWJvZHkgZWxzZSB3aG8gZ2F2ZSBtZTxicj4NCiZndDsgZmVlZGJhY2sgaGVyZS48YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgUFJPQkxFTTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZ210 X3VuaXhfdGltZSBmaWVsZCBpbiB0aGUgUmFuZG9tIGZpZWxkIGluIHRoZSBUTFMgaGFuZHNoYWtl PGJyPg0KJmd0OyBwcm92aWRlcyBhIHdheSBmb3IgYW4gb2JzZXJ2ZXIgdG8gZmluZ2VycHJpbnQg Y2xpZW50cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBEZXNwaXRlIHRoZSBsYXRlIGRhdGUsIG11Y2gg b2YgdGhlIHdvcmxkIGlzIHN0aWxsIG5vdDxicj4NCiZndDsgc3luY2hyb25pemVkIHRvIHRoZSBz ZWNvbmQgdmlhIGFuIG50cC1saWtlIHNlcnZpY2UuIFRoaXMgbWVhbnM8YnI+DQomZ3Q7IHRoYXQg ZGlmZmVyZW50IGNsaWVudHMgaGF2ZSBkaWZmZXJlbnQgdmlld3Mgb2YgdGhlIGN1cnJlbnQgdGlt ZSw8YnI+DQomZ3Q7IHdoaWNoIHByb3ZpZGVzIGEgZmluZ2VycHJpbnQgdGhhdCBoZWxwcyB0byB0 cmFjayBhbmQgZGlzdGluZ3Vpc2g8YnI+DQomZ3Q7IHRoZW0uICZuYnNwO1RoaXMgZmluZ2VycHJp bnQgaXMgdXNlZnVsIGZvciB0cmFja2luZyBjbGllbnRzIGFzIHRoZXk8YnI+DQomZ3Q7IG1vdmUg YXJvdW5kLiAmbmJzcDtJdCBjYW4gYWxzbyBkaXN0aW5ndWlzaCBjbGllbnRzIHVzaW5nIGEgc2lu Z2xlIFZQTiw8YnI+DQomZ3Q7IE5BVCwgb3IgcHJpdmFjeSBuZXR3b3JrLiAmbmJzcDsoVG9yJ3Mg bW9kaWZpZWQgZmlyZWZveCBhdm9pZHMgdGhpcyBieTxicj4NCiZndDsgbm90IHNlbmRpbmcgdGhl IHRpbWUuKTxicj4NCiZndDs8YnI+DQomZ3Q7IFdvcnNlLCBzb21lIGltcGxlbWVudGF0aW9ucyBk b24ndCBzZW5kIHRoZSBjdXJyZW50IHRpbWUsIGJ1dCB0aGU8YnI+DQomZ3Q7IHByb2Nlc3MgdGlt ZSwgb3IgdGhlIGNvbXB1dGVyJ3MgdXB0aW1lLCBib3RoIG9mIHdoaWNoIGFyZSBmYXI8YnI+DQom Z3Q7IG1vcmUgZGlzdGluZ3Vpc2hpbmcgdGhhbiB0aGUgY3VycmVudCB0aW1lKCkgdmFsdWUuPGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhlIGluZm9ybWF0aW9uIGZpbmdlcnByaW50IGhlcmUgaXMgc3Ry b25nIGVub3VnaCB0byB1bmlxdWVseTxicj4NCiZndDsgaWRlbnRpZnkgc29tZSBUTFMgdXNlcnMg KHRoZSBvbmVzIHdob3NlIGNsb2NrcyBhcmUgaG91cnMgb2ZmKS48YnI+DQomZ3Q7IEV2ZW4gZm9y IHRoZSBvbmVzIHdob3NlIGNsb2NrcyBhcmUgbW9zdGx5IHJpZ2h0ICh3aXRoaW4gYSBzZWNvbmQ8 YnI+DQomZ3Q7IG9yIHR3byksIHRoZSBmaWVsZCBsZWFrcyBhIGJpdCBvZiBpbmZvcm1hdGlvbiwg YW5kIGl0IG9ubHkgdGFrZXM8YnI+DQomZ3Q7IHNvIG1hbnkgYml0cyB0byBtYWtlIGEgdXNlciB1 bmlxdWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgT2YgY291cnNlLCBJIHJlYWxpemUgdGhhdCB0aGUg Z210X3VuaXhfdGltZSBmaW5nZXJwcmludCBpcyBub3QgdGhlPGJyPg0KJmd0OyBvbmx5IHdheSB0 byB0cmFjayBhIHR5cGljYWwgY2xpZW50IGFzIGl0IG1vdmVzIGZyb20gbmV0d29yayB0bzxicj4N CiZndDsgbmV0d29yaywgYW5kIG5vdCB0aGUgb25seSB3YXkgdG8gZGlzdGluZ3Vpc2ggZGlmZmVy ZW50IGNsaWVudHM8YnI+DQomZ3Q7IGJlaGluZCBhIE5BVC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IEJBQ0tHUk9VTkQ6IFdIWSBnbXRfdW5peF90aW1lIElOIFRIRSBG SVJTVCBQTEFDRT88YnI+DQomZ3Q7PGJyPg0KJmd0OyBBY2NvcmRpbmcgdG8gdGhpcmQtaGFuZCBy ZXBvcnRzIChhbmQgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmchKTxicj4NCiZndDsgZ210X3VuaXhf dGltZSB3YXMgaW50cm9kdWNlZCBpbiBTU0wgMy4wIHRvIHByZXZlbnQgY29tcGxldGUgZmFpbHVy ZTxicj4NCiZndDsgaW4gY2FzZXMgd2hlcmUgdGhlIFBSTkcgd2FzIGNvbXBsZXRlbHkgYnJva2Vu LCBieSBtYWtpbmcgYSBwYXJ0IG9mPGJyPg0KJmd0OyB0aGUgUmFuZG9tIGZpZWxkIHRoYXQgd291 bGQgZGVmaW5pdGVseSB2YXJ5IGJldHdlZW4gVExTIGhhbmRzaGFrZXMuPGJyPg0KJmd0Ozxicj4N CiZndDsgSSBkb3VidCB0aGF0IHRoaXMgZ29hbCBpcyByZWFsbHkgYWNoaWV2ZWQsIGZvciB0d28g cmVhc29uczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7KiBPbiBtb2Rlcm4gZGVz a3RvcCBlbnZpcm9ubWVudHMsIGl0J3Mgbm90IHJlYWxseSBzbyBzdHJhbmdlIHRvPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N0YXJ0IHR3byBvciBtb3JlIFRMUyBjb25uZWN0aW9ucyB3 aXRoaW4gdGhlIHNhbWUgc2Vjb25kLiAmbmJzcDtXaGVuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3RoaXMgb2NjdXJzLCB0aGUgZ210X3VuaXhfdGltZSBmYWlscyBpbiBpdHMgaW50ZW5k ZWQgcHVycG9zZSBvZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwcmV2ZW50aW5nIHJl cGVhdGVkIFJhbmRvbSB2YWx1ZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyog Tm9ud2l0aHN0YW5kaW5nIHRoZSBnbXRfdW5peF90aW1lIHdvcmthcm91bmQsIFRMUyBpbiBnZW5l cmFsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvZXMgbm90IHdpdGhzdGFuZCBicm9r ZW4gUFJOR3MuICZuYnNwO0ZvciBvbmUgZXhhbXBsZSwgaWYgYW48YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7aW1wbGVtZW50YXRpb24ncyBQUk5HIGlzIHByb25lIHRvIHJlcGVhdGluZyBD bGllbnRSYW5kb208YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dmFsdWVzLCBpdCBpcyBw cm9iYWJseSBwcm9uZSB0byByZXBlYXRpbmcgdGhvc2Ugc29tZSB2YWx1ZXMgYXM8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXBoZW1lcmFsIERpZmZpZS1IZWxsbWFuIHByaXZhdGUgdmFs dWVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IE5ldmVydGhlbGVzcywgaWYgdGhlIGdvYWwgb2YgcHJv dmlkaW5nIHVuaXF1ZS1sb29raW5nIG91dHB1dDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgV0hZIEVMU0UgSVMgZ210X3VuaXhfdGltZSBVU0VEPzxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZSBjb25zZW5zdXMgYW1vbmcgaW1wbGVtZW50b3JzIEkndmUgYXNrZWQgc2VlbXMg dG8gYmUgdGhhdCBpdCdzPGJyPg0KJmd0OyB1bndpc2UgdG8gZGVwZW5kIG9uIGFueSBwYXJ0aWN1 bGFyIHZhbHVlIG9yIGludGVycHJldGF0aW9uIGZvciB0aGU8YnI+DQomZ3Q7IGZpZWxkLiAmbmJz cDtUaGUgVExTIDEuMiBzdGFuZGFyZCwgUkZDIDUyNDYsIHNheXMgdGhhdCAmcXVvdDtDbG9ja3Mg YXJlIG5vdDxicj4NCiZndDsgcmVxdWlyZWQgdG8gYmUgc2V0IGNvcnJlY3RseSBieSB0aGUgYmFz aWMgVExTIHByb3RvY29sOyBoaWdoZXItbGV2ZWw8YnI+DQomZ3Q7IG9yIGFwcGxpY2F0aW9uIHBy b3RvY29scyBtYXkgZGVmaW5lIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzLiZxdW90Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IFNvbWUgaW1wbGVtZW50YXRpb25zIHNldCB0aGUgZW50aXJlIGdtdF91bml4 X3RpbWUgZmllbGQgcmFuZG9tbHk7PGJyPg0KJmd0OyB0aGlzIGFwcGVhcnMgbm90IHRvIGhhdmUg YnJva2VuIFRMUyBvbiB0aGUgaW50ZXJuZXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQXQgbGVhc3Qg b25lIHRvb2wgKHRsc2RhdGUpIHVzZXMgdGhlIHNlcnZlci1zaWRlIHZhbHVlIG9mIHRoZTxicj4N CiZndDsgZmllbGQgYXMgYW4gYXV0aGVudGljYXRlZCB2aWV3IG9mIHRoZSBjdXJyZW50IHRpbWUu PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQUk9QT1NBTCAxOjxicj4N CiZndDs8YnI+DQomZ3Q7IERlY2xhcmUgdGhhdCBpbXBsZW1lbnRhdGlvbnMgTUFZIHJlcGxhY2Ug Z210X3VuaXhfdGltZSBlaXRoZXIgd2l0aDxicj4NCiZndDsgZm91ciBtb3JlIHJhbmRvbSBieXRl cywgb3IgZm91ciBieXRlcyBvZiB6ZXJvZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmF0aW9uYWxl Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyogU29tZSBpbXBsZW1lbnRhdGlvbnMgKGxpa2UgVG9y QnJvd3NlcikgYXJlIGFscmVhZHkgZG9pbmcgdGhpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtpbiBwcmFjdGljZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7KiBJdCdz IHNlbnNpYmxlIGFuZCBzaW1wbGUuICZuYnNwO0ltcGxlbWVudG9ycyBhcmUgcXVpdGUgdW5saWtl bHkgdG88YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWVzcyBpdCB1cC48YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFBST1BPU0FMIDI6PGJyPg0KJmd0Ozxicj4N CiZndDsgU3VwcG9zZSB0aGF0IHdlIGRvIG5vdCBhY2NlcHQgdGhlIGFyZ3VtZW50IGFib3V0IHRo ZSBwb2ludGxlc3NuZXNzPGJyPg0KJmd0OyBvZiBnbXRfdW5pdF90aW1lIHRoYXQgSSBtYWtlIGFi b3ZlLCBhbmQgd2Ugd2FudCB0byBwcmVzZXJ2ZSB0aGU8YnI+DQomZ3Q7IHNlY3VyaXR5IGl0IGFs bGVnZWRseSBwcm92aWRlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiB0aGF0IGNhc2UsIHdlIGNh biBhbGxvdyB0aGUgZm9sbG93aW5nIGFwcHJvYWNoIGluc3RlYWQ6PGJyPg0KJmd0Ozxicj4NCiZn dDsgU2V0IHRoZSBSYW5kb20gZmllbGQsIG5vdCB0byAzMiBieXRlcyBmcm9tIHlvdXIgUFJORywg YnV0IHRvIHRoZTxicj4NCiZndDsgSE1BQy1TSEEyNTYgb2YgYW55IGhpZ2ggcmVzb2x1dGlvbiB0 aW1lciB0aGF0IHlvdSBoYXZlLCB1c2luZyAzMjxicj4NCiZndDsgYnl0ZXMgZnJvbSB5b3VyIFBS TkcgYXMgYSBrZXkuICZuYnNwO0luIG90aGVyIHdvcmRzLCByZXBsYWNlIHRoaXM6PGJyPg0KJmd0 Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1JhbmRvbS5nbXRfdW5peF90aW1lID0gdGltZSgpOzxi cj4NCiZndDsgJm5ic3A7ICZuYnNwO1JhbmRvbS5yYW5kb21fYnl0ZXMgPSBnZXRfcmFuZG9tX2J5 dGVzKDI4KTxicj4NCiZndDs8YnI+DQomZ3Q7IHdpdGggdGhpczo8YnI+DQomZ3Q7PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7bm93ID0gaGlyZXNfdGltZSgpOyAvLyBjbG9ja19nZXR0aW1lKCksIG9y IGNvbmNhdGVuYXRlIHRpbWUoKTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsv LyB3aXRoIGEgQ1BVIHRpbWVyLCBvciBwcm9jZXNzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOy8vIHVwdGltZSwgb3Igd2hhdGV2ZXIuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 a2V5ID0gZ2V0X3JhbmRvbV9ieXRlcygzMik7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7UmFuZG9t ID0gaG1hY19zaGEyNTYoa2V5LCBub3cpOzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgYXBwcm9h Y2ggaXMgYmV0dGVyIHRoYW4gdGhlIHN0YXR1cyBxdW8gb24gdGhlIGZvbGxvd2luZzxicj4NCiZn dDsgY291bnRzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsqIEl0IGRvZXNuJ3Qg bGVhayB5b3VyIHZpZXcgb2YgdGhlIGN1cnJlbnQgdGltZSwgYXNzdW1pbmcgdGhhdDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt5b3VyIFBSTkcgaXNuJ3QgYnVzdGVkLjxicj4NCiZndDs8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsqIEl0IGFjdHVhbGx5IGZpeGVzIHRoZSBwcm9ibGVtIHRo YXQgZ210X3VuaXhfdGltZSBwdXJwb3J0ZWQgdG88YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Zml4LCBieSB1c2luZyBhIGhpZ2gtcmVzb2x1dGlvbiB0aW1lIHRoYXQncyBtdWNoIGxlc3Mg bGlrZWx5IHRvPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlIHVzZWQgdHdpY2UuICZu YnNwO0V2ZW4gaWYgdGhlIFBSTkcgaXMgYnJva2VuLCB0aGUgdmFsdWUgaXMgc3RpbGw8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bm9ucmVwZWF0aW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7 IEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgbm90IHdvcnNlIHRoYW4gdGhlIHN0YXR1cyBxdW86PGJy Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyogSXQgaXMgdW5wcmVkaWN0YWJsZSBmcm9t IGFuIGF0dGFja2VyJ3MgUE9WLCBhc3N1bWluZyB0aGF0IHRoZTxicj4NCiZndDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtQUk5HIHdvcmtzLiAmbmJzcDsoQmVjYXVzZSBhbiBITUFDLCBldmVuIG9mIGtu b3duIGRhdGEsIHdpdGggYW48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dW5rbm93biBy YW5kb20ga2V5IGlzIHN1cHBvc2VkIHRvIGxvb2sgcmFuZG9tKS48YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgUFJPUE9TQUwgMzxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIGEgaHlicmlkIGFs dGVybmF0aXZlLCBvbmUgY291bGQgc2V0IHBhcnQgb2YgdGhlIENsaWVudFJhbmRvbTxicj4NCiZn dDsgZmllbGQgKHBlcmhhcHMgMTIgYnl0ZXMgb3Igc28pIGJhc2VkIG9uIHRoZSBITUFDIG9mIHRo ZSB0aW1lLCBhbmQ8YnI+DQomZ3Q7IHRoZSByZXN0IG9mIHRoZSBDbGllbnRSYW5kb20gZmllbGQg YmFzZWQgb24gdGhlIFBSTkc6PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwO04gPSAx Mjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtub3cgPSBoaXJlc190aW1lKCk7PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7a2V5ID0gZ2V0X3JhbmRvbV9ieXRlcygzMik7PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7bWFjID0gaG1hY19zaGEyNTYoa2V5LCBub3cpWzA6Tl07ICZuYnNwOy8v IEZpcnN0IE4gYnl0ZXMuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7cmFuZCA9IGdldF9yYW5kb21f Ynl0ZXMoMzIgLSBOKTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1JhbmRvbSA9IG1hYyAmIzQzOyYj NDM7IHJhbmQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IC8vIGNvbmNhdGVuYXRlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEJ1dCB0aGlzIHNlZW1zIHRvIGJl IGdldHRpbmcgcG9pbnRsZXNzbHkgYmFyb3F1ZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IENPTlNJREVSQVRJT05TOjxicj4NCiZndDs8YnI+DQomZ3Q7IEknZCBwZXJz b25hbGx5IHN1Z2dlc3QgcHJvcG9zYWwgMSAoanVzdCBzZXQgdGhlIGZpZWxkIGF0IHJhbmRvbSkg Zm9yPGJyPg0KJmd0OyBtb3N0IHVzZXJzLiAmbmJzcDtZZXMsIGl0IG1ha2VzIHRoaW5ncyBhIGxp dHRsZSB3b3JzZSBpZiB5b3VyIFBSTkcgY2FuPGJyPg0KJmd0OyBnZW5lcmF0ZSByZXBlYXQgdmFs dWVzLi4uIGJ1dCBuZWFybHkgZXZlcnl0aGluZyBpbiBjcnlwdG9ncmFwaHk8YnI+DQomZ3Q7IGZh aWxzIGlmIHlvdXIgUFJORyBpcyBicm9rZW4uPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IFdlIG1pZ2h0IHdhbnQgdG8gYXBwbHkgdGhpcyBmaXggb24gY2xpZW50cyBvbmx5LiAmbmJzcDtX aXRoIGEgZmV3PGJyPg0KJmd0OyBleGNlcHRpb25zIChsaWtlIGhpZGRlbiBzZXJ2aWNlcykgdGhl IHNlcnZlcidzIHZpZXcgb2YgdGhlIGN1cnJlbnQ8YnI+DQomZ3Q7IHRpbWUgaXMgbm90IHNlbnNp dGl2ZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSW1wbGVtZW50b3JzIG1pZ2h0IHdh bnQgdG8gbWFrZSB0aGlzIGZlYXR1cmUgb3B0aW9uYWwgYW5kPGJyPg0KJmd0OyBvbi1ieS1kZWZh dWx0LCBqdXN0IGluIGNhc2Ugc29tZSBoaWdoZXItbGV2ZWwgYXBwbGljYXRpb24gcHJvdG9jb2w8 YnI+DQomZ3Q7IHJlYWxseSBkb2VzIGRlcGVuZCBvbiBpdC48YnI+DQomZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBUTFMgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpU TFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+ VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E774C81546D66E429BF56B1474C7EBBA010E33002ESEAEMBX01olym_-- From tytso@thunk.org Wed Sep 11 11:39:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8692B11E80D7 for ; Wed, 11 Sep 2013 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZBDi9jho0xb for ; Wed, 11 Sep 2013 11:39:00 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id EA95111E80D2 for ; Wed, 11 Sep 2013 11:38:59 -0700 (PDT) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1VJpJZ-00048h-N2; Wed, 11 Sep 2013 18:38:57 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 0077C5801C7; Wed, 11 Sep 2013 14:38:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1378924736; bh=zH7Gzt2FzM9u6nLhCC/Bl9chk1nEJ5R7231d4oyT2MU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VoJ949Yl+0x2XT5gG3FFzVeTT9a+C2KyxhGA7loYr1AUc2mWQFFzOIyow45OJl945 i1JYnceNM7TP6SLyuZZvpaA0dRW12TNp5fS8dkzJjtjLGrwMO5OGZsFCteCsIuKQzk fEfYSWi471h8QWJy+QcNYbY3YDY3bv46ETy+uU14= Date: Wed, 11 Sep 2013 14:38:56 -0400 From: Theodore Ts'o To: Karl Malbrain Message-ID: <20130911183856.GA13397@thunk.org> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:39:00 -0000 On Wed, Sep 11, 2013 at 05:31:52PM +0000, Karl Malbrain wrote: >Rather than have each TLS server receive user public certificates >individually for strong authentication, implement a global user public >certificate list hosted internationally that supplies user public >certificates to TLS hosts and clients. The list would be read-only, >indexed by GUID, and hosted at multiple international sites. Both TLS >servers and clients could then reliably obtain public certificates by >GUID for use in strong authentication challenges per the TLS protocol. And how would this global public certificate directory be securely updated? If you simply accept valid certificates, then it doesn't solve the rogue/comrpomised CA problem. - Ted From karl@petzent.com Wed Sep 11 11:46:20 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E9F11E8155 for ; Wed, 11 Sep 2013 11:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.069 X-Spam-Level: ** X-Spam-Status: No, score=2.069 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5MvgPyqZfV7 for ; Wed, 11 Sep 2013 11:46:14 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id DEBD411E80D7 for ; Wed, 11 Sep 2013 11:46:13 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 11 Sep 2013 11:46:18 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 11:46:10 -0700 From: Karl Malbrain To: "perpass@ietf.org" Thread-Topic: [perpass] proposed enhancement to TLS strong authentication protocol Thread-Index: Ac6vFM0oAaChRWR6StGXJtPmuw8x5wARAsQAAA6lFfAAHRQhoA== Date: Wed, 11 Sep 2013 18:46:09 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A5AA@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [perpass] FW: proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:46:20 -0000 From: Karl Malbrain=20 Sent: Wednesday, September 11, 2013 11:43 To: 'Theodore Ts'o' Subject: RE: [perpass] proposed enhancement to TLS strong authentication pr= otocol It's a WORM list. Users post requests to the list maintainers they trust w= ith a GUID to register their public key, and then send this GUID as part of= the TLS negotiation process. =20 -----Original Message----- From: Theodore Ts'o [mailto:tytso@mit.edu] Sent: Wednesday, September 11, 2013 11:39 To: Karl Malbrain Cc: perpass@ietf.org Subject: Re: [perpass] proposed enhancement to TLS strong authentication pr= otocol On Wed, Sep 11, 2013 at 05:31:52PM +0000, Karl Malbrain wrote:=20 >Rather than have each TLS server receive user public certificates=20 >individually for strong authentication, implement a global user public=20 >certificate list hosted internationally that supplies user public=20 >certificates to TLS hosts and clients. The list would be read-only,=20 >indexed by GUID, and hosted at multiple international sites. Both TLS=20 >servers and clients could then reliably obtain public certificates by=20 >GUID for use in strong authentication challenges per the TLS protocol. And how would this global public certificate directory be securely updated?= If you simply accept valid certificates, then it doesn't solve the rogue/= comrpomised CA problem. - Ted From hallam@gmail.com Wed Sep 11 11:50:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DC011E8114 for ; Wed, 11 Sep 2013 11:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5HLJQw-udu2 for ; Wed, 11 Sep 2013 11:50:14 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id AB76C11E80D7 for ; Wed, 11 Sep 2013 11:50:13 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ea20so7718191lab.41 for ; Wed, 11 Sep 2013 11:50:12 -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; bh=6v8QLlNMDDAEao48N4J/MSrC88u1b4okZms7Es5ZFmY=; b=asuEsQqN4BFLqJXT3C1W23PUCc/wJhuu17GipaHI9vdZG6GKrHK35JFmlPFdaqpbXM IchCMUQzvk14701tlEHdF1vvh4X/D5GC+XvkR/uXEHcfl6vF32qYIvA3QCWMgitOSVjP L0N7q07II9WQmxoL2fYUly0iFek1G+szPr+RD58lbqU7CI/r6FjrYwXttJSPgKY22l87 oGcqqXdyANPHj4XQPKOysEKppDW5krAvNU8gtGf3LaOHuVeDQJcmxmKxW+27LgZMrrmP zyrYHycaNYDvt1wmfA0y266edBAvN2oictobmwx0ZW29fIKNCrCbmadLrrq5baGu8Aob VYHw== MIME-Version: 1.0 X-Received: by 10.112.126.37 with SMTP id mv5mr3837509lbb.20.1378925412507; Wed, 11 Sep 2013 11:50:12 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Wed, 11 Sep 2013 11:50:12 -0700 (PDT) In-Reply-To: <20130911183856.GA13397@thunk.org> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> Date: Wed, 11 Sep 2013 14:50:12 -0400 Message-ID: From: Phillip Hallam-Baker To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary=001a11c373e46265d704e620175e Cc: "perpass@ietf.org" , Karl Malbrain Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:50:14 -0000 --001a11c373e46265d704e620175e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 2:38 PM, Theodore Ts'o wrote: > On Wed, Sep 11, 2013 at 05:31:52PM +0000, Karl Malbrain wrote: > >Rather than have each TLS server receive user public certificates > >individually for strong authentication, implement a global user public > >certificate list hosted internationally that supplies user public > >certificates to TLS hosts and clients. The list would be read-only, > >indexed by GUID, and hosted at multiple international sites. Both TLS > >servers and clients could then reliably obtain public certificates by > >GUID for use in strong authentication challenges per the TLS protocol. > > And how would this global public certificate directory be securely > updated? If you simply accept valid certificates, then it doesn't > solve the rogue/comrpomised CA problem. > The normal way this is done in practice is for every relying party to issue their own certificates. Which completely destroys the point of using public key. If the issuer is going to be the only relying party you might as well use symmetric crypto and a proof of knowledge which is what I have tried to do in the HTTP Session ID proposal. -- Website: http://hallambaker.com/ --001a11c373e46265d704e620175e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 2:38 PM, Theodore Ts'o <tytso@mit= .edu> wrote:
On Wed, Sep 11, 2013 at 05= :31:52PM +0000, Karl Malbrain wrote:
>Rather than have each TLS server receive user public certificates
>individually for strong authentication, implement a global user public<= br> >certificate list hosted internationally that supplies user public
>certificates to TLS hosts and clients. The list would be read-only,
>indexed by GUID, and hosted at multiple international sites. Both TLS >servers and clients could then reliably obtain public certificates by >GUID for use in strong authentication challenges per the TLS protocol.<= br>
And how would this global public certificate directory be securely updated? =A0If you simply accept valid certificates, then it doesn't solve the rogue/comrpomised CA problem.

The normal way this is done in practice is for every relying party to issu= e their own certificates. Which completely destroys the point of using publ= ic key.=A0

If the issuer is going to be the only relying party you= might as well use symmetric crypto and a proof of knowledge which is what = I have tried to do in the HTTP Session ID proposal.


--
Website: ht= tp://hallambaker.com/
--001a11c373e46265d704e620175e-- From paul@nohats.ca Wed Sep 11 11:51:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A510311E8219 for ; Wed, 11 Sep 2013 11:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzGMYliAa7rx for ; Wed, 11 Sep 2013 11:51:12 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id DECF211E81D1 for ; Wed, 11 Sep 2013 11:51:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cZsdP6G3cz9HH; Wed, 11 Sep 2013 14:51:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id euykPQRqlmu7; Wed, 11 Sep 2013 14:51:05 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 11 Sep 2013 14:51:05 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id DCB7580031; Wed, 11 Sep 2013 14:51:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D410B80030; Wed, 11 Sep 2013 14:51:05 -0400 (EDT) Date: Wed, 11 Sep 2013 14:51:05 -0400 (EDT) From: Paul Wouters To: Karl Malbrain In-Reply-To: <65EEC6E375AA474A847D510D5B7E83742502A5AA@mail2010> Message-ID: References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5AA@mail2010> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "perpass@ietf.org" Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:51:16 -0000 On Wed, 11 Sep 2013, Karl Malbrain wrote: > From: Karl Malbrain > Sent: Wednesday, September 11, 2013 11:43 > To: 'Theodore Ts'o' > Subject: RE: [perpass] proposed enhancement to TLS strong authentication protocol > > It's a WORM list. Users post requests to the list maintainers they trust with a GUID to register their public key, and then send this GUID as part of the TLS negotiation process. Seems to me to be basically like an unscalable central version of the TLSA record? https://tools.ietf.org/html/rfc6698 Paul From karl@petzent.com Wed Sep 11 11:56:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C0D11E813B for ; Wed, 11 Sep 2013 11:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.943 X-Spam-Level: * X-Spam-Status: No, score=1.943 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AxmAnGrL+W1 for ; Wed, 11 Sep 2013 11:56:43 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id 53B8111E8121 for ; Wed, 11 Sep 2013 11:56:04 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 11 Sep 2013 11:56:13 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 11:56:05 -0700 From: Karl Malbrain To: Phillip Hallam-Baker , Theodore Ts'o Thread-Topic: [perpass] proposed enhancement to TLS strong authentication protocol Thread-Index: Ac6vFM0oAaChRWR6StGXJtPmuw8x5wARAsQAAABkuwAADqGlkA== Date: Wed, 11 Sep 2013 18:56:04 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E83742502A5C7mail2010_" MIME-Version: 1.0 Cc: "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 18:56:52 -0000 --_000_65EEC6E375AA474A847D510D5B7E83742502A5C7mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The goal of the proposal is to enable the use of strong authentication for = all TLS connections over the internet. The certificates as things-in-thems= elves don't really matter, they are actually just a vehicle to post the pub= lic key of the user/server in a reliable public place. The security occurs= when the challenges to prove private key ownership are cross-issued by eac= h party. MITM would not have the private keys to answer either challenge. Note that this still doesn't solve the problem of MITM obtaining the server= 's private key. I'm still working on that one. Karl From: Phillip Hallam-Baker [mailto:hallam@gmail.com] Sent: Wednesday, September 11, 2013 11:50 To: Theodore Ts'o Cc: Karl Malbrain; perpass@ietf.org Subject: Re: [perpass] proposed enhancement to TLS strong authentication pr= otocol On Wed, Sep 11, 2013 at 2:38 PM, Theodore Ts'o > wrote: On Wed, Sep 11, 2013 at 05:31:52PM +0000, Karl Malbrain wrote: >Rather than have each TLS server receive user public certificates >individually for strong authentication, implement a global user public >certificate list hosted internationally that supplies user public >certificates to TLS hosts and clients. The list would be read-only, >indexed by GUID, and hosted at multiple international sites. Both TLS >servers and clients could then reliably obtain public certificates by >GUID for use in strong authentication challenges per the TLS protocol. And how would this global public certificate directory be securely updated? If you simply accept valid certificates, then it doesn't solve the rogue/comrpomised CA problem. The normal way this is done in practice is for every relying party to issue= their own certificates. Which completely destroys the point of using publi= c key. If the issuer is going to be the only relying party you might as well use s= ymmetric crypto and a proof of knowledge which is what I have tried to do i= n the HTTP Session ID proposal. -- Website: http://hallambaker.com/ --_000_65EEC6E375AA474A847D510D5B7E83742502A5C7mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The goal of the proposal = is to enable the use of strong authentication for all TLS connections over = the internet.  The certificates as things-in-themselves don’t really matter, they are actually just a vehicle to post the pu= blic key of the user/server in a reliable public place.  The security = occurs when the challenges to prove private key ownership are cross-issued = by each party.  MITM would not have the private keys to answer either challenge.

 <= /p>

Note that this still does= n’t solve the problem of MITM obtaining the server’s private ke= y.  I’m still working on that one.

Karl

 <= /p>

From: Phillip = Hallam-Baker [mailto:hallam@gmail.com]
Sent: Wednesday, September 11, 2013 11:50
To: Theodore Ts'o
Cc: Karl Malbrain; perpass@ietf.org
Subject: Re: [perpass] proposed enhancement to TLS strong authentica= tion protocol

 

On Wed, Sep 11, 2013 at 2:38 PM, Theodore Ts'o <<= a href=3D"mailto:tytso@mit.edu" target=3D"_blank">tytso@mit.edu> wro= te:

On Wed, Sep 11, 2013 = at 05:31:52PM +0000, Karl Malbrain wrote:
>Rather than have each TLS server receive user public certificates
>individually for strong authentication, implement a global user public<= br> >certificate list hosted internationally that supplies user public
>certificates to TLS hosts and clients. The list would be read-only,
>indexed by GUID, and hosted at multiple international sites. Both TLS >servers and clients could then reliably obtain public certificates by >GUID for use in strong authentication challenges per the TLS protocol.<= o:p>

And how would this global public certificate directo= ry be securely
updated?  If you simply accept valid certificates, then it doesn't
solve the rogue/comrpomised CA problem.

 

The normal way this is done in practice is for every= relying party to issue their own certificates. Which completely destroys t= he point of using public key. 

 

If the issuer is going to be the only relying party = you might as well use symmetric crypto and a proof of knowledge which is wh= at I have tried to do in the HTTP Session ID proposal.

 

 

--
Website: http://hallambaker.com/

--_000_65EEC6E375AA474A847D510D5B7E83742502A5C7mail2010_-- From karl@petzent.com Wed Sep 11 12:06:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F1F21E811D for ; Wed, 11 Sep 2013 12:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.88 X-Spam-Level: * X-Spam-Status: No, score=1.88 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kses4O5lSqD for ; Wed, 11 Sep 2013 12:06:24 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id 73E0E21E80DE for ; Wed, 11 Sep 2013 12:05:23 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 11 Sep 2013 12:05:05 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 12:04:57 -0700 From: Karl Malbrain To: Paul Wouters Thread-Topic: [perpass] FW: proposed enhancement to TLS strong authentication protocol Thread-Index: AQHOrx/lV3ta+zfkaE6b6qzUt7miPpnA5FRw Date: Wed, 11 Sep 2013 19:04:56 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A5DA@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5AA@mail2010> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "perpass@ietf.org" Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 19:06:46 -0000 >From a very quick read rfc 6698, what I'm doing differently is to add the a= bility for the TLS server to authenticate the client by using the client's = registration GUID rather than DNS Karl. -----Original Message----- From: Paul Wouters [mailto:paul@nohats.ca]=20 Sent: Wednesday, September 11, 2013 11:51 To: Karl Malbrain Cc: perpass@ietf.org Subject: Re: [perpass] FW: proposed enhancement to TLS strong authenticatio= n protocol On Wed, 11 Sep 2013, Karl Malbrain wrote: > From: Karl Malbrain > Sent: Wednesday, September 11, 2013 11:43 > To: 'Theodore Ts'o' > Subject: RE: [perpass] proposed enhancement to TLS strong authentication = protocol > > It's a WORM list. Users post requests to the list maintainers they trust= with a GUID to register their public key, and then send this GUID as part = of the TLS negotiation process. Seems to me to be basically like an unscalable central version of the TLSA = record? https://tools.ietf.org/html/rfc6698 Paul From hallam@gmail.com Wed Sep 11 12:16:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A7D11E80EE for ; Wed, 11 Sep 2013 12:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEQ99pe4ZgkI for ; Wed, 11 Sep 2013 12:15:58 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id C291121F8E2D for ; Wed, 11 Sep 2013 12:15:55 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id er20so7817288lab.35 for ; Wed, 11 Sep 2013 12:15:54 -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; bh=zt1ybje4j62wJnRvh37tWfw+JmZ0xf7I6CVmgkzeSn4=; b=bZZAccrdWHpNWKbltVWX69M2T6bKxgwed8ldD5of9/ZTncrqvMnvUhiaDE2eQr19DJ avPpKxRTwDO2CQjNWmLlDmse7NmFl3a6/DB0808t+1t99SjCaTaLgwWJiPQw4FbVC8t/ r8Thqgm/rfDKXQ9YoWaFapmyl2cowRZL/OkV5TWisckeyRBEfnTlNal2y9Petf5UPFnE njlchrmTXzV9tt0LX9KxzVf3TFva+RK+QdCXpnZYajxB8D3gVTeyj1PSKS3DpxnLeoZM AHuUfzsFXEeIU19DDfJUEJqSjdpNEHAIe/Wswbb44v++iYWx2IBNO1gntLFkAR82+drh 4YTA== MIME-Version: 1.0 X-Received: by 10.152.19.1 with SMTP id a1mr2534701lae.8.1378926954711; Wed, 11 Sep 2013 12:15:54 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Wed, 11 Sep 2013 12:15:54 -0700 (PDT) In-Reply-To: References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5AA@mail2010> Date: Wed, 11 Sep 2013 15:15:54 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=089e01493e424e91cc04e62073b8 Cc: "perpass@ietf.org" , Karl Malbrain Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 19:16:00 -0000 --089e01493e424e91cc04e62073b8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters wrote: > On Wed, 11 Sep 2013, Karl Malbrain wrote: > > From: Karl Malbrain >> Sent: Wednesday, September 11, 2013 11:43 >> To: 'Theodore Ts'o' >> Subject: RE: [perpass] proposed enhancement to TLS strong authentication >> protocol >> >> It's a WORM list. Users post requests to the list maintainers they trust >> with a GUID to register their public key, and then send this GUID as part >> of the TLS negotiation process. >> > > Seems to me to be basically like an unscalable central version of the TLSA > record? > > https://tools.ietf.org/html/**rfc6698 I think it can be decentralized and have been working on an architecture to do that for email security. But it does not really help much for authentication to random Web sites or for enterprise use either. -- Website: http://hallambaker.com/ --089e01493e424e91cc04e62073b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <= ;paul@nohats.ca>= wrote:
On Wed, 11 Sep 2013, Karl = Malbrain wrote:

From: Karl Malbrain
Sent: Wednesday, September 11, 2013 11:43
To: 'Theodore Ts'o'
Subject: RE: [perpass] proposed enhancement to TLS strong authentication pr= otocol

It's a WORM list. =A0Users post requests to the list maintainers they t= rust with a GUID to register their public key, and then send this GUID as p= art of the TLS negotiation process.

Seems to me to be basically like an unscalable central version of the TLSA = record?

https://t= ools.ietf.org/html/rfc6698

I thi= nk it can be decentralized and have been working on an architecture to do t= hat for email security.

But it does not really help much for authentication to = random Web sites or for enterprise use either.

=A0=

--
Website: http://hallambaker.com/
--089e01493e424e91cc04e62073b8-- From karl@petzent.com Wed Sep 11 12:23:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B57221E80B9 for ; Wed, 11 Sep 2013 12:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.842 X-Spam-Level: * X-Spam-Status: No, score=1.842 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKppwIVLKzjY for ; Wed, 11 Sep 2013 12:23:49 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29C21E80CE for ; Wed, 11 Sep 2013 12:23:39 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 11 Sep 2013 12:23:47 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 12:23:39 -0700 From: Karl Malbrain To: Phillip Hallam-Baker , Paul Wouters Thread-Topic: [perpass] FW: proposed enhancement to TLS strong authentication protocol Thread-Index: AQHOrx/lV3ta+zfkaE6b6qzUt7miPpnBXcQA//+LUFA= Date: Wed, 11 Sep 2013 19:23:38 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A5F7@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5AA@mail2010> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E83742502A5F7mail2010_" MIME-Version: 1.0 Cc: "perpass@ietf.org" Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 19:23:54 -0000 --_000_65EEC6E375AA474A847D510D5B7E83742502A5F7mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The list is replicated but not centralized per-se. There is only one conten= t. Larger servers could maintain their own copy of the replicated list for = their own usage. As to the utility of the enhancement, MITM attachments/attacks are preclude= d by strong authentication of both the server and the client. The specific= technical problem addressed is the ability of both parties to reliably obt= ain client public keys during TLS negotiation. From: Phillip Hallam-Baker [mailto:hallam@gmail.com] Sent: Wednesday, September 11, 2013 12:16 To: Paul Wouters Cc: Karl Malbrain; perpass@ietf.org Subject: Re: [perpass] FW: proposed enhancement to TLS strong authenticatio= n protocol On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters > wrote: On Wed, 11 Sep 2013, Karl Malbrain wrote: From: Karl Malbrain Sent: Wednesday, September 11, 2013 11:43 To: 'Theodore Ts'o' Subject: RE: [perpass] proposed enhancement to TLS strong authentication pr= otocol It's a WORM list. Users post requests to the list maintainers they trust w= ith a GUID to register their public key, and then send this GUID as part of= the TLS negotiation process. Seems to me to be basically like an unscalable central version of the TLSA = record? https://tools.ietf.org/html/rfc6698 I think it can be decentralized and have been working on an architecture to= do that for email security. But it does not really help much for authentication to random Web sites or = for enterprise use either. -- Website: http://hallambaker.com/ --_000_65EEC6E375AA474A847D510D5B7E83742502A5F7mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The list is replicated bu= t not centralized per-se. There is only one content. Larger servers could m= aintain their own copy of the replicated list for their own usage.

 <= /p>

As to the utility of the = enhancement, MITM attachments/attacks are precluded by strong authenticatio= n of both the server and the client.  The specific technical problem addressed is the ability of both parties to reliably obtain client= public keys during TLS negotiation.

 <= /p>

From: Phillip = Hallam-Baker [mailto:hallam@gmail.com]
Sent: Wednesday, September 11, 2013 12:16
To: Paul Wouters
Cc: Karl Malbrain; perpass@ietf.org
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authen= tication protocol

 

 

 

On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <paul@nohats.ca> wr= ote:

On Wed, 11 Sep 2013, = Karl Malbrain wrote:

From: Karl Malbrain
Sent: Wednesday, September 11, 2013 11:43
To: 'Theodore Ts'o'
Subject: RE: [perpass] proposed enhancement to TLS strong authentication pr= otocol

It's a WORM list.  Users post requests to the list maintainers they tr= ust with a GUID to register their public key, and then send this GUID as pa= rt of the TLS negotiation process.

 

Seems to me to be basically like an unscalable centr= al version of the TLSA record?

https://t= ools.ietf.org/html/rfc6698

 

I think it can be decentralized and have been workin= g on an architecture to do that for email security.

 

But it does not really help much for authentication = to random Web sites or for enterprise use either.

 

 

 

--
Website: http://hallambaker.com/

--_000_65EEC6E375AA474A847D510D5B7E83742502A5F7mail2010_-- From hallam@gmail.com Wed Sep 11 13:28:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8BB21E8054 for ; Wed, 11 Sep 2013 13:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qPWL+iAfPzQ for ; Wed, 11 Sep 2013 13:27:59 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 32BF311E80E2 for ; Wed, 11 Sep 2013 13:27:58 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id el20so7691573lab.26 for ; Wed, 11 Sep 2013 13:27:57 -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=T2hcI7XMnUWk2VaGHTadoqyevZFVdFXolkAWZpkhwa8=; b=z4xN2rFHgk2jcyU0XhVBEwMSpRm5Cggedv2GtesIPyaojPppe8cNe6OWaWhBVjhwnK mdr+RN5vrS28zZZb0V5npSmRxoLda4Qih1vBeF7plq+HF8dM0k04cfqYbOp8qFfuQXFK OCiPRPsTQSjY1Zj1fR/vytB57gbGaH8C0PoLkX4ig2YtjUdTn1aRwNl693HFZw/vGjdL ip/lBHyxqnYylW7YNPzT+5YtPD5dY5Pp9LXTDGDtWRVtDrR0ljsLOuR418dTeDqh7GIV C9jhXm8KE7OKwrvL19EvPmeuTRLl4qksahQJyQYeOilTfE6sZsD8KaqflOdC7lw35XEu x0GQ== MIME-Version: 1.0 X-Received: by 10.112.156.166 with SMTP id wf6mr4078707lbb.13.1378931276942; Wed, 11 Sep 2013 13:27:56 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Wed, 11 Sep 2013 13:27:56 -0700 (PDT) Date: Wed, 11 Sep 2013 16:27:56 -0400 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=001a11c18e7aee92c804e62174fb Subject: [perpass] PRISM-Proof Criteria X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 20:28:00 -0000 --001a11c18e7aee92c804e62174fb Content-Type: text/plain; charset=ISO-8859-1 If you have been following the cryptography list you will have noticed that it is rather high volume of late. I produced some notes in an attempt to summarize the discussion and have just converted them into an Internet draft which might be helpful to people who don't have time to go through the whole discussion. http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt It is currently missing citations and acknowledgements and quite likely whole areas of discussion. I will try to get to those. All errors including the formatting errors (clublines!) are mine. -- Website: http://hallambaker.com/ --001a11c18e7aee92c804e62174fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If you have been following the cryptography list you will = have noticed that it is rather high volume of late. I produced some notes i= n an attempt to summarize the discussion and have just converted them into = an Internet draft which might be helpful to people who don't have time = to go through the whole discussion.

http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.t= xt

It is currently missing citatio= ns and acknowledgements and quite likely whole areas of discussion. I will = try to get to those.

All errors including the formatting errors (clublines!)= are mine.

--
Website: http://hallambaker.com/
--001a11c18e7aee92c804e62174fb-- From ggm@algebras.org Wed Sep 11 16:08:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C94A11E8186 for ; Wed, 11 Sep 2013 16:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws67B5TDCJUG for ; Wed, 11 Sep 2013 16:07:42 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 29BA411E8106 for ; Wed, 11 Sep 2013 16:07:41 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so262567pab.29 for ; Wed, 11 Sep 2013 16:07:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SzBBnl8Mrm/xUuZVro4CFNdXyReBcjd8vB3Oz/95L8I=; b=jxkfWpe6zL6Plr7K/1eZm0CGahGIXRTd8AhTeyq35DwKBcIDL2ARIVoMZzvXpYukPX BCgwNF2GiRCkvPi3meE30R0CeSp2B/XLDyqDJjyCxUqqxEZPDWRRunbciCVtkvC6DA85 OA5tNp6Ds6Yqds6VrHESH4y2p0dc0i3osxVW7QIaj2wqUN3ZPVSS84VJ+jciywIV7tWV SunPgN380jQGjimSYHI5eoX79Ct5JPqT9SLR9X2qSITOZ2DELrpVJ6IYZ+57CksUqXRU kC2XZv8rZx+xp+lDrdPwwXV0rCknHoG6PEYWc9pP95qhVTc365aP6DBtxsRBmVX75TWE kMjw== X-Gm-Message-State: ALoCoQkygJZvaUXyJsIkPprEhTtW9kZQxFiLbzRZwfrRyzuKMHkOjtUuBTdabW+ejtFHD7Y1Yni0 MIME-Version: 1.0 X-Received: by 10.66.150.69 with SMTP id ug5mr6307246pab.55.1378940861475; Wed, 11 Sep 2013 16:07:41 -0700 (PDT) Received: by 10.70.19.98 with HTTP; Wed, 11 Sep 2013 16:07:41 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:b507:9241:edf2:674b] In-Reply-To: <65EEC6E375AA474A847D510D5B7E83742502A5F7@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5AA@mail2010> <65EEC6E375AA474A847D510D5B7E83742502A5F7@mail2010> Date: Thu, 12 Sep 2013 09:07:41 +1000 Message-ID: From: George Michaelson To: Karl Malbrain Content-Type: multipart/alternative; boundary=047d7b6dc31e36ffbd04e623b09c Cc: "perpass@ietf.org" , Paul Wouters , Phillip Hallam-Baker Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 23:08:04 -0000 --047d7b6dc31e36ffbd04e623b09c Content-Type: text/plain; charset=ISO-8859-1 unscaleable is a word which had currency in 16 bit computer days, and possibly in 32 bit computers when disks and bandwidth were untenably expensive. I am less sure that any enterprise which only has to scale to addressing 2 billion people in the next 5-10 years is 'unscaleable' in the real sense of the world. 'seems very inefficient' or 'seems like a problem which will carry its own sub-problems' or 'scaling this is a challenge which demands funding and eyeballs' are all less direct statements going to the same place. or do you believe UUID collide, and in fact cannot uniquely identify end entities casting the runes to make randoms? On Thu, Sep 12, 2013 at 5:23 AM, Karl Malbrain wrote: > The list is replicated but not centralized per-se. There is only one > content. Larger servers could maintain their own copy of the replicated > list for their own usage.**** > > ** ** > > As to the utility of the enhancement, MITM attachments/attacks are > precluded by strong authentication of both the server and the client. The > specific technical problem addressed is the ability of both parties to > reliably obtain client public keys during TLS negotiation.**** > > ** ** > > *From:* Phillip Hallam-Baker [mailto:hallam@gmail.com] > *Sent:* Wednesday, September 11, 2013 12:16 > *To:* Paul Wouters > *Cc:* Karl Malbrain; perpass@ietf.org > *Subject:* Re: [perpass] FW: proposed enhancement to TLS strong > authentication protocol**** > > ** ** > > ** ** > > ** ** > > On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters wrote:**** > > On Wed, 11 Sep 2013, Karl Malbrain wrote:**** > > From: Karl Malbrain > Sent: Wednesday, September 11, 2013 11:43 > To: 'Theodore Ts'o' > Subject: RE: [perpass] proposed enhancement to TLS strong authentication > protocol > > It's a WORM list. Users post requests to the list maintainers they trust > with a GUID to register their public key, and then send this GUID as part > of the TLS negotiation process.**** > > ** ** > > Seems to me to be basically like an unscalable central version of the TLSA > record? > > https://tools.ietf.org/html/rfc6698**** > > ** ** > > I think it can be decentralized and have been working on an architecture > to do that for email security.**** > > ** ** > > But it does not really help much for authentication to random Web sites or > for enterprise use either.**** > > ** ** > > **** > > ** ** > > -- > Website: http://hallambaker.com/**** > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > --047d7b6dc31e36ffbd04e623b09c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
unscaleable is a word which had currency in 16 bit compute= r days, and possibly in 32 bit computers when disks and bandwidth were unte= nably expensive. I am less sure that any enterprise which only has to scale= to addressing 2 billion people in the next 5-10 years is 'unscaleable&= #39; in the real sense of the world.

'seems very inefficient' or 'seems like a proble= m which will carry its own sub-problems' or 'scaling this is a chal= lenge which demands funding and eyeballs' are all less direct statement= s going to the same place.

or do you believe UUID collide, and in fact cannot uniq= uely identify end entities casting the runes to make randoms?


On Thu, Sep 12,= 2013 at 5:23 AM, Karl Malbrain <karl@petzent.com> wrote:

The list is replicated bu= t not centralized per-se. There is only one content. Larger servers could m= aintain their own copy of the replicated list for their own usage.

=A0<= /p>

As to the utility of the = enhancement, MITM attachments/attacks are precluded by strong authenticatio= n of both the server and the client.=A0 The specific technical problem addressed is the ability of both parties to reliably obtain client= public keys during TLS negotiation.

=A0<= /p>

From: Phillip = Hallam-Baker [mailto:= hallam@gmail.com]
Sent: Wednesday, September 11, 2013 12:16
To: Paul Wouters
Cc: Karl Malbrain; perpass@ietf.org
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authen= tication protocol

=A0

=A0

=A0

On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <paul@nohats.ca> wr= ote:

On Wed, 11 Sep 2013, = Karl Malbrain wrote:

From: Karl Malbrain
Sent: Wednesday, September 11, 2013 11:43
To: 'Theodore Ts'o'
Subject: RE: [perpass] proposed enhancement to TLS strong authentication pr= otocol

It's a WORM list. =A0Users post requests to the list maintainers they t= rust with a GUID to register their public key, and then send this GUID as p= art of the TLS negotiation process.

=A0

Seems to me to be basically like an unscalable centr= al version of the TLSA record?

https://t= ools.ietf.org/html/rfc6698

=A0

I think it can be decentralized and have been workin= g on an architecture to do that for email security.

=A0

But it does not really help much for authentication = to random Web sites or for enterprise use either.

=A0

=A0

=A0

--
Website: http://halla= mbaker.com/


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


--047d7b6dc31e36ffbd04e623b09c-- From karl@petzent.com Wed Sep 11 16:14:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9974E11E81D7 for ; Wed, 11 Sep 2013 16:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.817 X-Spam-Level: * X-Spam-Status: No, score=1.817 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir8WrkxBYAZR for ; Wed, 11 Sep 2013 16:14:09 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4060721F96EF for ; Wed, 11 Sep 2013 16:14:08 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 11 Sep 2013 16:14:15 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 16:14:07 -0700 From: Karl Malbrain To: George Michaelson Thread-Topic: [perpass] FW: proposed enhancement to TLS strong authentication protocol Thread-Index: AQHOrx/lV3ta+zfkaE6b6qzUt7miPpnBXcQA//+LUFCAALVzgP//i0pw Date: Wed, 11 Sep 2013 23:14:06 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A638@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5AA@mail2010> <65EEC6E375AA474A847D510D5B7E83742502A5F7@mail2010> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E83742502A638mail2010_" MIME-Version: 1.0 Cc: "perpass@ietf.org" , Paul Wouters , Phillip Hallam-Baker Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 23:14:30 -0000 --_000_65EEC6E375AA474A847D510D5B7E83742502A638mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable UUID collisions would be handled by the list servers which would silently r= eject posts of user public keys to occupied UUID slots. User's would deter= mine this by noting that a UUID query doesn't produce their public key, an= d then retry the post with a different UUID. List servers would communicate among themselves to replicate the list globa= lly. Karl From: George Michaelson [mailto:ggm@algebras.org] Sent: Wednesday, September 11, 2013 16:08 To: Karl Malbrain Cc: Phillip Hallam-Baker; Paul Wouters; perpass@ietf.org Subject: Re: [perpass] FW: proposed enhancement to TLS strong authenticatio= n protocol unscaleable is a word which had currency in 16 bit computer days, and possi= bly in 32 bit computers when disks and bandwidth were untenably expensive. = I am less sure that any enterprise which only has to scale to addressing 2 = billion people in the next 5-10 years is 'unscaleable' in the real sense of= the world. 'seems very inefficient' or 'seems like a problem which will carry its own = sub-problems' or 'scaling this is a challenge which demands funding and eye= balls' are all less direct statements going to the same place. or do you believe UUID collide, and in fact cannot uniquely identify end en= tities casting the runes to make randoms? On Thu, Sep 12, 2013 at 5:23 AM, Karl Malbrain > wrote: The list is replicated but not centralized per-se. There is only one conten= t. Larger servers could maintain their own copy of the replicated list for = their own usage. As to the utility of the enhancement, MITM attachments/attacks are preclude= d by strong authentication of both the server and the client. The specific= technical problem addressed is the ability of both parties to reliably obt= ain client public keys during TLS negotiation. From: Phillip Hallam-Baker [mailto:hallam@gmail.com] Sent: Wednesday, September 11, 2013 12:16 To: Paul Wouters Cc: Karl Malbrain; perpass@ietf.org Subject: Re: [perpass] FW: proposed enhancement to TLS strong authenticatio= n protocol On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters > wrote: On Wed, 11 Sep 2013, Karl Malbrain wrote: From: Karl Malbrain Sent: Wednesday, September 11, 2013 11:43 To: 'Theodore Ts'o' Subject: RE: [perpass] proposed enhancement to TLS strong authentication pr= otocol It's a WORM list. Users post requests to the list maintainers they trust w= ith a GUID to register their public key, and then send this GUID as part of= the TLS negotiation process. Seems to me to be basically like an unscalable central version of the TLSA = record? https://tools.ietf.org/html/rfc6698 I think it can be decentralized and have been working on an architecture to= do that for email security. But it does not really help much for authentication to random Web sites or = for enterprise use either. -- Website: http://hallambaker.com/ _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass --_000_65EEC6E375AA474A847D510D5B7E83742502A638mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

UUID collisions would be = handled by the list servers which would silently reject posts of user publi= c keys to occupied UUID slots.  User’s would determine this by noting that a  UUID query doesn’t produce their public key, = and then retry the post with a different UUID.

 <= /p>

List servers would commun= icate among themselves to replicate the list globally.

 <= /p>

Karl

 <= /p>

From: George M= ichaelson [mailto:ggm@algebras.org]
Sent: Wednesday, September 11, 2013 16:08
To: Karl Malbrain
Cc: Phillip Hallam-Baker; Paul Wouters; perpass@ietf.org
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authen= tication protocol

 

unscaleable is a word which had currency in 16 bit c= omputer days, and possibly in 32 bit computers when disks and bandwidth wer= e untenably expensive. I am less sure that any enterprise which only has to= scale to addressing 2 billion people in the next 5-10 years is 'unscaleable' in the real sense of the world.

 

'seems very inefficient' or 'seems like a problem wh= ich will carry its own sub-problems' or 'scaling this is a challenge which = demands funding and eyeballs' are all less direct statements going to the s= ame place.

 

or do you believe UUID collide, and in fact cannot u= niquely identify end entities casting the runes to make randoms?=

 

On Thu, Sep 12, 2013 at 5:23 AM, Karl Malbrain <<= a href=3D"mailto:karl@petzent.com" target=3D"_blank">karl@petzent.com&g= t; wrote:

The list is replicated but not centrali= zed per-se. There is only one content. Larger servers could maintain their own copy of the replicated list for their own usage.=

 

As to the utility of the enhancement, M= ITM attachments/attacks are precluded by strong authentication of both the server and the client.  The specific technical problem ad= dressed is the ability of both parties to reliably obtain client public key= s during TLS negotiation.

 

From: Phillip Hallam-Baker [= mailto:hallam@gmail.c= om]
Sent: Wednesday, September 11, 2013 12:16
To: Paul Wouters
Cc: Karl Malbrain; perpass@ietf.org
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authen= tication protocol

 

 

 

On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <paul@nohats.ca> wrote:

On Wed, 11 Sep 2013, Karl Malbrain wrote:

From: Karl Malbrain
Sent: Wednesday, September 11, 2013 11:43
To: 'Theodore Ts'o'
Subject: RE: [perpass] proposed enhancement to TLS strong authentication pr= otocol

It's a WORM list.  Users post requests to the list maintainers they tr= ust with a GUID to register their public key, and then send this GUID as pa= rt of the TLS negotiation process.

 

Seems to me to be basically like an unscalable central version of = the TLSA record?

https://t= ools.ietf.org/html/rfc6698

 

I think it can be decentralized and have been working on an archit= ecture to do that for email security.

 

But it does not really help much for authentication to random Web = sites or for enterprise use either.

 

 

 

--
Website: http://halla= mbaker.com/


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

 

--_000_65EEC6E375AA474A847D510D5B7E83742502A638mail2010_-- From nick.a.mathewson@gmail.com Wed Sep 11 20:51:32 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E65E21E8128; Wed, 11 Sep 2013 20:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j5P5BRAAzz2; Wed, 11 Sep 2013 20:51:30 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BEB9021E8122; Wed, 11 Sep 2013 20:51:28 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ep20so8078574lab.2 for ; Wed, 11 Sep 2013 20:51:20 -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=pFrMfEaZLUQ0i0pHlHuaRqSUvR8ShZy7SbRVYvG2CRg=; b=zgorwEkDUCdmi7O6aTdFrwMSfWoJ2NkNhgFjZZHR2WQXup1+97sHC6+qhLAVrlYr1I x5bIdNi/g1hX0sqPwMyxXydEZvYjOPQeBRya85aOxWLzGyZSIw2irBLQ1x5zwsarPr1Z WLRIpxlYol+cy54N/n2/yioKR174i9QVU+Jy0LBVlp6dYZJQg2qZ/8QZi2DEhC+Y9do0 BwBfIix0qGS0yn04oImX0SI1/IZKOFVgcUy6Ig7mMxcA2YAAqILiPh2wXPHcCz2mOxCK KE/zjqEcJVENtHlnFFw+2oIFUBwQETMpXXhqNz/ouxM8hZJGmi3JGfJDHzsc3gGsxzVd +fnA== MIME-Version: 1.0 X-Received: by 10.112.126.37 with SMTP id mv5mr5549191lbb.20.1378957880839; Wed, 11 Sep 2013 20:51:20 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.112.30.166 with HTTP; Wed, 11 Sep 2013 20:51:20 -0700 (PDT) In-Reply-To: <20130911174135.455A01A960@ld9781.wdf.sap.corp> References: <20130911174135.455A01A960@ld9781.wdf.sap.corp> Date: Wed, 11 Sep 2013 23:51:20 -0400 X-Google-Sender-Auth: qrYdXjCpbpbr9boikU2391fFQu0 Message-ID: From: Nick Mathewson To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass@ietf.org, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 03:51:32 -0000 On Wed, Sep 11, 2013 at 1:41 PM, Martin Rex wrote: > Nick Mathewson wrote: >> ==== >> SYNOPSIS: >> >> In TLS as currently specified, clients and servers each send their >> current view of "the time" in the clear as part of their handshake. >> This provides a fingerprint that can track users in spite of other >> attempts to make them untrackable. I propose several ways to stop >> doing sending this cleartext timestamp; some trivial and some more >> complex. > > I would really appreciate a different approach to the underlying > issue, and less throwing of smoke grenades here. I assume good faith on your part; please do the favor of assuming good faith on mine. > If you're worried about being slightly "distinguishable" from some > other clients, then there are a lot more reliable identifiers available > in the average TLS handshake, so claiming that sending the actual local > time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting > issue and sending random will solve the fingerprinting issue, is > bordering on lame for >99% of the clients. Indeed, I never said this was a "severe" issue, or that it was the only issue you need to solve to solve fingerprinting. I said: "This provides a fingerprint that can track users in spite of other attempts to make them untrackable." I know that reading perpass, one expects proposals to fundamentally transform the Internet to make it more secure. This is not such a fundamental transformation. This is a little simple change to fix a little simple little problem. Of such simple little problems, client linkability is made. > Most of the time, repeated requests of the same TLS client can be > identified by the network connection having the same client IP address, > the TLS session proposed for resumption in ClientHello.session_id > or maybe someone still using TLS session tickets (rfc5077). > So rather than pointing to ClientHello.Random.gmt_unix_time as a > and claiming there would be a simple fix, one will likely have to > create and go through a long list of issues to determine which > features facilitate fingerprinting and tracking (cipher suites > and many TLS extensions (TLS caching extension, signature algorithms, > Next protocol negotiation, supported elliptic curves, etc.) may > all help in distinguishing clients, and would also have to be > taken care of. That's all true; disabling gmt_unix_time is by no means sufficient to make multiple TLS clients look the same on the wire, or to prevent an observer distinguishing TLS instances. In Tor's case, we mitigate this by disabling some TLS features, specifying required values for others, rotating some identifiers more frequently than most implementations, and shipping all of our clients with the same crypto libraries. Most of the fingerprinting issues in TLS can be ameliorated, for a single application, by defining a profile that all of that application's users should share. My issue here right now that, even *after* taking all these precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC doesn't make it optional. Come heck or high water, Tor is going to stop sending gmt_unix_time unless we find a really excellent reason to send it. We'd like to replace it with the best alternative we can. I sent all the alternatives I could think of, because: 1) I would like future versions of the TLS RFC to not require gmt_unix_time. 2) I would like to know whether there's a truly legit reason to send gmt_unx_time. 3) I would like to know the best thing to do instead of gmt_unix_time. (The IP address issue is important too, but not overriding here. The issue here is that even after a client has changed its IP addresses either through moving around the network or going behind a NAT or VPN or by using an IP anonymization service, this fingerprint remains.) -- Nick From mrex@sap.com Wed Sep 11 21:17:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C16421F9C06; Wed, 11 Sep 2013 21:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13sas5iH2Gqx; Wed, 11 Sep 2013 21:17:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7521F9E99; Wed, 11 Sep 2013 21:17:35 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8C4HXJi025819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Sep 2013 06:17:33 +0200 (MEST) In-Reply-To: To: Nick Mathewson Date: Thu, 12 Sep 2013 06:17:33 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130912041733.817521A961@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: perpass@ietf.org, mrex@sap.com, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 04:17:40 -0000 Nick Mathewson wrote: > > My issue here right now that, even *after* taking all these > precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC > doesn't make it optional. Huh? where in rfc6101, rfc2246, rfc4346 or rfc5246 do you find _anything_at_all_ that could be remotely interpreted as a requirement for ClientHello.Random.gmt_unix_time to have any specific value or be within any particular value range -- in contradiction to what section 7.4.1.2 says? (Same for ServerHello.Random.gmt_unix_time). http://tools.ietf.org/html/rfc2246#section-7.4.1.2 Structure of this message: The client hello message includes a random structure, which is used later in the protocol. struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; gmt_unix_time The current time and date in standard UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, GMT) according to the sender's internal clock. Clocks are not required to be set correctly by the basic TLS Protocol; higher level or application protocols may define additional requirements. Which part of "Clocks are not required to be set correctly by the basic TLS protocol" is unclear? This explicitly spells out that one can send _ANY_ pattern of 32 bits as gmt_unix_time, as far as the SSLv3&TLS protocol specifications themselves are concerned. -Martin From pgut001@cs.auckland.ac.nz Wed Sep 11 22:20:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1621E812A; Wed, 11 Sep 2013 22:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiWtVMEBTDDE; Wed, 11 Sep 2013 22:20:53 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABE721E812E; Wed, 11 Sep 2013 22:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378963248; x=1410499248; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=uWlLEbZZLdgXpTrt1h0LVJnFiQyGwJvyg5uqJeWMM0k=; b=iU9FWhMKo1zv9hEvE+xShVsxhhk9ueYeClUO6iVRmsbrqeF836sSq+G8 QNTrB/hRtyTgMvg/Cs5XEQXnpTP5+H7oVlzPQyMLn5AZhrLs2BQSa5pkw jSQNFNpIwKQ0420Wy51X0sSERcCnWj735lOBFCvDFGGLv95VXaFtKTXXN I=; X-IronPort-AV: E=Sophos;i="4.90,888,1371038400"; d="scan'208";a="211759492" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Sep 2013 17:20:44 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.187]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 17:20:44 +1200 From: Peter Gutmann To: Eric Rescorla , Alfredo Pironti , "perpass@ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] Let's remove gmt_unix_time from TLS Thread-Index: Ac6vd9PFx71XQUH1RkGmUyB65MA//g== Date: Thu, 12 Sep 2013 05:20:42 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735566D793@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 05:21:01 -0000 Eric Rescorla writes:=0A= =0A= >Before we discuss mechanisms, it would be good to verify that in general = =0A= >clients and servers don't become unhappy if the timestamp is radically =0A= >wrong. Has someone done measurements to verify that this is in fact the = =0A= >case at a broad scale?=0A= =0A= Yes. I've been putting random noise in the timestamp field for about 15=0A= years (or more specifically I've never put a timestamp in the timestamp=0A= field), no user has ever reported problems with this.=0A= =0A= Peter.=0A= From maray@microsoft.com Thu Sep 12 01:26:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5D221E8160; Thu, 12 Sep 2013 01:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzMYVfRRUy63; Thu, 12 Sep 2013 01:25:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1121E8154; Thu, 12 Sep 2013 01:25:54 -0700 (PDT) Received: from BLUPR03MB166.namprd03.prod.outlook.com (10.255.212.142) by BLUPR03MB167.namprd03.prod.outlook.com (10.255.212.143) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 12 Sep 2013 08:25:49 +0000 Received: from BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) by BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) with mapi id 15.00.0775.005; Thu, 12 Sep 2013 08:25:49 +0000 From: Marsh Ray To: Peter Gutmann , Eric Rescorla , Alfredo Pironti , "perpass@ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] Let's remove gmt_unix_time from TLS Thread-Index: Ac6vd9PFx71XQUH1RkGmUyB65MA//gAGLggg Date: Thu, 12 Sep 2013 08:25:48 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C735566D793@uxcn10-tdc06.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735566D793@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(74316001)(74366001)(74876001)(19580405001)(19580395003)(83322001)(83072001)(81342001)(81542001)(80976001)(76482001)(81816001)(81686001)(65816001)(79102001)(54316002)(76576001)(76786001)(74502001)(56816003)(77096001)(56776001)(76796001)(31966008)(69226001)(74706001)(49866001)(4396001)(50986001)(47976001)(47736001)(53806001)(54356001)(63696002)(59766001)(77982001)(46102001)(80022001)(47446002)(33646001)(51856001)(74662001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB167; H:BLUPR03MB166.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-Mailman-Approved-At: Thu, 12 Sep 2013 01:33:33 -0700 Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 08:26:00 -0000 > Eric Rescorla writes: >Before we discuss mechanisms, it would be good to verify that in >general clients and servers don't become unhappy if the timestamp is >radically wrong. Has someone done measurements to verify that this is >in fact the case at a broad scale? I just checked and the current version doesn't do this, but ISTR older Inte= rnet Explorer would populate the "GMT" field with the local time. If my rec= ollection is true, this would probably represent "broad scale". This would reveal the client's time zone. So particularly for clients trave= rsing VPNs and proxies it would represent an info leak to a passive eavesdr= opper positioned near the server. - Marsh From stephen.farrell@cs.tcd.ie Thu Sep 12 01:57:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C54621E819C; Thu, 12 Sep 2013 01:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D78rxCz9yLOI; Thu, 12 Sep 2013 01:57:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6D21E8194; Thu, 12 Sep 2013 01:57:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 97CD9BE8F; Thu, 12 Sep 2013 09:57:39 +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 ik0FrTZwrhCl; Thu, 12 Sep 2013 09:57:39 +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 777FBBE8A; Thu, 12 Sep 2013 09:57:39 +0100 (IST) Message-ID: <52318203.4070109@cs.tcd.ie> Date: Thu, 12 Sep 2013 09:57:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nick Mathewson , mrex@sap.com References: <20130911174135.455A01A960@ld9781.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, "tls@ietf.org" Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 08:57:47 -0000 Hi Nick, Martin, On 09/12/2013 04:51 AM, Nick Mathewson wrote: > On Wed, Sep 11, 2013 at 1:41 PM, Martin Rex wrote: >> Nick Mathewson wrote: >>> ==== >>> SYNOPSIS: >>> >>> In TLS as currently specified, clients and servers each send their >>> current view of "the time" in the clear as part of their handshake. >>> This provides a fingerprint that can track users in spite of other >>> attempts to make them untrackable. I propose several ways to stop >>> doing sending this cleartext timestamp; some trivial and some more >>> complex. >> >> I would really appreciate a different approach to the underlying >> issue, and less throwing of smoke grenades here. > > I assume good faith on your part; please do the favor of assuming good > faith on mine. I think its fair to say that Martin is not renowned for taking a laid-back zen-like approach when making his almost-always-good technical contributions:-) But I didn't see him questioning good faith, I interpret him as asking (forcefully:-) why this change is worth doing. (And that's a common pattern actually: someone says "if we do X that'll make privacy a bit better" and someone else says "but there are so many other ways to leak private info, why bother just doing X?") >> If you're worried about being slightly "distinguishable" from some >> other clients, then there are a lot more reliable identifiers available >> in the average TLS handshake, so claiming that sending the actual local >> time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting >> issue and sending random will solve the fingerprinting issue, is >> bordering on lame for >99% of the clients. > > Indeed, I never said this was a "severe" issue, or that it was the > only issue you need to solve to solve fingerprinting. I said: "This > provides a fingerprint that can track users in spite of other attempts > to make them untrackable." > > I know that reading perpass, one expects proposals to fundamentally > transform the Internet to make it more secure. Well, boiling oceans is definitely not the intent of this list. My guess is that overbroad proposals will get the (lack of) attention they deserve and will wither on the vine. > This is not such a > fundamental transformation. This is a little simple change to fix a > little simple little problem. I agree. And seems like a worthwhile one too. BTW, since the TLS list discussion is up and running, I don't think there's a need to cc perpass more for this. It was a good idea to bring it here, but I suspect for this one, we can let the TLS wg fire ahead and get someone to write up an I-D if one is needed for this. (My guess is it'd be useful to have a nice short RFC that updates the relevant bit of 5246 and says why.) > Of such simple little problems, client linkability is made. > >> Most of the time, repeated requests of the same TLS client can be >> identified by the network connection having the same client IP address, >> the TLS session proposed for resumption in ClientHello.session_id >> or maybe someone still using TLS session tickets (rfc5077). > >> So rather than pointing to ClientHello.Random.gmt_unix_time as a >> and claiming there would be a simple fix, one will likely have to >> create and go through a long list of issues to determine which >> features facilitate fingerprinting and tracking (cipher suites >> and many TLS extensions (TLS caching extension, signature algorithms, >> Next protocol negotiation, supported elliptic curves, etc.) may >> all help in distinguishing clients, and would also have to be >> taken care of. > > That's all true; disabling gmt_unix_time is by no means sufficient to > make multiple TLS clients look the same on the wire, or to prevent an > observer distinguishing TLS instances. > > In Tor's case, we mitigate this by disabling some TLS features, > specifying required values for others, rotating some identifiers more > frequently than most implementations, and shipping all of our clients > with the same crypto libraries. Most of the fingerprinting issues in > TLS can be ameliorated, for a single application, by defining a > profile that all of that application's users should share. I think that'd be a fine thing to document (and worthy of a separate thread on the perpass list). Any chance we could get that done? (Where "that" == document the implementation steps to reduce fingerprinting opportunities as outlined above.) I think it'd be really useful for folks doing other protocol work to have an example of how its been done for Tor so they could copy some of the relevant techniques when developing other protocols. Ping me offlist if you'd like some help with writing it up as an I-D and I can try find someone to help, or if you've the energy just write it up and shoot it out and I can help figure out how best to get it turned into an RFC. If its already written up elsewhere then a pointer would be good regardless. Cheers, S. > > My issue here right now that, even *after* taking all these > precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC > doesn't make it optional. Come heck or high water, Tor is going to > stop sending gmt_unix_time unless we find a really excellent reason to > send it. We'd like to replace it with the best alternative we can. I > sent all the alternatives I could think of, because: > > 1) I would like future versions of the TLS RFC to not require gmt_unix_time. > 2) I would like to know whether there's a truly legit reason to send > gmt_unx_time. > 3) I would like to know the best thing to do instead of gmt_unix_time. > > (The IP address issue is important too, but not overriding here. The > issue here is that even after a client has changed its IP addresses > either through moving around the network or going behind a NAT or VPN > or by using an IP anonymization service, this fingerprint remains.) > From pgut001@cs.auckland.ac.nz Thu Sep 12 04:25:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377C211E8217; Thu, 12 Sep 2013 04:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vx8d5CK7Jxs; Thu, 12 Sep 2013 04:25:07 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 98B6121E81E1; Thu, 12 Sep 2013 04:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378985096; x=1410521096; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=MxTqlGTIFACzcPHvNyKAjNIxas0/xOu/uhqqMpS59gI=; b=Jr+xvggqAIqMiw6v9YIZUQ2r3NsiI8qqIB3z3EMx+kTBQaduzHyrd0FH OfJTVouYL1+91ZAuvB8DEOYLmOExmZB44EjbalKW3AACJn5t5QJKzn1ro Q+7PoMW93yVvWwdRtkhzXtGc3A3KVkn12fd+GYlHeXNeRb15TiWkihkxO Y=; X-IronPort-AV: E=Sophos;i="4.90,890,1371038400"; d="scan'208";a="211785655" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Sep 2013 23:24:49 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.187]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 23:24:49 +1200 From: Peter Gutmann To: Stephen Farrell , Nick Mathewson , "mrex@sap.com" , "perpass@ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] [perpass] Let's remove gmt_unix_time from TLS Thread-Index: Ac6vqrCvzBRaStaeT72/wQJTAi/Ewg== Date: Thu, 12 Sep 2013 11:24:48 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735566D9C3@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [perpass] [TLS] Let's remove gmt_unix_time from TLS X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 11:25:12 -0000 Stephen Farrell writes:=0A= =0A= >(And that's a common pattern actually: someone says "if we do X that'll ma= ke=0A= >privacy a bit better" and someone else says "but there are so many other w= ays=0A= >to leak private info, why bother just doing X?")=0A= =0A= I've only partially seen it as a privacy issue but more as a security issue= ,=0A= by telling an attacker that your clock is two weeks out you're letting them= =0A= know that they can reuse an expired cert or replay an old CRL. Even in ter= ms=0A= of privacy it wasn't a specific user-tracking thing but more a question of = why=0A= you needed to tell the world what your system clock was set to. So my code= =0A= has always populated the field with random noise, not an actual time.=0A= =0A= Peter.=0A= From hannes.tschofenig@gmx.net Thu Sep 12 04:27:38 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0416F21F8618 for ; Thu, 12 Sep 2013 04:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBbgvmDEpYwW for ; Thu, 12 Sep 2013 04:27:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3366421F9E63 for ; Thu, 12 Sep 2013 04:27:33 -0700 (PDT) Received: from [10.255.128.165] ([194.251.119.201]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LkBPy-1Vvtz40hac-00c6xK for ; Thu, 12 Sep 2013 13:27:32 +0200 Message-ID: <5231A515.7070007@gmx.net> Date: Thu, 12 Sep 2013 14:27:17 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dean Willis References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:MwWjBHS4RcLsc1nwJZYZONCrBuOK74UtzPPIZc5BSTaHwaExOUV Kxg0dr0R5MNYWtvLX03SIHvsl+Cez5/jxe3abYQDG/un++quG28qxyh8bNVz2d6nb8ji4+9 FT2iM4yYrlKbFA3VPS5RWoG35DSON2G+FfSVTkq7I3C9KKPv7u9QlaTzbKR6NcIgaY2a0JB 7AFrcHMO5a+1CVgDST/2w== Cc: Linus Nordberg , perpass@ietf.org, Hannes Tschofenig Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 11:27:38 -0000 Hi Dean, I may not be up to speed with RELOAD but I understood that all the energy has vanished from that work. There were also a number of technical problems. Maybe someone can give us a brief update on the status. Ciao Hannes On 09.09.2013 17:46, Dean Willis wrote: > I think we can mostly get there with RELOAD, but the implementations are > still pretty early. > > On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" > wrote: > > Hi Linus, > > thanks for the comments. > > I have indeed skipped that topic. I will have to read into the > Mumble project to see what security and privacy guarantees it provides. > > My current conclusion from using VoIP/IM systems without using Tor > is that you cannot really protect against collecting this > transaction data (i.e., you have to at least trust the two VSPs, our > own and then the VSP of your communication partner). While you can > influence routing of the data traffic to a certain extend it does > not work too well when your VSP is working against you. > > With IM you could at least set up your own server (e.g., by using an > XMPP server) but with VoIP that's more complicated because nobody > else will accepted your connection attempts (as explained in the > interconnection part of my write-up). > > I will come back to you on that issue. > > Ciao > Hannes > > > On 09.09.2013 14:31, Linus Nordberg wrote: > > Hannes Tschofenig > wrote > Mon, 09 Sep 2013 11:26:39 +0300: > > | http://www.tschofenig.priv.at/__wp/?p=997 > > | > | It contains a number of recommendations, which are addressed > to VoIP > | providers and vendors but have to be enforced by data protection > | authorities. > | > | The recommendations unfortunately highlight some challenges... > > Indeed. And still, I miss any mention on protection against > collecting > data about who's talking to who. > > Without claiming any expertise at all in this area, the closest > thing to > something implementing this that I've heard of is Mumble over > Tor. Mumble [0] is not standardised AFAICT. The Guardian Project > wrote > [1] about this earlier this year. Some people seem to use it [2]. > > [0] https://en.wikipedia.org/wiki/__Mumble_%28software%29 > > [1] > https://trac.torproject.org/__projects/tor/wiki/doc/__TorifyHOWTO/Mumble > > [2] > https://guardianproject.info/__2013/01/31/anonymous-cb-radio-__with-mumble-and-tor/ > > _________________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/__listinfo/perpass > > > > _________________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/__listinfo/perpass > > From br@brianrosen.net Thu Sep 12 05:21:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9B21E80DB for ; Thu, 12 Sep 2013 05:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.391 X-Spam-Level: X-Spam-Status: No, score=-103.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3pOsel6Hmyx for ; Thu, 12 Sep 2013 05:20:52 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id BCB6C21E80B7 for ; Thu, 12 Sep 2013 05:20:51 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 6so6522644qea.4 for ; Thu, 12 Sep 2013 05:20:47 -0700 (PDT) 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=0iddSn6kGEzJuJRqcl5jN14VXxc+Yu14WLuK02EQAaA=; b=kZgrDWXAMcJ0oIe1CnjJZ+mQ+Eci+QPtgHVmByI1L2pMnWXtoJWdf2MpuLcvYbTik5 KQcvXeROcovwNz6JtNOgSQ4LhlwZSQ7zukjWZDUtCoxkqXuI4mDAHS8swZPtWeZn9/hN 3qjWNd9MdJk0Dq5zZIlrGCtNWJfX3eeP5u4Jj0S4MPS7Abx4ctMctyJ7R+/NcE5kmz0a Pvv1RGsH2ItlgF7rMsjRUj4Pk7f9g04eRavuwJgq5hMbFiEijYLsxf67dme5IBMKq7wK uorCu2vWUYLT/4lFiASOLOsrI7toHNML0wKjukDRYCwkgp2P/23quZ4LUnZKYe6D/5hP ZEMg== X-Gm-Message-State: ALoCoQk8zEOvqye+aktNJrekw7YaXd16pZZ3roasHMgmdquE3saTmt23pn4wMdL+HjQyXn5L/mQZ X-Received: by 10.49.76.6 with SMTP id g6mr13088886qew.41.1378988447594; Thu, 12 Sep 2013 05:20:47 -0700 (PDT) Received: from [10.33.193.10] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id fy7sm7939863qeb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 05:20:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <5231A515.7070007@gmx.net> Date: Thu, 12 Sep 2013 08:20:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <24E607EB-E528-43DA-9F88-FB62D1D8D8A8@brianrosen.net> References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> <5231A515.7070007@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Cc: Linus Nordberg , perpass@ietf.org, Dean Willis Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 12:21:06 -0000 There is low energy in the work group at the moment, but the technical = problems have been addressed and there are a few implementations. The base spec should be published soon (it's in AUTH48). We need the = SIP spec to be finished. There are some subsidiary specs that are in = process which improve operation in certain circumstances, but base = RELOAD and the SIP application of RELOAD would provide a good basis for = VoIP which is substantially less susceptible to interception. As it is a true peer to peer solution, the opportunity to charge = customers lots of money to place calls is somewhat limited. There are = some opportunities in the enrollment server, but they are limited, and = as I had mentioned previously, if the enrollment server was compromised, = mischief could be inserted into the credentialing. I think if this seemed to be one of our responses to recent revelations, = work could be completed rather quickly. Brian On Sep 12, 2013, at 7:27 AM, Hannes Tschofenig = wrote: > Hi Dean, >=20 > I may not be up to speed with RELOAD but I understood that all the = energy has vanished from that work. There were also a number of = technical problems. >=20 > Maybe someone can give us a brief update on the status. >=20 > Ciao > Hannes >=20 > On 09.09.2013 17:46, Dean Willis wrote: >> I think we can mostly get there with RELOAD, but the implementations = are >> still pretty early. >>=20 >> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" = > > wrote: >>=20 >> Hi Linus, >>=20 >> thanks for the comments. >>=20 >> I have indeed skipped that topic. I will have to read into the >> Mumble project to see what security and privacy guarantees it = provides. >>=20 >> My current conclusion from using VoIP/IM systems without using Tor >> is that you cannot really protect against collecting this >> transaction data (i.e., you have to at least trust the two VSPs, = our >> own and then the VSP of your communication partner). While you can >> influence routing of the data traffic to a certain extend it does >> not work too well when your VSP is working against you. >>=20 >> With IM you could at least set up your own server (e.g., by using = an >> XMPP server) but with VoIP that's more complicated because nobody >> else will accepted your connection attempts (as explained in the >> interconnection part of my write-up). >>=20 >> I will come back to you on that issue. >>=20 >> Ciao >> Hannes >>=20 >>=20 >> On 09.09.2013 14:31, Linus Nordberg wrote: >>=20 >> Hannes Tschofenig> > wrote >> Mon, 09 Sep 2013 11:26:39 +0300: >>=20 >> | http://www.tschofenig.priv.at/__wp/?p=3D997 >> >> | >> | It contains a number of recommendations, which are addressed >> to VoIP >> | providers and vendors but have to be enforced by data = protection >> | authorities. >> | >> | The recommendations unfortunately highlight some = challenges... >>=20 >> Indeed. And still, I miss any mention on protection against >> collecting >> data about who's talking to who. >>=20 >> Without claiming any expertise at all in this area, the = closest >> thing to >> something implementing this that I've heard of is Mumble over >> Tor. Mumble [0] is not standardised AFAICT. The Guardian = Project >> wrote >> [1] about this earlier this year. Some people seem to use it = [2]. >>=20 >> [0] https://en.wikipedia.org/wiki/__Mumble_%28software%29 >> >> [1] >> = https://trac.torproject.org/__projects/tor/wiki/doc/__TorifyHOWTO/Mumble >> = >> [2] >> = https://guardianproject.info/__2013/01/31/anonymous-cb-radio-__with-mumble= -and-tor/ >> = >> _________________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/__listinfo/perpass >> >>=20 >>=20 >> _________________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/__listinfo/perpass >> >>=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From joncallas@icloud.com Thu Sep 12 06:21:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E79221E80B7 for ; Thu, 12 Sep 2013 06:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SBs3Le2OUIP for ; Thu, 12 Sep 2013 06:21:07 -0700 (PDT) Received: from st11p01mm-asmtp003.mac.com (st11p01mm-asmtp003.mac.com [17.172.204.238]) by ietfa.amsl.com (Postfix) with ESMTP id 1815421E80CC for ; Thu, 12 Sep 2013 06:21:03 -0700 (PDT) Received: from [192.168.137.8] (173-167-199-66-ip-static.hfc.comcastbusiness.net [173.167.199.66]) by st11p01mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-27.07(7.0.4.27.6) 64bit (built Jun 21 2013)) with ESMTPSA id <0MT0005ZYL2Z5Q20@st11p01mm-asmtp003.mac.com> for perpass@ietf.org; Thu, 12 Sep 2013 13:21:01 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-12_04:2013-09-12, 2013-09-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309120053 Content-type: multipart/alternative; boundary="Apple-Mail=_2DE981CD-BECE-4B6E-9361-94AF078F3D9E" MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jon Callas In-reply-to: <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> Date: Thu, 12 Sep 2013 06:20:59 -0700 Message-id: <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> To: Karl Malbrain X-Mailer: Apple Mail (2.1508) Cc: Theodore Ts'o , "perpass@ietf.org" , Phillip Hallam-Baker , Jon Callas Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 13:21:22 -0000 --Apple-Mail=_2DE981CD-BECE-4B6E-9361-94AF078F3D9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 11, 2013, at 11:56 AM, Karl Malbrain wrote: > The goal of the proposal is to enable the use of strong authentication = for all TLS connections over the internet. The certificates as = things-in-themselves don=92t really matter, they are actually just a = vehicle to post the public key of the user/server in a reliable public = place. The security occurs when the challenges to prove private key = ownership are cross-issued by each party. MITM would not have the = private keys to answer either challenge. > =20 > Note that this still doesn=92t solve the problem of MITM obtaining the = server=92s private key. I=92m still working on that one. I might be misunderstanding, but it seems to me that your global = directory would allow a passive listener to fingerprint the client by = sniffing in a variety of places -- near the client, near the server, or = near the directory. If you assume an attacker interested in collecting metadata about the = clients, this would be suboptimal. I may be missing something, but this sounds like it is just a global, = central certificate authority, albeit one that is not actually issuing = the certificates, but still assigning them GUIDs, which are by = definition globally unique. Am I indeed missing something? Jon --Apple-Mail=_2DE981CD-BECE-4B6E-9361-94AF078F3D9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 karl@petzent.com> = wrote:
The goal of the proposal = is to enable the use of strong authentication for all TLS connections = over the internet.  The certificates as things-in-themselves don=92t = really matter, they are actually just a vehicle to post the public key = of the user/server in a reliable public place.  The security occurs = when the challenges to prove private key ownership are cross-issued by = each party.  MITM would not have the private keys to answer either = challenge.
 
Note that this still doesn=92t solve the = problem of MITM obtaining the server=92s private key.  I=92m still = working on that = one.

I = might be misunderstanding, but it seems to me that your global directory = would allow a passive listener to fingerprint the client by sniffing in = a variety of places -- near the client, near the server, or near the = directory.

If you assume an attacker interested = in collecting metadata about the clients, this would be = suboptimal.

I may be missing something, but = this sounds like it is just a global, central certificate authority, = albeit one that is not actually issuing the certificates, but still = assigning them GUIDs, which are by definition globally = unique.

Am I indeed missing = something?

Jon

= --Apple-Mail=_2DE981CD-BECE-4B6E-9361-94AF078F3D9E-- From karl@petzent.com Thu Sep 12 09:01:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665F911E8253 for ; Thu, 12 Sep 2013 09:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.499 X-Spam-Level: * X-Spam-Status: No, score=1.499 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRfgTh3Tr0De for ; Thu, 12 Sep 2013 09:00:44 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id A282E11E821E for ; Thu, 12 Sep 2013 09:00:36 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Thu, 12 Sep 2013 09:00:41 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 09:00:33 -0700 From: Karl Malbrain To: Jon Callas Thread-Topic: [perpass] proposed enhancement to TLS strong authentication protocol Thread-Index: Ac6vFM0oAaChRWR6StGXJtPmuw8x5wARAsQAAABkuwAADqGlkAAYKYmAAAlqEgA= Date: Thu, 12 Sep 2013 16:00:33 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A690@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> In-Reply-To: <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E83742502A690mail2010_" MIME-Version: 1.0 Cc: Theodore Ts'o , "perpass@ietf.org" , Phillip Hallam-Baker Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:01:08 -0000 --_000_65EEC6E375AA474A847D510D5B7E83742502A690mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The global directory is queried once per TLS server and client pair. This = is done over a TLS strong authentication connection between the global dire= ctory server and the TLS server. The query by the TLS server and its respon= se is encrypted. After that, the server holds onto the user's public key fo= r future connections from the client. There is no new centralized traffic = point other than all the routers that make up the internet for passive list= eners to exploit. Under current TLS strong authentication negotiations, the server must have = the client's public key uploaded to it over a secondary channel before the = connection can be authenticated. This proposal eliminates this requirement= . In essence I'm proposing doing away with reliance on the Certificates entir= ely. Only public/private keys are required. Karl From: Jon Callas [mailto:joncallas@icloud.com] Sent: Thursday, September 12, 2013 06:21 To: Karl Malbrain Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; perpass@ietf.org Subject: Re: [perpass] proposed enhancement to TLS strong authentication pr= otocol On Sep 11, 2013, at 11:56 AM, Karl Malbrain > wrote: The goal of the proposal is to enable the use of strong authentication for = all TLS connections over the internet. The certificates as things-in-thems= elves don't really matter, they are actually just a vehicle to post the pub= lic key of the user/server in a reliable public place. The security occurs= when the challenges to prove private key ownership are cross-issued by eac= h party. MITM would not have the private keys to answer either challenge. Note that this still doesn't solve the problem of MITM obtaining the server= 's private key. I'm still working on that one. I might be misunderstanding, but it seems to me that your global directory = would allow a passive listener to fingerprint the client by sniffing in a v= ariety of places -- near the client, near the server, or near the directory= . If you assume an attacker interested in collecting metadata about the clien= ts, this would be suboptimal. I may be missing something, but this sounds like it is just a global, centr= al certificate authority, albeit one that is not actually issuing the certi= ficates, but still assigning them GUIDs, which are by definition globally u= nique. Am I indeed missing something? Jon --_000_65EEC6E375AA474A847D510D5B7E83742502A690mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The global directory is q= ueried once per TLS server and client pair.  This is done over a TLS s= trong authentication connection between the global directory server and the TLS server. The query by the TLS server and its response is= encrypted. After that, the server holds onto the user’s public key f= or future connections from the client.  There is no new centralized tr= affic point other than all the routers that make up the internet for passive listeners to exploit.

 <= /p>

Under current TLS strong = authentication negotiations, the server must have the client’s public= key uploaded to it over a secondary channel before the connection can be authenticated.  This proposal eliminates this requirement.

 <= /p>

In essence I’m prop= osing doing away with reliance on the Certificates entirely.  Only pub= lic/private keys are required.

 <= /p>

Karl

 <= /p>

From: Jon Call= as [mailto:joncallas@icloud.com]
Sent: Thursday, September 12, 2013 06:21
To: Karl Malbrain
Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; perpass@ietf.or= g
Subject: Re: [perpass] proposed enhancement to TLS strong authentica= tion protocol

 

 

On Sep 11, 2013, at 11:56 AM, Karl Malbrain <karl@petzent.com> wrote:<= /p>



The goal of the proposal = is to enable the use of strong authentication for all TLS connections over = the internet.  The certificates as things-in-themselves don’t really matter, they are actually just a vehicle to post the pu= blic key of the user/server in a reliable public place.  The security = occurs when the challenges to prove private key ownership are cross-issued = by each party.  MITM would not have the private keys to answer either challenge.

 <= /p>

Note that this still does= n’t solve the problem of MITM obtaining the server’s private ke= y.  I’m still working on that one.

 

I might be misunderstanding, but it seems to me that= your global directory would allow a passive listener to fingerprint the cl= ient by sniffing in a variety of places -- near the client, near the server= , or near the directory.

 

If you assume an attacker interested in collecting m= etadata about the clients, this would be suboptimal.

 

I may be missing something, but this sounds like it = is just a global, central certificate authority, albeit one that is not act= ually issuing the certificates, but still assigning them GUIDs, which are b= y definition globally unique.

 

Am I indeed missing something?

 

   &nb= sp;        Jon

 

--_000_65EEC6E375AA474A847D510D5B7E83742502A690mail2010_-- From karl@petzent.com Thu Sep 12 09:09:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63C411E826E for ; Thu, 12 Sep 2013 09:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.955 X-Spam-Level: ** X-Spam-Status: No, score=2.955 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir2oOGN+YMOk for ; Thu, 12 Sep 2013 09:08:57 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id 916EB11E821E for ; Thu, 12 Sep 2013 09:07:50 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Thu, 12 Sep 2013 09:07:54 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 09:05:47 -0700 From: Karl Malbrain To: George Michaelson Thread-Topic: [perpass] FW: proposed enhancement to TLS strong authentication protocol Thread-Index: AQHOrx/lV3ta+zfkaE6b6qzUt7miPpnBXcQA//+LUFCAALVzgP//i0pwgAB4goD//4smEAARXt6AABF+xiA= Date: Thu, 12 Sep 2013 16:05:47 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A6A2@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5AA@mail2010> <65EEC6E375AA474A847D510D5B7E83742502A5F7@mail2010> <65EEC6E375AA474A847D510D5B7E83742502A638@mail2010> <65EEC6E375AA474A847D510D5B7E83742502A654@mail2010> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E83742502A6A2mail2010_" MIME-Version: 1.0 Cc: "perpass@ietf.org" Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:09:12 -0000 --_000_65EEC6E375AA474A847D510D5B7E83742502A6A2mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for your assistance! I had just ignored the "unscaleable" attrib= ute in favor of additional explanation. I would think that the introduction of a captcha in the registration proce= ss should handle your concern about flooding the registration engines. The= registration is normally done once per creation of a user private/public k= ey combination. From: George Michaelson [mailto:ggm@algebras.org] Sent: Wednesday, September 11, 2013 17:40 To: Karl Malbrain Subject: Re: [perpass] FW: proposed enhancement to TLS strong authenticatio= n protocol no no, I don't think this. sorry its my english. if somebody else from soun= d groundings had said 'palpably wrong' I'd have expected just what you did:= ask why. the 'unscaleable' hit my funny bone and got a 'this is bullshit, = its the I dont want it so I'll say something to fudge it response. I just m= eant that HAD somebody said wrong because... or broken because.. I'd not ha= ve leapt. But they didn't, they just intruded the 'unscaleable' which frank= ly counts as much as 'unfashionable' with mechanisms like UUID registration, (which has come up in APNIC) there = is an attack model where you flood the registration engine with huge number= s of and make it die in a ditch. we have discussed how you make the T= CP lifetime exponential increase to get to the submit button, or use TLS to= bind to it, so the cost on the client side is non-trivial, or do captcha o= r the like. none of them are very good. we've been running registry/whois f= or years, and periodically somebody designs a new method of business which = demands we handle eg 60,000 emails for whois update of their customer more = specific, every month. we survive fine, but its a challenge. you need to be= mindful of this kind of non-cost On Thu, Sep 12, 2013 at 9:30 AM, Karl Malbrain > wrote: Of course you've piqued my interest. In what sense is this palpably broken= and wrong? slow: No, The user's UUID for his public key is only obtained once per TL= S server on first login. After that it is stored along with the UUID on th= e server for use in the TLS challenge. Subvertable: No, Since the list is read-only, MITM attackers cannot change= the user's public key to one of their own choosing. Without the user's pr= ivate key the MITM attacker cannot answer the TLS challenge from the server= . If the MITM attacker tries to change the UUID, the server will have no k= nowledge of the bogus client. From: George Michaelson [mailto:ggm@algebras.org] Sent: Wednesday, September 11, 2013 16:21 To: Karl Malbrain Subject: Re: [perpass] FW: proposed enhancement to TLS strong authenticatio= n protocol right. none of this seems to warrant use of the 'unscaleable' word. slow, o= r subvertable, or palpably broken and wrong I can go with, but unscaleable = just doesn't seem to me to be applicable. On Thu, Sep 12, 2013 at 9:14 AM, Karl Malbrain > wrote: UUID collisions would be handled by the list servers which would silently r= eject posts of user public keys to occupied UUID slots. User's would deter= mine this by noting that a UUID query doesn't produce their public key, an= d then retry the post with a different UUID. List servers would communicate among themselves to replicate the list globa= lly. Karl From: George Michaelson [mailto:ggm@algebras.org] Sent: Wednesday, September 11, 2013 16:08 To: Karl Malbrain Cc: Phillip Hallam-Baker; Paul Wouters; perpass@ietf.org Subject: Re: [perpass] FW: proposed enhancement to TLS strong authenticatio= n protocol unscaleable is a word which had currency in 16 bit computer days, and possi= bly in 32 bit computers when disks and bandwidth were untenably expensive. = I am less sure that any enterprise which only has to scale to addressing 2 = billion people in the next 5-10 years is 'unscaleable' in the real sense of= the world. 'seems very inefficient' or 'seems like a problem which will carry its own = sub-problems' or 'scaling this is a challenge which demands funding and eye= balls' are all less direct statements going to the same place. or do you believe UUID collide, and in fact cannot uniquely identify end en= tities casting the runes to make randoms? On Thu, Sep 12, 2013 at 5:23 AM, Karl Malbrain > wrote: The list is replicated but not centralized per-se. There is only one conten= t. Larger servers could maintain their own copy of the replicated list for = their own usage. As to the utility of the enhancement, MITM attachments/attacks are preclude= d by strong authentication of both the server and the client. The specific= technical problem addressed is the ability of both parties to reliably obt= ain client public keys during TLS negotiation. From: Phillip Hallam-Baker [mailto:hallam@gmail.com] Sent: Wednesday, September 11, 2013 12:16 To: Paul Wouters Cc: Karl Malbrain; perpass@ietf.org Subject: Re: [perpass] FW: proposed enhancement to TLS strong authenticatio= n protocol On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters > wrote: On Wed, 11 Sep 2013, Karl Malbrain wrote: From: Karl Malbrain Sent: Wednesday, September 11, 2013 11:43 To: 'Theodore Ts'o' Subject: RE: [perpass] proposed enhancement to TLS strong authentication pr= otocol It's a WORM list. Users post requests to the list maintainers they trust w= ith a GUID to register their public key, and then send this GUID as part of= the TLS negotiation process. Seems to me to be basically like an unscalable central version of the TLSA = record? https://tools.ietf.org/html/rfc6698 I think it can be decentralized and have been working on an architecture to= do that for email security. But it does not really help much for authentication to random Web sites or = for enterprise use either. -- Website: http://hallambaker.com/ _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass --_000_65EEC6E375AA474A847D510D5B7E83742502A6A2mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for your assist= ance!  I had just ignored the “unscaleable” attribute in f= avor of additional explanation.

 <= /p>

I would think that  = the introduction of a captcha in the registration process should handle you= r concern about flooding the registration engines.  The registration is normally done once per creation of a user private/public key combinatio= n.

 <= /p>

From: George M= ichaelson [mailto:ggm@algebras.org]
Sent: Wednesday, September 11, 2013 17:40
To: Karl Malbrain
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authen= tication protocol

 

no no, I don't think this. sorry its my english. if = somebody else from sound groundings had said 'palpably wrong' I'd have expe= cted just what you did: ask why. the 'unscaleable' hit my funny bone and go= t a 'this is bullshit, its the I dont want it so I'll say something to fudge it response. I just meant that HAD = somebody said wrong because... or broken because.. I'd not have leapt. But = they didn't, they just intruded the 'unscaleable' which frankly counts as m= uch as 'unfashionable'

 

with mechanisms like UUID registration, (which has c= ome up in APNIC) there is an attack model where you flood the registration = engine with huge numbers of <new> and make it die in a ditch. we have= discussed how you make the TCP lifetime exponential increase to get to the submit button, or use TLS to bind to it= , so the cost on the client side is non-trivial, or do captcha or the like.= none of them are very good. we've been running registry/whois for years, a= nd periodically somebody designs a new method of business which demands we handle eg 60,000 emails for whoi= s update of their customer more specific, every month. we survive fine, but= its a challenge. you need to be mindful of this kind of non-cost

 

On Thu, Sep 12, 2013 at 9:30 AM, Karl Malbrain <<= a href=3D"mailto:karl@petzent.com" target=3D"_blank">karl@petzent.com&g= t; wrote:

Of course you’ve piqued my intere= st.  In what sense is this palpably broken and wrong?

 

slow:   No, The user’s = UUID for his public key is only obtained once per TLS server on first login= .  After that it is stored along with the UUID on the server for use in the T= LS challenge.

 

Subvertable:  No, Since the list i= s read-only, MITM attackers cannot change the user’s public key to one of their own choosing.  Without the user’s private key t= he MITM attacker cannot answer the TLS challenge from the server.  If = the MITM attacker tries to change the UUID, the server will have no knowled= ge of the bogus client.

 

From: George Michaelson [mai= lto:ggm@algebras.org<= /a>]
Sent: Wednesday, September 11, 2013 16:21
To: Karl Malbrain


Subject: Re: [perpass] FW: proposed enhancement to TLS strong authen= tication protocol

 

right. none of this seems to warrant use of the 'unscaleable' word= . slow, or subvertable, or palpably broken and wrong I can go with, but uns= caleable just doesn't seem to me to be applicable.

 

On Thu, Sep 12, 2013 at 9:14 AM, Karl Malbrain <karl@petzent.com> wrote:=

UUID collisions would be handled by the= list servers which would silently reject posts of user public keys to occupied UUID slots.  User’s would determine this by no= ting that a  UUID query doesn’t produce their public key, and th= en retry the post with a different UUID.

 

List servers would communicate among th= emselves to replicate the list globally.

 

Karl

 

From: George Michaelson [mai= lto:ggm@algebras.org<= /a>]
Sent: Wednesday, September 11, 2013 16:08
To: Karl Malbrain
Cc: Phillip Hallam-Baker; Paul Wouters; perpass@ietf.org


Subject: Re: [perpass] FW: proposed enhancement to TLS strong authen= tication protocol

 

unscaleable is a word which had currency in 16 bit computer days, = and possibly in 32 bit computers when disks and bandwidth were untenably ex= pensive. I am less sure that any enterprise which only has to scale to addressing 2 billion people in the next 5-10 ye= ars is 'unscaleable' in the real sense of the world.

 

'seems very inefficient' or 'seems like a problem which will carry= its own sub-problems' or 'scaling this is a challenge which demands fundin= g and eyeballs' are all less direct statements going to the same place.

 

or do you believe UUID collide, and in fact cannot uniquely identi= fy end entities casting the runes to make randoms?

 

On Thu, Sep 12, 2013 at 5:23 AM, Karl Malbrain <karl@petzent.com> wrote:=

The list is replicated but not centrali= zed per-se. There is only one content. Larger servers could maintain their own copy of the replicated list for their own usage.=

 

As to the utility of the enhancement, M= ITM attachments/attacks are precluded by strong authentication of both the server and the client.  The specific technical problem ad= dressed is the ability of both parties to reliably obtain client public key= s during TLS negotiation.

 

From: Phillip Hallam-Baker [= mailto:hallam@gmail.c= om]
Sent: Wednesday, September 11, 2013 12:16
To: Paul Wouters
Cc: Karl Malbrain; perpass@ietf.org
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authen= tication protocol

 

 

 

On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <paul@nohats.ca> wrote:

On Wed, 11 Sep 2013, Karl Malbrain wrote:

From: Karl Malbrain
Sent: Wednesday, September 11, 2013 11:43
To: 'Theodore Ts'o'
Subject: RE: [perpass] proposed enhancement to TLS strong authentication pr= otocol

It's a WORM list.  Users post requests to the list maintainers they tr= ust with a GUID to register their public key, and then send this GUID as pa= rt of the TLS negotiation process.

 

Seems to me to be basically like an unscalable central version of = the TLSA record?

https://t= ools.ietf.org/html/rfc6698

 

I think it can be decentralized and have been working on an archit= ecture to do that for email security.

 

But it does not really help much for authentication to random Web = sites or for enterprise use either.

 

 

 

--
Website: http://halla= mbaker.com/


_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass

 

 

 

--_000_65EEC6E375AA474A847D510D5B7E83742502A6A2mail2010_-- From karl@petzent.com Thu Sep 12 09:12:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0034611E8274 for ; Thu, 12 Sep 2013 09:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.576 X-Spam-Level: * X-Spam-Status: No, score=1.576 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP43CN9YBjxH for ; Thu, 12 Sep 2013 09:11:59 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2326911E8282 for ; Thu, 12 Sep 2013 09:10:41 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Thu, 12 Sep 2013 09:10:52 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 09:08:45 -0700 From: Karl Malbrain To: Jon Callas Thread-Topic: [perpass] proposed enhancement to TLS strong authentication protocol Thread-Index: Ac6vFM0oAaChRWR6StGXJtPmuw8x5wARAsQAAABkuwAADqGlkAAYKYmAAAjVeWA= Date: Thu, 12 Sep 2013 16:08:44 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A6B1@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> In-Reply-To: <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E83742502A6B1mail2010_" MIME-Version: 1.0 Cc: Theodore Ts'o , "perpass@ietf.org" , Phillip Hallam-Baker Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:12:07 -0000 --_000_65EEC6E375AA474A847D510D5B7E83742502A6B1mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another minor point: The GUIDs are submitted with the public keys by the u= ser to any of the registration authorities which then replicates the pairs = to all the other participating co-authorities. From: Jon Callas [mailto:joncallas@icloud.com] Sent: Thursday, September 12, 2013 06:21 To: Karl Malbrain Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; perpass@ietf.org Subject: Re: [perpass] proposed enhancement to TLS strong authentication pr= otocol On Sep 11, 2013, at 11:56 AM, Karl Malbrain > wrote: The goal of the proposal is to enable the use of strong authentication for = all TLS connections over the internet. The certificates as things-in-thems= elves don't really matter, they are actually just a vehicle to post the pub= lic key of the user/server in a reliable public place. The security occurs= when the challenges to prove private key ownership are cross-issued by eac= h party. MITM would not have the private keys to answer either challenge. Note that this still doesn't solve the problem of MITM obtaining the server= 's private key. I'm still working on that one. I might be misunderstanding, but it seems to me that your global directory = would allow a passive listener to fingerprint the client by sniffing in a v= ariety of places -- near the client, near the server, or near the directory= . If you assume an attacker interested in collecting metadata about the clien= ts, this would be suboptimal. I may be missing something, but this sounds like it is just a global, centr= al certificate authority, albeit one that is not actually issuing the certi= ficates, but still assigning them GUIDs, which are by definition globally u= nique. Am I indeed missing something? Jon --_000_65EEC6E375AA474A847D510D5B7E83742502A6B1mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another minor point: = ; The GUIDs are submitted with the public keys by the user to any of the re= gistration authorities which then replicates the pairs to all the other participating co-authorities.

 <= /p>

From: Jon Call= as [mailto:joncallas@icloud.com]
Sent: Thursday, September 12, 2013 06:21
To: Karl Malbrain
Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; perpass@ietf.or= g
Subject: Re: [perpass] proposed enhancement to TLS strong authentica= tion protocol

 

 

On Sep 11, 2013, at 11:56 AM, Karl Malbrain <karl@petzent.com> wrote:<= /p>



The goal of the proposal = is to enable the use of strong authentication for all TLS connections over = the internet.  The certificates as things-in-themselves don’t really matter, they are actually just a vehicle to post the pu= blic key of the user/server in a reliable public place.  The security = occurs when the challenges to prove private key ownership are cross-issued = by each party.  MITM would not have the private keys to answer either challenge.

 <= /p>

Note that this still does= n’t solve the problem of MITM obtaining the server’s private ke= y.  I’m still working on that one.

 

I might be misunderstanding, but it seems to me that= your global directory would allow a passive listener to fingerprint the cl= ient by sniffing in a variety of places -- near the client, near the server= , or near the directory.

 

If you assume an attacker interested in collecting m= etadata about the clients, this would be suboptimal.

 

I may be missing something, but this sounds like it = is just a global, central certificate authority, albeit one that is not act= ually issuing the certificates, but still assigning them GUIDs, which are b= y definition globally unique.

 

Am I indeed missing something?

 

   &nb= sp;        Jon

 

--_000_65EEC6E375AA474A847D510D5B7E83742502A6B1mail2010_-- From karl@petzent.com Thu Sep 12 09:26:43 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F7211E8181 for ; Thu, 12 Sep 2013 09:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.527 X-Spam-Level: * X-Spam-Status: No, score=1.527 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4rkZe5U32Ab for ; Thu, 12 Sep 2013 09:26:15 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA6F21E8056 for ; Thu, 12 Sep 2013 09:26:01 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Thu, 12 Sep 2013 09:26:13 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 09:24:07 -0700 From: Karl Malbrain To: Jon Callas Thread-Topic: [perpass] proposed enhancement to TLS strong authentication protocol Thread-Index: Ac6vFM0oAaChRWR6StGXJtPmuw8x5wARAsQAAABkuwAADqGlkAAYKYmAAAiDDnA= Date: Thu, 12 Sep 2013 16:24:06 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> In-Reply-To: <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E83742502A6C0mail2010_" MIME-Version: 1.0 Cc: Theodore Ts'o , "perpass@ietf.org" , Phillip Hallam-Baker Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:26:44 -0000 --_000_65EEC6E375AA474A847D510D5B7E83742502A6C0mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The assumed attack profile is a MITM insertion into a connection stream bet= ween server and client whereby the attacker gains complete unencrypted acce= ss to all traffic over the connection, not just meta data. TLS already has a built-in concept of "strong authentication" between serve= r and client to defeat this attack. It requires that the TLS server pre-ob= tain by some secondary channel the public key of the user. This proposal e= liminates that requirement by making the user's public keys public knowledg= e. Karl From: Jon Callas [mailto:joncallas@icloud.com] Sent: Thursday, September 12, 2013 06:21 To: Karl Malbrain Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; perpass@ietf.org Subject: Re: [perpass] proposed enhancement to TLS strong authentication pr= otocol On Sep 11, 2013, at 11:56 AM, Karl Malbrain > wrote: The goal of the proposal is to enable the use of strong authentication for = all TLS connections over the internet. The certificates as things-in-thems= elves don't really matter, they are actually just a vehicle to post the pub= lic key of the user/server in a reliable public place. The security occurs= when the challenges to prove private key ownership are cross-issued by eac= h party. MITM would not have the private keys to answer either challenge. Note that this still doesn't solve the problem of MITM obtaining the server= 's private key. I'm still working on that one. I might be misunderstanding, but it seems to me that your global directory = would allow a passive listener to fingerprint the client by sniffing in a v= ariety of places -- near the client, near the server, or near the directory= . If you assume an attacker interested in collecting metadata about the clien= ts, this would be suboptimal. I may be missing something, but this sounds like it is just a global, centr= al certificate authority, albeit one that is not actually issuing the certi= ficates, but still assigning them GUIDs, which are by definition globally u= nique. Am I indeed missing something? Jon --_000_65EEC6E375AA474A847D510D5B7E83742502A6C0mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The assumed attack profil= e is a MITM insertion into a connection stream between server and client wh= ereby the attacker gains complete unencrypted access to all traffic over the connection, not just meta data.

 <= /p>

TLS already has a built-i= n concept of “strong authentication” between server and client = to defeat this attack.  It requires that the TLS server pre-obtain by some secondary channel the public key of the user.  This proposal eli= minates that requirement by making the user’s public keys public know= ledge.

 <= /p>

Karl

 <= /p>

From: Jon Call= as [mailto:joncallas@icloud.com]
Sent: Thursday, September 12, 2013 06:21
To: Karl Malbrain
Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; perpass@ietf.or= g
Subject: Re: [perpass] proposed enhancement to TLS strong authentica= tion protocol

 

 

On Sep 11, 2013, at 11:56 AM, Karl Malbrain <karl@petzent.com> wrote:<= /p>



The goal of the proposal = is to enable the use of strong authentication for all TLS connections over = the internet.  The certificates as things-in-themselves don’t really matter, they are actually just a vehicle to post the pu= blic key of the user/server in a reliable public place.  The security = occurs when the challenges to prove private key ownership are cross-issued = by each party.  MITM would not have the private keys to answer either challenge.

 <= /p>

Note that this still does= n’t solve the problem of MITM obtaining the server’s private ke= y.  I’m still working on that one.

 

I might be misunderstanding, but it seems to me that= your global directory would allow a passive listener to fingerprint the cl= ient by sniffing in a variety of places -- near the client, near the server= , or near the directory.

 

If you assume an attacker interested in collecting m= etadata about the clients, this would be suboptimal.

 

I may be missing something, but this sounds like it = is just a global, central certificate authority, albeit one that is not act= ually issuing the certificates, but still assigning them GUIDs, which are b= y definition globally unique.

 

Am I indeed missing something?

 

   &nb= sp;        Jon

 

--_000_65EEC6E375AA474A847D510D5B7E83742502A6C0mail2010_-- From stephen.farrell@cs.tcd.ie Thu Sep 12 09:47:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7D511E81C3 for ; Thu, 12 Sep 2013 09:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWk-hhMswAjU for ; Thu, 12 Sep 2013 09:47:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9ED11E8258 for ; Thu, 12 Sep 2013 09:47:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E8A90BE97; Thu, 12 Sep 2013 17:47:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrKtbhHd9KjA; Thu, 12 Sep 2013 17:47:06 +0100 (IST) Received: from [10.87.48.10] (unknown [86.41.58.167]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D3ACBE6F; Thu, 12 Sep 2013 17:47:06 +0100 (IST) Message-ID: <5231EFFF.2020606@cs.tcd.ie> Date: Thu, 12 Sep 2013 17:46:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Karl Malbrain References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> In-Reply-To: <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , "perpass@ietf.org" , Theodore Ts'o , Jon Callas Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 16:48:02 -0000 Hi, We seem to be designing this protocol one mail at a time. Could I ask that we stop doing that and that Karl and whoever else is minded submit an internet-draft specifying the protocol so that it can be more easily reviewed. Thanks, Stephen. PS: Karl, if you need help with the mechanics just ask me offlist. On 09/12/2013 05:24 PM, Karl Malbrain wrote: > The assumed attack profile is a MITM insertion into a connection stream between server and client whereby the attacker gains complete unencrypted access to all traffic over the connection, not just meta data. > > TLS already has a built-in concept of "strong authentication" between server and client to defeat this attack. It requires that the TLS server pre-obtain by some secondary channel the public key of the user. This proposal eliminates that requirement by making the user's public keys public knowledge. > > Karl > > From: Jon Callas [mailto:joncallas@icloud.com] > Sent: Thursday, September 12, 2013 06:21 > To: Karl Malbrain > Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; perpass@ietf.org > Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol > > > On Sep 11, 2013, at 11:56 AM, Karl Malbrain > wrote: > > > The goal of the proposal is to enable the use of strong authentication for all TLS connections over the internet. The certificates as things-in-themselves don't really matter, they are actually just a vehicle to post the public key of the user/server in a reliable public place. The security occurs when the challenges to prove private key ownership are cross-issued by each party. MITM would not have the private keys to answer either challenge. > > Note that this still doesn't solve the problem of MITM obtaining the server's private key. I'm still working on that one. > > I might be misunderstanding, but it seems to me that your global directory would allow a passive listener to fingerprint the client by sniffing in a variety of places -- near the client, near the server, or near the directory. > > If you assume an attacker interested in collecting metadata about the clients, this would be suboptimal. > > I may be missing something, but this sounds like it is just a global, central certificate authority, albeit one that is not actually issuing the certificates, but still assigning them GUIDs, which are by definition globally unique. > > Am I indeed missing something? > > Jon > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From karl@petzent.com Thu Sep 12 10:13:57 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797621E8157 for ; Thu, 12 Sep 2013 10:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.487 X-Spam-Level: * X-Spam-Status: No, score=1.487 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx-Ar6tQonen for ; Thu, 12 Sep 2013 10:13:52 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id DA14021E80CC for ; Thu, 12 Sep 2013 10:13:52 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Thu, 12 Sep 2013 10:14:00 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 10:13:50 -0700 From: Karl Malbrain To: Stephen Farrell Thread-Topic: [perpass] proposed enhancement to TLS strong authentication protocol Thread-Index: Ac6vFM0oAaChRWR6StGXJtPmuw8x5wARAsQAAABkuwAADqGlkAAYKYmAAAiDDnD///VxgIAAcEXA Date: Thu, 12 Sep 2013 17:13:50 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> In-Reply-To: <5231EFFF.2020606@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Phillip Hallam-Baker , "perpass@ietf.org" , Theodore Ts'o , Jon Callas Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 17:13:58 -0000 I was under the impression that this list was to discuss things pre-draft -= - e.g. general concepts first, details later in a specific work-group. I'm= sorry if you find the piece meal approach difficult. My proposal in a nutshell: 1. Use TLS strong authentication between client and server on all connectio= ns over the internet to obviate MITM attacks. 2. Make users' public keys public information to obviate current TLS limita= tions on obtaining them. If everyone agrees with this, we can certainly move onto a draft to work ou= t details, and yes, I'd need assistance from that point onward. Karl -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Thursday, September 12, 2013 09:47 To: Karl Malbrain Cc: Jon Callas; Theodore Ts'o; perpass@ietf.org; Phillip Hallam-Baker Subject: Re: [perpass] proposed enhancement to TLS strong authentication pr= otocol Hi, We seem to be designing this protocol one mail at a time. Could I ask that = we stop doing that and that Karl and whoever else is minded submit an inter= net-draft specifying the protocol so that it can be more easily reviewed. Thanks, Stephen. PS: Karl, if you need help with the mechanics just ask me offlist. On 09/12/2013 05:24 PM, Karl Malbrain wrote: > The assumed attack profile is a MITM insertion into a connection stream b= etween server and client whereby the attacker gains complete unencrypted ac= cess to all traffic over the connection, not just meta data. >=20 > TLS already has a built-in concept of "strong authentication" between ser= ver and client to defeat this attack. It requires that the TLS server pre-= obtain by some secondary channel the public key of the user. This proposal= eliminates that requirement by making the user's public keys public knowle= dge. >=20 > Karl >=20 > From: Jon Callas [mailto:joncallas@icloud.com] > Sent: Thursday, September 12, 2013 06:21 > To: Karl Malbrain > Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; perpass@ietf.org > Subject: Re: [perpass] proposed enhancement to TLS strong=20 > authentication protocol >=20 >=20 > On Sep 11, 2013, at 11:56 AM, Karl Malbrain > wrote: >=20 >=20 > The goal of the proposal is to enable the use of strong authentication fo= r all TLS connections over the internet. The certificates as things-in-the= mselves don't really matter, they are actually just a vehicle to post the p= ublic key of the user/server in a reliable public place. The security occu= rs when the challenges to prove private key ownership are cross-issued by e= ach party. MITM would not have the private keys to answer either challenge= . >=20 > Note that this still doesn't solve the problem of MITM obtaining the serv= er's private key. I'm still working on that one. >=20 > I might be misunderstanding, but it seems to me that your global director= y would allow a passive listener to fingerprint the client by sniffing in a= variety of places -- near the client, near the server, or near the directo= ry. >=20 > If you assume an attacker interested in collecting metadata about the cli= ents, this would be suboptimal. >=20 > I may be missing something, but this sounds like it is just a global, cen= tral certificate authority, albeit one that is not actually issuing the cer= tificates, but still assigning them GUIDs, which are by definition globally= unique. >=20 > Am I indeed missing something? >=20 > Jon >=20 >=20 >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 From stephen.farrell@cs.tcd.ie Thu Sep 12 10:23:09 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A385E21F9D34 for ; Thu, 12 Sep 2013 10:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m16bTllTjM6g for ; Thu, 12 Sep 2013 10:23:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8323C21E81ED for ; Thu, 12 Sep 2013 10:22:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 97868BE8E; Thu, 12 Sep 2013 18:22:38 +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 7to7G5QkEMrs; Thu, 12 Sep 2013 18:22:35 +0100 (IST) Received: from [10.87.48.10] (unknown [86.41.58.167]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07A2FBDDC; Thu, 12 Sep 2013 18:22:35 +0100 (IST) Message-ID: <5231F859.2040002@cs.tcd.ie> Date: Thu, 12 Sep 2013 18:22:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Karl Malbrain References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> In-Reply-To: <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 17:23:09 -0000 Hi Karl, On 09/12/2013 06:13 PM, Karl Malbrain wrote: > I was under the impression that this list was to discuss things > pre-draft -- e.g. general concepts first, details later in a specific > work-group. I'm sorry if you find the piece meal approach > difficult. Its not that its difficult but rather that another level of detail might be needed before its clear if the approach could work. (Being honest, I'm skeptical of anything that needs every client who uses TLS have a private key, if that is what's proposed.) > > My proposal in a nutshell: > > 1. Use TLS strong authentication between client and server on all > connections over the internet to obviate MITM attacks. 2. Make users' > public keys public information to obviate current TLS limitations on > obtaining them. > > If everyone agrees with this, we can certainly move onto a draft to > work out details, and yes, I'd need assistance from that point > onward. I'd say the overall thrust of the idea is clear(ish), but you won't get rough consensus on something like that until after its written down (ideally with running code), so I reckon this is at the point where an I-D is the next step. So if you get others who're interested and who know how to do it, write up that I-D. (And again, if you're not sure how to do it yourself, just ping me.) S. > > Karl > > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, September 12, 2013 > 09:47 To: Karl Malbrain Cc: Jon Callas; Theodore Ts'o; > perpass@ietf.org; Phillip Hallam-Baker Subject: Re: [perpass] > proposed enhancement to TLS strong authentication protocol > > > Hi, > > We seem to be designing this protocol one mail at a time. Could I ask > that we stop doing that and that Karl and whoever else is minded > submit an internet-draft specifying the protocol so that it can be > more easily reviewed. > > Thanks, Stephen. > > PS: Karl, if you need help with the mechanics just ask me offlist. > > On 09/12/2013 05:24 PM, Karl Malbrain wrote: >> The assumed attack profile is a MITM insertion into a connection >> stream between server and client whereby the attacker gains >> complete unencrypted access to all traffic over the connection, not >> just meta data. >> >> TLS already has a built-in concept of "strong authentication" >> between server and client to defeat this attack. It requires that >> the TLS server pre-obtain by some secondary channel the public key >> of the user. This proposal eliminates that requirement by making >> the user's public keys public knowledge. >> >> Karl >> >> From: Jon Callas [mailto:joncallas@icloud.com] Sent: Thursday, >> September 12, 2013 06:21 To: Karl Malbrain Cc: Jon Callas; Phillip >> Hallam-Baker; Theodore Ts'o; perpass@ietf.org Subject: Re: >> [perpass] proposed enhancement to TLS strong authentication >> protocol >> >> >> On Sep 11, 2013, at 11:56 AM, Karl Malbrain >> > wrote: >> >> >> The goal of the proposal is to enable the use of strong >> authentication for all TLS connections over the internet. The >> certificates as things-in-themselves don't really matter, they are >> actually just a vehicle to post the public key of the user/server >> in a reliable public place. The security occurs when the >> challenges to prove private key ownership are cross-issued by each >> party. MITM would not have the private keys to answer either >> challenge. >> >> Note that this still doesn't solve the problem of MITM obtaining >> the server's private key. I'm still working on that one. >> >> I might be misunderstanding, but it seems to me that your global >> directory would allow a passive listener to fingerprint the client >> by sniffing in a variety of places -- near the client, near the >> server, or near the directory. >> >> If you assume an attacker interested in collecting metadata about >> the clients, this would be suboptimal. >> >> I may be missing something, but this sounds like it is just a >> global, central certificate authority, albeit one that is not >> actually issuing the certificates, but still assigning them GUIDs, >> which are by definition globally unique. >> >> Am I indeed missing something? >> >> Jon >> >> >> >> >> _______________________________________________ perpass mailing >> list perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> > _______________________________________________ perpass mailing list > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > > From karl@petzent.com Thu Sep 12 10:38:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DFD21F9EA8 for ; Thu, 12 Sep 2013 10:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.454 X-Spam-Level: * X-Spam-Status: No, score=1.454 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_EQ_STATIC=1.172, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1bWkLZI-ccO for ; Thu, 12 Sep 2013 10:38:13 -0700 (PDT) Received: from mail.petzent.com (206-169-92-130.static.twtelecom.net [206.169.92.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0DF11E81D4 for ; Thu, 12 Sep 2013 10:37:58 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Thu, 12 Sep 2013 10:37:58 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 10:37:50 -0700 From: Karl Malbrain To: Stephen Farrell Thread-Topic: [perpass] proposed enhancement to TLS strong authentication protocol Thread-Index: Ac6vFM0oAaChRWR6StGXJtPmuw8x5wARAsQAAABkuwAADqGlkAAYKYmAAAiDDnD///VxgIAAcEXA//+Zr4CAAHLroA== Date: Thu, 12 Sep 2013 17:37:49 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> In-Reply-To: <5231F859.2040002@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 17:38:35 -0000 I'm not an expert in TLS -- my technical background is SRP/AES. I thought = every client already has a private key in order to negotiate with the serve= r for a session key. If that's not true, then yes, authentication by the server that the connect= ion is with the client directly, and not through MITM, requires each user t= o have a private key. -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Thursday, September 12, 2013 10:23 To: Karl Malbrain Cc: perpass@ietf.org Subject: Re: [perpass] proposed enhancement to TLS strong authentication pr= otocol Hi Karl, On 09/12/2013 06:13 PM, Karl Malbrain wrote: > I was under the impression that this list was to discuss things=20 > pre-draft -- e.g. general concepts first, details later in a specific=20 > work-group. I'm sorry if you find the piece meal approach difficult. Its not that its difficult but rather that another level of detail might be= needed before its clear if the approach could work. (Being honest, I'm ske= ptical of anything that needs every client who uses TLS have a private key,= if that is what's proposed.) >=20 > My proposal in a nutshell: >=20 > 1. Use TLS strong authentication between client and server on all=20 > connections over the internet to obviate MITM attacks. 2. Make users' > public keys public information to obviate current TLS limitations on=20 > obtaining them. >=20 > If everyone agrees with this, we can certainly move onto a draft to=20 > work out details, and yes, I'd need assistance from that point onward. I'd say the overall thrust of the idea is clear(ish), but you won't get rou= gh consensus on something like that until after its written down (ideally w= ith running code), so I reckon this is at the point where an I-D is the nex= t step. So if you get others who're interested and who know how to do it, write up = that I-D. (And again, if you're not sure how to do it yourself, just ping m= e.) S. >=20 > Karl >=20 > -----Original Message----- From: Stephen Farrell=20 > [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, September 12, 2013 > 09:47 To: Karl Malbrain Cc: Jon Callas; Theodore Ts'o;=20 > perpass@ietf.org; Phillip Hallam-Baker Subject: Re: [perpass] proposed=20 > enhancement to TLS strong authentication protocol >=20 >=20 > Hi, >=20 > We seem to be designing this protocol one mail at a time. Could I ask=20 > that we stop doing that and that Karl and whoever else is minded=20 > submit an internet-draft specifying the protocol so that it can be=20 > more easily reviewed. >=20 > Thanks, Stephen. >=20 > PS: Karl, if you need help with the mechanics just ask me offlist. >=20 > On 09/12/2013 05:24 PM, Karl Malbrain wrote: >> The assumed attack profile is a MITM insertion into a connection=20 >> stream between server and client whereby the attacker gains complete=20 >> unencrypted access to all traffic over the connection, not just meta=20 >> data. >>=20 >> TLS already has a built-in concept of "strong authentication" >> between server and client to defeat this attack. It requires that=20 >> the TLS server pre-obtain by some secondary channel the public key of=20 >> the user. This proposal eliminates that requirement by making the=20 >> user's public keys public knowledge. >>=20 >> Karl >>=20 >> From: Jon Callas [mailto:joncallas@icloud.com] Sent: Thursday,=20 >> September 12, 2013 06:21 To: Karl Malbrain Cc: Jon Callas; Phillip=20 >> Hallam-Baker; Theodore Ts'o; perpass@ietf.org Subject: Re: >> [perpass] proposed enhancement to TLS strong authentication protocol >>=20 >>=20 >> On Sep 11, 2013, at 11:56 AM, Karl Malbrain=20 >> > wrote: >>=20 >>=20 >> The goal of the proposal is to enable the use of strong=20 >> authentication for all TLS connections over the internet. The=20 >> certificates as things-in-themselves don't really matter, they are=20 >> actually just a vehicle to post the public key of the user/server in=20 >> a reliable public place. The security occurs when the challenges to=20 >> prove private key ownership are cross-issued by each party. MITM=20 >> would not have the private keys to answer either challenge. >>=20 >> Note that this still doesn't solve the problem of MITM obtaining the=20 >> server's private key. I'm still working on that one. >>=20 >> I might be misunderstanding, but it seems to me that your global=20 >> directory would allow a passive listener to fingerprint the client by=20 >> sniffing in a variety of places -- near the client, near the server,=20 >> or near the directory. >>=20 >> If you assume an attacker interested in collecting metadata about the=20 >> clients, this would be suboptimal. >>=20 >> I may be missing something, but this sounds like it is just a global,=20 >> central certificate authority, albeit one that is not actually=20 >> issuing the certificates, but still assigning them GUIDs, which are=20 >> by definition globally unique. >>=20 >> Am I indeed missing something? >>=20 >> Jon >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ perpass mailing list=20 >> perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass >>=20 > _______________________________________________ perpass mailing list=20 > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass >=20 >=20 From leifj@mnt.se Thu Sep 12 11:13:57 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1239A11E8184 for ; Thu, 12 Sep 2013 11:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.066 X-Spam-Level: X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grajpz084-RY for ; Thu, 12 Sep 2013 11:13:51 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id E3D9311E80D3 for ; Thu, 12 Sep 2013 11:13:50 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id eh20so146325lab.4 for ; Thu, 12 Sep 2013 11:13:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hnFurSCRGw7m2ZjQRc18R8xy+hgXOi/eW7TjJfwJgc4=; b=SQ+1Cw/lRVTbqvCFSjt+dSgamXU3Q26qtXXC+vt/lvhgLL+U7y/Ia/dB6tOaK+/YKk 3swEEj6chueot1PknXxaILrPkE2s8Bd25Sr5EhqMqIXwcb4Hx4+mLaxBZzN6RAYmGKKb gbv4TS/0VQyQtWv71NrGe1JwxnD3PXNzlacBDC4Ou/xmo5dXrDVG9pqVjm1XRRqi7Kln JHysQXSBXjIUEKNo56QLbjvF3aHrrG+RdyIYXb2wucTwXMVLkJZTu2tmcQknbyd5PGZJ rZF2hVp5YDle/C6b3lquaba9UZehylHm5rxs2n1+ZOYgx47Bc9qkwnI52rLPIBJhi5rc P0Jw== X-Gm-Message-State: ALoCoQlq2yJGiUDkVbktwOIxIK3WxVqmx7onBwzkfNt6/3KV88HSI1+kIsiFQPB1Stm2UDsToORp X-Received: by 10.112.9.195 with SMTP id c3mr2497509lbb.33.1379009629874; Thu, 12 Sep 2013 11:13:49 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id i3sm2381477laf.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 11:13:49 -0700 (PDT) Message-ID: <5232045B.4040904@mnt.se> Date: Thu, 12 Sep 2013 20:13:47 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> In-Reply-To: <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 18:13:57 -0000 On 09/12/2013 07:37 PM, Karl Malbrain wrote: > I'm not an expert in TLS -- my technical background is SRP/AES. I thought every client already has a private key in order to negotiate with the server for a session key. > > If that's not true, then yes, authentication by the server that the connection is with the client directly, and not through MITM, requires each user to have a private key. > I believe Stephen is asking you to spell out details like that in an internet-draft. I would also like to move on to other things while we wait for that draft to appear. thx /leif From malbrain@yahoo.com Thu Sep 12 11:37:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D1511E8249 for ; Thu, 12 Sep 2013 11:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cD5ZiIC4VyN for ; Thu, 12 Sep 2013 11:37:07 -0700 (PDT) Received: from nm20-vm4.bullet.mail.ne1.yahoo.com (nm20-vm4.bullet.mail.ne1.yahoo.com [98.138.91.180]) by ietfa.amsl.com (Postfix) with ESMTP id CB77621E809D for ; Thu, 12 Sep 2013 11:37:06 -0700 (PDT) Received: from [98.138.226.178] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2013 18:37:02 -0000 Received: from [98.138.101.164] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2013 18:37:02 -0000 Received: from [127.0.0.1] by omp1075.mail.ne1.yahoo.com with NNFMP; 12 Sep 2013 18:37:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 771866.70512.bm@omp1075.mail.ne1.yahoo.com Received: (qmail 87012 invoked by uid 60001); 12 Sep 2013 18:37:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379011022; bh=gtbXnghGlfgX/bx2CtHDs5gpYCalvlc9gzFMc+kx/Ts=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=zD/oHam0rgeLzug7kl5einU6GllyH5ZJiIqefN2NQWcwOC12Jc58ngOtEx1M2sY0jmtK/e327hh2lb1HWOk1hispd0EzkvkU/STO8zC+3J8lpm7TC9tnAHu3kJq6nE/1pnd+rKlP/sOLnWM3OFB9uWcB7oEhDUu0ntbkg3jUMOc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Iljf+7CSUxN3jXkb3si11G1IlOhDBio/cQud24pnGHjnloOiMymhvzlxUvbUW477NOKQbTVew9rRze3lmoV+xEpjRDgk/u6YBH/jKqWhBYQsrihVL0SZkF6r5ApLVq5JFbKBtWZSh7EZv02ec6uLHZMhXkQaqaUzuYFXT3+EsPA=; X-YMail-OSG: HtZJMO4VM1mJIdEUMU.qrRh6odjt9iGcqpbpZEzYXNsYHJM rWYX3aR6hFFHIpUPdEIO1r5z0fRZsbvoZoHo4l5TPPJfdeGvZFzP844f3h_L .prWyJdf57NiMBY9ZJwe7awWlgHRKJMLK2aDMW1NcLRzYq8JBAwIULFY_XY5 e3ob25G3POWBO.VRUmvqaDR9ziXF.powNDH9L8B8NOx1AzBrdM6Xh2epPQIo zILOM5AiVRWvSOZz1_h1VDvaeeXY.Sf53cXNPZJia3Wfc4ydGoNFQSCSBU.i Ahve3CXBOW6xVJA.ifS5HWCPMvwMZYyhQ9rDIifYWPvk4BjCWlreXSjc6cC7 vL8fr7S04H4_nE.GJ48mjMS3yKBfzyaGE7x0gjieKgnqCizOuIkh8SI0mFLX 442cSeNkkifs0iiDLkc5qSa2mHnEBnnhUqqAdPD3HRlmb8m52S5lFbABxGKz GEatnoLutNY5HkqdCCocSWqK7W1ObTua4fbYYVZAujCTQuPAoq8bDxa3XXwb Vhc521Vl_5dnzoSHvh0jFQLN_U5cctKIqy4WtImQdkr3PQt2CpkxWbi5BnG4 RXo8T99Jwdfu2Iq0vbbiDnyjUUDzSPevgjev9Js8- Received: from [206.169.92.130] by web125506.mail.ne1.yahoo.com via HTTP; Thu, 12 Sep 2013 11:37:02 PDT X-Rocket-MIMEInfo: 002.001, TGVpZiwKwqAKSSBkb24ndCBvd24gdGhlIHRlY2huaWNhbCBhYmlsaXR5IHRvIHNwZWxsIG91dCBzcGVjaWZpYyBjaGFuZ2VzIHRvIHRoZSBUTFMgc3Ryb25nIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIG5lZWRlZCB0byBpbXBsZW1lbnQgdGhlIHByb3Bvc2VkIGNoYW5nZXMuwqAgSSd2ZSBvbmx5IGJlZW4gZXhwb3NlZCB0byB0aGlzIGFzIGEgY2xpZW50IHRvIGEgc3Ryb25nIGF1dGhlbnRpY2F0aW9uIHNlcnZlci4KwqAKSSBoYWQgaG9wZWQgdG8gb3BlbiBhIGdlbmVyYWwgZGlzY3Vzc2lvbiBvbiB0aGUgdG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> Message-ID: <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> Date: Thu, 12 Sep 2013 11:37:02 -0700 (PDT) From: karl m To: Leif Johansson , "perpass@ietf.org" In-Reply-To: <5232045B.4040904@mnt.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="264668936-1515786225-1379011022=:86026" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: karl m List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 18:37:12 -0000 --264668936-1515786225-1379011022=:86026 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Leif,=0A=A0=0AI don't own the technical ability to spell out specific chang= es to the TLS strong authentication protocol needed to implement the propos= ed changes.=A0 I've only been exposed to this as a client to a strong authe= ntication server.=0A=A0=0AI had hoped to open a general discussion on the t= opic of strong authentication for every connection=A0to every server as a m= eans to preclude MITM.=A0 Do you have any input on that?=0A=A0=0AThanks,=0A= Karl=0A =0A=0A________________________________=0A From: Leif Johansson =0ATo: perpass@ietf.org =0ASent: Thursday, September 12, 2013 11:= 13 AM=0ASubject: Re: [perpass] proposed enhancement to TLS strong authentic= ation=09protocol=0A =0A=0AOn 09/12/2013 07:37 PM, Karl Malbrain wrote:=0A>= I'm not an expert in TLS -- my technical background is SRP/AES.=A0 I thoug= ht every client already has a private key in order to negotiate with the se= rver for a session key.=0A>=0A> If that's not true, then yes, authenticatio= n by the server that the connection is with the client directly, and not th= rough MITM, requires each user to have a private key.=0A>=0AI believe Steph= en is asking you to spell out details like that in an=0Ainternet-draft. I w= ould also like to move on to other things while we=0Await for that draft to= appear.=0A=0A=A0 =A0 thx /leif=0A=0A______________________________________= _________=0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/= mailman/listinfo/perpass --264668936-1515786225-1379011022=:86026 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Leif,
 
I don't own the technical = ability to spell out specific changes to the TLS strong authentication prot= ocol needed to implement the proposed changes.  I've only been exposed= to this as a client to a strong authentication server.
 
I had hoped to open a general discussion = on the topic of strong authentication for every connection to every se= rver as a means to preclude MITM.  Do you have any input on that?
 
Thanks,
<= span>Karl

From: Le= if Johansson <leifj@mnt.se>
To: perpass@ietf.org
Sent: Thursday, September 12, 2013 11:13 AM
Subject: Re: [perpass] proposed enhancem= ent to TLS strong authentication=09protocol

On 09/12/2013 07:37 PM, Karl Malbrain wrote:
&g= t; I'm not an expert in TLS -- my technical background is SRP/AES.  I = thought every client already has a private key in order to negotiate with t= he server for a session key.
>
> If that's not true, then yes, = authentication by the server that the connection is with the client directly, and not through MI= TM, requires each user to have a private key.
>
I believe Stephen = is asking you to spell out details like that in an
internet-draft. I wou= ld also like to move on to other things while we
wait for that draft to = appear.

    thx /leif

_____________________________= __________________
perpass mailing list
perpass@ietf.org
https:= //www.ietf.org/mailman/listinfo/perpass


=
--264668936-1515786225-1379011022=:86026-- From dhc@dcrocker.net Thu Sep 12 13:18:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7C111E81E0 for ; Thu, 12 Sep 2013 13:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAzLz0unRFyW for ; Thu, 12 Sep 2013 13:18:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 23A5C11E80AD for ; Thu, 12 Sep 2013 13:18:45 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r8CKIf8x020191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Sep 2013 13:18:44 -0700 Message-ID: <5232218A.9010704@dcrocker.net> Date: Thu, 12 Sep 2013 13:18:18 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 12 Sep 2013 13:18:45 -0700 (PDT) Subject: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 20:18:49 -0000 Folks, G'day. While all of the very specific lines of discussion look quite interesting, it is not possible to tell whether any of these are important to the task of perpass, which was established to discuss: http://www.ietf.org/mail-archive/web/perpass/current/msg00000.html "privacy properties of IETF protocols and concrete ways in which those could be improved." So my simple question is: What are the problems that need to be solved here? Otherwise, all this activity is a random walk down some entertaining and possibly useful paths, but without any guidance, prioritization or systems view. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From bdickson@verisign.com Thu Sep 12 15:10:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C0011E81BA for ; Thu, 12 Sep 2013 15:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrdwSPy1jukS for ; Thu, 12 Sep 2013 15:10:36 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id C791F11E80F2 for ; Thu, 12 Sep 2013 15:10:35 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUjI71vWM6ka5ZeBhQEyBz2j665PkqDoJ@postini.com; Thu, 12 Sep 2013 15:10:35 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r8CMARL5007827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Sep 2013 18:10:30 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 12 Sep 2013 18:10:27 -0400 From: "Dickson, Brian" To: "perpass@ietf.org" Thread-Topic: [perpass] What problems does perpass need to solve? Thread-Index: AQHOsATTh0y2nFht0kGVvkRXb8E6Zw== Date: Thu, 12 Sep 2013 22:10:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CE57B411D432bdicksonverisigncom_" MIME-Version: 1.0 Cc: Dave Crocker Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 22:10:42 -0000 --_000_CE57B411D432bdicksonverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave wrote: "privacy properties of IETF protocols and concrete ways in which those could be improved." So my simple question is: What are the problems that need to be solved here? I think one thing we should look at, is what place(s) in the protocol stack= exist, and can be considered for incremental privacy modifications via pro= tocol enhancements. Clearly, there are already some protocols that support = security after some fashion, which also often provides privacy. Privacy is = trivial in those cases, but only if they are used (and usable). I think it would be good to look at active and passive independently. There= will be methods which may be useful against one, which are not useful agai= nst the other. I'll start with things specific to the "passive" case. (BTW - Enumerating them seems like it would be useful to do, I.e. identify = privacy weaknesses, privacy protection methods, and requirements/deficienci= es of each.) As an example, if we distinguish privacy from security, we can observe: * If we can accomplish "privacy =3D=3D anonymity" (by protecting the id= entities), the cost of doing so may be significantly lower. * Observe, that in order to surveil a subject on a network, it is neces= sary (but maybe not sufficient) to identify source & destination address & = port, plus enough protocol-specific information (e.g . sequence numbers for= TCP) to decipher and de-multiplex the protocol stream from the aggregate t= raffic collected. * Hide (e.g. encrypt, or otherwise render "hidden") those, and the traf= fic becomes a soup of clear-text without sufficient context to decipher. * This is analogous to using a shredder shared with lots of co-tennants= . The characters are visible, but the arrangement of them trashed, and find= ing bits that belong together is difficult at best. The larger the volume, = the harder it becomes. * This becomes scaling problem for the attacker. The easier it is to co= llect volumes of data, the harder it is to process. * If the decode is deterministic, and if encode/decode operate at line = rate, the economics shift drastically for the passive observer, at no incre= mental cost to the networks. This leads to an immediate suggestion: If we make possible hop-by-hop packet obfuscation, in such a way that adjac= ent routers (sender & receiver) mangle/unmangle the first N bytes of each L= 3 packet, so that a passive listener could not trivially discover the "keys= " used, then privacy (where privacy =3D=3D anonymity) against passive liste= ners can be achieved. If, for example the first 8 bytes are clear, but the = next 56 bytes are mangled, IPv4 and IPv6 both gain privacy, against both IP= and "next protocol" header data. The "IP Version" field could be overloade= d for signaling use of clear/mangled, and possibly for additional purposes = (two extra bits for signaling crypto behavior on-the-fly, for example). Som= e feasibility of doing this mangling/un-mangling at line rate on current ha= rdware needs to be done, but my gut says that XOR on a subset of the first = 64 bytes of each packet, with a periodically-updated small set of fixed val= ues, should be possible to do (and be interoperable) on pretty much every m= ajor platform already deployed, without that much work. Operating at L3 mea= ns all upper layer protocols gain the same benefit, at no cost. L2 addresse= s should be sufficient for disambiguation (for de-mangling). This only protects non-end-points, though, unless the end points have this = capability added (e.g. via protocols the key exchange piggy-backs on, such = as BGP, OSPF, or ISIS). However, this means any aggregation point beyond th= e first hop, represents a place where opportunistic privacy can be incremen= tally be deployed. Obviously, this requires some kind of opt-in or negotiation, and key sharin= g/distribution/exchange, ideally with PFS using ephemeral keys. As Randy Bu= sh pointed out, for EBGP neighbors, adding key exchange is pretty easy to d= o. For IGPs, this should also be easy to do. Across the Internet, each hop = should be either over an IGP link or over an EBGP link, generally. (Outer p= acket only for tunneled links.) So, other than getting vendors to implement= this and operators to configure it, it should be feasible to deploy ubiqui= tously, defeating all passive observers. QED. Brian --_000_CE57B411D432bdicksonverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2B6A3871EEAA4D409D360FC459F45680@verisign.com> Content-Transfer-Encoding: quoted-printable
Dave wrote:
  
 "privacy properties of IETF protocols and concrete ways in = which
    those could be improved."

So my simple question is:

   What are the problems that need to be solved here?

I think one thing we should look at, is what place(s) in the protocol = stack exist, and can be considered for incremental privacy modifications vi= a protocol enhancements. Clearly, there are already some protocols that sup= port security after some fashion, which also often provides privacy. Privacy is trivial in those cases, but = only if they are used (and usable).

I think it would be good to look at active and passive independently.&= nbsp;There will be methods which may be useful against one, which are not u= seful against the other.

I'll start with things specific to the "passive" case.

(BTW - Enumerating them seems like it would be useful to do, I.e. iden= tify privacy weaknesses, privacy protection methods, and requirements/defic= iencies of each.)

As an example, if we distinguish privacy from security, we can observe= :

  • If we can accomplish "privacy =3D=3D anonymity" (by protectin= g the identities), the cost of doing so may be significantly lower.
    • Observe, that in order to surveil a subject on a network, it is necessary = (but maybe not sufficient) to identify source & destination address &am= p; port, plus enough protocol-specific information (e.g . sequence numbers = for TCP) to decipher and de-multiplex the protocol stream from the aggregate traffic collected.
  • Hide (e.= g. encrypt, or otherwise render "hidden") those, and the traffic = becomes a soup of clear-text without sufficient context to decipher.
    • This is analogous to using a shredder shared with lots of co-tennants. Th= e characters are visible, but the arrangement of them trashed, and finding = bits that belong together is difficult at best. The larger the volume, the = harder it becomes. 
  • This becomes scaling problem for the attac= ker. The easier it is to collect volumes of data, the harder it is to proce= ss.
  • If the decode is deterministic, and if encode/decode operate at= line rate, the economics shift drastically for the passive observer, at no= incremental cost to the networks.

This leads to an immediate suggestion:
If we make possible hop-by-hop packet obfuscation, in such a way that = adjacent routers (sender & receiver) mangle/unmangle the first N bytes = of each L3 packet, so that a passive listener could not trivially discover = the "keys" used, then privacy (where privacy =3D=3D anonymity) against passive listeners can be achieved. If, f= or example the first 8 bytes are clear, but the next 56 bytes are mangled, = IPv4 and IPv6 both gain privacy, against both IP and "next protocol&qu= ot; header data. The "IP Version" field could be overloaded for signaling use of clear/mangled, and possibly for additio= nal purposes (two extra bits for signaling crypto behavior on-the-fly, for = example). Some feasibility of doing this mangling/un-mangling at line rate = on current hardware needs to be done, but my gut says that XOR on a subset of the first 64 bytes of each p= acket, with a periodically-updated small set of fixed values, should be pos= sible to do (and be interoperable) on pretty much every major platform alre= ady deployed, without that much work. Operating at L3 means all upper layer protocols gain the same b= enefit, at no cost. L2 addresses should be sufficient for disambiguation (f= or de-mangling).

This only protects non-end-points, though, unless the end points have = this capability added (e.g. via protocols the key exchange piggy-backs on, = such as BGP, OSPF, or ISIS). However, this means any aggregation point= beyond the first hop, represents a place where opportunistic privacy can be incrementally be deployed.

Obviously, this requires some kind of opt-in or negotiation, and key s= haring/distribution/exchange, ideally with PFS using ephemeral keys. A= s Randy Bush pointed out, for EBGP neighbors, adding key exchange is pretty= easy to do. For IGPs, this should also be easy to do. Across the Internet, each hop should be either over an= IGP link or over an EBGP link, generally. (Outer packet only for tunneled = links.) So, other than getting vendors to implement this and operators to c= onfigure it, it should be feasible to deploy ubiquitously, defeating all passive observers. QED.

Brian
--_000_CE57B411D432bdicksonverisigncom_-- From randy@psg.com Thu Sep 12 19:59:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484EA21E80BE for ; Thu, 12 Sep 2013 19:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ4dS1kAdbHj for ; Thu, 12 Sep 2013 19:59:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id CF36321E804D for ; Thu, 12 Sep 2013 19:59:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKJav-0000wr-JZ; Fri, 13 Sep 2013 02:58:54 +0000 Date: Thu, 12 Sep 2013 16:58:52 -1000 Message-ID: From: Randy Bush To: dcrocker@bbiw.net In-Reply-To: <5232218A.9010704@dcrocker.net> References: <5232218A.9010704@dcrocker.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 02:59:19 -0000 > "privacy properties of IETF protocols and concrete ways in which > those could be improved." to repeat my statement from berlin, privacy by default. and as many places as we can enable it. randy From code@funwithsoftware.org Thu Sep 12 20:12:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5120D21E81E1 for ; Thu, 12 Sep 2013 20:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt4nr+g+QTg8 for ; Thu, 12 Sep 2013 20:12:32 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8921E81DD for ; Thu, 12 Sep 2013 20:12:32 -0700 (PDT) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.52]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 33B231EE509F for ; Thu, 12 Sep 2013 23:12:12 -0400 (EDT) Received: (qmail 13923 invoked from network); 13 Sep 2013 03:12:11 -0000 Received: by simscan 1.4.0 ppid: 9165, pid: 23355, t: 1.2298s scanners: clamav: 0.88.2/m:52/d:13513 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 13 Sep 2013 03:12:10 -0000 Message-ID: <52328288.6070806@funwithsoftware.org> Date: Thu, 12 Sep 2013 20:12:08 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: perpass@ietf.org References: <5232218A.9010704@dcrocker.net> In-Reply-To: <5232218A.9010704@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 03:12:41 -0000 On 9/12/13 1:18 PM, Dave Crocker wrote: > "privacy properties of IETF protocols and concrete ways in which > those could be improved." One obvious thing is the amount of (usually unnecessary) information leaked by the User-Agent field in HTTP. Should we downgrade the User-Agent field (section 14.43 of RFC 2616) from a SHOULD to a MAY? Or, if that's too radical, should we standardize a small number of fixed strings to use in the User-Agent field? (For example, "Desktop/1.0" for desktop browsers, "Mobile/1.0" for mobile browsers, "Text/1.0" for text browsers like Lynx, "Batch/1.0" for non-interactive clients like curl which are performing a task more specific than crawling the web, and "Robot/1.0" for clients which are crawling the web?) --Patrick From dhc@dcrocker.net Thu Sep 12 20:45:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD1821E804D for ; Thu, 12 Sep 2013 20:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRCfeaY0q94G for ; Thu, 12 Sep 2013 20:45:11 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D69FC11E80E0 for ; Thu, 12 Sep 2013 20:45:11 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r8D3j7n6028125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Sep 2013 20:45:10 -0700 Message-ID: <52328A2C.10805@dcrocker.net> Date: Thu, 12 Sep 2013 20:44:44 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass References: <5232218A.9010704@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 12 Sep 2013 20:45:11 -0700 (PDT) Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 03:45:24 -0000 >> "privacy properties of IETF protocols and concrete ways in which >> those could be improved." > > to repeat my statement from berlin, privacy by default. and as many > places as we can enable it. If we -- the IETF community -- had a definition of privacy, that would help, but we don't. If we knew what it meant to 'enable privacy' (nevermind whether by default), that would also help, but we don't. So the idea of 'privacy by default' well could serve as a useful catch-phrase, but at the moment, it lacks technical substance. We have no shared, technical understanding of its meaning. No doubt you have particulars in mind. No doubt lots of folks have their own set of particulars. Unfortunately each person's particulars tends to be different. So what we lack are a) anything like a specific technical meaning for privacy, b) any system-level sense of what it means to provide privacy, or c) any prioritization of privacy issues so that we can get the most benefit from initial efforts. My question was meant to prompt discussion at a technical level. There have been the tiniest wisps of comment on the list that might provide touchstones for this, but they haven't been pursued. We need to pursue them. Catch-phrases will be useful to summarize the results. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tbray@textuality.com Thu Sep 12 20:55:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E2021E80E1 for ; Thu, 12 Sep 2013 20:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN7x1bIlPKJu for ; Thu, 12 Sep 2013 20:55:41 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4C31E21E8063 for ; Thu, 12 Sep 2013 20:55:37 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id hz10so543101vcb.26 for ; Thu, 12 Sep 2013 20:55:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b/lekJvRuC1s+hU8lRxm2V2JRDq2Ww+cWjiQZI3HuM0=; b=RbfJUox9fuAICODdgC5sz4Asd3uAjE6xOsVY5Go3c2oC/gXaU01Unx4NmqFhF3kr3I zcRU7SIFPGiespm+nsgqr6ZxZY4Q1ihFYbvnyjxCpS8SIMGOloTa1bBwzqh9h75fnZG5 t7+0ega/xoBDlAZQWIL02/iRHP9/N28whUeTCIzG3SXWI4Oxk307b3NqLs8feEsZp1wb z2Zj8jKW5HfULVIcw8kA//9oNAloa0J0FhIxyKxpG1bliitGtO3arOY0wCcKl881R242 W75NCVS6rwTVRQrpi3PrUrNYdn87pHl0hon665DSe9das9wIku4/cWE+bBZ6XE8cu42Q CzrQ== X-Gm-Message-State: ALoCoQksd/tF8zpoZOGBs5rezIFhQ8Ec9UOXT3ZulAmMVvX5iPmUlLvAKSpt2BErY57Dp/X5/pFL MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr9860984vcb.16.1379044535923; Thu, 12 Sep 2013 20:55:35 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 12 Sep 2013 20:55:35 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <52328A2C.10805@dcrocker.net> References: <5232218A.9010704@dcrocker.net> <52328A2C.10805@dcrocker.net> Date: Thu, 12 Sep 2013 20:55:35 -0700 Message-ID: From: Tim Bray To: Dave CROCKER Content-Type: multipart/alternative; boundary=047d7b5db26ab1841504e63bd314 Cc: perpass Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 03:55:45 -0000 --047d7b5db26ab1841504e63bd314 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dave, there=E2=80=99s been some useful and grown-up discussion going on aro= und here. I don=E2=80=99t think you=E2=80=99re trying to derail it, but you ri= sk having that effect. I think it would be better to ease off and see where it leads us, because I=E2=80=99ve read some smart and enlightening things. On Thu, Sep 12, 2013 at 8:44 PM, Dave Crocker wrote: > > "privacy properties of IETF protocols and concrete ways in which >>> those could be improved." >>> >> >> to repeat my statement from berlin, privacy by default. and as many >> places as we can enable it. >> > > > If we -- the IETF community -- had a definition of privacy, that would > help, but we don't. > > If we knew what it meant to 'enable privacy' (nevermind whether by > default), that would also help, but we don't. > > So the idea of 'privacy by default' well could serve as a useful > catch-phrase, but at the moment, it lacks technical substance. We have n= o > shared, technical understanding of its meaning. > > No doubt you have particulars in mind. No doubt lots of folks have their > own set of particulars. Unfortunately each person's particulars tends to > be different. > > So what we lack are a) anything like a specific technical meaning for > privacy, b) any system-level sense of what it means to provide privacy, o= r > c) any prioritization of privacy issues so that we can get the most benef= it > from initial efforts. > > My question was meant to prompt discussion at a technical level. There > have been the tiniest wisps of comment on the list that might provide > touchstones for this, but they haven't been pursued. We need to pursue > them. > > Catch-phrases will be useful to summarize the results. > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > ______________________________**_________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/**listinfo/perpass > --047d7b5db26ab1841504e63bd314 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dave, there=E2=80=99s been some useful and grown-up discus= sion going on around here.=C2=A0 I don=E2=80=99t think you=E2=80=99re tryin= g to derail it, but you risk having that effect. I think it would be better= to ease off and see where it leads us, because I=E2=80=99ve read some smar= t and enlightening things.


On Thu,= Sep 12, 2013 at 8:44 PM, Dave Crocker <dhc@dcrocker.net> wro= te:

"privacy properties of IETF protocols and concrete ways in which
those could be improved."

to repeat my statement from berlin, privacy by default. =C2=A0and as many places as we can enable it.


If we -- the IETF community -- had a definition of privacy, that would help= , but we don't.

If we knew what it meant to 'enable privacy' (nevermind whether by = default), that would also help, but we don't.

So the idea of 'privacy by default' well could serve as a useful ca= tch-phrase, but at the moment, it lacks technical substance. =C2=A0We have = no shared, technical understanding of its meaning.

No doubt you have particulars in mind. =C2=A0No doubt lots of folks have th= eir own set of particulars. =C2=A0Unfortunately each person's particula= rs tends to be different.

So what we lack are a) anything like a specific technical meaning for priva= cy, b) any system-level sense of what it means to provide privacy, or c) an= y prioritization of privacy issues so that we can get the most benefit from= initial efforts.

My question was meant to prompt discussion at a technical level. =C2=A0Ther= e have been the tiniest wisps of comment on the list that might provide tou= chstones for this, but they haven't been pursued. =C2=A0We need to purs= ue them.

Catch-phrases will be useful to summarize the results.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass

--047d7b5db26ab1841504e63bd314-- From esuarez@fcaglp.fcaglp.unlp.edu.ar Thu Sep 12 21:27:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA63B21E80FC for ; Thu, 12 Sep 2013 21:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61a7Mg4xa+ZF for ; Thu, 12 Sep 2013 21:27:03 -0700 (PDT) Received: from mercurio.fcaglp.unlp.edu.ar (mercurio.fcaglp.unlp.edu.ar [163.10.4.2]) by ietfa.amsl.com (Postfix) with ESMTP id B340921E809F for ; Thu, 12 Sep 2013 21:27:02 -0700 (PDT) Received: from fcaglp.fcaglp.unlp.edu.ar (fcaglp.fcaglp.unlp.edu.ar [163.10.4.1]) by mercurio.fcaglp.unlp.edu.ar (8.14.4/8.14.4/Debian-2.1) with ESMTP id r8D4OH02004411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Sep 2013 01:24:17 -0300 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fcaglp.unlp.edu.ar; s=fcag-20130303; t=1379046337; bh=4tlsN3cTyJCRB9mDICPI+wnbLmF/05vJItiK6wnf4RU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:Content-Type:From: Date:Subject:Content-Type; b=IK7ghjJyCFvTBX6f329r2l2TW+FgkqUaay1sFl8V2YwjZvFf1MDpj/9y0b3LflN7W vKcP0QMdLHa1pbIg3IJ0cNFlYXdUAJKjX97bCBC+h7l602xJ28rRW8WHupLsUIFDpa zr4bbxgNOELM0UjPewmECbN8r67/Inm3adXcdevc= Received: from fcaglp.fcaglp.unlp.edu.ar (localhost.localdomain [127.0.0.1]) by fcaglp.fcaglp.unlp.edu.ar (8.14.3/8.14.4/Debian-4) with ESMTP id r8D4OHaV012488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Sep 2013 01:24:17 -0300 Received: (from www-data@localhost) by fcaglp.fcaglp.unlp.edu.ar (8.14.3/8.14.4/Submit) id r8D4OHP3012487; Fri, 13 Sep 2013 01:24:17 -0300 X-Authentication-Warning: fcaglp.fcaglp.unlp.edu.ar: www-data set sender to esuarez@fcaglp.fcaglp.unlp.edu.ar using -f Received: from 201-255-94-128.mrse.com.ar (201-255-94-128.mrse.com.ar [201.255.94.128]) by fcaglp.fcaglp.unlp.edu.ar (Horde MIME library) with HTTP; Fri, 13 Sep 2013 01:24:17 -0300 Message-ID: <20130913012417.zag96lpc4go440s0@fcaglp.fcaglp.unlp.edu.ar> Date: Fri, 13 Sep 2013 01:24:17 -0300 From: "Eduardo A. =?utf-8?b?U3XDoXJleg==?=" To: Dave Crocker References: <5232218A.9010704@dcrocker.net> <52328A2C.10805@dcrocker.net> In-Reply-To: <52328A2C.10805@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (mercurio.fcaglp.unlp.edu.ar [163.10.4.2]); Fri, 13 Sep 2013 01:25:37 -0300 (ART) X-Scanned-By: MIMEDefang 2.71 on 163.10.4.2 Cc: perpass Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 04:27:13 -0000 Quoting Dave Crocker : > > If we -- the IETF community -- had a definition of privacy, that would > help, but we don't. > > If we knew what it meant to 'enable privacy' (nevermind whether by > default), that would also help, but we don't. > > So the idea of 'privacy by default' well could serve as a useful > catch-phrase, but at the moment, it lacks technical substance. We have > no shared, technical understanding of its meaning. Here are something to understand what privacy means. "Information privacy, or data privacy, is the relationship between =20 collection and dissemination of data, technology, the public =20 expectation of privacy, and the legal and political issues surrounding =20 them. Privacy concerns exist wherever personally identifiable information is =20 collected and stored. The challenge in data privacy is to share data while protecting =20 personally identifiable information." [1] "Internet privacy involves the right or mandate of personal privacy =20 concerning the storing, repurposing, provision to third-parties, and =20 displaying of information pertaining to oneself via the Internet." [2] "Personally identifiable information (PII), as used in US privacy law =20 and information security, is information that can be used on its own =20 or with other information to identify, contact, or locate a single =20 person, or to identify an individual in context." [3] [1] http://en.wikipedia.org/wiki/Data_privacy [2] http://en.wikipedia.org/wiki/Internet_privacy [3] http://en.wikipedia.org/wiki/Personally_identifiable_information ES.- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From moritz@headstrong.de Thu Sep 12 21:54:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C18721E809A for ; Thu, 12 Sep 2013 21:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3JVnLwXGrZQ for ; Thu, 12 Sep 2013 21:54:34 -0700 (PDT) Received: from mail.headstrong.de (mail.headstrong.de [IPv6:2a02:180:a:25:2::1]) by ietfa.amsl.com (Postfix) with ESMTP id 377A521F88A9 for ; Thu, 12 Sep 2013 21:54:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.headstrong.de (Postfix) with ESMTP id 19B731C004F6 for ; Fri, 13 Sep 2013 06:54:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=headstrong.de; h=content-transfer-encoding:content-type:content-type:subject :subject:mime-version:user-agent:from:from:date:date:message-id :received; s=mail; t=1379048072; x=1380862473; bh=Etgit06cLLGxiU UxcS2j6yFIYGPLx4vJUQPYGRnPOWc=; b=bYZE5YavjCfgnpX84TgC/cFNnZ0Oin 0ZjgUz2iz/u3r9QISkmqekMvKkldbycPhA+EIhENwVt3ZjC8ezCNNgnAq2t6yD6R x872Lif81lGe8mfZ4y1veTrkeD6u3L5L62ViPkP+VpTdBPP3JkA5uFjFt9x574WN Vt66oonMRv3bI= X-Virus-Scanned: Debian amavisd-new at mail.headstrong.de Received: from mail.headstrong.de ([127.0.0.1]) by localhost (mail.headstrong.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kok1lJWUd5KL for ; Fri, 13 Sep 2013 06:54:32 +0200 (CEST) Message-ID: <52329A7A.7060103@headstrong.de> Date: Fri, 13 Sep 2013 06:54:18 +0200 From: Moritz Bartl User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130827 Icedove/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 04:54:35 -0000 Hi, I would very much like to see servers having a minimal logging policy by default, especially and at least when it comes to IP addresses. I wonder if RFC 6302 is the right document to look at or extend for this. It is easy to flip a switch to enable IP logging. The default should be no IP logs, which is true for most XMPP servers, for example, but not for web or mail servers. On a side node, can we do anything to get rid of sender IP addresses in (the first) Received headers of mail? -- Moritz From leifj@mnt.se Thu Sep 12 23:36:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5DE11E8151 for ; Thu, 12 Sep 2013 23:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEYfihFVCA6x for ; Thu, 12 Sep 2013 23:36:12 -0700 (PDT) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id F00E411E8156 for ; Thu, 12 Sep 2013 23:36:11 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id l10so346924eei.7 for ; Thu, 12 Sep 2013 23:36:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=xYJu8hBm4pskt+uH0IwwQjQnQt00AWA/B1BXmocKXgc=; b=Q759Z7m+A4+MtONzuGkn+PgsiDDQwm4qDJN0bmNDdO2yDUltbeH8NTZ4GKSz4QKtIo ISVhNSYC+c3U5lTylIPlh4LumleMVw2ByJRBMVehhOfHs7t0S2kkZx+S6LVoJSm6gmy3 fKoXr2vxms9K7sgW/kX1q9JjvcFJYmAg4CC7LJrIXJjDYGtTLhadsBPHQpLWzKm5W3Ka tLNUJ4OwDrvVRGTh0ZrR2uCUGzriU27pWNj4+xHIUlB7LmeCAGN6vKNm0RnD/yNKgrTU SCGpf8+HgARtmrZsosJ/nzP7SBB7GJgLlNiQI2Fdr3n6u1awPT5eUJn3+ygsKopiZj29 /SmQ== X-Gm-Message-State: ALoCoQm5DnTCrqULmSKmJG80ArUjbhuuxb1o1gm9f7kMVufHuqGRQeJmId4U2na2DrADEp9JQ5K4 X-Received: by 10.14.42.3 with SMTP id i3mr55832eeb.95.1379054170738; Thu, 12 Sep 2013 23:36:10 -0700 (PDT) Received: from [109.105.104.183] (dhcp49.se-tug.nordu.net. [109.105.104.183]) by mx.google.com with ESMTPSA id n48sm11919870eeg.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 23:36:09 -0700 (PDT) Message-ID: <5232B258.1070104@mnt.se> Date: Fri, 13 Sep 2013 08:36:08 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: karl m References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> In-Reply-To: <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> Content-Type: multipart/alternative; boundary="------------000705040407030007010309" Cc: "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 06:36:18 -0000 This is a multi-part message in MIME format. --------------000705040407030007010309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/12/2013 08:37 PM, karl m wrote: > Leif, > > I don't own the technical ability to spell out specific changes to the > TLS strong authentication protocol needed to implement the proposed > changes. I've only been exposed to this as a client to a strong > authentication server. > > I had hoped to open a general discussion on the topic of strong > authentication for every connection to every server as a means to > preclude MITM. Do you have any input on that? > Only that the devil is in the details. I think most on this list recognize that "encryption is a problem of turning a hard problem into a hard key management problem" and that your proposal leaves several problems to the imagination of the reader, including how to build a multi-master globally scalable directory of keys and GUIDS. I think that while you try to spell out some of those things, the list can do other things so I re-iterate Stephens point: go write a draft please. Cheers Leif --------------000705040407030007010309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/12/2013 08:37 PM, karl m wrote:
Leif,
 
I don't own the technical ability to spell out specific changes to the TLS strong authentication protocol needed to implement the proposed changes.  I've only been exposed to this as a client to a strong authentication server.
 
I had hoped to open a general discussion on the topic of strong authentication for every connection to every server as a means to preclude MITM.  Do you have any input on that?

Only that the devil is in the details. I think most on this list recognize that "encryption
is a problem of turning a hard problem into a hard key management problem" and
that your proposal leaves several problems to the imagination of the reader, including
how to build a multi-master globally scalable directory of keys and GUIDS.

I think that while you try to spell out some of those things, the list can do other things
so I re-iterate Stephens point: go write a draft please.

        Cheers Leif
--------------000705040407030007010309-- From leifj@mnt.se Thu Sep 12 23:55:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8AC11E8159 for ; Thu, 12 Sep 2013 23:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7Rmm3zjb-VG for ; Thu, 12 Sep 2013 23:55:08 -0700 (PDT) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB3611E8153 for ; Thu, 12 Sep 2013 23:55:08 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id b10so357279eae.38 for ; Thu, 12 Sep 2013 23:55:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7Iq/ZtbpM+hMd7GiATENS4QPq4jq7JLlNEmvm6QspzE=; b=aMMvFaznFzjY5poqKJeX4Uvo9QxsQkkN3tBGCHw50+icd6lKSSLK9qtl1TUTNegUt2 o+GOWZRJe8XptfVpejSIZsQjRGVKH46/GgoxYxvTH13k+zFHjNLHau3HOGP54AE+T9Mh wFWewDX4oJNxe3LAWPpmJLxn8aclJPxwGSgjxgOVt6t0Zd4O0f2duEFwhkJdP7gdRJlj NBGnVWR+tWHTiIhjAJNLre3GGh1T8njajnO4TtaMLurkeCLdm8UJYH7/hpVUQVjls35D 4xbYn+vUvztneZa8NsQlfcWf7ad0FdA6oHlxkMjbzwrTN4mZBTiB8uAGXnD+6sVPth1n v2Uw== X-Gm-Message-State: ALoCoQnsa3L+RKFfq34AgQnEDgw69w7bjymfH29Nju/BORdIbyUJNQzwYDpCgOlK5QIRn4/ZFIb4 X-Received: by 10.15.75.73 with SMTP id k49mr15957222eey.36.1379055302162; Thu, 12 Sep 2013 23:55:02 -0700 (PDT) Received: from [109.105.104.183] (dhcp49.se-tug.nordu.net. [109.105.104.183]) by mx.google.com with ESMTPSA id a1sm12180057eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Sep 2013 23:55:01 -0700 (PDT) Message-ID: <5232B6C4.2050702@mnt.se> Date: Fri, 13 Sep 2013 08:55:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <5232218A.9010704@dcrocker.net> <52328A2C.10805@dcrocker.net> In-Reply-To: <52328A2C.10805@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 06:55:15 -0000 On 09/13/2013 05:44 AM, Dave Crocker wrote: > >>> "privacy properties of IETF protocols and concrete ways in which >>> those could be improved." >> >> to repeat my statement from berlin, privacy by default. and as many >> places as we can enable it. > > > If we -- the IETF community -- had a definition of privacy, that would > help, but we don't. > Its always entertaining to go trolling back to first principles on one of these IETF lists but we've done that before and its typically about as useful as random walks through technology. I hope and suspect some folks are busy working on problem statement drafts already... Personally I'd like to talk about specific proposals to do what Randy just said: more P and by default, whatever your definition of P is. Cheers Leif From hannes.tschofenig@gmx.net Fri Sep 13 00:13:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB2C11E8178 for ; Fri, 13 Sep 2013 00:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUcjjn55jO45 for ; Fri, 13 Sep 2013 00:12:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEC511E816B for ; Fri, 13 Sep 2013 00:12:56 -0700 (PDT) Received: from [10.255.128.165] ([194.251.119.201]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LnPGI-1VrlVA27he-00hg5f for ; Fri, 13 Sep 2013 09:12:46 +0200 Message-ID: <5232BAE4.9040202@gmx.net> Date: Fri, 13 Sep 2013 10:12:36 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> In-Reply-To: <522DB47D.5080400@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:x3kLcpeN4sphtC1xAsA4ieD0WnFtlzOXtSL0Ns1HSAsSLeu6uJU 2XnNvoeW4Uu2vyfPgSW5tGJReVpR/mnRmGonP1nv/KOegkSw3WDMlspy/9Fk3eVPBjD2JSs RdjTjRCDkJOAQsRATzFxx0lbweJgJq7O4vUo3V6nu9xMQmW7shwiJfq1aHlHW06HPVs9+ii BB8nNeU9jbSYaC0jEKQvQ== Cc: Linus Nordberg , perpass@ietf.org Subject: [perpass] Mumble project .... Re: Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 07:13:00 -0000 Hi Linus, now I had the time to look at the Mumble project. I might be incorrect in my assessment. I found some information but it was mostly irrelevant to make a good assessment about the security and privacy properties about it. There seems to be the (wrong) believe that if you publish software as open source then everyone can look at the code and the quality will be good. That's of course not the case. There are a few words here and there about security but I failed to see enough to even give me enough to say something meaningful about it. From what I can tell the software does not interoperate with anything else other than their own silo, which is bad. If you use a provider that runs that VoIP service then you have to trust him like with any other VoIP providers. Of course you can run your own server but then your friends have to be on your own server as well, if I understood it correctly. Maybe that's a great idea that everyone should have their own server and if you want to talk to someone then they create an account at your server and start communicating with you. (You could simplify the account creating by using identity federations, even if they don't have anything to do with VoIP.) Of course, this would be OK with gaming (which seems to be the main target audience of that VoIP platform) but not for normal communication use because it would not be obviously for anyone trying to contact you how to reach you unless you have a permanent VoIP provider. From the point of view what we are trying, namely to develop globally interoperable VoIP solutions, this is obviously a step backwards (maybe 20 years). What is worse, in my point of view, is that adding Tor to Mumble may not actually provide you any additional privacy/security benefits. If you trust the VoIP provider than you could very easily create an end-to-end security solution. Without Tor the other party would most likely still see the IP address of your device (or the IP address of some NAT). That's what Tor (or other tunneling technologies) could hide. The VoIP provider still knows who you are talking with and, depending on how the details look like, he may still be able to decrypt the VoIP communication. Ciao Hannes On 09.09.2013 14:43, Hannes Tschofenig wrote: > Hi Linus, > > thanks for the comments. > > I have indeed skipped that topic. I will have to read into the Mumble > project to see what security and privacy guarantees it provides. > > My current conclusion from using VoIP/IM systems without using Tor is > that you cannot really protect against collecting this transaction data > (i.e., you have to at least trust the two VSPs, our own and then the VSP > of your communication partner). While you can influence routing of the > data traffic to a certain extend it does not work too well when your VSP > is working against you. > > With IM you could at least set up your own server (e.g., by using an > XMPP server) but with VoIP that's more complicated because nobody else > will accepted your connection attempts (as explained in the > interconnection part of my write-up). > > I will come back to you on that issue. > > Ciao > Hannes > > > On 09.09.2013 14:31, Linus Nordberg wrote: >> Hannes Tschofenig wrote >> Mon, 09 Sep 2013 11:26:39 +0300: >> >> | http://www.tschofenig.priv.at/wp/?p=997 >> | >> | It contains a number of recommendations, which are addressed to VoIP >> | providers and vendors but have to be enforced by data protection >> | authorities. >> | >> | The recommendations unfortunately highlight some challenges... >> >> Indeed. And still, I miss any mention on protection against collecting >> data about who's talking to who. >> >> Without claiming any expertise at all in this area, the closest thing to >> something implementing this that I've heard of is Mumble over >> Tor. Mumble [0] is not standardised AFAICT. The Guardian Project wrote >> [1] about this earlier this year. Some people seem to use it [2]. >> >> [0] https://en.wikipedia.org/wiki/Mumble_%28software%29 >> [1] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble >> [2] >> https://guardianproject.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/ >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > From hannes.tschofenig@gmx.net Fri Sep 13 00:21:09 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79A311E8176 for ; Fri, 13 Sep 2013 00:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTu7gK8qykIC for ; Fri, 13 Sep 2013 00:20:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA5921E80F5 for ; Fri, 13 Sep 2013 00:20:53 -0700 (PDT) Received: from [10.255.128.165] ([194.251.119.201]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MY7dI-1VOnWF3EHo-00UrJQ for ; Fri, 13 Sep 2013 09:20:52 +0200 Message-ID: <5232BCC8.2060204@gmx.net> Date: Fri, 13 Sep 2013 10:20:40 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: SM References: <522D863F.10903@gmx.net> <6.2.5.6.2.20130910164150.0cbac7b8@resistor.net> In-Reply-To: <6.2.5.6.2.20130910164150.0cbac7b8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:RhvqfXlxEcHDhe5ApHTgzlXv2hCN0aDASAyiauuAjBPg+vd6Gjj xA3mbMjbdTUZsMOz5V5VKLMK7RFAjeCchKdYagUdWXwRHJJPRT0OpGgP15h17W/6mf2ujhT LvIUIl8bHoOxGJN2vKWHGW8zqAx9lsZqDOtAHSZa/k+f++ptkQR8zdjXzbuYWlKiV+Ij+KV SwcE3BRYvf3uPkXLEpllQ== Cc: perpass@ietf.org, Hannes Tschofenig Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 07:21:09 -0000 There may well be a mismatch between data protection laws and lawful intercept but I think it is outside my realm to solve that problem. On the SIP Identity and 3GPP: To my knowledge the 3GPP IMS does not make use of SIP Identity; it only relies on PAI. On 11.09.2013 02:59, SM wrote: > Hi Hannes, > At 01:26 09-09-2013, Hannes Tschofenig wrote: >> I gave a presentation last week to a group of international data >> protection authorities about VoIP security & privacy. I produced a >> blog post about the presentation and put it here: >> http://www.tschofenig.priv.at/wp/?p=997 >> >> It contains a number of recommendations, which are addressed to VoIP >> providers and vendors but have to be enforced by data protection >> authorities. > > There seems to be an agreement between a country which you can guess and > a country in Europe which bypasses data protection requirements. I did > not verify the information. > > I suggest looking at the 3GPP use-case in respect to SIP identity. > > One of the issues with transparency is that it is overruled by "in > accordance with the law". > > Lawful intercept seems to be quite broad in a country even though the > legislation says otherwise. > > The list of recommendations is a good start. > > Regards, > -sm > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From hannes.tschofenig@gmx.net Fri Sep 13 00:35:57 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4C321E8051 for ; Fri, 13 Sep 2013 00:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ptv18KIdncdb for ; Fri, 13 Sep 2013 00:35:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE0F21F9FD0 for ; Fri, 13 Sep 2013 00:35:48 -0700 (PDT) Received: from [10.255.128.165] ([194.251.119.201]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MAQ0o-1VDHS73YNe-00Bd3g for ; Fri, 13 Sep 2013 09:35:46 +0200 Message-ID: <5232C047.1040607@gmx.net> Date: Fri, 13 Sep 2013 10:35:35 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: perpass , Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:NGJgwAW+IbAZ7mwIzQVw60gaY6Z0hfcqsWKJsL3Iv9/vHRGkoTH 8n/NO8XgScWCmcT/69vTnXO4DJIakuDny/rz0hjjbbax+6Tyi9Teow1TOfwLzvvbRFQcTY4 X28M8RC2HVQNTrHCXagqv7M+8ldWXlLBRh2zF60AJyaXgQedNl5NH/ElLSsJLxQysWTPcwE 4k+whURU/R8Wkn4vJaJvg== Cc: hannes.tschofenig@gmx.net Subject: [perpass] draft-saintandre-xmpp-tls-01 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 07:35:57 -0000 Hi Peter, I am wondering whether it would be possible to link the recommendations between draft-saintandre-xmpp-tls-01 and draft-sheffer-tls-bcp-00 with respect to what it says about TLS. I believe that the TLS recommendations should be generic for the crypto (no RC4, key length, etc.) and don't depend on the specific application that is being protected. Of course you could argue that it makes sense to replicate the text for simpler readability. One other remark about session resumption. There are two versions of session resumption, namely one that is part of the base TLS spec and another one that provides session resumption without server side state. From your text it seems that focus on the latter, which is OK. RFC 5077 already says that you have to encrypt and authenticate the ticket. What can be said in the XMPP context is to implement the recommended format of the ticket to avoid problems with not encrypting the information or not authenticating it. The info is found in Section 4 of RFC 5077. Of course, we could double-check the recommended algorithms for that as well. Ciao Hannes From oej@edvina.net Fri Sep 13 00:37:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C3D11E812C for ; Fri, 13 Sep 2013 00:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBDGwdV9-RV1 for ; Fri, 13 Sep 2013 00:37:06 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id EF98321F9FD0 for ; Fri, 13 Sep 2013 00:36:53 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-126.dynamic.se.alltele.net [87.96.134.126]) by smtp7.webway.se (Postfix) with ESMTPA id D6B8D93C2A1; Fri, 13 Sep 2013 07:36:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <5232BAE4.9040202@gmx.net> Date: Fri, 13 Sep 2013 09:36:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> <5232BAE4.9040202@gmx.net> To: Hannes Tschofenig , perpass@ietf.org X-Mailer: Apple Mail (2.1508) Cc: "Olle E. Johansson" Subject: Re: [perpass] . Re: Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 07:37:07 -0000 Changing subject a little. I've looked at the Tor project and thought about how it would adopt to a = SIP solution. The current network has way too much latency to be useful = for anything else than push-to-talk messages. What is done in Tor (if I understand correctly) is that they adopt three = layers of TLS encryption from the user agent to the exit server - maybe = a fourth to the final service.=20 There's an old draft defining a new method that opens a clear connection = through a proxy, much like websockets, in order to be able to do TLS = peer to peer. This could come in handy. Maybe we could just use the Tor = network Socks interface. So signalling may not be a big problem, but the question is if that = could be done with something like SRTP+DTLS? Would the three layer encryption simply add too much latency to be = useful? /O= From oej@edvina.net Fri Sep 13 00:38:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833A021F9A10 for ; Fri, 13 Sep 2013 00:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoXhKlrWuC-o for ; Fri, 13 Sep 2013 00:38:19 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8B56E21F99EF for ; Fri, 13 Sep 2013 00:38:18 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-126.dynamic.se.alltele.net [87.96.134.126]) by smtp7.webway.se (Postfix) with ESMTPA id B3FFA93C2A1; Fri, 13 Sep 2013 07:38:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_59EDB026-1785-475F-A8E8-BB139C5CDF17" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <5232BCC8.2060204@gmx.net> Date: Fri, 13 Sep 2013 09:38:19 +0200 Message-Id: <7C7A4852-E445-47DC-BCC1-5AF86E863E8B@edvina.net> References: <522D863F.10903@gmx.net> <6.2.5.6.2.20130910164150.0cbac7b8@resistor.net> <5232BCC8.2060204@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Cc: "perpass@ietf.org" , "Olle E. Johansson" Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 07:38:19 -0000 --Apple-Mail=_59EDB026-1785-475F-A8E8-BB139C5CDF17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 13 sep 2013 kl. 09:20 skrev Hannes Tschofenig = : > On the SIP Identity and 3GPP: To my knowledge the 3GPP IMS does not = make use of SIP Identity; it only relies on PAI. And the number of implementations are depressingly low. I've run a half test of SIP Identity at SIPit. The other half failed... /O= --Apple-Mail=_59EDB026-1785-475F-A8E8-BB139C5CDF17 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
13 sep 2013 kl. 09:20 skrev Hannes Tschofenig <hannes.tschofenig@gmx.net>:

On the SIP Identity and 3GPP: To my knowledge the 3GPP IMS does not make use of SIP Identity; it only relies on PAI.

And the number of implementations are depressingly low.

I've run a half test of SIP Identity at SIPit. The other half failed...

/O
--Apple-Mail=_59EDB026-1785-475F-A8E8-BB139C5CDF17-- From acooper@cdt.org Fri Sep 13 01:07:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD2D11E8179 for ; Fri, 13 Sep 2013 01:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.877 X-Spam-Level: X-Spam-Status: No, score=-98.877 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_00=-2.599, GB_SUMOF=5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n02S80WN7tPn for ; Fri, 13 Sep 2013 01:07:00 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id BA39C11E81C5 for ; Fri, 13 Sep 2013 01:06:59 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 13 Sep 2013 04:06:42 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_7558D890-2275-4E05-B49D-FBD364E17763"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Alissa Cooper In-Reply-To: <52328A2C.10805@dcrocker.net> Date: Fri, 13 Sep 2013 04:06:40 -0400 Message-Id: <960DF488-4C8D-450F-BDCD-CBC68060CDF8@cdt.org> References: <5232218A.9010704@dcrocker.net> <52328A2C.10805@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1499) Cc: perpass Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 08:07:04 -0000 --Apple-Mail=_7558D890-2275-4E05-B49D-FBD364E17763 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dave, all, On Sep 12, 2013, at 11:44 PM, Dave Crocker wrote: >=20 >>> "privacy properties of IETF protocols and concrete ways in which >>> those could be improved." >>=20 >> to repeat my statement from berlin, privacy by default. and as many >> places as we can enable it. >=20 >=20 > If we -- the IETF community -- had a definition of privacy, that would = help, but we don't. RFC 6973 contains a rather comprehensive threat model for privacy on the = Internet. It demonstrates that privacy, like "security" and "efficiency" = and most any other design goal, is a complex, multi-faceted concept. I = realize that in the past you have questioned the usefulness of defining = "privacy" via the sum of its properties, but wanted to point it out to = others on this list who are looking for common terminology and threat = descriptions (and mitigations) to use. We need not resort to wikipedia = for definitions. Alissa >=20 > If we knew what it meant to 'enable privacy' (nevermind whether by = default), that would also help, but we don't. >=20 > So the idea of 'privacy by default' well could serve as a useful = catch-phrase, but at the moment, it lacks technical substance. We have = no shared, technical understanding of its meaning. >=20 > No doubt you have particulars in mind. No doubt lots of folks have = their own set of particulars. Unfortunately each person's particulars = tends to be different. >=20 > So what we lack are a) anything like a specific technical meaning for = privacy, b) any system-level sense of what it means to provide privacy, = or c) any prioritization of privacy issues so that we can get the most = benefit from initial efforts. >=20 > My question was meant to prompt discussion at a technical level. = There have been the tiniest wisps of comment on the list that might = provide touchstones for this, but they haven't been pursued. We need to = pursue them. >=20 > Catch-phrases will be useful to summarize the results. >=20 > d/ >=20 >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 --Apple-Mail=_7558D890-2275-4E05-B49D-FBD364E17763 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJSMseQAAoJEIXyHQftqgBQ7WkH/Aw/msBvSktWlDpTtUheLt61 eN2YDXB6Z8Xf6RiHd7e3EL02bltJqhNvYAsfL2GFAiTFzUJ9GxOujj+xfKLpGbZY nb17L/F8sBxquQWNbgjxMClGC0Fiec+28Hfiu9azr1A6Cw38FG0/DW+iY5uVnuFN aEnZENGPedzWBF7O4RfdtKebVx/3A86u5O0T817CScBceb6QVGpmOxKDgQH1UITp ZuAEETVI94/NBXi0972fwg5yloNtFRXHXdHWJWdEPwAJFWGOCQsgc3A+5C0K+eXa JugnLP36u0UuUCmZmaiD3c+Hjz2mWkB1wUVh8OOzBDmGMLxjKe3QH0zWhRf5gw4= =p0De -----END PGP SIGNATURE----- --Apple-Mail=_7558D890-2275-4E05-B49D-FBD364E17763-- From scott.brim@gmail.com Fri Sep 13 02:58:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF0521F9C54 for ; Fri, 13 Sep 2013 02:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4kxCFJJO25v for ; Fri, 13 Sep 2013 02:58:30 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 32F6D21F9C4A for ; Fri, 13 Sep 2013 02:58:30 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id wm4so879211obc.25 for ; Fri, 13 Sep 2013 02:58:29 -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; bh=zvVZpc7Y8v/BeJBI04dY4vLfIBSpY1LuXUw5fCMOIDY=; b=Q4r1zQwgsBrKeaR/qGj8nwym7axx2rB8JeM7OMVUh62hjIdhtgkcoKSSFbASa9mm6f 05ZY0nALWDQJvgAhXloXt+VtQGRxoo/L68ncukSi0MkammdMYfriDhEg7eNSmd1iaqmF 0OTFLIPgMwi9Xoxb0eAXg3+VTUWxBtWDkaSD5YbHJHawwCV3upfn8iTG+0FkNFcsyH9D T7zY6DKq0Q9zOB1IjxA4Qw/zP0DiPA7SMf375eq7VdCAM3lhUs/5q/xHR9a3SLoQvRYR dVJJonWHbFHwhDhkgfXcpi4i4EQXdNcFyMRc3LueTYSTgzlVmeCH/X8XSGo1glPf/gKt n+1w== MIME-Version: 1.0 X-Received: by 10.60.96.131 with SMTP id ds3mr11358978oeb.50.1379066308228; Fri, 13 Sep 2013 02:58:28 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Fri, 13 Sep 2013 02:58:28 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Fri, 13 Sep 2013 02:58:28 -0700 (PDT) In-Reply-To: <960DF488-4C8D-450F-BDCD-CBC68060CDF8@cdt.org> References: <5232218A.9010704@dcrocker.net> <52328A2C.10805@dcrocker.net> <960DF488-4C8D-450F-BDCD-CBC68060CDF8@cdt.org> Date: Fri, 13 Sep 2013 05:58:28 -0400 Message-ID: From: Scott Brim To: Alissa Cooper Content-Type: multipart/alternative; boundary=089e01227b7c6c7ddd04e640e52a Cc: perpass , Dave Crocker Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 09:58:30 -0000 --089e01227b7c6c7ddd04e640e52a Content-Type: text/plain; charset=ISO-8859-1 For me, one focus is on breach of privacy through use of identifiers in scopes with different confidentiality. For example, if you take a VIN (a public identifier mapping from vehicle to owner information, but with no location information) and use it in a global IPv6 address (a public locator that by itself would not be personally identifying) you have crossed scope boundaries and breached privacy. This sort of thing is low hanging fruit in the IETF. It's an issue that can easily be checked, in every WG. This group can provide guidance. Scott --089e01227b7c6c7ddd04e640e52a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

For me, one focus is on breach of privacy through use of ide= ntifiers in scopes with different confidentiality.=A0 For example, if you t= ake a VIN (a public identifier mapping from vehicle to owner information, b= ut with no location information) and use it in a global IPv6 address (a pub= lic locator that by itself would not be personally identifying) you have cr= ossed scope boundaries and breached privacy.=A0 This sort of thing is low h= anging fruit in the IETF. It's an issue that can easily be checked, in = every WG. This group can provide guidance.=A0

Scott

--089e01227b7c6c7ddd04e640e52a-- From jacob@appelbaum.net Fri Sep 13 03:27:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1B221F9FB3 for ; Fri, 13 Sep 2013 03:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4gJWicsCpO2 for ; Fri, 13 Sep 2013 03:27:20 -0700 (PDT) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id B615621F9FAD for ; Fri, 13 Sep 2013 03:27:19 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id d49so476591eek.34 for ; Fri, 13 Sep 2013 03:27:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=aEnLbF8JYFH5WnWcq732d0R/ayGtpENiUjPjGY28Etw=; b=dFekRSFG3b833aL7vPZPBHhp7yN9VeNP7ywiAGz+Rij316wu6GjFIrzHPJM+Ax2JRJ HxTAeksEsHIZrNgraU77YacT/UTBQcv00p7J3mJDzqGtbAwwcjfWE+/JTsPzYuXNZr4q q0yh++8RxPlC84bLylLmFzJMjbxa8VTaCO7Dk2eqkH17BpnE1Ma6MMnKe2L3LLeLWhOC n6XxM/Uqn+MHPzSyA1wXKKx+kMIYhmgE5yQmEultZyFnVN8HczQOb2FL/9DTS4koB9vm GethBbseA2Oj7zROvMzdd2WalGKwm6rr8vIJVYcEYNwSMyeVBAlu+tzN3bB/UjsYPhFh 6hhA== X-Gm-Message-State: ALoCoQl8Wx+T2Ihc/1X7NE9j0Zmhu6nQu9UAsjHkxHaXX3RYwIJ/6CPkt7gad8CPuE5S/hTq0QLb X-Received: by 10.15.99.72 with SMTP id bk48mr17435477eeb.22.1379068038736; Fri, 13 Sep 2013 03:27:18 -0700 (PDT) Received: from 127.0.0.1 (tor21.anonymizer.ccc.de. [31.172.30.4]) by mx.google.com with ESMTPSA id b45sm13638811eef.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 03:27:17 -0700 (PDT) Message-ID: <5232D366.1000803@appelbaum.net> Date: Fri, 13 Sep 2013 08:57:10 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Theodore Ts'o References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> <20130910185544.GF29237@thunk.org> In-Reply-To: <20130910185544.GF29237@thunk.org> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Hannes Tschofenig , Dean Willis Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 10:27:25 -0000 Theodore Ts'o: > On Tue, Sep 10, 2013 at 09:43:39PM +0300, Hannes Tschofenig wrote: >> >>> 1) Everything SHOULD be encrypted, unless there is an absolute >> operational requirement not to. This means "encryption by default" >> in new protocols, and not even specifying unencrypted operations >> modes unless necessary.... >> >> I guess there are two issues here, namely: >> >> * End-to-end vs. Hop-by-hop (or stuff in between) >> >> * Encryption itself is often not the problem but rather the key management > > Also, perfect forward secrecy (PFS) versus non-PFS. If we are going > to make encryption a SHOULD or a MUST, so should be PFS. Even if the > key management is a problem, or worse, let's suppose the NSA has the > private keys for a number of the major CA's, if everything is using > PFS, then an attacker who is interested in doing bulk surveillance > will have to MITM all of the traffic. That will take a large amount > of power and cooling, so it becomes a lot more expensive to do bulk > surveillance, and it will also be much, MUCH harder to do it covertly > (you can't just hide a box in a telephone closet somewhere; but rather > racks and racks of servers at Tier 1 NAP's will be required). > I completely agree. I think that MUST is a reasonable requirement for core internet protocols. > OF course, there will be some things where encryption is simply not > needed, and but data integrity is is needed. Example: time (NTP) and > routing protocols. So we need to be careful how we specify MUST. :-) > I think this is a reasonable read but I'd like to encourage dissent here. Time is a very important part of almost all cryptographic protocols - if an attacker is able to distinguish queries about time from other queries, it allows the attacker to discriminate and thus to tamper with time related protocols. This is especially true when the system in question may not have a properly sync'ed clock. I hacked together a solution for network time that gives most of these properties - tlsdate ( https://github.com/ioerror/tlsdate/ ) - and it is used by ChromeOS rather than using the traditional NTP protocol. It has some downsides (32bit time rather than 64bit time resolution) but overall, it allows for all of the properties of TLS without any of the weird downsides of the ancient NTP protocol, of which there are many... As an example - DNSSEC requires a sync'ed clock and in theory, one argument goes: no one needs query privacy in DNSSEC, after all, one just connects directly so an attacker will learn what you learned anyway, right? However, one needs query privacy to ensure that an attacker cannot tell that your DNSSEC client is currently trying to learn the time, thus all other queries are vulnerable to a replay attack or worse. So really, query privacy, even for data that appears to only need integrity is really essential. Give the attackers nothing for free - make them tamper to get even a single bit of information more. This gives us agency to detect and to take counter actions. All the best, Jacob From stephen.farrell@cs.tcd.ie Fri Sep 13 04:44:34 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D7911E81D7 for ; Fri, 13 Sep 2013 04:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzPrlvmz7OMz for ; Fri, 13 Sep 2013 04:44:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0106811E81A1 for ; Fri, 13 Sep 2013 04:44:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0C878BEB0; Fri, 13 Sep 2013 12:44:09 +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 0Bnn8McQTN6P; Fri, 13 Sep 2013 12:44:08 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.19.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 093B6BE39; Fri, 13 Sep 2013 12:44:08 +0100 (IST) Message-ID: <5232FA7D.4030409@cs.tcd.ie> Date: Fri, 13 Sep 2013 12:43:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Leif Johansson References: <5232218A.9010704@dcrocker.net> <52328A2C.10805@dcrocker.net> <5232B6C4.2050702@mnt.se> In-Reply-To: <5232B6C4.2050702@mnt.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 11:44:34 -0000 Hiya, On 09/13/2013 07:55 AM, Leif Johansson wrote: >> > >> > If we -- the IETF community -- had a definition of privacy, that would >> > help, but we don't. >> > > Its always entertaining to go trolling back to first principles on one of > these IETF lists but we've done that before and its typically about as > useful as random walks through technology. Well, to be fair to Dave, I don't think he's trolling. We're seeing a bunch of proposals for things to do on this list and that's great - keep 'em coming; write I-Ds, we can figure out how to handle 'em etc. That's all good. But, where I think Dave is right is that we don't have an overview, so its possible that some effort we devote here could be wasted if we miss something important. So, while I definitely do not want to see us go into an analytic paralysis, I do think some higher level consideration would be good in addition to the specific proposals we need to get. > > I hope and suspect some folks are busy working on problem statement > drafts already... Great! If folks are doing that, I'd appreciate a heads-up offlist, just so's we have a chance to avoid some duplication. That's not required though - work away quietly if you prefer until you're ready. S. From stephen.farrell@cs.tcd.ie Fri Sep 13 05:18:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6D511E8186 for ; Fri, 13 Sep 2013 05:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5VGtHVf620v for ; Fri, 13 Sep 2013 05:17:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A055A11E80F7 for ; Fri, 13 Sep 2013 05:17:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2A170BEAF; Fri, 13 Sep 2013 13:17:54 +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 c6zdQUfdr4CF; Fri, 13 Sep 2013 13:17:51 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.19.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3ACDFBE98; Fri, 13 Sep 2013 13:17:51 +0100 (IST) Message-ID: <52330265.9020709@cs.tcd.ie> Date: Fri, 13 Sep 2013 13:17:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Patrick Pelletier References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> In-Reply-To: <52328288.6070806@funwithsoftware.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 12:18:01 -0000 On 09/13/2013 04:12 AM, Patrick Pelletier wrote: > On 9/12/13 1:18 PM, Dave Crocker wrote: > >> "privacy properties of IETF protocols and concrete ways in which >> those could be improved." > > One obvious thing is the amount of (usually unnecessary) information > leaked by the User-Agent field in HTTP. > > Should we downgrade the User-Agent field (section 14.43 of RFC 2616) > from a SHOULD to a MAY? I think everyone finds those values problematic, and not only for privacy reasons. But yes, if you believe [1] then its probably the biggest contributor to browser fingerprinting that's in an IETF spec. (No idea if that site's evaluation is sound myself though.) [1] https://panopticlick.eff.org/ > Or, if that's too radical, should we standardize a small number of fixed > strings to use in the User-Agent field? (For example, "Desktop/1.0" for > desktop browsers, "Mobile/1.0" for mobile browsers, "Text/1.0" for text > browsers like Lynx, "Batch/1.0" for non-interactive clients like curl > which are performing a task more specific than crawling the web, and > "Robot/1.0" for clients which are crawling the web?) Interesting. An IANA registry of those kinds of value might just end up like the UA string though, which also started out nice and simple. Maybe ask this on httpbis if you don't get more feedback here? That's where you'd find folks who know if it could be done and who could do it. S. > > --Patrick > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Fri Sep 13 05:37:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2298111E81FE for ; Fri, 13 Sep 2013 05:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taPjB-JXoT8P for ; Fri, 13 Sep 2013 05:37:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3911E81FD for ; Fri, 13 Sep 2013 05:37:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 92C1ABEBF; Fri, 13 Sep 2013 13:37: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 QQPByTNuViB7; Fri, 13 Sep 2013 13:37:38 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.19.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 98792BEA1; Fri, 13 Sep 2013 13:37:38 +0100 (IST) Message-ID: <52330712.8060104@cs.tcd.ie> Date: Fri, 13 Sep 2013 13:37:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Moritz Bartl References: <52329A7A.7060103@headstrong.de> In-Reply-To: <52329A7A.7060103@headstrong.de> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 12:37:52 -0000 On 09/13/2013 05:54 AM, Moritz Bartl wrote: > Hi, > > I would very much like to see servers having a minimal logging policy by > default, especially and at least when it comes to IP addresses. I wonder > if RFC 6302 is the right document to look at or extend for this. Or obsolete it. > > It is easy to flip a switch to enable IP logging. The default should be > no IP logs, which is true for most XMPP servers, for example, but not > for web or mail servers. The wonderfully ironically named PRISM [1] project was an EU funded project that did some work on obfuscating IP addresses in logs. I'd love to see an RFC that described such techniques and recommended when to use what, so we could point people at that. Any takers for a -00 to get that going? S. [1] http://www.fp7-prism.eu/ > > On a side node, can we do anything to get rid of sender IP addresses in > (the first) Received headers of mail? > > -- Moritz > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From hadriel.kaplan@oracle.com Fri Sep 13 05:52:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E1511E80F7 for ; Fri, 13 Sep 2013 05:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIxvOLDs83oy for ; Fri, 13 Sep 2013 05:52:43 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7B221F9F2B for ; Fri, 13 Sep 2013 05:52:43 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8DCqdOn015366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Sep 2013 12:52:40 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8DCqcjW014594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 12:52:38 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8DCqbdZ026495; Fri, 13 Sep 2013 12:52:37 GMT Received: from [10.36.80.180] (/69.241.19.12) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 13 Sep 2013 05:52:37 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5232BCC8.2060204@gmx.net> Date: Fri, 13 Sep 2013 08:52:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <00D0FAC3-B325-491F-A2FA-46C1023DFB5C@oracle.com> References: <522D863F.10903@gmx.net> <6.2.5.6.2.20130910164150.0cbac7b8@resistor.net> <5232BCC8.2060204@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: SM , perpass@ietf.org Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 12:52:50 -0000 If by "SIP Identity" you mean RFC 4474, it's not deployable as I think = you know; and even were it deployed it wouldn't actually provide = identity for E.164's which are the most common form of identifier for = SIP deployments (including 3gpp ones); nor does it provide any = new/additional privacy benefits afaik. Essentially the RFC was dead on = arrival, and we all knew it. -hadriel On Sep 13, 2013, at 3:20 AM, Hannes Tschofenig = wrote: > There may well be a mismatch between data protection laws and lawful = intercept but I think it is outside my realm to solve that problem. >=20 > On the SIP Identity and 3GPP: To my knowledge the 3GPP IMS does not = make use of SIP Identity; it only relies on PAI. From leifj@mnt.se Fri Sep 13 06:08:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3949D21E80A6 for ; Fri, 13 Sep 2013 06:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hG-imtca+AD for ; Fri, 13 Sep 2013 06:08:04 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id 229A721E80A1 for ; Fri, 13 Sep 2013 06:08:03 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hj3so978863wib.2 for ; Fri, 13 Sep 2013 06:08:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ly5fFAGpykQJEIPG3WFzTeSwk4jwPcaL2INynSHaR0w=; b=faGw5UtD+Tjm+KxDYA4z09qv8Fv+jBA7/7y4CaH3f4XkJ9GvoAPF29UmR73FWAWAgz HQWYQVCJRQa/jaawcylo8BzafFb0bGfQXIMz8yXJdxxK24uAyjcUTsOTHw2vdZs3lPy5 yb59dq9zax7kIoBdaJFXXmNiS6BfUynOwPGHGYWq2gEG/D0uvfbKBe7XLcbDyv1meUnm c7sbrKNM7IWrVUeyVb4QlhMM28QPCjEFGoOOxOA9a1sMru1XOPNtGYhDXWGdZPiI6off eS7kk9GPsTM40vs5BnorZGFgwnjWczw8sFacNjuO1jdzYSdt3oDdAf7XKD7EL1v3nAjD iOPw== X-Gm-Message-State: ALoCoQkqXjh9FKBB+72HRBBsqEQPh9laTw2r8uKX13YtGB/nxaIjELTd5aOLE2UaneAtv+3jM5vH X-Received: by 10.194.249.97 with SMTP id yt1mr1460432wjc.49.1379077683186; Fri, 13 Sep 2013 06:08:03 -0700 (PDT) Received: from [109.105.104.183] (dhcp49.se-tug.nordu.net. [109.105.104.183]) by mx.google.com with ESMTPSA id e5sm3456021wiy.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 06:08:02 -0700 (PDT) Message-ID: <52330E30.2000904@mnt.se> Date: Fri, 13 Sep 2013 15:08:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <5232218A.9010704@dcrocker.net> <52328A2C.10805@dcrocker.net> <5232B6C4.2050702@mnt.se> <5232FA7D.4030409@cs.tcd.ie> In-Reply-To: <5232FA7D.4030409@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] What problems does perpass need to solve? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:08:10 -0000 On 09/13/2013 01:43 PM, Stephen Farrell wrote: > Hiya, > > On 09/13/2013 07:55 AM, Leif Johansson wrote: >>>> If we -- the IETF community -- had a definition of privacy, that would >>>> help, but we don't. >>>> >> Its always entertaining to go trolling back to first principles on one of >> these IETF lists but we've done that before and its typically about as >> useful as random walks through technology. > Well, to be fair to Dave, I don't think he's trolling. Fair enough - bad choice or words. I blame my non-native English. > We're seeing a bunch of proposals for things to do on this > list and that's great - keep 'em coming; write I-Ds, we can > figure out how to handle 'em etc. That's all good. > > But, where I think Dave is right is that we don't have an > overview, so its possible that some effort we devote here could > be wasted if we miss something important. I'd rather miss something than spend days talking about things like "what is identity" or "what is privacy". > > So, while I definitely do not want to see us go into an > analytic paralysis, I do think some higher level consideration > would be good in addition to the specific proposals we need > to get. Agree. > >> I hope and suspect some folks are busy working on problem statement >> drafts already... > Great! If folks are doing that, I'd appreciate a heads-up > offlist, just so's we have a chance to avoid some duplication. > That's not required though - work away quietly if you prefer > until you're ready. > > S. > > From dean.willis@softarmor.com Fri Sep 13 06:59:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4225311E8212 for ; Fri, 13 Sep 2013 06:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.144 X-Spam-Level: X-Spam-Status: No, score=-101.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AohFJsnATaP5 for ; Fri, 13 Sep 2013 06:59:00 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 89A7621F9FD6 for ; Fri, 13 Sep 2013 06:59:00 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so1000529veb.12 for ; Fri, 13 Sep 2013 06:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iCYM5q0NkVGCGwq8zx66d3m5X2CGNaey1PoLRv1HYms=; b=UIRIqMkH6SB1PNgRYPsebp4C1l9p/dOrENlnrE/5sgvUCsu+4QjAzVYRZ8mdmk1V1/ ZhainJmtoXQCazmIiMynUCLZokz0tZJQKjGZqYUAjQpnp1Xedl+v3PaiunRNanEMbshE LxEGKcaE9cNYaFyWsob9coB5/rqHt7Sdd1pQ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iCYM5q0NkVGCGwq8zx66d3m5X2CGNaey1PoLRv1HYms=; b=QaeTrbrQWLjmzHdKMgYX+fpprhyJtqBv4kRqlnX0r8zd/X1uIXaYM0mMJ/sGmun0jL o/GH0Htf5S/UyzpF6Xj4KWSgU1GHwnapSVTFFP3BEqAutAN2Ra37AdXQi0AichH9eHTl V3NzC/EuMUl6cbv71Jsq/u36DA3g8Yk8uTUhQw/k1nIxwk8FaC2eV0OpG+EyA+5GvwMO y//65M9WDqMttBWum/d8BOg64rfICC9rVIMU0edKGZpy1Td7TfRYaS77NspdJLLxf92Q vRWoOJQqoOr3FhD/w4kS2v/PmxZpN+weasnBQnRrGrZbAtZEfWU7axbSN+wEPVucIjLZ jfJQ== X-Gm-Message-State: ALoCoQkBmgEvEk8506GBHgrDZNjt4+CD16hIVhUrrSaMQkg4qOh06hG7FLFfA2fFMdJyVdfIGEoU MIME-Version: 1.0 X-Received: by 10.58.19.233 with SMTP id i9mr213408vee.36.1379080738920; Fri, 13 Sep 2013 06:58:58 -0700 (PDT) Received: by 10.58.168.180 with HTTP; Fri, 13 Sep 2013 06:58:58 -0700 (PDT) Received: by 10.58.168.180 with HTTP; Fri, 13 Sep 2013 06:58:58 -0700 (PDT) In-Reply-To: <5231A515.7070007@gmx.net> References: <522D863F.10903@gmx.net> <87ioyaz0xg.fsf@nordberg.se> <522DB47D.5080400@gmx.net> <5231A515.7070007@gmx.net> Date: Fri, 13 Sep 2013 08:58:58 -0500 Message-ID: From: Dean Willis To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7b86c5ca8f6deb04e6444177 Cc: perpass@ietf.org Subject: Re: [perpass] Securing VoIP in the Presence of Pervasive Monitoring X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:59:02 -0000 --047d7b86c5ca8f6deb04e6444177 Content-Type: text/plain; charset=ISO-8859-1 I and several others are still working at it and making good progress. I'm currently researching storage over RELOAD. There are some ways around the credentialing issues for pseudonymous modes that preserve the useful property of "this identity owns that data" without making strong assertions about the identity. It's also workable with client-generated certs or even pgp keys. Any extension of trust between identities can be handled by out-of-band fingerprint verification, as in PGP and zRTP. One could certainly use RELOAD as a messaging substrate without much work. On Sep 12, 2013 6:27 AM, "Hannes Tschofenig" wrote: > Hi Dean, > > I may not be up to speed with RELOAD but I understood that all the energy > has vanished from that work. There were also a number of technical problems. > > Maybe someone can give us a brief update on the status. > > Ciao > Hannes > > On 09.09.2013 17:46, Dean Willis wrote: > >> I think we can mostly get there with RELOAD, but the implementations are >> still pretty early. >> >> On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" > >> wrote: >> >> Hi Linus, >> >> thanks for the comments. >> >> I have indeed skipped that topic. I will have to read into the >> Mumble project to see what security and privacy guarantees it >> provides. >> >> My current conclusion from using VoIP/IM systems without using Tor >> is that you cannot really protect against collecting this >> transaction data (i.e., you have to at least trust the two VSPs, our >> own and then the VSP of your communication partner). While you can >> influence routing of the data traffic to a certain extend it does >> not work too well when your VSP is working against you. >> >> With IM you could at least set up your own server (e.g., by using an >> XMPP server) but with VoIP that's more complicated because nobody >> else will accepted your connection attempts (as explained in the >> interconnection part of my write-up). >> >> I will come back to you on that issue. >> >> Ciao >> Hannes >> >> >> On 09.09.2013 14:31, Linus Nordberg wrote: >> >> Hannes Tschofenig> >> >> wrote >> Mon, 09 Sep 2013 11:26:39 +0300: >> >> | http://www.tschofenig.priv.at/**__wp/?p=997 >> >> > >> | >> | It contains a number of recommendations, which are addressed >> to VoIP >> | providers and vendors but have to be enforced by data protection >> | authorities. >> | >> | The recommendations unfortunately highlight some challenges... >> >> Indeed. And still, I miss any mention on protection against >> collecting >> data about who's talking to who. >> >> Without claiming any expertise at all in this area, the closest >> thing to >> something implementing this that I've heard of is Mumble over >> Tor. Mumble [0] is not standardised AFAICT. The Guardian Project >> wrote >> [1] about this earlier this year. Some people seem to use it [2]. >> >> [0] https://en.wikipedia.org/wiki/**__Mumble_%28software%29 >> >> > >> [1] >> https://trac.torproject.org/__**projects/tor/wiki/doc/__** >> TorifyHOWTO/Mumble >> > TorifyHOWTO/Mumble >> > >> [2] >> https://guardianproject.info/_**_2013/01/31/anonymous-cb-** >> radio-__with-mumble-and-tor/ >> > with-mumble-and-tor/ >> > >> ______________________________**___________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/perpass >> >> > >> >> >> ______________________________**___________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/perpass >> >> > >> >> > --047d7b86c5ca8f6deb04e6444177 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I and several others are still working at it and making good= progress. I'm currently researching storage over RELOAD.

There are some ways around the credentialing issues for pseu= donymous modes that preserve the useful property of "this identity own= s that data" without making strong assertions about the identity. It&#= 39;s also workable with client-generated certs or even pgp keys. Any extens= ion of trust between identities can be handled by out-of-band fingerprint v= erification, as in PGP and zRTP.

One could certainly use RELOAD as a messaging substrate with= out much work.

On Sep 12, 2013 6:27 AM, "Hannes Tschofenig= " <hannes.tschofenig@g= mx.net> wrote:
I think we can mostly get there with RELOAD, but the implementations are still pretty early.

On Sep 9, 2013 6:53 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net=
<mailto:h= annes.tschofenig@gmx.net>> wrote:

=A0 =A0 Hi Linus,

=A0 =A0 thanks for the comments.

=A0 =A0 I have indeed skipped that topic. I will have to read into the
=A0 =A0 Mumble project to see what security and privacy guarantees it provi= des.

=A0 =A0 My current conclusion from using VoIP/IM systems without using Tor<= br> =A0 =A0 is that you cannot really protect against collecting this
=A0 =A0 transaction data (i.e., you have to at least trust the two VSPs, ou= r
=A0 =A0 own and then the VSP of your communication partner). While you can<= br> =A0 =A0 influence routing of the data traffic to a certain extend it does =A0 =A0 not work too well when your VSP is working against you.

=A0 =A0 With IM you could at least set up your own server (e.g., by using a= n
=A0 =A0 XMPP server) but with VoIP that's more complicated because nobo= dy
=A0 =A0 else will accepted your connection attempts (as explained in the =A0 =A0 interconnection part of my write-up).

=A0 =A0 I will come back to you on that issue.

=A0 =A0 Ciao
=A0 =A0 Hannes


=A0 =A0 On 09.09.2013 14:31, Linus Nordberg wrote:

=A0 =A0 =A0 =A0 Hannes Tschofenig<hannes.tschofenig@__gmx.net
=A0 =A0 =A0 =A0 <mailto:hannes.tschofenig@gmx.net>> =A0wrote
=A0 =A0 =A0 =A0 Mon, 09 Sep 2013 11:26:39 +0300:

=A0 =A0 =A0 =A0 | http://www.tschofenig.priv.at/__wp/?p=3D997
=A0 =A0 =A0 =A0 <http://www.tschofenig.priv.at/wp/?p=3D997> =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 | It contains a number of recommendations, which are addres= sed
=A0 =A0 =A0 =A0 to VoIP
=A0 =A0 =A0 =A0 | providers and vendors but have to be enforced by data pro= tection
=A0 =A0 =A0 =A0 | authorities.
=A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 | The recommendations unfortunately highlight some challeng= es...

=A0 =A0 =A0 =A0 Indeed. And still, I miss any mention on protection against=
=A0 =A0 =A0 =A0 collecting
=A0 =A0 =A0 =A0 data about who's talking to who.

=A0 =A0 =A0 =A0 Without claiming any expertise at all in this area, the clo= sest
=A0 =A0 =A0 =A0 thing to
=A0 =A0 =A0 =A0 something implementing this that I've heard of is Mumbl= e over
=A0 =A0 =A0 =A0 Tor. Mumble [0] is not standardised AFAICT. The Guardian Pr= oject
=A0 =A0 =A0 =A0 wrote
=A0 =A0 =A0 =A0 [1] about this earlier this year. Some people seem to use i= t [2].

=A0 =A0 =A0 =A0 [0] https://en.wikipedia.org/wiki/__Mumble_= %28software%29
=A0 =A0 =A0 =A0 <https://en.wikipedia.org/wiki/Mumble_%28s= oftware%29>
=A0 =A0 =A0 =A0 [1]
=A0 =A0 =A0 =A0 https://trac.torproject.org/__<= u>projects/tor/wiki/doc/__TorifyHOWTO/Mumble
=A0 =A0 =A0 =A0 <https://trac.torproject.org/= projects/tor/wiki/doc/TorifyHOWTO/Mumble>
=A0 =A0 =A0 =A0 [2]
=A0 =A0 =A0 =A0 https://guardianproj= ect.info/__2013/01/31/anonymous-cb-radio-__with-mumble-and-to= r/
=A0 =A0 =A0 =A0 <https://guardianproj= ect.info/2013/01/31/anonymous-cb-radio-with-mumble-and-tor/>
=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 perpass mailing list
=A0 =A0 =A0 =A0 perpa= ss@ietf.org <mailto:perpass@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/perpass
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/perpass>


=A0 =A0 _________________________________________________
=A0 =A0 perpass mailing list
=A0 =A0 perpass@ietf.= org <mailto:pe= rpass@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/perpass
=A0 =A0 <https://www.ietf.org/mailman/listinfo/perpass>

--047d7b86c5ca8f6deb04e6444177-- From dean.willis@softarmor.com Fri Sep 13 09:27:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA8E21E80B7 for ; Fri, 13 Sep 2013 09:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.013 X-Spam-Level: X-Spam-Status: No, score=-102.013 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0Z1H8Kw9DGB for ; Fri, 13 Sep 2013 09:27:55 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 168CD21E80F1 for ; Fri, 13 Sep 2013 09:27:44 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id n12so1383494oag.1 for ; Fri, 13 Sep 2013 09:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=CEburxc4Cfwh+ycvTKZSbefw+GjGZEc8StOWuKfVvxg=; b=hengNfFnlB1C+7SL/ft7FMbHuYEUlWg+skiVxQVSRLjrYs2+3lPgDuyDGMwn9IDl5c Vq4byzDH2sDSdf0crUraRJYs+/PPTWt60b3P0oSYWw0nnI8M7LjA5mVQowjZ8+PjFUTa /TKpo1tW6s+GKnt33KoV2UsI0L8zFI40gDeks= 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:message-id:references:to; bh=CEburxc4Cfwh+ycvTKZSbefw+GjGZEc8StOWuKfVvxg=; b=Yi5Qu/ffmWFYaHRdC1+jEf0qNPBq5TfGILSGk47SvHapmAIFuTTEedRW9OMWCbvN3a c8nfQhwKajP5vjs59c9uhQpwfMvFapmmO7ckg0Z98Hdn+7eMsK/5nkjx7ZNTQ7GVA1bw nyRxby0CkxFFBU1bhb3zyOwevydxxIZnODYFhRzTgzYlfSrZXkMC3C56pp8yxSTJLUkc CNrdMDyOz+VGxDDT9nY/yk2WVvHxAmbOHZY3gfx9NVbvV5RAeb0U+ALjdvkNzfTlsdzn MAFp03P/mRaan7P96k7dMJlAiaimzdkrqh7SACFaOHPy1brX9ldfHjVWc6h6bPMd2bvS +Xuw== X-Gm-Message-State: ALoCoQmJ4tAFvruJrv2rl7WF94WS773/EmGj4wkfVjwhUwCFz8iRy4mdZKevnu0HO0h0ZHeOBBTi X-Received: by 10.182.130.131 with SMTP id oe3mr13030431obb.34.1379089664463; Fri, 13 Sep 2013 09:27:44 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id tz10sm14990597obc.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 09:27:43 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_BCC58AB8-F368-4B7A-9569-6188163E587D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: <5232D366.1000803@appelbaum.net> Date: Fri, 13 Sep 2013 11:27:42 -0500 Message-Id: <862382F3-A1D4-4AE2-94ED-D9D96B1D6805@softarmor.com> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> <20130910185544.GF29237@thunk.org> <5232D366.1000803@appelbaum.net> To: Jacob Appelbaum X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org, Hannes Tschofenig , Theodore Ts'o Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:27:55 -0000 --Apple-Mail=_BCC58AB8-F368-4B7A-9569-6188163E587D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 13, 2013, at 3:57 AM, Jacob Appelbaum = wrote: >>=20 > I think this is a reasonable read but I'd like to encourage dissent > here. Time is a very important part of almost all cryptographic > protocols - if an attacker is able to distinguish queries about time > from other queries, it allows the attacker to discriminate and thus to > tamper with time related protocols. This is especially true when the > system in question may not have a properly sync'ed clock. I concur. Unless you have a VERY hard reason NOT to encrypt, then = encrypt. Even if it does nothing for you, it helps mask other encrypted = traffic. -- Dean --Apple-Mail=_BCC58AB8-F368-4B7A-9569-6188163E587D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSMzz+AAoJENG95ttGtcqrfx0P/2hu4G66REQFyTtvboohIn1P ZFEOVfhGVLllTf1D0Au5qqs1FlzWasRQRpWQVIa6Qn6F3CmG5KtWUxMj/Lq4ppvQ wbUblO/Hr2OEw4PZGzb3ZqbpM21W+E2BQVPXfD8dBjl6psrA4QuD/P0zOj/2pshd 9OIZ0yiPwEib72clJ2I23pxRMJl5gNXYX315Yqdf8CMFLcDSEencfrJIA3thNdDL 6ZGhncwURLcNZEOOD1B6vI9oyrewOpj3QvII8HzA4AIkQ85nf5fWta3FigksadTw 3q3Pa5G7PIldrIfnfXm5chzNkxtj3CQoUofaPAv2Jytirno80dk0xym5l99ycv3z E9CkiPPAoPODiE4rDDf9IJoAVUxSNdqHdJg7ATqJa6+Xv7ZkBNlkJBj0tvgTuBdz EU7Ci0u2Idrr3FzG2RJPdsa+ydq00qQw6ZCmu+h1u0p1McDNKZzCMSwoL6EsLxev mx2DndfYTxSvNe1O8NBkgkBWdwwTBZI8/EvxqEoy7u1TIvvdPOs0Z6wW9ct52m9d oPqDng3TsVxUelxGlik4sBssRmoz+J4EUpAimMMIDgxhpUaDQt9JaqaVX0UIUw2b r3D8ddwRggr02q1LIp31zm84TR7XDmcKlWpsjgKOvNcNdfR7UW+bK+E7TbL46hSR LEzl2XK4/99Bhctqd6gb =jEp5 -----END PGP SIGNATURE----- --Apple-Mail=_BCC58AB8-F368-4B7A-9569-6188163E587D-- From dean.willis@softarmor.com Fri Sep 13 09:29:09 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA5421E80E8 for ; Fri, 13 Sep 2013 09:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.01 X-Spam-Level: X-Spam-Status: No, score=-102.01 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWRljv+VLZJ3 for ; Fri, 13 Sep 2013 09:29:08 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 229AF21E80AE for ; Fri, 13 Sep 2013 09:28:58 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id gq1so1319301obb.12 for ; Fri, 13 Sep 2013 09:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lGJ5V50InJYKLAHhSl+koymis8kOTbwU1jBu2W4q6aE=; b=bjE+q8Yy0yFGMEvI/9+wN1G1hVhHrcuNg1Gc0gegkDvfq3yoEEECBUAZOvAUfgKqmv cU25h1AAujVeDqAV5jv83y7NkUSTuuTb7EU3k+z2rg/95u1xzhfCzeUWpW+Pq5U6xRca 2GCdruSy76qxdOIwM6lT8g5EZLdbkJUQ4ZoDk= 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:message-id:references:to; bh=lGJ5V50InJYKLAHhSl+koymis8kOTbwU1jBu2W4q6aE=; b=FuE3a8Ut2Wtri6UN90TRPuDccmuBcrIsaa9xjTjsFDIYqd5kKjpcHnBeaas0YrhxB9 AT7Og7kIm0V0YZmLis9uMsp7B3KW0YarOKXAngpdKS8usdtwkYm//7yo/py9cYcz8zaF J/2dbOog5e2e9ADTNlzyIq8G5S1gVRD9KzJDH64x8ipCf4Wg9tmDFAvIFRNDk7I+mu2x Jlx9usMonI7opFNHDpB+xoUsf2qDMcIS0dTHWRKtg7JR9EtYaAzsGZbauGyboNdqg8n9 w54XUQH2evgl7rTyCGwtScL4f8PW7Jm167QiFUniGrFzfhbQH3+6pRDF4yRWfkV77w7m wzdA== X-Gm-Message-State: ALoCoQmuBRKVHl+AP2+Utf5YiCXl+eEeJDjZZW9fN6m2RAWJ/tQkgRUjr/VsFgi4GFBFM/mmPo39 X-Received: by 10.182.242.37 with SMTP id wn5mr13017096obc.56.1379089737684; Fri, 13 Sep 2013 09:28:57 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id hl3sm14985900obb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 09:28:57 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FD29B929-CC83-4158-92EC-E5EFF8C3F362"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: <20130910185544.GF29237@thunk.org> Date: Fri, 13 Sep 2013 11:28:55 -0500 Message-Id: <6014FAD0-A423-4DC1-9F3D-4D407F7F74A8@softarmor.com> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> <20130910185544.GF29237@thunk.org> To: Theodore Ts'o X-Mailer: Apple Mail (2.1508) Cc: "perpass@ietf.org" Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:29:09 -0000 --Apple-Mail=_FD29B929-CC83-4158-92EC-E5EFF8C3F362 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Sep 10, 2013, at 1:55 PM, Theodore Ts'o wrote: > > Also, perfect forward secrecy (PFS) versus non-PFS. If we are going > to make encryption a SHOULD or a MUST, so should be PFS. Even if the > key management is a problem, or worse, let's suppose the NSA has the > private keys for a number of the major CA's, if everything is using > PFS, then an attacker who is interested in doing bulk surveillance > will have to MITM all of the traffic. That will take a large amount > of power and cooling, so it becomes a lot more expensive to do bulk > surveillance, and it will also be much, MUCH harder to do it covertly > (you can't just hide a box in a telephone closet somewhere; but rather > racks and racks of servers at Tier 1 NAP's will be required). Sounds reasonable. -- Dean --Apple-Mail=_FD29B929-CC83-4158-92EC-E5EFF8C3F362 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSMz1IAAoJENG95ttGtcqra60QAKbJqMI9PbrdUcJKriQOs9eD 4lx+NVbC8zmp3B23zdXl3UzP2AhwKotGm2irAu83kHCGOJXb3LkHRshB435gNBAl tK3cTPHBpxBVlNp3v7kY/1IsOK6Kqs0Ofqbtct7pEcfK1jO+okj5Trm4SewluK7N W+NROABeS9n1lhSyf5DkEkqCht+g3wK35ZLucp1VGSWHChEg0phcucd/02NIW6ca R5yKy1hFh8JnPs39phC92QcLg+cFArd/5cW5CL0T6B2LExDI7GhZOaW/QFEMpTUY 1wZvdUO541GperiHAcON+L//98djtl8Os0qyyzx3A7FOgFwXBdQwGWPXUr7FIPM1 QyG/2RtNHsNIiQDmSjwssOUKuRNgQhfU1z5bqr1h86HPPX1fEEasjw6s5cuntsB6 dBC8L+U3EasBt4WPbBrUV9KZvEpn+P+bihbIO5foGRarRCb0e39+jPeldaX/s9FK bs0+N+Elcx5zSne1GkR+uEseE/GQmTvpPB/x5o/Yaoj7oc4uuMFF9k8fkxCK2ctd zC1l83SYYADKN7lStMeBB/aoRZ6bHzBwIB8C4qUlfeGVgvJXt5ICY7++D95FYwPC Q22+C6d+pSYxsDni5hI4GILjAn2KkqO6v/EVEl4aBVr8SPyGMTMItmA0aDnmHab8 ZUTTm5lpH6jRHYZsuaY3 =M8tl -----END PGP SIGNATURE----- --Apple-Mail=_FD29B929-CC83-4158-92EC-E5EFF8C3F362-- From dean.willis@softarmor.com Fri Sep 13 09:40:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A3C21F8F3C for ; Fri, 13 Sep 2013 09:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI3dKwUf6ZOA for ; Fri, 13 Sep 2013 09:40:03 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4308F21F8EDF for ; Fri, 13 Sep 2013 09:40:03 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id gq1so1288728obb.26 for ; Fri, 13 Sep 2013 09:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=JVbyDkTzlKYeAzYCxJ3qgeHKK7zvmX2Kh318u9Darfg=; b=Jl62GkVRNiYORupkavTGitUdWIxSkSM1CY37jjynzV3r3wzaRBog72Zj/piwSVJEeC g46E5QxCQyxdxndoa9THa05EYc5BAR0Hhve0exoI+7wDv1NabqENFk7vcIIsy1UHp/Ra TUBJWSmG5pvkCGQAvjxTtLg8TT9YhgJQ2rCWI= 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:message-id:references:to; bh=JVbyDkTzlKYeAzYCxJ3qgeHKK7zvmX2Kh318u9Darfg=; b=CmmI7g1Q2FAo2yboe5Fu3pdmSoyGmyYVpThNtM02g+wL+5FrjkbaY89oIJkM8sj6Wq W0XXK9+apxGAl0/w/l/WHkf2NwxYhTyPmw6zZSTVQbptclxNSuUz62MGL6f3TDmFuiYa vMdUYIxq4d3p8IzMGbaBLzbJ7KkE6QTNfsiaTdbGQcCgxx0QRmvs1WbGo4NAPEIXT5aP c/38QryPonXw443CarsdPshQ+57dsZYXjYvuDbl3S/Jesr8yS0+OVVy2yj0/qo55Sgee qfo2Ng6wcZB+rrN0XgvGTqWcms7dZlervkBVm/tFvXKushxIa6Jstk4XGeOu4rfOS999 P7dQ== X-Gm-Message-State: ALoCoQmoJFb1bFRWEE2zEMPYzk3+iIbGNVLnOOOOc/B60DJzird6YdKCvywpsuYVDn/0Gbjm+g4P X-Received: by 10.182.230.135 with SMTP id sy7mr12848656obc.24.1379090402818; Fri, 13 Sep 2013 09:40:02 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id hl3sm15053901obb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 09:40:01 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9CCCA889-DE75-4BBD-AA9C-79C5ECD6FB31"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: Date: Fri, 13 Sep 2013 11:39:53 -0500 Message-Id: <7192D79F-883F-4DAB-BCAE-1D3DD57D69D2@softarmor.com> References: <522DF017.2030504@cs.tcd.ie> <522E0AC0.6040808@dcrocker.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1508) Cc: perpass , Dave Crocker , Stephen Farrell Subject: Re: [perpass] plenary vs BOF: (was Re: BoFing in Vancouver) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:40:05 -0000 --Apple-Mail=_9CCCA889-DE75-4BBD-AA9C-79C5ECD6FB31 Content-Type: multipart/alternative; boundary="Apple-Mail=_41A5B1DF-8278-471E-B90E-CA9B7A80E1E3" --Apple-Mail=_41A5B1DF-8278-471E-B90E-CA9B7A80E1E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 9, 2013, at 1:15 PM, Phillip Hallam-Baker = wrote: >=20 > When we first heard of PRISM it was assumed that the data was being = voluntarily disclosed by Google etc. It now appears that it is plaintext = traffic on the Internet trunks that is being intercepted. I recall that some of Vint's team at InternetMCI demoed a wire-speed = interceptor using an optical splitter tap back before they were sold to = Cable & Wireless. In my mind, optical splitter tap =3D=3D a prism. And = this was in the late 90's, so it's gotten better since then. Much = better. I suspect that all that is needed is a slight kink in the fiber, = and enough signal leaks out that it can be recovered. > While it is true that the NSA probably can't do the intercepts without = any help, we can't build an Internet without intermediaries either. The = question at issue should be not whether an intermediary can default but = whether that default could be detected. Given that current belief is that both submarine and physical cables = have been tapped, cross-factored with what I believe of the capabilities = of multiple nations to perform undersea taps (you can read about in in = Wikipedia), I believe we can assume that surveillance can and does occur = without the assistance of intermediaries. = http://en.wikipedia.org/wiki/Signals_intelligence_operational_platforms_by= _nation So I second PHB's suggestion that discussion of capability-by-attacker = be avoided, and we simply make the presumptions that wires leak, = intermediary nodes at all protocol layers are compromised, and that you = can be betrayed by anybody at any time, so no trust is absolute. yes, I had a large box of paranoia for breakfast. -- Dean --Apple-Mail=_41A5B1DF-8278-471E-B90E-CA9B7A80E1E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 hallam@gmail.com> = wrote:

When we first heard of PRISM it was = assumed that the data was being voluntarily disclosed by Google etc. It = now appears that it is plaintext traffic on the Internet trunks that is = being intercepted.

I recall = that some of Vint's team at InternetMCI demoed a wire-speed interceptor = using an optical splitter tap back before they were sold to Cable & = Wireless. In my mind, optical splitter tap =3D=3D a prism. And this was = in the late 90's, so it's gotten better since then. Much better. I = suspect that all that is needed is a slight kink in the fiber, and = enough signal leaks out that it can be = recovered.

While it is true that the NSA probably can't do the = intercepts without any help, we can't build an Internet without = intermediaries either. The question at issue should be not whether an = intermediary can default but whether that default could be = detected.

Given that current belief is that both = submarine and physical cables have been tapped, cross-factored with what = I believe of the capabilities of multiple nations to perform undersea = taps (you can read about in in Wikipedia), I believe we can assume that = surveillance can and does occur without the assistance of = intermediaries.



So = I second PHB's suggestion that discussion of capability-by-attacker be = avoided, and we simply make the presumptions that wires leak, = intermediary nodes at all protocol layers are compromised, and that you = can be betrayed by anybody at any time, so no trust is = absolute.

yes, I had a large box of paranoia = for = breakfast.

--
Dean
= --Apple-Mail=_41A5B1DF-8278-471E-B90E-CA9B7A80E1E3-- --Apple-Mail=_9CCCA889-DE75-4BBD-AA9C-79C5ECD6FB31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSMz/ZAAoJENG95ttGtcqrSnIP/1YKwK4gP2rll5pfaF/2xMHE 8Naw8Ypq6P124RoPiVu43ZW1NuJUNCjKcLHX9PnPW1ZT8iLLdgy5V5ik+5B9oDLs dWytlXWw21Fp1R8QVy92pUvI2sQij0yAWuCG2/21wkQjuAwQVGGM0dPI+U2ncGx7 2dP2ki2L13g9ngj+1IhmnDRE/cia6HJ8M3m1v7oNvCSQQVqTRxB4XrGjNwroaEGa H7mFD2Fb3bcz0RVVoeoo1n5V89xKYHeoXxkM+zLci/6ffDA4UKYblyKgi+/b9Qp1 ZKgt9G6KXTnjK2XEVZTxLigQRb2OftGosj7yi1XIj5i3NkDQz+tInwQ23NYSPpjv YDs7V9VB0AMwyEk991lGGXdNpkyabN0KKXTubX3Y71HBPLE6dL+PafNWMVhzaX9Z 1AoHmOubF46vl2VGlWukzUFzWY+HoaCKMNlwYLQ4YvPx8C8w5SArsuBlngcsdiwh Y4YcEc7UHLQE+5DSKJv8771eHbu9lipmIFHk+N+Z7eBhFRMllPsqwLVDfpaeyOGq JA+rOLdpH7EPpqC4yYY2IEo49HBS2VtqigFqRbv3JFbS9yR119ZNknbhEy338iah prs9N+tAWS7SQ5TD5IBri0+f5RphSCEgrC3CQt9WaJkMe3fdGuoI//X8Aw7A6Xq4 4JffYSF/fFdr09WV85Rn =2PS0 -----END PGP SIGNATURE----- --Apple-Mail=_9CCCA889-DE75-4BBD-AA9C-79C5ECD6FB31-- From joelja@bogus.com Fri Sep 13 09:50:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5CD21E80AA for ; Fri, 13 Sep 2013 09:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+CxT-55Ofyl for ; Fri, 13 Sep 2013 09:50:11 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1085421F9D92 for ; Fri, 13 Sep 2013 09:50:11 -0700 (PDT) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r8DGnk5p009048 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 13 Sep 2013 16:49:46 GMT (envelope-from joelja@bogus.com) Message-ID: <52334225.4030808@bogus.com> Date: Fri, 13 Sep 2013 09:49:41 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Dean Willis , Phillip Hallam-Baker References: <522DF017.2030504@cs.tcd.ie> <522E0AC0.6040808@dcrocker.net> <7192D79F-883F-4DAB-BCAE-1D3DD57D69D2@softarmor.com> In-Reply-To: <7192D79F-883F-4DAB-BCAE-1D3DD57D69D2@softarmor.com> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 13 Sep 2013 16:49:47 +0000 (UTC) Cc: perpass , Dave Crocker , Stephen Farrell Subject: Re: [perpass] plenary vs BOF: (was Re: BoFing in Vancouver) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 16:50:12 -0000 On 9/13/13 9:39 AM, Dean Willis wrote: > > On Sep 9, 2013, at 1:15 PM, Phillip Hallam-Baker > wrote: >> >> When we first heard of PRISM it was assumed that the data was being >> voluntarily disclosed by Google etc. It now appears that it is >> plaintext traffic on the Internet trunks that is being intercepted. > > I recall that some of Vint's team at InternetMCI demoed a wire-speed > interceptor using an optical splitter tap back before they were sold to > Cable & Wireless. In my mind, optical splitter tap == a prism. And this > was in the late 90's, so it's gotten better since then. Much better. I > suspect that all that is needed is a slight kink in the fiber, and > enough signal leaks out that it can be recovered. In the 90s that was OCxmon/DAG capture cards at oc3/oc12 and so rates in 64bit 66 mhz pci-x slots... That was heady stuff then but it's not super exciting when PC's can have 40Gb/s nics. >> While it is true that the NSA probably can't do the intercepts without >> any help, we can't build an Internet without intermediaries either. >> The question at issue should be not whether an intermediary can >> default but whether that default could be detected. > > Given that current belief is that both submarine and physical cables > have been tapped, cross-factored with what I believe of the capabilities > of multiple nations to perform undersea taps (you can read about in in > Wikipedia), I believe we can assume that surveillance can and does occur > without the assistance of intermediaries. > > http://en.wikipedia.org/wiki/Signals_intelligence_operational_platforms_by_nation > > > So I second PHB's suggestion that discussion of capability-by-attacker > be avoided, and we simply make the presumptions that wires leak, > intermediary nodes at all protocol layers are compromised, and that you > can be betrayed by anybody at any time, so no trust is absolute. > > yes, I had a large box of paranoia for breakfast. > > -- > Dean > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From dean.willis@softarmor.com Fri Sep 13 10:12:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3220321E80B6 for ; Fri, 13 Sep 2013 10:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.143 X-Spam-Level: X-Spam-Status: No, score=-101.143 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkHl5dIZisj8 for ; Fri, 13 Sep 2013 10:12:45 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id B1F1911E8171 for ; Fri, 13 Sep 2013 10:12:45 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id gq1so1325738obb.40 for ; Fri, 13 Sep 2013 10:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=pvH31k2SCnmnQEHLzJKvxuHPcniYXYUfkhx4MHjHyjc=; b=Ppnf8pToLXh3kIPwrVx+cbYDmUmdSrQUoIg7d0BTe1Uf8AGBGfsj84KlSbTiDqcHc8 lM4mWMOarVm6WMKxTh92DXIozvDt/F1MnAIAeINNKAmernzaI3JHp5rT1n+wAPLQGG5j nYnaJ2Nc2yPz8mqU4X0nsh1QXgjAZagSnaAxw= 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:message-id:references:to; bh=pvH31k2SCnmnQEHLzJKvxuHPcniYXYUfkhx4MHjHyjc=; b=MmHUWdLZB/+ZilwY9k25qJWMugR4qFIi+hWuXuuSf14sQbdL35fgakT3/tp7iO/YL5 yDAtFPYsIy2pSwUILukOwyzhUiHYcHsIQ/NYTwvw/+SN4VSBjEuM2bNTNE9WNMs7Rkhp hHYmRhNAzbnWqccYo8RvU4chmBy439ZPYSUfkZ4v1NboMnVOG1wrvmh1+euehlCbVUZe QHQKFM8VxDzZA2bY5ZLpsXQZXPErR7IZLWTuIjHCgI4vrD/Mp+70vxb+5QX4C77WSDhv 0Fxbsv3HzqilBpoLNTuDIKHSeE55T/GdZOUG6kNRKplxrxO03Wph/hb8+/dPQ3kg+d20 +6Yw== X-Gm-Message-State: ALoCoQk6SKeNKqPkqW2Alwwg5VD/OeM3kSLtqzjWyEdCVcLRed0mnfjOwnikATZEnzPiqRTyrwsk X-Received: by 10.60.56.3 with SMTP id w3mr13124030oep.37.1379092364181; Fri, 13 Sep 2013 10:12:44 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id r6sm15363089obi.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 10:12:42 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7D421480-A173-4256-A69A-38FB3821E25D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: <522E17F9.4000206@bbn.com> Date: Fri, 13 Sep 2013 12:12:40 -0500 Message-Id: <7DA623C5-E8C4-437F-BFC9-0CDD350853A8@softarmor.com> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 17:12:47 -0000 --Apple-Mail=_7D421480-A173-4256-A69A-38FB3821E25D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 9, 2013, at 1:48 PM, Stephen Kent wrote: > Stephen, >=20 > Since you solicited feedback ... >=20 > We have had considerable, recent, experience with the need to avoid = adding delay to a user's web experience (e.g., "Happy Eyeballs") in the = v4/v6 transition context. Suggestions that we increase delay in favor of = security are not likely to be well received by users or service = providers. Too bad. We can try to minimize the impact, but a net that gets you = killed because the wrong person heard you say the wrong thing is worse = than one with slightly less bandwidth or temporal QoS. >>> I think there are a couple of principles that we need to adopt = IETF-wide. >>>=20 >>> Part of the definition of "good Internet citizen" for a protocol or = application is that not only does that protocol/application include = anti-surveillance principles for itself, but that it helps OTHER = protocols avoid surveillance. Surveillance-resistance is MORE IMPORTANT = than optimizing transport efficiency. > given the quantity of meta-data (and personal data) collected by = Google, Facebook, > and many other commercial entities, and the willingness of users to = supply such data, it's hard to believe that most users would agree with = this statement. Perhaps. But unless one accepts it as a principle, one is doomed to = build surveillance-friendly networks. >>> 1) Everything SHOULD be encrypted, unless there is an absolute = operational requirement not to. This means "encryption by default" in = new protocols, and not even specifying unencrypted operations modes = unless necessary. Older protocol specs still in use should be revised to = require encryption. Deprecate the non "s" versions of protocols. > One of the reasons many enterprises decline to employ e-t-e encryption = within their > nets is because it interferes with debugging and scanning of traffic = for malware. While > I am in favor of mandatory to implement encryption for our protocols, = mandatory to use > is not a good idea in all cases. I've been enterprise IT. And enterprise security. Most of their security = problems come form their own people abusing the loopholes. Sure, the IT = department is lazy. But once the "generally accepted best practices" = require e2e, they'll play along. remember, corporate policies are driven = by generally accepted best practices such as GAAP for accounting. Note that, at least under US law, the management of a corporation is = subject to legal attacks from shareholders for losses related to the = failure to deploy generally accepted best practices for information = security. A listing of best practies is here: http://www.wpi.edu/academics/CCC/Policies/bestpractices.html Note that they're written by people like CDT (an officer of which edited = our privacy RFC), NIST, and other bodies that we influence. An Internet BCP can go a long way in addressing these things. >>> 2) Well-known ports should be avoided. Or overloaded to the point = where the port number is no longer a significant indicator to the = application. This gives rise to the "everything over 443" mentality, = which we need to find a way to handle gracefully. Demuxing the service = within the channel is a better idea than I used to think. > others have already noted that this is a bad idea from a protocol = perspective. in an era when many folks try to minimize the number of = round trips needed to provide a service to a user, this add to the = total. again, while security folks might see this as attractive, I > doubt that many users and service providers wold agree. Everybody wants something for nothing. See Best Current Practices. >>> 3) Packet sizes should be variable, preferably random. This is the = opposite of the "discover the MTU and fill every packet" model of = efficiency. Or, we could make all packets the same fixed size by padding = small ones. I like random better, but there might well be some hardware = optimizations around fixed packet sizes. > we have long understood what it takes to provide TFS, and nobody has = wanted to waste the bandwidth to do it properly. I doubt that this view = has changed. Should it? Who funds BBN, anyhow? What's your motivation for making = choices that increase surveillance?=20 Yeah, that's an ad hominem attack . But we're going to get a lot of = those, and need to have a great deal of confidence in our answers. = "Nobody wants security" is probably not a good enough answer =85 Nor is = "Security costs too much", especially until the costs have been more = completely quantified -- including the costs of making systems that = nobody will buy because they don't want to spill their guts to our = friends at Meade. Even the least suspicion of pro-surveillance bias = needs to be avoided for the results to be credible. >>> 4) Every protocol spec needs to include a pseudonymous usage model, = and most should include an anonymous usage model. > Use of pseudonyms is applicable to very few of our protocols, and most = of the ones where it > is applicable, it is already satisfied. Anonymous use, depending on = the definition one > uses, may be easy or nearly impossible. Admittedly, the definition here is tricky. Plausible deniability only = works for guilty-beyond-a-reasonable-doubt, which is missing in a number = of domains. But there's a lot here we can do that we don't. >>> 5) New protocols should be built around end-to-end crypto rather = than relying on transport-level wrappers for everything. It's too easy = to use a compromised CA-cert to dynamically build a TLS proxy cert. Some = level of key delivery out-of-band, coupled to in-band footprint = verification, is probably needed. zRTP is a good model. > see comments above re #1. Ah yes, the old "if we build E2E, nobody will use it" argument. I find = that to be an extremely suspicious argument, but recognize it and its = kin have, for many years, led us down a rabbit-warren of bad choices, = resulting in the problem we have today. Get over it. >>> 6) Randomizing interpacket timing is useful. This does all sorts of = horrible things to both TCP optimization and the jitter buffers in = real-time communications. But it's worth it. Remember, = surveillance-resistance is MORE IMPORTANT than efficiency. > not, it's not worth it. see comment above re #3. respectfully, either you're playing for the other team, your = value-system is inconsistent with mine (and consistent with that of a = surveillance state), or both. If surveillance resistance weren't more important than security, we = wouldn't have TOR. >>> 7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have = lessons we should learn. So does TOR. > DTN is great for the interplanetary Internet. I prefer realtime = performance for almost all of my Earth-bound Internet apps. I suspect = other users fell the same way. P2P is fine > for some apps, but not all, maybe not even many. But the concepts of peer-validation, explicit (rather than hidden) = intermediaries,=20 >>> 8) Every piece of crypto-advice needs serious, multiparty, = international, and aggressive review. No more documents authored by NSA = shills (which Schneier says we seem to have). > I think we have generally good review for the algs we choose; we = periodically review algs and key sizes and make revisions as deemed = necessary. We have folks like David McGrew (Cisco) providing much of = this expert review. I think we have operated in this mode for many = years. Regrettably, and as a former Cisco employee, I can tell you that folks = there also face certain pressures from state actors. I'm sure this is = true of most folks. David may be a saint. He might be a devil. But as an = external party lacking the expertise, I have no way of telling if his = position is biased against my objectives. So unless we have widespread review, from people likely to be in the = influence of multiple and conflicting actors, we really haven't had a = review. How widespread? I'm not exactly sure -- but it means more than = one review, from more than one company, from more than one sector, and = from more than one nation-state at a minimum. Trust is really hard; our = best substitute is a very widespread consensus.=20 Arguably, the mode that we've operated in for many years has given us a = rather bad current situation. Perhaps we should reassess "good enough". -- Dean --Apple-Mail=_7D421480-A173-4256-A69A-38FB3821E25D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSM0eIAAoJENG95ttGtcqr8XYP/3GrhtSY7iBC5+fGR62ZIPRB UTF+s6AEobA7/eMZ+MFhDpIpelDULI+nzRk51C7MfPhKryiXol+nYQrUEuv4f2lL 67E2hE5UQwU5+9n6LiEorHq9cj6pvS8+pR1ffFu2UQPglbHLw2s26eUxPXol3Kb6 Uyn1OqcQhOeZgtNuQdVc86pZvs+XM4G0SNtDFQ0vm/Hb2J9xULvSU1iuOv9mukI9 08HqiV+NYXPUXdonOddrQncQv14Cv+GeTWystHyd6jx2wSk05OnVoAI4bG4wGTjd EmZRS5uZ/aiZQwxtvew8z2AaNeWrppvQMCIB8WG5HZdwg3MCrgYTUWA2tictmijz A4y7Bzwz3hIodIyEsnYTxb1nstaiLeXr98GLFIxHcIIriFDFWJkWEJ6kw/108dK0 vCLC0JoSkZTVU3g7+ixipzAbT1ajZ3jmoGG3/aD55QRWI/5mYu+Q6Zw8n3NoA+AR VlxnZFwscyiDIuo7GLbqmNiqIttG2f04F8PYdn9itfKQIYiWvUnCovDm3Xkfrsrn PSnUxzAeVfInM3Pn+b3fu2wQXqL/UNwkSDb/GulXaTipEhW6ePHIaUw2UMZZxTLy yiAns/aYy40zHWh3lEBdLYr3nTRlBTN0L5hYx8D1oFCxQetggSe0cnI1uGtDH+gD 3Uu5AfWqw9ld4p6O4Lif =6n2R -----END PGP SIGNATURE----- --Apple-Mail=_7D421480-A173-4256-A69A-38FB3821E25D-- From dean.willis@softarmor.com Fri Sep 13 10:37:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D068521E812A for ; Fri, 13 Sep 2013 10:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmF-+UgRFW62 for ; Fri, 13 Sep 2013 10:36:59 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6150921E811C for ; Fri, 13 Sep 2013 10:36:59 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h1so1441206oag.38 for ; Fri, 13 Sep 2013 10:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cbzjOtsCzYU6ZBPh/2XiXZlz9QTeX6I9nXZp0JmmdSQ=; b=NTJ6C5f+7y3LQFyfaFfQuWXsG2HFht5Haz/fJ4S3ealN6W5pLDVy0wShl+x3H/2xtC u8gjLqhEGH5pCXmvYOfGQokdBPNLVAhdBFW7VbGitjrUDxVpmnhdRB7MpBHiCMtDFxtg +GwarwVF1vv4Op25DPrBu9J2Eux3nabICxS0k= 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:message-id:references:to; bh=cbzjOtsCzYU6ZBPh/2XiXZlz9QTeX6I9nXZp0JmmdSQ=; b=RC5sp90Eyivf/fahpN+6ajvlcpzRCS25A+gj3CtmXIPd9jL84TadzPXSGHv9VisYaa 5cm7YSriytS2Y4jhdJrhoeabguFOeyC03wM3Z2SgNrBrbfkCtLMFzYW+BeOp81mqwkVJ bapmfUidQOkF72GMe+EI4p8LFfeE4ZXWPHAzjqLG+Wd1yQPvSS30COP6QV+EfKu10Nau JGimxKs7XPvIzUYVjhWNsSIMrdI/NSxC48Ck9bo7xQ17SFSg0yPj8wm6P2avCwybGv7P WVU+9gIsxDr4N8mhtDuDoxmGhkcVDScOHlkjF2vevdrxIR2v9Mj1cBNTn5+XU4GkhBwz 3w4Q== X-Gm-Message-State: ALoCoQkOMxjFJSLJgAxTY/5CoiSItZXh9I4QSnG26WsuvhzA0mtbVPl1FBw0aXitN/g9voCfHLt7 X-Received: by 10.182.32.70 with SMTP id g6mr2038093obi.81.1379093816553; Fri, 13 Sep 2013 10:36:56 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id r6sm15521740obi.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 10:36:55 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3D2AEC12-1288-4CF9-BCEE-13C0B56344BF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: <522F685B.8040106@gmx.net> Date: Fri, 13 Sep 2013 12:36:54 -0500 Message-Id: References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 17:37:01 -0000 --Apple-Mail=_3D2AEC12-1288-4CF9-BCEE-13C0B56344BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 10, 2013, at 1:43 PM, Hannes Tschofenig = wrote: > Hi Dean, >=20 >=20 > I wanted to comment on your suggestions: >=20 > > 1) Everything SHOULD be encrypted, unless there is an absolute = operational requirement not to. This means "encryption by default" in = new protocols, and not even specifying unencrypted operations modes = unless necessary. Older protocol specs still in use should be revised to = require encryption. Deprecate the non "s" versions of protocols. >=20 >=20 > I guess there are two issues here, namely: >=20 > * End-to-end vs. Hop-by-hop (or stuff in between) >=20 > * Encryption itself is often not the problem but rather the key = management >=20 >=20 > As you have seen my post about the VoIP stuff it is actually not so = easy to say what exactly has to be done in what situations since our = protocols are a bit more complex... >=20 > So, you will have to expand a bit. Maybe you also want to explain the = SHOULD vs. a MUST. >=20 There's no final answer here, just a trend-reversal that points us, I = think, in a batter direction. So for example, IMAP, POP, SMTP, HTTP, SIP, RTP, all those protocols for = which there is an "S" variant? Deprecate the non-S variant to = historical ASAP. Don't write any more like them. > > > > 2) Well-known ports should be avoided. Or overloaded to the point = where the port number is no longer a significant indicator to the = application. This gives rise to the "everything over 443" mentality, = which we need to find a way to handle gracefully. Demuxing the service = within the channel is a better idea than I used to think. >=20 > That does not make sense. We are heading in the direction of = everything running on 443 with TLS (from a standardization point of = view) -- not necessarily on the deployment side (since otherwise we = wouldn't need efforts like those from EFF). Having only one port for everything is information-density equivalent = to having random ports, so that's acceptable. >=20 > You might also find it interesting to hear that the ability for = demultiplexing HTTP 2.0 and earlier version will be done based on = information in the TLS handshake and that the TLS group had decided that = they prefer a solution that reveals the type of application and rejected = a proposal for hiding it. Bad decision. Question the motivations of the people who made it. = Remember, we've been told that the security of our network is being = systematically crippled, by design, from within. I believe that to be = true, in the general (rather than specific) sense. On the other hand, = maybe they just didn't think about the problem from this perspective. >=20 > Here are the two proposals: > http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ > http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04 >=20 > Maybe it would be worthwhile to revisit the decision? >=20 I haven't followed the technicals; they MIGHT have good reasons. But if = security/privacy/whatever really IS more important than efficiency = (which Stephen has done me the honor to dispute), then a rethink is = probably in order. That sounds like an IAB question that should lead to = community review of fundamental principles. > (A side remark: I was at that meeting and pointed out that this is a = privacy decision and folks in the room said that this has nothing to do = with privacy=85. Perhaps they didn't understand. I've found that most people don't, and = that much can be explained by misinformation that could also be = explained by malice. > ) >=20 > > > > 3) Packet sizes should be variable, preferably random. This is the = opposite of the "discover the MTU and fill every packet" model of = efficiency. Or, we could make all packets the same fixed size by padding = small ones. I like random better, but there might well be some hardware = optimizations around fixed packet sizes. >=20 > Ok. Sounds reasonable to have that option. I know that IPsec has the = ability to add padding. Again, is privacy more important than security? >=20 > > > > 4) Every protocol spec needs to include a pseudonymous usage model, = and most should include an anonymous usage model. >=20 > Makes sense to me (at least for protocols that are potentially run by = end devices). For some protocols I guess it is less useful (thinking = about routing protocols). >=20 even with routing you might want to know that a given route update came = from the same source as another, even if you don't know who that source = REALLY is. > Here is the challenge: If I look at SIP then we certainly have that = option but > a) you will have to get providers to implement it, and > b) the functionality often conflicts with other privacy features. >=20 > For example, you may not want to get interrupted with a phone call = when you do not know the person on the other end. >=20 true, but there may be models where "I" know the person on the other = end, but the network provider doesn't know them -- or know that I know = them. That's an aspect of pseudonymity. > > > > 5) New protocols should be built around end-to-end crypto rather = than relying on transport-level wrappers for everything. It's too easy = to use a compromised CA-cert to dynamically build a TLS proxy cert. Some = level of key delivery out-of-band, coupled to in-band footprint = verification, is probably needed. zRTP is a good model. >=20 > I think they should have both since the functions provided are = actually different. >=20 > ZRTP is not a good model if you don't know the voice of the other = person. Not all communication is (a) between persons, (b) between = persons who use voice communication, and (b) persons who know each = other. Other out-of-band verification models can be used. For example, if a = bot's fingerprint is on its advertisement flyer, I can verify I'm = communicating with the bot mentioned in the flyer rather than an = impostor. > > > > 6) Randomizing interpacket timing is useful. This does all sorts of = horrible things to both TCP optimization and the jitter buffers in = real-time communications. But it's worth it. Remember, = surveillance-resistance is MORE IMPORTANT than efficiency. >=20 > Need to think about that. yes, I think we all do. My opinion is that we need to internalize this = position right next to the hourglass and Postel's law. >=20 > > > > 7) Peer-to-peer, DTN, and peer-relay (TURN, for example) all have = lessons we should learn. So does TOR. >=20 > In case of Tor we could certainly learn something about fingerprinting = avoidance. I am not sure about the lessons you have learned from the = other efforts. Our IETF p2p efforts are still in a dying state since the = entire industry has unfortunately changed their preferred communication = model in the meanwhile from p2p to client-to-server for pretty much = everything. We're in the process of distributing those servers very widely, so it'll = make a comeback. >=20 > In my VoIP blog post I argued that TURN doesn't actually give you any = additional privacy protection if the adversary is a powerful = eavesdropper or the VoIP provider itself. It only helps when you want to = hide your IP address towards the communication party, as Shida explained = in his SIP privacy RFC. >=20 true. But if do something like TOR to a TURN exit, and those other = factors (variable inter packet timing, variable packet sizes, random = port numbers, etc.) are in place, It takes a VERY powerful attacker to = correlate. > > > > 8) Every piece of crypto-advice needs serious, multiparty, = international, and aggressive review. No more documents authored by NSA = shills (which Schneier says we seem to have). >=20 >=20 > I agree with you about the standardization aspects (regarding openness = and transparency). The problem is that with the Web world we are = unfortunately heading into a different direction, as we (=3DIAB) tried = to explain some time ago with the 'post standardization' plenary = (+document). I am not sure yet how to best tackle that story (and I am = unfortunately not entirely alone with my lack of suggestions). >=20 > On the second suggestion I don't think you are serious. We obviously = have documents co-authored by NSA employees (see = http://www.arkko.com/tools/allstats/c_nsa.html) but first I dislike to = exclude people (since that's the whole point of having an open standards = process) and second where do you stop excluding? We have people who are = contracting for the NSA, we have people who work at government = organizations (like NIST), we have companies who work on government = contracts (like BBN). The reality is, we'll have people with counter-privacy secret biases = doing the work, because state security apparatus fund them. Many are = true believers in the missions of their apparatus. =20 So there is no single trusted reviewer. The best we can hope is large-scale consensus from multiple reviewers = who hopefully have conflicting agendas. This is hard. But it's VITAL, to = eliminate the taint of distrust now smeared on our systems. Frankly, if I were a state purchasing agent outside the USA, I wouldn't = want to buy systems that had been specced for me by NSA employees. But I = might buy systems that had been specced by a combination of NSA, EFF, = MSS, FSB, and Anonymous activists. -- |Dean --Apple-Mail=_3D2AEC12-1288-4CF9-BCEE-13C0B56344BF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSM002AAoJENG95ttGtcqrJSsQALOWE9V5sAlZsU/6n+0/iqNQ HGC+Z0X1t5WDrfs4l7Kw2ZN9uKyz192Gvgx10xvr4Zp+uW+bT2IF9oTauxskvO/V Xk3pEra0lqc+ayT7JaKwMTeUstxTSg1uUTerj+yJU3RG1IkAa25tX0Bq4nBW22A9 VCSuduXW+POjGfyqoWkX9mhZ1pY1oSwaW06rmBockoa262idyfUhder1KmA3V4xA lQmecpTIMCdqbENMLWDzXXXQL5dcUJ+JJiFMS0GxR3Rx1sAxX8v3jLnIojSqFybH tFB3hvHDk9ZLQRW7uFt/EyrwT8b17JIQ35qD2mgePGhPhfGLLv1GPCMpqgKQu+Py bI2wl/bD2VBaVPudxQHoBTrLnYNZlIzflBNGNHhtctMsHGzU/dIunERtVzj88IAv +YvWU8cagctwzvrLEiCbQKlieSnQddNllHSGlBaHOrN3UNojnXSPmeC01zEsykAT jGdM9KBZUHAFBmT0AEXCPbEHQcityRp9qRo9jJj5kaewoIFI+V4p96GNE3oXG6mV FpbCGNn6KX0YCWdv5Gf/6GPQn3DNaM6QtBoRwO4DcWxmaVExXugwV0w6oxpii0OS ecFkDc1dhgd6ootB751EKQVt9nPragy2jk7WWwa36BOtpNsvV0J94Yv45Fb8uF6w 7E4gddhN3NcSDBJqXcRL =Tq5/ -----END PGP SIGNATURE----- --Apple-Mail=_3D2AEC12-1288-4CF9-BCEE-13C0B56344BF-- From randy@psg.com Fri Sep 13 10:49:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35C221E80D1 for ; Fri, 13 Sep 2013 10:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWi4KzI1G+Ex for ; Fri, 13 Sep 2013 10:49:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 3501521E80AA for ; Fri, 13 Sep 2013 10:49:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKXUb-0002Ee-Ee; Fri, 13 Sep 2013 17:49:18 +0000 Date: Fri, 13 Sep 2013 07:49:16 -1000 Message-ID: From: Randy Bush To: Jacob Appelbaum In-Reply-To: <5232D366.1000803@appelbaum.net> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> <20130910185544.GF29237@thunk.org> <5232D366.1000803@appelbaum.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass , Theodore Ts'o Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 17:49:21 -0000 >> OF course, there will be some things where encryption is simply not >> needed, and but data integrity is is needed. Example: time (NTP) and >> routing protocols. So we need to be careful how we specify MUST. >> :-) > I think this is a reasonable read but I'd like to encourage dissent > here. Time is a very important part of almost all cryptographic > protocols i might go further. having some protocols in the clear allows the attacker to better focus their efforts on what is encrypted. also, though some data themselves might not require privacy, the nature of the conversation may facilitate traffic analysis. randy From hallam@gmail.com Fri Sep 13 11:18:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C4021F9C4A for ; Fri, 13 Sep 2013 11:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SPEC_ROLEX_NOV5A=1.062] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC8sLebK9mgR for ; Fri, 13 Sep 2013 11:18:24 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C8CFD21F9C42 for ; Fri, 13 Sep 2013 11:18:21 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ea20so1352994lab.27 for ; Fri, 13 Sep 2013 11:18:20 -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; bh=b8Sjx4XKVzuIINEiHr43hycHYAoeWt4Qv51JQn9aLpU=; b=cRp+ip5Gdtzbc/6ux6d/i90sqWbQnlwC/AZHtOd6LNX6R0LUN7L/b8czmW/b7lCABO y/Ctq0i+izimQzmV4nInJZrFbLI+RnwUDWvk1ogKe6qsOf76xFljFZajZpQx/uHNPJH0 ViJE28p3zOWBxhSETBLDgohc/+5W1OFh/qmjR5CAxbaD+g2pG9kD8PDLw27d2ryXDYv8 9TNL96+lkQMl2Jcz76V2Nq4CZz9fwmmeLfATG3M56Z0xGno80pphXFxu/0ZGtkaC+uCc qQFkdS59VqLjhWcNZSZOFx6k03bzhQABW11lBdHb4txaQBkGFtHllPTcyhmkLsovCkMQ YPFw== MIME-Version: 1.0 X-Received: by 10.112.210.136 with SMTP id mu8mr12928051lbc.25.1379096300743; Fri, 13 Sep 2013 11:18:20 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 13 Sep 2013 11:18:20 -0700 (PDT) In-Reply-To: References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> <20130910185544.GF29237@thunk.org> <5232D366.1000803@appelbaum.net> Date: Fri, 13 Sep 2013 14:18:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c3c7041df1cb04e647e158 Cc: perpass , Theodore Ts'o , Jacob Appelbaum Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:18:26 -0000 --001a11c3c7041df1cb04e647e158 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 13, 2013 at 1:49 PM, Randy Bush wrote: > >> OF course, there will be some things where encryption is simply not > >> needed, and but data integrity is is needed. Example: time (NTP) and > >> routing protocols. So we need to be careful how we specify MUST. > >> :-) > > I think this is a reasonable read but I'd like to encourage dissent > > here. Time is a very important part of almost all cryptographic > > protocols > > i might go further. having some protocols in the clear allows the > attacker to better focus their efforts on what is encrypted. also, > though some data themselves might not require privacy, the nature of > the conversation may facilitate traffic analysis. > My security concern with NTP is not so much on the encryption side as the authentication side. Due to the nature of the protocol it is easy to get encryption if you do authentication, so why not. But the protocol seems to have been by the type of people who care about synchronizing their clocks to Tier 1 stratum sources to within a nanosecond rather than people who care about getting a very high degree of assurance that they have a trustworthy time value that is good to maybe a minute. I do want my system clock to be within a second of a good reference of course. But for security purposes I would tolerate a much lower degree of accuracy. -- Website: http://hallambaker.com/ --001a11c3c7041df1cb04e647e158 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 13, 2013 at 1:49 PM, Randy Bush <randy@psg.com> wrote:
>> OF course, there will be some things where encry= ption is simply not
>> needed, and but data integrity is is needed. =A0Example: time (NTP= ) and
>> routing protocols. =A0So we need to be careful how we specify MUST= .
>> :-)
> I think this is a reasonable read but I'd like to encourage dissen= t
> here. Time is a very important part of almost all cryptographic
> protocols

i might go further. =A0having some protocols in the clear allows the<= br> attacker to better focus their efforts on what is encrypted. =A0also,
though some data themselves might not require privacy, the nature of
the conversation may facilitate traffic analysis.

=
My security concern with NTP is not so much on the encryption si= de as the authentication side. Due to the nature of the protocol it is easy= to get encryption if you do authentication, so why not.=A0

But the protocol seems to have been by the type of peop= le who care about synchronizing their clocks to Tier 1 stratum sources to w= ithin a nanosecond rather than people who care about getting a very high de= gree of assurance that they have a trustworthy time value that is good to m= aybe a minute.

I do want my system clock to be within a second of a go= od reference of course. But for security purposes I would tolerate a much l= ower degree of accuracy.=A0


-- =
Website: http://hallambaker.com/
--001a11c3c7041df1cb04e647e158-- From jacob@appelbaum.net Fri Sep 13 11:51:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E4221E80D8 for ; Fri, 13 Sep 2013 11:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 961DEL19UB47 for ; Fri, 13 Sep 2013 11:51:03 -0700 (PDT) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4486F21E80D1 for ; Fri, 13 Sep 2013 11:51:02 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id a15so766836eae.37 for ; Fri, 13 Sep 2013 11:51:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=opstwy21JX6eU/JcUMAwNciiRvdUjZddow3xiv/Nhws=; b=WyFxWVb4c6wm/C6Ly+pwfWNBL5mc9y430/cAM9OxwzO1/WAlqTF8AtG7Y7pgGKqkJ3 fR5IdTfU/Js6mnSXdgEbyAYYA5bY0NuZzt/F8lhyMcHaWliCwfp28qbiPY+f+HlfufKN WVF5Vvuc/nTYWtsI72nA/kPx9KYwP48ZT7fD5s7cF4/kHZeTzyISzefGQsC8KwgnSwmU 1wXEJchg9chFA8zG7/56bC6WhA88w1/32K+G/PhN1ZB4knagScR3imA+e44u1nxKK1+D RmvUaOZLTIHsNT2AOar4xvOWRoKeucogmyI2ZfGPvb5sFLOF1oMupfxQYi/BQTbY9T5F KhSA== X-Gm-Message-State: ALoCoQmJUkzlYe+roiexW/mXTaLw17ZJgzFKGTtGBZoS8HsSwkvo4+pj2vbBbkGuMTa0BWEwVxjR X-Received: by 10.15.75.73 with SMTP id k49mr20057554eey.36.1379098260766; Fri, 13 Sep 2013 11:51:00 -0700 (PDT) Received: from 127.0.0.1 (foto.ro1.torservers.net. [109.163.233.194]) by mx.google.com with ESMTPSA id x47sm17343298eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 11:51:00 -0700 (PDT) Message-ID: <52335E23.6040102@appelbaum.net> Date: Fri, 13 Sep 2013 18:49:07 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: perpass@ietf.org References: <522DF017.2030504@cs.tcd.ie> <522E0AC0.6040808@dcrocker.net> <7192D79F-883F-4DAB-BCAE-1D3DD57D69D2@softarmor.com> In-Reply-To: <7192D79F-883F-4DAB-BCAE-1D3DD57D69D2@softarmor.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] plenary vs BOF: (was Re: BoFing in Vancouver) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:51:08 -0000 Dean Willis: > > On Sep 9, 2013, at 1:15 PM, Phillip Hallam-Baker > wrote: >> >> When we first heard of PRISM it was assumed that the data was being >> voluntarily disclosed by Google etc. It now appears that it is >> plaintext traffic on the Internet trunks that is being >> intercepted. > PRISM is one program. There are many programs. Other programs are responsible for dragnet surveillance, analysis and attacking cryptography. XKEYSCORE is the name of the replicated search/query system. There are literally thousands of programs that all have specific names and meanings. One of the best resources around is Bugged Planet - the main editor has been keeping good track of every key word, every program, tv clips, news clippings, etc: http://www.buggedplanet.info If you require a general name for all of these programs, it isn't PRISM, it is TYRANNY... All the best, Jacob From stephen.farrell@cs.tcd.ie Fri Sep 13 12:13:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BD911E8200 for ; Fri, 13 Sep 2013 12:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-Vig-WU727h for ; Fri, 13 Sep 2013 12:13:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E634C11E80FF for ; Fri, 13 Sep 2013 12:13:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7ECEABEC6; Fri, 13 Sep 2013 20:12:59 +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 h2poztrboFIG; Fri, 13 Sep 2013 20:12:58 +0100 (IST) Received: from [10.87.48.8] (unknown [86.41.55.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B3FDABEC3; Fri, 13 Sep 2013 20:12:58 +0100 (IST) Message-ID: <523363B0.2090503@cs.tcd.ie> Date: Fri, 13 Sep 2013 20:12:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dean Willis References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Hannes Tschofenig Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 19:13:16 -0000 Hiya, On 09/13/2013 06:36 PM, Dean Willis wrote: >> to hear that the ability for demultiplexing HTTP 2.0 and earlier >> version will be done based on information in the TLS handshake and >> that the TLS group had decided that they prefer a solution that >> reveals the type of application and rejected a proposal for hiding >> it. > Bad decision. Question the motivations of the people who made it. > Remember, we've been told that the security of our network is being > systematically crippled, by design, from within. I believe that to be > true, in the general (rather than specific) sense. On the other hand, > maybe they just didn't think about the problem from this > perspective. On this point: I think we're actually ok. The TLS WG were asked to provide this feature for HTTP/2.0. One proposal involved establishing confidentiality before nominating the next protocol, but was somewhat hacky in how it fit into TLS1.2. The other (ALPN) was selected as it did the job required for HTTP/2.0 more cleanly. BUT, the WG also decided (formally I guess a little later on) to start work on TLS1.3 with a major goal of that work being to confidentiality protect much more of the TLS handshake as an inherent protocol feature. And that work has started, though I don't think there's an I-D just yet. So the TLS WG decision was in fact to go for more confidentiality. FWIW I think that was the right choice, S. From code@funwithsoftware.org Fri Sep 13 12:18:48 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F2E21F93D4 for ; Fri, 13 Sep 2013 12:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.882, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab96C3Qk9Kzh for ; Fri, 13 Sep 2013 12:18:43 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id CBB7E21F93BA for ; Fri, 13 Sep 2013 12:18:42 -0700 (PDT) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 6AD251EE52BA for ; Fri, 13 Sep 2013 15:18:36 -0400 (EDT) Received: (qmail 15333 invoked from network); 13 Sep 2013 19:18:35 -0000 Received: by simscan 1.4.0 ppid: 27050, pid: 24846, t: 1.4781s scanners: clamav: 0.88.2/m:52/d:13495 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 13 Sep 2013 19:18:34 -0000 Message-Id: <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> From: Patrick Pelletier To: Stephen Farrell , ietf-http-wg@w3.org In-Reply-To: <52330265.9020709@cs.tcd.ie> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 13 Sep 2013 12:18:32 -0700 References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> X-Mailer: Apple Mail (2.936) Cc: perpass@ietf.org Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 19:18:49 -0000 Forwarding this idea along to httpbis as you (Stephen) suggested. Although this could be retrofitted onto existing HTTP, not just httpbis, since it's merely recommending practices which are already legal in HTTP. On Sep 13, 2013, at 5:17 AM, Stephen Farrell wrote: > On 09/13/2013 04:12 AM, Patrick Pelletier wrote: >> On 9/12/13 1:18 PM, Dave Crocker wrote: >> >>> "privacy properties of IETF protocols and concrete ways in which >>> those could be improved." >> >> One obvious thing is the amount of (usually unnecessary) information >> leaked by the User-Agent field in HTTP. >> >> Should we downgrade the User-Agent field (section 14.43 of RFC 2616) >> from a SHOULD to a MAY? > > I think everyone finds those values problematic, and not only for > privacy reasons. But yes, if you believe [1] then its probably the > biggest contributor to browser fingerprinting that's in an IETF > spec. (No idea if that site's evaluation is sound myself though.) > > [1] https://panopticlick.eff.org/ > >> Or, if that's too radical, should we standardize a small number of >> fixed >> strings to use in the User-Agent field? (For example, "Desktop/ >> 1.0" for >> desktop browsers, "Mobile/1.0" for mobile browsers, "Text/1.0" for >> text >> browsers like Lynx, "Batch/1.0" for non-interactive clients like curl >> which are performing a task more specific than crawling the web, and >> "Robot/1.0" for clients which are crawling the web?) > > Interesting. An IANA registry of those kinds of value might just end > up like the UA string though, which also started out nice and simple. I agree that things always start out simple and get messy. However, I think there are some differences: * The original User-Agent field was not designed with privacy in mind. In fact, it was designed specifically to identify the product and version the user is using. So, with a different goal (privacy first), we will hopefully get different results. * By specifying only a single product token, omitting comments, and fixing the version number at 1.0, we've already eliminated a fair amount of information. And then we further limit the information by making the product name not the actual name of the software, but merely a generic indication of the type of User-Agent; whatever is the minimal amount of information necessary for any legitimate browser sniffing that needs to occur. (Such as differentiating desktop and mobile clients.) And, of course, using the simplified User-Agent strings was just one of my two proposals. My other proposal, which was even simpler, though perhaps more radical, was to downgrade the requirement on User- Agent from SHOULD to MAY, and encourage browsers not to send User- Agent at all. (We could even change it to a SHOULD NOT if we feel really heavy-handed.) One could argue that by using other techniques such as responsive layout, no browser sniffing should be necessary at all. > Maybe ask this on httpbis if you don't get more feedback here? That's > where you'd find folks who know if it could be done and who could do > it. --Patrick From malbrain@yahoo.com Fri Sep 13 13:00:46 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7331321E80F3 for ; Fri, 13 Sep 2013 13:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+gXnW6QuzNh for ; Fri, 13 Sep 2013 13:00:40 -0700 (PDT) Received: from nm5-vm5.bullet.mail.ne1.yahoo.com (nm5-vm5.bullet.mail.ne1.yahoo.com [98.138.91.227]) by ietfa.amsl.com (Postfix) with ESMTP id 3106221E811C for ; Fri, 13 Sep 2013 13:00:34 -0700 (PDT) Received: from [98.138.226.176] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 20:00:32 -0000 Received: from [98.138.89.232] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 20:00:32 -0000 Received: from [127.0.0.1] by omp1047.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 20:00:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 612938.63496.bm@omp1047.mail.ne1.yahoo.com Received: (qmail 62363 invoked by uid 60001); 13 Sep 2013 20:00:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379102432; bh=9WFyEWa68rLx2mRbatRgGyIAa7Jb0DT9f4MZcv+yLl0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HoqsA/EdD1eKAAv+6EP2GPWmBIiWvRfAKItbjZWxMSB6qBQdwgcucqvRYO+hT251ucnUlLHT4jhyelyb7oH5JKqJzJVCf+l7519PMNP6GhdpJ+OnsLTa3qFbZqRTK46kMukpcs1twT/qXXcGZK3hQuiCvdUIAtikMvREgRi4+1E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=I3zLI4A3mR4MK4uALfh88S5RU4HoPZUfHaAXPilqY4wLffdBLjLvGWUIpqk1+98ujttI0Z/l59btpUOfUjluUonTHmCdJECeHrNmmPboFrhECGqLu4pSPwyV0XUAyz+JQdtjsWrcm/CCcHxDHy8s7xR77QUQY1zSXUngOddGlSw=; X-YMail-OSG: 5lkcimQVM1loxCXclbNGUsbqaqEagR8CB0aWHUiMuDTxz9m 637K9TWVJlxshNA65EyiENKswzAjALWipqCXKL6wZIarvhmbwyihkRJ9PrWF Pn0abvqJpjIpc3pJ3YFTsreRtfKycoLaT46.S6c6sdSE5Fy7h8mBv_VsmanX RvE1gvo.mEs3jSijwiCR_5qg2XSJ.p5uUsodZK3MAeHlhxbSdWhrP2iFehMt zXkKXnEDzFc5TrKw2y_2hOtgmUA2BMZtP_wdrXlD5F6ZlZkxrZzZc0rRcVz7 fUcoWam2y2bC5oh42MXPgBOxgGLav4OSFuvCW2Q5Pdmh1c6LWINTihPLl9Ek ZFjPHR.5QDGc24BCcOfOIcAS4X1WhZ50YxYyXczRcUQK.OsCuLgC4_JfRA70 7R.ikcBD1MuyzKIjRR2qQRUjnxNyMZpPqN3OZPoWfM6BlEAG6mFM83TQvQ4G abg2x5vd3LZNAOXCVIREOcvXe2dlWiU207NeUVwX0erx2ti2nvtmJVvrIVBk 7gF477VWD_w.gz5OZKj673eYZXCC2upZOs8eM9WrLhVTNZZe7KH8P5L2Tcnj CX3.5pEKhZU6LMxzfCe.t2WxSHZBbw_Iieg-- Received: from [206.169.92.130] by web125503.mail.ne1.yahoo.com via HTTP; Fri, 13 Sep 2013 13:00:32 PDT X-Rocket-MIMEInfo: 002.001, SSd2ZSBwcmVwYXJlZMKgYW4gSUQgYW5kIGhhdmUgc3VibWl0dGVkIGl0IGFzIGEgZHJhZnQgdG8gSUVURiBmb3IgcHVibGljYXRpb24uwqAgSW4gdGhlIGludGVyaW0gSSd2ZSBhdHRhY2hlZCBhIHBkZiB2ZXJzaW9uIHRvIHRoaXMgbWVzc2FnZS4KwqAKSSd2ZSBkcm9wcGVkIHRoZSBpZGVhIG9mIGluY2x1ZGluZyBib3RoIGNsaWVudCBhbmQgc2VydmVyIHB1YmxpYyBjZXJ0aWZpY2F0ZXMgaW4gdGhlIGRpcmVjdG9yeSBpbiBmYXZvciBvZiBhIHNlcnZlciBjZXJ0aWZpY2F0ZSBvbmx5IHJlcG9zaXRvcnkgd2kBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> Message-ID: <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 13:00:32 -0700 (PDT) From: Karl Malbrain To: Leif Johansson In-Reply-To: <5232B258.1070104@mnt.se> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-2005986409-377316027-1379102432=:61098" Cc: "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:00:46 -0000 ---2005986409-377316027-1379102432=:61098 Content-Type: multipart/alternative; boundary="-2005986409-426786944-1379102432=:61098" ---2005986409-426786944-1379102432=:61098 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've prepared=A0an ID and have submitted it as a draft to IETF for publicat= ion.=A0 In the interim I've attached a pdf version to this message.=0A=A0= =0AI've dropped the idea of including both client and server public certifi= cates in the directory in favor of a server certificate only repository wit= h=A0an additional TLS interface to authorize access by clients.=0A=A0=0AKar= l=0A =0A=0A________________________________=0A From: Leif Johansson =0ATo: karl m =0ACc: "perpass@ietf.org" =0ASent: Thursday, September 12, 2013 11:36 PM=0ASubject: Re: [= perpass] proposed enhancement to TLS strong authentication=09protocol=0A = =0A=0A=0AOn 09/12/2013 08:37 PM, karl m wrote:=0A =0ALeif, =0A>=A0 =0A>I do= n't own the technical ability to spell out specific changes to the TLS stro= ng authentication protocol needed to implement the proposed changes.=A0 I'v= e only been exposed to this as a client to a strong authentication server. = =0A>=A0 =0A>I had hoped to open a general discussion on the topic of strong= authentication for every connection=A0to every server as a means to preclu= de MITM.=A0 Do you have any input on that? =0A>=0A> =0AOnly that the devil= is in the details. I think most on this list recognize that "encryption=0A= is a problem of turning a hard problem into a hard key management=0A pro= blem" and=0Athat your proposal leaves several problems to the imagination o= f the=0A reader, including =0Ahow to build a multi-master globally scala= ble directory of keys and=0A GUIDS.=0A=0AI think that while you try to s= pell out some of those things, the=0A list can do other things=0Aso I re= -iterate Stephens point: go write a draft please.=0A=0A=A0=A0=A0 =A0=A0=A0 = Cheers Leif=0A =0A_______________________________________________=0Aperpass= mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/pe= rpass ---2005986409-426786944-1379102432=:61098 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've prepa= red an ID and have submitted it as a draft to IETF for publication.&nb= sp; In the interim I've attached a pdf version to this message.
 
I've dropped the idea of includin= g both client and server public certificates in the directory in favor of a= server certificate only repository with an additional TLS interface t= o authorize access by clients.
 
Karl

=
=
From: Leif Johansson <leifj@mnt.se>
To: karl m <malbrain@yahoo.com> Cc: "perpass@ietf.org" &= lt;perpass@ietf.org>
Sent: Thursday, September 12, 2013 11:36 PM
Subject: Re: [perpass] proposed enhancement to TLS= strong authentication=09protocol

=0A =0A=0A =0A =0A
=0A =
On 09/12/2013 08:37 PM, karl m= wrote:
=0A
=0A
=0A
=0A Leif,
=0A
 
=0A =
I don't own the technical ability to spell out=0A = specific changes to the TLS strong authentication protocol=0A ne= eded to implement the proposed changes.  I've only been=0A = exposed to this as a client to a strong authentication=0A server= .
=0A
 
=0A
I had hoped to open a general discussion on the topic=0A of st= rong authentication for every connection to every=0A server= as a means to preclude MITM.  Do you have any input=0A on = that?
=0A

=0A
=0A
=0A =0A O= nly that the devil is in the details. I think most on this list=0A recog= nize that "encryption
=0A is a problem of turning a hard problem into= a hard key management=0A problem" and
=0A that your proposal leav= es several problems to the imagination of the=0A reader, including
= =0A how to build a multi-master globally scalable directory of keys and= =0A GUIDS.
=0A
=0A I think that while you try to spell out = some of those things, the=0A list can do other things
=0A so I re-= iterate Stephens point: go write a draft please.
=0A
=0A  = ;       Cheers Leif
=0A
=0A=0A

= _______________________________________________
perpass mailing list
= per= pass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
=

---2005986409-426786944-1379102432=:61098-- ---2005986409-377316027-1379102432=:61098 Content-Type: application/pdf; name="draft-ietf-perpass-malbrain-TLS-STRONG-AUTHENTICATION-00.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-perpass-malbrain-TLS-STRONG-AUTHENTICATION-00.pdf" JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFn ZXMgMiAwIFIvTGFuZyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDMzIDAgUi9N YXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+Pg0KZW5kb2JqDQoyIDAgb2JqDQo8 PC9UeXBlL1BhZ2VzL0NvdW50IDUvS2lkc1sgMyAwIFIgNyAwIFIgMTggMCBS IDIxIDAgUiAzMCAwIFJdID4+DQplbmRvYmoNCjMgMCBvYmoNCjw8L1R5cGUv UGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBS Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+ L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDQgMCBSL0dyb3Vw PDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9U YWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNCAwIG9iag0KPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNzgwPj4NCnN0cmVhbQ0KeJyV WVlv2zgQfg+Q/0D0qQWysm7JRVGguRbZbYpgY2Afmj7QEm0TK4teisqxv35n KCch3ZBSESBwjG8OznxzkJl9kYqvaKXIp0+zL0rRasNq8n22ELsfs8XTjs1u 6Jq3VHHRfv5MTs/PyOni+Gh2GZEoJovV8VFEQviJSJKTIgqDlCy2x0chWeOv 34+Pvr8nH36QxR/HRxcgh7KGQD4vg6TUEn5cmY/j4rIMwmwaNi3iYG5D/wxc 2LIIkolq52lw4ME1bZaS8tYhkWVxEE1TjnEo0lfcVauYbJki55KulEMoSvKg jG3BsQBOwaYhYAsbe8PUf+QCvdpJ3rGOfP165j/2FEt47Dy2j93WQNJOUdV3 H8lVuxJyqxlKG9fRwB4ezVQ0FoYp2DSOg7Swsbdsp9h2ySRUyAmJwyjxB2GK HQxCFr7iLh53XDI4/DmrBltJ5LUVx0kQZ7aSsQBMwaJjiaOIycX1GZk5Gsyp UEpsfT3GMBFBY0nGPcFuEqbjOKy2KTik5wtupJDnSZDHqS3iUh3NdYAt7D6j VkJdnqUx1t4kU0k6D+IDrIcmSVFOVj00Owv6HRLJXPgsKYID1ZELmqbQni3o D28RTYsFcDV24DRXyewGWXp9dnVOwreYGOa6MOIJ3TpKCyAEySOzQUqxbNiW 3ELnYlvWupp2XITajin70YktdGFHkxp8GqQH2MXXW/BHinZNvvRqA07xSlei K+u5HnGTzIWZdi00GlztmVVxGv2E/82JLfVRTCxnajUSpUmq91EysRAlF6n2 nJiiOYmSn7wYYu8SyHI9XiYpz6EDHWDDMFCPrnCn4Hl5IOAtiejt5pzluXkc HMpErIja8I5cs61wFQisYLCZWNJe8/Eb5jMoMugWZqbQ7PNq5DKdAdFiW84V 1igDoh1g9cJFwE7XL7dcKRhovCWrvmlIJYZtpK0YeeBqA2FwN0TtfAKjLdsr 3klxzzsoPh3B07MbUpSEtvXwcR44K22uK83S5Y1l4owlkOJFhY5lLaoeexXZ 0ic8noIZCJ8hwJw2ZCXFllxdLC7J+R4HrsvhG9+xcXi82Dlzdhs4cwxT1UIr yZe90kHa9cuGd7hQgM0trdnwTdU8EXpPeUOh3ZIlg4ww8k3cD4PV61YZvxqK QlypYNElC0jijslOtHfvu7sPOgxSNA2HrokJrsTuSfL1RiEPOrFlLwXgNVYY 6XqJKIa5FYps6D0ja0lbpBca0TFdyL5T+s/BnhKENo148BsCDr8aEjVf7Xu8 plnXV5vXhIpedRwC+WIRKrqtqaw7AuOrcpkJU5jClh3WdQHxu5UaXPsbigVs E7FEgmFgaUsgo//24BmBnLK2YwPdlCcbXnuJyaKf0maGoTsZ0meRH7OyZGQI ICTFays2iDQSU4jUia7yGmzfQ2Ig8Q9C/qOzwwfbXluRwaO9k5VkFIkzZto1 TOY57oGWZvSSPVZwu0HWDXcur1/J3KADnANE9vWpyUdohzn+6/IMqxdUKiB7 12C6OWYEvmlou+5hpYRIwAH8pZuUuZld0HzRrrE7uO71+ylgyXmbZupqmklu JHts9kSZtmqKOGcP3i4PsHr2QODkwBHkfP3aeVdDop9fBiACvGXAqpHKSPCq 93zBWtDuH3IpJEywu/fImbsPJ5ARbZPumYp/PptfS9HvsNa/CYVEG2MFXhef bQ1pHTRonkPpuRaGGDpxmdnyzoEY6a3Mwta8G0bHW5Gjo0vD0OIsja68DefE W0JiZc3JRHxMiW0JLxMzJxNxmUt+jYmmyBgTTazBRL3VG9G8pw2vdb1TyOoj 3/ZbPWn4I3TPVm38czGeG2xEtiExoKf1uxp72gmRbNfQCj+BBbHsRMOw1y2f 9m3CSKsCuvq7Z1wYGVV8y4DJV3q74y3dwUa2g4GAxBak79gYS5I8xMZpKXVv 7AXezS3sc1A7OOSKSYZ7pNf73OAMTi8HGJpcCouUBR/mvW69FdelC3fTIYK6 f4IT77BScDpCHNYSR/o754tqFiS2fi+FcxeF49TgGC5e0MMVsqfqpcRRPJKB OJvjLmypcV71wN30ALvPQAUBAM7RCsczkIs6r1GpvqNZOvwpSwx6b5TafZzN Hh4eAry+BkKuZ/hhFvF65ICmmrEDmli6hD5IK2hH7rvhM41NOW86C2c6w/zt dI6lMYyCPLPFnaccJoOFHe5otxtaw3J8ziWrlJCc/UJis6gMDpR68xrhJcWX 1047E2zU1vlMXYZ4EEuTN+ylK+xR8fpiOlyJnbMnxGu4iZ90eTYFRu7OJnRI ywOHqzLTL54EFkHn08ocKWCJ719H/R3VlHAqL1IsWxPqeXEd1uEpetMwOXTB 896aJvGhYue/oZK572yaGv8Df5Bo2A0KZW5kc3RyZWFtDQplbmRvYmoNCjUg MCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEv QmFzZUZvbnQvQUJDREVFK0NvdXJpZXIjMjBOZXcvRW5jb2RpbmcvV2luQW5z aUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDYgMCBSL0ZpcnN0Q2hhciAzMi9M YXN0Q2hhciAxMjIvV2lkdGhzIDE0MSAwIFI+Pg0KZW5kb2JqDQo2IDAgb2Jq DQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDb3Vy aWVyIzIwTmV3L0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDgzMy9E ZXNjZW50IC0xODgvQ2FwSGVpZ2h0IDYxMy9BdmdXaWR0aCA2MDAvTWF4V2lk dGggNzQ0L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDYwL0Zv bnRCQm94WyAtMTIyIC0xODggNjIzIDYxM10gL0ZvbnRGaWxlMiAxMzkgMCBS Pj4NCmVuZG9iag0KNyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAg Ui9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgOSAwIFIvRjMgMTUg MCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUld ID4+L0Fubm90c1sgMTQgMCBSIDE3IDAgUiAxOSAwIFIgMjAgMCBSIDIyIDAg UiAyMyAwIFIgMjQgMCBSIDI1IDAgUl0gL01lZGlhQm94WyAwIDAgNjEyIDc5 Ml0gL0NvbnRlbnRzIDggMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5z cGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAx Pj4NCmVuZG9iag0KOCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCAyNDM4Pj4NCnN0cmVhbQ0KeJydWltv27gSfg+Q/8DHLtCVJYq6+CAo YOeyyOJkUWz81vZBluhYqCwZkpzW/35nSDoiXZNSswvXtjIzpD7OfHORZ4u2 LzdZ3pObm9mi77N8ywvyZbZq9t9mq+Oezz5nL2Wd9WVTf/pElne3ZLm6vpo9 BCSgZLW5vgqID/8HJIxJEvgeI6vd9ZVPXvCfv66vvnx4rHve1rz/4xtZ/X19 dQ/qaOKkNw+9mDJN98uHPy2ige97KTVE79psY7MchPG5OLGJzn+xfLP6/zN5 7tumfiGLQ7/ldV/mEgeLkTCNPJpMWi+cU49NE2VRcG71me97vlvzllA/CC16 UUS9YNIKUeLFJJ6nXphekCT3T7dkZnGTZdP3zc7lKZp7BLCXcAyYmOBG/FEA Y5LGmtxTVq3brKzdTmao2H0h9fzIlL3/uS9b3pE7nkvgbduiAPeZbhB+tEkz 6vnJtF2FbI5uYMg6Tj9M0smm2Zx5Z3v+AmfJrf4SJt75TmyijHlzU/Sb018n bVg4bMIsksJhyewzuurT7eMd8S+7Y4wWTh5/2+yPbfmy7a1e4QOg1FT6pwFK 4DYFjNszBec2gwvblKEZ+Zc2+vVD/vUP63aj1GPUVHW4S5AmYrO6uD0+2C+m H+9XD2TVHrqeZHVBgC3JnrddU3ekLJA5NyXwRdaJvzhpKNRoqGjyww60SQb8 27SdRxZVRcTddwTCkbevvPBsERAK3jQMOvGnRn6j5/lNbi8YTvPG98PE99kS Xre+H8U+XIDPcC2i8A7foxRecJnhO2SvKFEymnyk5BgIsjspK3SVbKTs4WcK MhT+Fobye7CA11LZZHINpumJvaVKF9akqdwznctr+DmK1D7Vmst42Bt9UPtZ SPvsAa9/MgG/UAtIrHw6IP+5bV7LrkSH+JdXkCQgq/YNAb+xHB8F5kgj08gD uVMe0TmdKJprrvn1w7bv9/+bzXp0T869kvcbr2lfZhUEb93Z4pemIg0YtmyF CZ1D5j+TLetNA/FZ1oRvNhwyZ1ML7y+ynpNm476BRHPa/WFdqcoD9fpt2ZFT ZHjkc8WzjkM0vJb8By4AX4ppKMXxsEietXxzqKrjRxWlR1LwLm/LNSfH5tCe og6jGyKvb8u8F6f5o+y3eGWPt+hcLtKIEI7+7D7cxGQoO6M4vEz2UQhHEykD izXcABQz7mLBUHGuyWzMHfnxYGIFh9/x/NCW/ZHsMR4K4ESbRwWx8D7dwPpI sCbNm7rmCn3AUbBg25Fu2xyqAg33F47CRmiY+08L3AxEIAgr0khtrr5TSWh4 bRmKN0U846QQxBHgaqxor/QTivW4IWst7pSPTDMsk5chC97uPgWn5QvIUhoi HZxhK7C6lQQtXopcl0zi6S/lGxI1EjN+9m81ck8UqTOZINg9ns847mEaeHFi 3oS1ygTSS89kGxvuzA8xw04yzLAPOZPlP/NtVr9AEAAnZh4hq5HigKV00O56 4KKsLciOQ3FQkE3TivA4xQMyVV6VggYhTOBauTkC62Q90lvLCTCee7VEi/+6 IU+Pqyegc0gjBdpXdJ43u92hPvEz3lDNK1JaqZcFiTgN3ThwQgv7rI7u/UBJ NwTDbl9xZM5fKeSCQwaQTKF41S3cKKeKh2A+VQBvgR7IzP/mgKleVYw7Ho3m Igz0fb810eObDikTwWdueskmeLws/YyFrR4P9SE7k/2xLfOtPURkOOkKcOxV xcGVZYG7b8tXzPLO02Qas3+HdIv+aiOtIBIEp6uA3+2zljsrago9C9RQhl42 jDLs2Sf05158pphzHAEIPdId1ruyRwMFpDMo5TDwnHcbanFf8xdonGTAiPIh G2k1DO19O8bW4YQ8cKJoXRbKmgxKrQ5HGzm0WVjWlAXenop1SS22hiMKAi80 LU7OwpQamWKhWgQVbCIYU60l+K1AHVoPkX3iIZuINZT+pZZByD4ovfMWZmkS yNs+QD66vWzPqCzmw+eh5ZjYWmA2MR3TXcoZ8sqHISfosfCWGVTSIFuog1Wp Bf4gClZ3RIdzjRGgeC5b0JMu85GsDz3RIghMZzWB2hqyFiZADH6RXzKcrX2X f3Yulmqh2eSQQdwIGPL2GYeYghqyUHQeOogB95xhmnlZABqyAOrOHfyGuC32 qB8gYZnbGKmtDeG7ttnvMdRbXpVZnXOM+eHAVO9ly+np3EtMe/Lc3UeY6Kwm mjwCiUBWLrvsu2iRAR4C5QVWNJBiIEu8ZmUFLGV1RVVfXDReNz+sI8DYm5tK FS8cI0Dme4Epby955N3G1Dh10jXVQeB66gWhc4H72lmPGNpVFpl27Eec+pj5 DOFFUZS4YCa63FOZKMIeB9vZyP5x3HWaXiuKyF5Edak6r232CkUlqawgnzal W7LmJzl9MGQr/gql5Y5jkVl2Oxwt7KssF1Tm3DqOwMIL+f9EdVpHaUVf7Uc3 5eyJo8t9eIgDtJOBlXBkiKvbBgpZgHKEZHTdC4s/74E0T+vHtp6czjVIA488 QkXfFIfcmkPUINfQs/ZEiuMMYW/kP+szohhH+GOmrEN6ChFtKFPXeSXG9DOE mtPD6frmPOYNi2OHkLofGcrzSDSXoh76wis6KI43Dh3kxrI2Z0U2uIDVIboM c+/CXSGn2wldyM2nIpe4Y8dALvCnQIcTvLc9euSvqllnFSmg8sj7pj1iaGmJ xVrsUyRWw9g7XVZBZ2zL+cgjmIqdbnIUOzoFu0gjE+aR59NkDvwPqn7eiqRv w0xNpw0j78SMJRG0DRctuVE2bsCJcjgV5eg3CDZgU1BmdLAYAdku/llMRFgW aYaB9yIMbSy0+FZTbph1LTfM0VSYdZOjMMdTYA41Uo4Fh+bVoXPAq1KqofhO eNXMcNSUG2Zd2w3z5EwV/kamCialqkBj8MQj//INbzk0C3aUZekQTM5JDpTF 2GnclBtmXd0N8+S0FvxGWqOT0pqvkX3qkUWOnQv2IztXkSifAhjK78Ra9VBO U26YdU0nzHRyBvTdGVAzOSX9YXM90ZzliVqQDL/mCazP7+RimuhQbttraDmt 1rXcO7Q+fwtwgKlM3P8su94xyJAzVl3DOsegFLlTFxUPHuRvxTLjt2IjE1bd xvr49rwCJwCnBtVZNuj6OLng+FzC2bNPuUGJHQ4yzQGC+6cxusIwObFGq3+u Y2dROQjSZe0TbzEH0kWbdZ+V9duoeuQ8JqyhGg1dVD536jDhEm26bbshOS/S DViZSMxlpuwq8hmeri5pFQXGtt+qCK//ACCxKhMNCmVuZHN0cmVhbQ0KZW5k b2JqDQo5IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNl Rm9udC9BQkNERUUrQ291cmllciMyME5ldy9FbmNvZGluZy9JZGVudGl0eS1I L0Rlc2NlbmRhbnRGb250cyAxMCAwIFIvVG9Vbmljb2RlIDEzOCAwIFI+Pg0K ZW5kb2JqDQoxMCAwIG9iag0KWyAxMSAwIFJdIA0KZW5kb2JqDQoxMSAwIG9i ag0KPDwvQmFzZUZvbnQvQUJDREVFK0NvdXJpZXIjMjBOZXcvU3VidHlwZS9D SURGb250VHlwZTIvVHlwZS9Gb250L0NJRFRvR0lETWFwL0lkZW50aXR5L0RX IDEwMDAvQ0lEU3lzdGVtSW5mbyAxMiAwIFIvRm9udERlc2NyaXB0b3IgMTMg MCBSL1cgMTQwIDAgUj4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9PcmRlcmlu ZyhJZGVudGl0eSkgL1JlZ2lzdHJ5KEFkb2JlKSAvU3VwcGxlbWVudCAwPj4N CmVuZG9iag0KMTMgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9u dE5hbWUvQUJDREVFK0NvdXJpZXIjMjBOZXcvRmxhZ3MgMzIvSXRhbGljQW5n bGUgMC9Bc2NlbnQgODMzL0Rlc2NlbnQgLTE4OC9DYXBIZWlnaHQgNjEzL0F2 Z1dpZHRoIDYwMC9NYXhXaWR0aCA3NDQvRm9udFdlaWdodCA0MDAvWEhlaWdo dCAyNTAvU3RlbVYgNjAvRm9udEJCb3hbIC0xMjIgLTE4OCA2MjMgNjEzXSAv Rm9udEZpbGUyIDEzOSAwIFI+Pg0KZW5kb2JqDQoxNCAwIG9iag0KPDwvU3Vi dHlwZS9MaW5rL1JlY3RbIDU1LjM1IDI4OCA1NDIuMjUgMzAwXSAvQlM8PC9X IDA+Pi9GIDQvRGVzdFsgNyAwIFIvWFlaIDMzIDE4MCAwXSAvU3RydWN0UGFy ZW50IDI+Pg0KZW5kb2JqDQoxNSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5 cGUvVHJ1ZVR5cGUvTmFtZS9GMy9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaS9F bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgMTYgMCBS L0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAzMi9XaWR0aHMgMTQyIDAgUj4+DQpl bmRvYmoNCjE2IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRO YW1lL0FCQ0RFRStDYWxpYnJpL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNj ZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1 MjEvTWF4V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9T dGVtViA1Mi9Gb250QkJveFsgLTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZp bGUyIDE0MyAwIFI+Pg0KZW5kb2JqDQoxNyAwIG9iag0KPDwvU3VidHlwZS9M aW5rL1JlY3RbIDU1LjM1IDI3NiA1NDIuMjUgMjg4XSAvQlM8PC9XIDA+Pi9G IDQvRGVzdFsgMTggMCBSL1hZWiAzMyA1MjggMF0gL1N0cnVjdFBhcmVudCAz Pj4NCmVuZG9iag0KMTggMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAw IFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDkgMCBSPj4vRXh0 R1N0YXRlPDwvR1MyNyAyNyAwIFIvR1MyOCAyOCAwIFI+Pi9Qcm9jU2V0Wy9Q REYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg MCA2MTIgNzkyXSAvQ29udGVudHMgMjYgMCBSL0dyb3VwPDwvVHlwZS9Hcm91 cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0 UGFyZW50cyAxMD4+DQplbmRvYmoNCjE5IDAgb2JqDQo8PC9TdWJ0eXBlL0xp bmsvUmVjdFsgNTUuMzUgMjY0IDU0Mi4yNSAyNzZdIC9CUzw8L1cgMD4+L0Yg NC9EZXN0WyAxOCAwIFIvWFlaIDMzIDMxMiAwXSAvU3RydWN0UGFyZW50IDQ+ Pg0KZW5kb2JqDQoyMCAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDU1 LjM1IDI1MiA1NDIuMjUgMjY0XSAvQlM8PC9XIDA+Pi9GIDQvRGVzdFsgMjEg MCBSL1hZWiAzMyA0NjggMF0gL1N0cnVjdFBhcmVudCA1Pj4NCmVuZG9iag0K MjEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2Vz PDwvRm9udDw8L0YxIDUgMCBSL0YyIDkgMCBSPj4vRXh0R1N0YXRlPDwvR1My NyAyNyAwIFIvR1MyOCAyOCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFn ZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAv Q29udGVudHMgMjkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxMT4+ DQplbmRvYmoNCjIyIDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNTUu MzUgMjQwIDU0Mi4yNSAyNTJdIC9CUzw8L1cgMD4+L0YgNC9EZXN0WyAyMSAw IFIvWFlaIDMzIDQyMCAwXSAvU3RydWN0UGFyZW50IDY+Pg0KZW5kb2JqDQoy MyAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDU1LjM1IDIyOCA1NDIu MjUgMjQwXSAvQlM8PC9XIDA+Pi9GIDQvRGVzdFsgMjEgMCBSL1hZWiAzMyAz NzIgMF0gL1N0cnVjdFBhcmVudCA3Pj4NCmVuZG9iag0KMjQgMCBvYmoNCjw8 L1N1YnR5cGUvTGluay9SZWN0WyA1NS4zNSAyMTYgNTQyLjI1IDIyOF0gL0JT PDwvVyAwPj4vRiA0L0Rlc3RbIDIxIDAgUi9YWVogMzMgMzI0IDBdIC9TdHJ1 Y3RQYXJlbnQgOD4+DQplbmRvYmoNCjI1IDAgb2JqDQo8PC9TdWJ0eXBlL0xp bmsvUmVjdFsgNTUuMzUgMjA0IDU0Mi4yNSAyMTZdIC9CUzw8L1cgMD4+L0Yg NC9EZXN0WyAyMSAwIFIvWFlaIDMzIDMwMCAwXSAvU3RydWN0UGFyZW50IDk+ Pg0KZW5kb2JqDQoyNiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCAyMzcxPj4NCnN0cmVhbQ0KeJydWltP40oSfkfiP7R4miOxxnc7K4QU AjOHIxhmh4xWK2YeHLtDLHzJsZ0w/PutcneSbpPqZFcowiZV1eWqr67mYtx0 +TxJO3Z5eTHuuiRd8Iw9X0zr5a+L6fuSX3xLXvIq6fK6urpi1zcTdj09Pbn4 7DDHZdP56YnDbPhxmBeyyLEtn01L+P7Lkxuxl/b0xGYv4jaWt19OT54/3VUd byre/fGLTf86PbkFkSh2I2vkWaHrK/KeP/2DIHVs24pdjfSmSeaUZMcLh+SM Ih19kHw5vX9iT11TVy9svOoWvOryVNiGEOLFgQWWOOY8b+Ra/nGkfuAMpT7x ZcfLGW+YazsewRcEruUcdUIQWSELR7HlxXso2e3DhF0Q0Lmuu64uTehRIOOA Lt4hw4QMFbEPGjBkcajQPSTFrEnyygwyjYXGQmzZgU57+3uZN7xlNzwVhqfU csHcA17HO6eofdeyo+O08vwRwkCjNXjfi+KjRfsj3xro/Ay+5CRevMgaiCZB 6PvWSCf9ZcTrUQr3gI18grIHLLv4hlB9mNzdMHsPHAXmUcYG848VgyBnaZFD pLM2z/g5dT7Y3QoDnT3RUgTLW9KRXh/PGvMsaSGcgG3Ac/HZ/ZB6RyE6VmW/ tO0ggk8Anxg+obi3Pdv2J3DtiGv8m38Nn1jeh+K65xvtrq9D8Z3tXQ21+VAI hBlDd/coKcdMgWbgbAkhAzaBR8tWTQ55lLJnGGLUaHLQFxT5CPLsgByTNRmT PsazRv4nL4qalbxtAedUWDjwcJHOd87eFnm6QPfWSw6Iqc1JNbB3vPO6eeHN O0swfb5SySeILd/VGclEFQaQ1XTa2Tt7uJs+UJZzwt4UKodF0bpeb+VjNHG9 Pu1ptNMFbzgaqqrZyyppEgACR4MpUdYtko4ZPC2M6CmVKTscIaFvxRrTpcR2 KOMhEPd+ZI6DbfyE8tqHj4wtjLP+/rP4BBMpyzXEm6v/bXtGLHi2+gCdP9ov A8/vz5zs+JDmf49ZN1Ritq4qnmLeosAgWymNy5hzHTLn2u6HnNvyZg01FXMu 3m9ho+dUsuty+jBV5ZKpII6teEC7xeDOCofCGlCiJyoJZ8wKabpq+lz3lneL etX14ch4suZt1tTLJXxFGdmHRAXaadKNRnYpIweh4qcxa+titXmubgFaLpt6 VvASFDZnZE0OGfyRh9VQo03YW90Uw2AdZGSNg+r5ZbnUaN8QKMvVrMhTlkFf lnY15NV6TjrNcaDx1ERQDx44sTXQrAcn2bT4Q3IzcgJ/b6lsRSpMoCq9STS1 6K3XCu4BYVA1GjJL+tjjRwPZdVmuqj5yAIs1hldi1sxXi/gigVgoWMbXdZ6h ZZPqnWyGIKYCnZ+Eiqg/Gq2pXEH3OBRNlitoH4eijcHj7R9SEABesGmwLbPN VNpJXa0xWdVVy1bYzuWVCLasTlclfGPuZjRZRsV9Kuqxj9+KuKsY/52Uy4K3 5+xs8s8zcGHGzp7gIq8y0Z8VeQXIwxaNQd+gJDIkNT24H7u7k2T2hl5vielz zYt30kmicdbYjc8akM8aKOaCVoO9QoxAzsladvbw42l6di5+s6+P0zNKm7gf 9DRRwPb99l8/7r7f3qCIpz/H9/fbi14YORUIvfxwJwy4Hn/cS0F4JQXAEZPH h4fbrzfilIfxf+BX75/Hb9O7x6/j+7MtfIyneYrHNzjrUwXkjhmUUVy9QBeO LXgCSORt2uQzgc3vnyfmxlcTTqVnWbM0WtdxRmSuCm0YCDXyZ9AEWcjB0A2s wQkUvgLPHUon7efbMG6SpB+QGJJIxK2GEnVazJ9jVLVcIvMtLwqWLJc8afr2 QCT9rZPE5MiMHvdGCljrqgDQQ4uE/hybJwqNEaA8GX97sth9/Qahm8L4iTmr xUyvKoxIqupOoumQarEC/QHy0qRp3rES0aiTCVyTQqHODUaYMzXaHnVt/lL1 JbVKOQUS2QRqzEbXR5TrvdA94HoGlbRJUrAF5KWrqzMciVOeoSUS9FomxmNM xD8/tT//OGRiHLC8rYkz2Tsk0LtCps/xqSEP/72CnqjPBC1gSlytWjyz0xLl ocNwhNocVuRt78oZtBJkUdxATWWcok3SbW1kSQ4nN3yd8zc0CgAX1E1fAcg5 GiOf9zA5oBmOIZsD6obN0RTy8fhvMESad4RJJMRBJ0Ai2YjHI8g42ilGgMT7 WwkPx4yNAM/cSmi0Y4o0ghBxfZ34S1HPksLYB+8ZkmUnpkq6pEdh/Pv1keOl G9vYtGk6yl4doEf13R7UBTvSuYw2H1FB6UaxasmKd4D2V7SKaFQgDderIoPY qCG7YdEtk1e4WCd5kcBUxNZ5ApjETY1U2+Q3HJS2p+HzsXY1K6n4cF2MD40n 7zCuoP0ybLCkszQ+XoGy5lSq05MdnZzfNGppKvP8pnGQ2VbMbxqteXNArmtd XwEHmmvjUMrcMD7Yrs4G+de8TdOoyRdREIjxgBb9nvebhLxhCuANywQv8nFw 08TQg5bc/GrUZJtle73VVVqRISgG6FuHqmAykc19P4Ia48BTKtOihvjqmlWL zQ1ZKwAXrs5Hbp9EXdFoDyxFNVqcD3b5UU8DDcd6gdNQp1EZH9aJ1UDsmhyL cFmLElS2vFjzlpyBvKgPN1WGOSDIXZqDA99Gxr+hD+RizsfYkJOcOaNoAirO M3IfJDKKRk/KFs2ZRpso2zXyBVeAU8dRR3igTjyghTBLpG/JEU2iXONDYwko mFzu4MgqObCd4IDteVOX+7bXe8qtA0URUpEi5VIufWO5UB7LBTEup2//3xc2 8NuTy+lAWRSHyvJ4wx/J70Y7Glxo93+PD1d5McepViGbqTC2HI2S9E4UAI1K OT00ADuR/cEtwpkwr5RJJqp572Kct1rxOv+ovbJ8wujwO2v5hAollPNFsu67 fLP6uHrY8Kzy4sD/SKjkB/5HQiWFHhvbd2yBNt2QTOvqBtJco1R59GDVb+JV 0gOLeJV0Sr8GkgsJlRomy1VTcWrDLKF0hCbCD7i12fMCcwslHCZgGM62768U ono+581m38dNfZw4C1cO+15DUv8lIKufyneg+KmkPe5x1ixLmDtRX5jhGrIw 4OyG7lYk1OK5OE5w/SrYHDBHqCkDRqFU7Wk0nrtLDmXelkmXLsiuQXTbKsuH OvtfTghUtQ0KZW5kc3RyZWFtDQplbmRvYmoNCjI3IDAgb2JqDQo8PC9UeXBl L0V4dEdTdGF0ZS9CTS9Ob3JtYWwvY2EgMT4+DQplbmRvYmoNCjI4IDAgb2Jq DQo8PC9UeXBlL0V4dEdTdGF0ZS9CTS9Ob3JtYWwvQ0EgMT4+DQplbmRvYmoN CjI5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE5NzM+ Pg0Kc3RyZWFtDQp4nI1Z227bRhB9N+B/2McEcClyeS+MAPKtcJEYQa2iD0ke aHIlsaFIgVzacb++M0vK2qU1KyFQZFlnhrNzOTszns1bWS6zXLLLy9lcyixf i4J9my2a7Y/Z4nUrZl+zVVlnsmzqT5/Y1c01u1qcn83uPOZxtlien3nMhX8e 8yMWe64TsMUGvv/jkcds1Z2fuWw1fEzGj3+cn337cF9L0dZCfvzBFn+en92C SlS705X6TsQDTd+3D78RUM91nYQb0Js2W1KaPT+awhkFTd9pvlx8fmSPsm3q FZv3ci1qWeaDbwglfhI64IlTnuen3AlOgwahN9X6KLZSbJ5Ey7jr+YRcGHLH O+kJYexELEoTx08OINntl2s2I1LnqpGy2diyR0sZD2zxjzkmYmiIe9SBEUsi Dfclq57arKztSWaI0LmQOG5oYm9/bctWdOxG5IPjKbM4uHsi6/kXFDrgjhuf ZpUfpJgGBtYSfT9OTlYdpIEzsfkbxFKQ+eLHzkR1QEGDwElN6A9rvp5ksErY OCCQKmHZ7Cum6pfr+xvmHkjHIedRxy7n/94WmYQQy4ZBsTMgrJem/cmaJetE +wwhzwXWAHIAoMqONVtRI3rdVIVoO0RO7J3d8SlzDs+N+NtzL103jF03uIJX 4rquD+/R8HMYjt9dwysd3/G7YPw9YK7gcxgNcqE/yCAuTE2c0ns76r0e8Tud wfDZByy/g/edvmiQV3ZweAH/BvNRF+pOTNvx+zd7dTuv9/Ku/2nqo3e3y+Cj 0N3HJm/qWuTILA5jCy06WkxYARWay6Z9xeCUdSF+AUU9vbL7ByqNPA/4yHjQ 7cJOkr5GkllRACV0DkUjHtwG3BSxpql3mDUjT0vSwLHbp2PnRVGiy7KKspCn wIqmEEmKw11qYPGCzIybkRDmUYSseNKDeAxUPcGW2EHA7SMosgMfw21K6n/n ak4xApTEXsWDyFriiUBTAdwnBpw60Xj3GFhkGFEXyBnoxQ7yCNzHRCezp6rs 1hvw6YXiIfy63Gwrgb9STrZmQBhr6fZSVhXLM/jPngGGkFy3Tb9akyJJjGlt iGSkTdxNnCQ00W/RZMumZUtoGapJGl2wTfazrFfWujV02n0C6be39TkrK3Cy UN69f4CKHwuZZRAQ/OVxFvfdFJNUV3w5ct7dyH8aH+45+jj3+XAlQSobJusk R13hkQv3rCHVd0B/6OEDRzLdEwYTpj2SyAZekbKdNAwBRiYW9rkTMFL9ePvC QfKqhBxhL01fqUDVrBWyb8nkC3zVXhkax+ymJBIOnZBpLwlNnXe6jzg64Ieq 4GUtQFKdsG6kCtdwUortxuTTtZFdoxep+jOeXGClLUtRkHMMFG184gPSSPnY eECn6rlpy/8gBaFDsjrFB1oMd8WZ51iI8i3sZGaNLKQLWxnfJxnfjfYq7pfa s/Uej6I36IQxFLqOfa/S0VNCgBOGIbZsmw0Fh84Y46HD6bnIVfHQsbV4GTOq u2ClJDM6DpFWdclujbVG0nDihKdZFfLQmRjVZc/kzBBP7bDXFc4v+xSSrBJZ J1nG1lm3PtCV7+c8oFpuSu+Lz2gts45ts1aiMkRAmjY9WZ+DXwy1dr8YUBhC MnJCCk5WrPwCbLbPL6AX85aFHpkteyBQwaoGJvfOzjeGNqouR74xsNa6DA43 vUGY7BWE9qbXwD6KvG9L+cquof6A6Vp1VOponPsOD00NVnNDikYCX4vKJbTe 0E28ApGM1uSGNdQCiaehMscnIvzOnIjwnqfRYnTEezr2fv4wP81zu+LxTiXg mPKcn0QHPKcsMbxG+QzIEbjU0EKGO0zRvwaWjMUwsxhY6wGTw7HwI60UYnss DCyEIa96+ybUEOhs4Ro6MQNvPU1KhgvnWX8arlwZ21mTexgFDHn7PHxob4Me xTFvpyE54lEd+5dYilbU0GLYxyFDyG4iMbNznPV2GlK7iQZ2nv+sm5dKFCsc 90g7oxDtNCTtdpIDL6b5m47FGlqeosn7jeqz8dZrBVx80MVBbOsV4+QVwbFY DGXUEn+8TgzsP01LNqPDbH+a6gD8MsE+Az04UsAEDRe5UzSSurqG9seQtfuU bCk5NsP+WxlvX9tytZbs+4f8+0d6+kmQTw1RXO8eaV4M/P3t4o4t2h6bn3GU 3Yq2w0Z03/NjLzN052R7OhzC15Jr7HvyphAOm1cVUyfqYP5SrXJB+XS80Axd dqce6gcGe9xIr+Si7GRbPvWqkcHTwriLDU3X9C3MVPibJ/KvAbs80VVm7StO yxtokV9KucZpDN+bnuyXlVkYhzcdm6YYOka1w4BaAvdvSinB69u+7foMqko2 F8q6rn/6F8aE3bq5KnNRd/Y+18OuateoguYOaVdmZQ36y3pYFz3irmgI9NXj Dfs8qu2ExNPBucBHj8N4cuq22ovf/mxz6brwyfW8YdmhlsR8WE6rnyeLbH4N r2RcLKf7JbNaKCf7BbO+xMYFNMrjohkXyLhQUXK+togeF9cooy+Xdzr8cNRx N1lCawtstdjmtJ18/B7PqWx1zaXOqQudwYXYYI6R+/5hLeX299lMYqUK4ZRC Lp2mXc2oPS0PArw5dSVDWCl8ov6ApeMpxhwL1FBdL5vvH8kGf6BjXeBdQf8P 3Pa5Wg0KZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAgb2JqDQo8PC9UeXBlL1Bh Z2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9G MiA5IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1h Z2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3OTJdIC9Db250ZW50cyAzMSAw IFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0Rldmlj ZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDEyPj4NCmVuZG9iag0KMzEg MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjI3Pj4NCnN0 cmVhbQ0KeJyNVctq20AU3Rv8D3eZQjqa90jFGPxKSetAqAWlGC8Ue5IIYsko U2j69RnZdSPJvrIweHUed86cuQpGhUsfk7WDwSAYOZesn+0GlkGc71ZB/Laz wX3ylGaJS/NsOITxdALjuN8LbhgwDvFjv8eA+h8DocEwSiTE236PwlP597Xf W17dZs4WmXWfVhB/6/dmnl5KHHmRIJrLCnd59RmBMkpJyGvQaZE8YspM6CYc MGh0ojyI5wtYuCLPnmD02z3bzKXrQw6IiAgV4aaTn4g4kd2gUrGm6sLunN0+ 2AI4ZQLhKcUJ6+SgDNGgo5CI8AwSZncTCJCajHPn8m1bUyr1YH4WcSkYDeUg 9GKAGkJdwd0lLw9FkmbtJatR8C6EhKo6dvZnlxb2FaZ2fQgeG4v7uBtcJq4x tOSEmm5TCRmVNahhW25fmLCztIwkacy89Hdp0b4IQxrSCoNKSaI6dNXa104D 7wtrJILcFxaC+7Kqd5PbKdDzddSlwrHx5QvPC8TP+Oh9e2qE1wY2uOHNjejP Ihu0AaVjPWwyT3bpv7rWDNG6HpZi/TSbjW/rq20O+Z+jlTfA9U8iZGciPKwN RT8kvifFC1x4iaxcZ7zOa7XmqLWobKx76/7CrPzS7IrUH/wa5vMJMgKnIQlV nd86gkBH4PpDwiij4CfM0yyz8GNzIfoqs9VcouascntxkazfrmEygsg/T3PB nHW9d4WaU365msd3g2FP7DRmp6JKXWbbJH35gr8Hv/l4nXHsJCQOfiXPeY41 Q+zXd42L+XC/BXUDu8kdCtf6RHqdbzF0uP8GoYOcJGfQ5EzXloeohGqryzvG yB4SDQplbmRzdHJlYW0NCmVuZG9iag0KMzIgMCBvYmoNCjw8L1RpdGxlKE5l dHdvcmsgV29ya2luZyBHcm91cCkgL0F1dGhvcihKb2UgVG91Y2gpIC9DcmVh dG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABXAG8AcgBkACAAMgAwADEA MCkgL0NyZWF0aW9uRGF0ZShEOjIwMTMwOTEzMTEzOTUzLTA3JzAwJykgL01v ZERhdGUoRDoyMDEzMDkxMzExMzk1My0wNycwMCcpIC9Qcm9kdWNlcij+/wBN AGkAYwByAG8AcwBvAGYAdACuACAAVwBvAHIAZAAgADIAMAAxADApID4+DQpl bmRvYmoNCjM5IDAgb2JqDQo8PC9UeXBlL09ialN0bS9OIDEwNC9GaXJzdCA4 NDcvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNDY3Pj4NCnN0cmVhbQ0K eJzFWNtuGzcUfA+Qf+AfLA/vBIIAbS5I6uYC20AfCj/I9tZWbUuGIgPJ33fO 8khympXFZVsUkH24S87wcDi7S9JGpZXTypNypEgb5Ywib5WzyminnFPGe+W8 sjooF5T1UTn8dFIOP5+VZ/TA4AP+jApkFBhCsArQSE75pGJICo0TOMGQUBG0 yoZBKkeALHq3SQWHGJ0KSIMMWnnETCBVZJAbaMii85ARkV2IiDmoqBU5gEJA +ugygs8nrUBFgVAPvgBwBF+0qAdfTLgPvoSkI/hSQj34MgQB1GgMOQZE5J+g BxJQCYIQUk9GGdzASBBBkkgZa3E/ISKflJVxFvUREaCsWUjUgy9A5gw+zieD L0KUDL7IWoAvGdSDLyF5UBnOx6NdRmWOyhLGkxMiRMhZWSQC0QgFHjXIrYVy kBMFHg/orUNupDGNDpmT5om0g9QoICeCpDZAf9IgDOidMKc2wgZEYI7IA/Oh bHIQCvrarLkNCDNS44wcy0XE3oBeRHAHQzF7KPD0GjgN2qEAsxmeSIwTGvHM suE4ecOWM8gZA3AucRWYh1Rx1/nEVWAOkAQ+QAHCkQVhhBkIgrshVQvC5Ngr IMyaG4Mwe24cYFnNjSMKkJxvDONnv8KcgPiAYQLhE+aXXak51YyYWUYNe7Lh CC63XDCoArt68aL7zHxaHXcn3efu9Nt9352sVw8X6ze3/V139LvSZ6r7fKUs t3n58vmzCghNh5jpEDsd4qZD/HRImA6J0yFpOkSmMk6fyikQMx1ip0PcGARP doGcfnr1/onZfIwaWn36+Zfj7tP5n3gnDww/MkdhPrmfLX5g3jTvjlTYQTb5 /zpf3Iwmk7gBf2UQRocTKjuNExQYMPwxG+30b2rEcTXw3apLLO0gdECNYEti bp8aW4ZDneZ6NcpA+KNdo0beo0atN0jvMIfMEYo5wl5zhFpzEE3Qo7gjVrnD 6HE9Yq07yOwwh+wRiz3iXnvEWnuQrdejDIUXYTV6mD16VPvD7TCH/BGLP+Je f8Rqf/gJehR/pDp/2HE9UrU/di/TdMgfqfgj7fVHqvbHhLdpGQovqmv02PNt SdX+2L1O0yF/pOKPtNcfqdofE96nZSi8eajRw4/rkWv9YXbv03zIH7n4I+/1 R671h5nwPi1D4U3Svk/8IQbz9HIKsNGvvC9Li1A+IlRCuSovSnk/yGMhbhAR eBO3J99tx+9oNNuGlZwZXcpVrWQpTcBQA8Y8jRkXwTZ05BowvgETGjCxRYTU 0FFumdUmK7R4QToyNEUGehr0lOkmYWxLcq6hI9/SUWjoKLZ0lBo6yk3z2uaG FjtQix/ogCHGQS2G2JwP6emv4kkY04CxDRjXgPENmNCAiQ2YNI6xG8xstR6V rqzknC6hrAtcWc64spZyroSy1nBlBeEEJ2cbBe4L3Be4L/Cy9OED4iEUQB7W q8PpcIlGopXoJHqJQWKUmCQKD2mJwkfCR8JDwkPCQ8JDwkPCY4THCI8RHiN5 GeEzwmeEzwifET4rPFZ4rPBY4bHCY4XHCk+ZjjP1eCFdJux01ffHy+W6O17e 9h9m98rKNmO26hdDrSpkw6xuF3bb2o/91/VR/223LX4LssVy3Xcf+d+bxeXu 4hRtz5dfu5P+Yt2962eX/aqUGbMpv1/czhf9yfWMU+QbPy3AMFvPlwu5Xq3n f8xQGK5+W65uzpfLm+718uLhDkkNd75c9/26mPPD7GK1fHT96hr/H12/ns9u l1ePbpzczi/7R21LP2h2tZrddW/nVw+rXsb68eHuC15hfGQ+yMxn5lwwm3My uzkicpuzEb85FAib3XDcbgO3+5/Nwp/K6Xux0nD+XtwwnMBvJ/SfPm1nijlq HjnZFpRBljNAOXGTMzA5cJITIDlukfMPOWyQ3b9stWXvKxtN2fnJNkv2PbKd +P5JLzn/t4976eN/eual83/rwX/+7C/emRpzDQplbmRzdHJlYW0NCmVuZG9i ag0KMTM4IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM1 OD4+DQpzdHJlYW0NCnichVPLboMwELzzFT6mhwhjIDQSQgq0kTj0odJ+ANhL ilSMZciBv6/x0qRJpGAJ0LKzM+vRrpvlT7lsBuK+644XMJC6kUJD3x01B1LB oZEOY0Q0fJgj++ZtqRzXFBdjP0Cby7pz4pi4HybZD3okq53oKnhw3DctQDfy QFZfWWHi4qjUD7QgB0KdJCECakP0UqrXsgXi2rJ1Lky+Gca1qTkjPkcFhNnY w2Z4J6BXJQddygM4MTUnIfHenMQBKa7yc1VV8+9SW7Rv0JQyatHz/xPqTJpa GM0Q/TijMc+uST0PYc+JjSIb+cF/CXYj4e0szEMlP7K1LESmrf0E7EL35jIM 2wu29y/D9ihBEZ3dJ/XRoXDBIT/869uiFzr18bJhdN+TIEAYtrDxrCchKoVI ES0ohehJtOBJihLpJMiot+BJukHYBek0bdNSnEaZH7U2U2w3x47vNLiNhNNy qU5NVdPzC6GoDZENCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMzkgMCBvYmoNCjw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDM1MjUvTGVuZ3RoMSA4NDQ4 OD4+DQpzdHJlYW0NCnic7Hx5fFRF1vY5dW8nnU5COiFkJaSbJgt0wr7TkA5J 2CIQIECCIFkIRBFFA6goJOrgEkDAFYUB3JeIdELUBFDCiBuKuLC4MAMqyIyI KzgzQnK/p6q7Q0AdfX/f+8f8vs97OE/Vrb1OnTp16tqRmIjaA3TqmT1p9MiQ mv4NxN1nEcU/NjI7Z0SkJXQy0ZGviMQlI/PGT4q7/8WzRJ8NJBo4ceSkycMD TDtPE8etQCMHx0/q0TvMubiOiBvQatGU7LEFvevGpqCtKqLwe0vnFc+/9r7H /0KUHon2JpYuWmB7pl0Z4hmniQJXzJ4/Z15tRP/eRD3KiUwfzimumE9OCkL/ h9Gedc6VN8z+7lDvn4hGor0Fq8vLimd98EXAFejPhfz+5UiwPCcQ5wV471I+ b8H1XU+1fwR9xRDFzr7y6tJix/tBU4l2WPFeMq/4+vnWn4K7ovxalLddVTyv 7M4PLwklOoD6lpz5V1csaEkmOf8dMn/+tWXzd2xalUjUz438WpKyM3XsGvTI Ss/MMNcZc5CZ5PNo0oRiGb66YUKKEfjTav2s2YnXIFVePggDnm5+EELfawQa 7+tnW3P8jyZTQjw0EjH5CLJSDzkS7VP0q1L0vbyaTGQ2PWTqgyYTvKFWTLNF hMkkArUgIUxC149SN6OJrs9SI8CTPzbLRm6y2RL0Ey1L5UjEHDexYRioXaLf LWdKur6X5sjSCOWAT7KFttMxcAt/KmZwOn1Gq9lJ23gvfUHHkVNDr9BB2s0R 9AGd4Pa8lwdSCZXRvdyeDlE4TaVK2kAFtJGqaC5q1FAhYjHUncppK7iAGmkV TcI8kyiPSumAGEqfY12PofcdtJrSUWMpahyiJZDDS1RPOzGaDnQlrUFeFXL3 0d10KQ2hgej1PjrF9wkX34sy4aBKtC97moSWzlMN6nlpm49ka3661EfneAJG cROt4qvVqJVYeDtnoJ8IjHUeWiqhe8HTyAN97U9P0qecysk0FLOZT1/wSczz TqrFWCZhZpWoJ8dUDo6gNcZ3mP8n3MxJaGcdRl4KyQfSXJFP7ag9nYUknXQU bYVjDpILID0vlSuapGgbu9CniwcL4lrexkN4P6Q3BX02QjIH6JRwGc10M1q/ D/2lY/Xa8SKezKU+jZPrsgRtytKVmKfkpcZxsRt9rla8Ae/N6L1KcRVa9nN3 yE1yOaRWgHqSZTursCKSJ0GKkjEKxZWY4TTI63mOp7X0Lt1oHOcIxNuR4CV+ lkhPQ1YP0mqRIDeISBAJEr3sf3gJcmVp77b4lfivP2KOPwIK8/FzWO9k7D0N I8mkBsxSYH4bOQzjDsKqIBnrtR15gi/ny+k56IaUkV9yfil5JbWkledCd+fS MMh5ext+CTXqoVk7ISu/PKt88vTL1CvPxa2y9HMS9F2u6SHVfwQ0Lo/mY1fK dD8jH/rlojsw+hCUC6Z4YYZ+bGczuY1zmE+m8SPMxH76Xu3UMvR4QO3SQkhD 7tF7MI5Z0JvdGEMpekggF3JLqQSrtpy301TWaQRPoeW0VYRBUzIpn8ZwDsa+ B+OeijXMoYWcitga8EKlyZWgRqXHNeSA/MPpOkpDL3IE0lqMoQLjLF1LqaDr UCIGI/KOohKjSFPjKKSuOLl0tXZTod1RGO9qyO5G6NU0hJF4Gwy6nvpQIuqv AUtL8gTGfx3mOZZGkB2Ui9afoFuoC92KWnehtrQnL8Ei1FMf42us2PWoMRc9 r8UO70XlIonH8GgeLbrwi6C1vBaxXNFF9IdWrxUubTk18tvQ7Q3cgR6lTXwd j8bqlnMF1qqemmA1lmH/daTxiH9PP9Hf6BF6lZ6lt2kTVnkZcnfSP7G+f0f5 +5R+NiGvUfG7ivwtl8HSnm93mWpTttjaHl+HFalHyrMii1dwEXfh1/l1Oiuw qfgwPwA+zI+C9/An/BHPgmU7zZWczwPYzIGcQvej9BdiDL/HP3Aop3A4Vvb8 /tsjNMFC40f4Ma7heTwRaeu5hIuge0mqSDAFqJJWjEM+qyF5zXeyWUDyeQaW 8lt6APwtSm3AXgBhJNJOe9Mf4Fv5AEb+FO9B+QSsg7M19Mf/Fx6Mfb064Ygi scst9BYk9AA0v4l38L/UOJWxQNw3P36D/9Q6V3+ab64/CzfwBMlKBpIDvLJp DS9+Qnzy8YUch/VtE/plC+09qMJ67HeZb6ZrVFjHdSq9BVot33/AWOWD+ai5 PEOL1Psc7NFb6GFaD0sCFrFYbegFFdMlkMgn0I1QaMCjkMQM+AcmrMMe0AGs xq3Ilb2sp/X8JZ/hM9jfc/l5Ps2fc7IohdQ82DeZlMxHkfI5f8270OLrkMIG 9HUIfsM7tJevgM92F+2lHcqbu4/uhAaG09fQ9h2g1+kh2I/beAboZdAOfoiP nJd2qxSkpkg5Jyh9IB4JKqAf6GP+F9brHSRJewq7iTE8iF27m9/iJtjBV6G5 jezEzojhyzhbW0JvqPob+SV+nF9Re9ypKFWR0Uq7IYG27+dpOEqDW8/P38tt z45f4uOwSvLM8J8Ov5cvPjnacqnyO7wsxyD7+JU63IMj6QwYthD2ORJ29HrF c0ElqC85D5rdFbZVnnfDMWa0BX1YwZfyKN4JGqXoOrWLpCb6tfGiXfR7w1/d bb+xC3+RHwCva7NDf40v3rm/sYN/tmN/K5Q72s8mkHz8VtO3y38W+q3pb4St 1uFXQr+1+K2wVZ6wKvA6f1BxhOA3Wtf11zgMu9RnTX3r77VEMpzmJXni4DZR gFOliTcJC065SLKIeNGR5yKlgt/mBaDN1EtaBRHPTRevgl/qsOR1SnoaTvr1 9KLfzrVltDcYvtwyESHiMYa76N8cqnyRB5Sv0gF+UAT0bQK8Dx0svego5KYr liVq4B/LlCp6Hjv1WnRbhftIB+ymz5V3tx1WsANSpWfnwu6KQr2tyrPbDd/p blhW6S+7sMuGopT0lB9W9Am8kd3QubspHXeaE1SGG4UZZMF4zNivgSAL+sLO 5R6tfqDf55Q9+23Aw7QCuuKtK/MsGIH0Ni+2PV4bs+0CD1Sy3w74vfsakNen vY1OqBH7W5E7PvUC+yNtSznucN2UB3YFYvI+N06d8OV0O2gJqIYeQ9nJOI/m 0EvwJaWHvB23ynBIroNPeoNRYhxOmTVUoagGEjoMvAu0D/csSe9hdPI+2ID1 kHfCTLydws1sBW2GhtWDa9DrjehVzqCRroJnV6VyLD4qaY09jdtkBGgep3M3 UDr9HachwzfCrY2bRTvRDvctt7oFLqbFoj9OlB1AF86pHfIsUCXWKnLxJty8 +vBYLuR+7Ma7C7c/IO5A8u6Wgb0zhF2ofQDhYJDsI0mLVW15WzhxvjU5V1kH /vw23q/6tMvWVM1U+V3Eey+E3J6ED9cOb89wJ35FEPrbgXGmonWzrAetOoAW vefbFfyibwOl4K0n53EyR/Mg1rAS70EKQ3AC9PPOEho8Et4sgddQb5zVcq1X YB02gty4EazAqSxXzqsrCyHrRtxEXlF39puhNTtUrB71aujf0J1UvA/GPr8f fvkgZT/D5Y0LFrArzhUZ3oAdmYAbhewpDqsruRP8ezfNRL1IzFTWrkSb9ZCy S4SKUGJQKtqdSrPVzk2ivtihq9XJFQ2/X97ILdhHU7G/5Q1uFexuCEieYibY KsnHW887B+4Tc30kS8RQIg9u3UVy98k9gJNP1ZD9vAI5yP4l+3fEzfC40rAr /CxbEmhrAXaGFTOSu3oC7KBF7ddIJSeMC75KLh/GDaQBvsmHPBR4DPy4Npo+ o0iewkuxjkihT+FtPY73GrytxTvxt7il9ADJNf4r3+izFn4b5rVjNfKm/zP+ JU9kI+zm+VvthSw9FGlBpPXxc9tvBpJjoBV+9n9DaPstoS1vVbYyvdUStf3O cDH7vztc/P2hLVuhM5L9d2TpsUiWVsr/nULyZNQfiLTVmGvJRdTmMeKNeG5D bfOwBy6ki+qJUD4Oq3C/YstFnwKl3q5pQ7LOetBuY7c6m9oSGQtA8dhjFxIZ XxlTQEtB8UagHLsaI8bCVVyj2p2q7uULf2uOvzWX39N3G5K7Tt7dw7FH+0MO 0Ms2bQsfzVU+fyoscKSSrvw4Kr8bIM+b0yqBPSAZloJkTXg0sG6pbcbjb9Ml UmEVHoSu+h/5TTEZ9m0wfSG/CeA++wj2zTHY4x2wxEPQ/17+h4+khR3Nx2BP B+OGIEvFiHa+dqSWDsH9IwmaKL8iSFpNLzJjH+2DlZKn1y3gGmibg7so6T9B t4KeoCkYUQxOIXlinUItD/LW4m0u8hJgcz6lg7h9h3MUrHG0up3Phid+lqNp P30HTykCluES7s8ODqa/ql2u0fvUArvdE/a6F0iDLU+FDR8Ci+4CJyN3CNq6 BPp9BjULqRmeuQ2nXB7sfDTSZEovmXJ+pTUb/Krb+G6+AXVn4F74soiDb++/ 1/qfwRQKu9UJJ34CfJ1OyDtCdRiREzLKaC0lPdJKaUHh+Y4EhSsbVIWduw8y uF5bjnWI500o5VBelqS10NpG2LLreC0dxl3wM3Wr2Atd+Bjj/N+6RbS9q/v8 yovv37/q1fs99YtC/3384nv5zzxrvyd+8W2DcO69DJQn+jqcd4XQ9lM0jmPh cxL8zGPQvinUH7gUKxrW+pU8XeliLXSpDOWnYU2WYg0Gou1A9f1R/leFFdCO QRyGW3AvngXS4CnkiZ68EFQC79iF9dsNz+oA0iOhO5Gcz+OU9ozi9ritn+Fr FPXlLKlZ/BU0bK/yH5Khff2wpvJcrMSpcJGVQUteCvHSxZaNTaC26dJjfwm7 oxtseZg6i6QHkY8wDDFpw2sUbVdf7Py2XZ7DOLl5qpdoF+3C+mLvYu5yry5A +fnwTQqUry1PMXlqyVPAe7u9kV/jo7h5uJTXVoVzqoorvV/R+Xouhy29HlTF STixqtSpshAncjlkbqI4SCKdPwUtAZ1U5PJrBsvHpGkMp5JiTF8FN9G/zAZO /QCjhYIoCPcKi8JgCgbCLwGGAs9ROwoFhim0UjtgOIXB64hQ2J6sygMJB3YA /oR9GAGMpvbAGIo0/k2xFAWMUxhP0cCOwH9hz8YAO1EsMFGhjeKNf8I2SuxM HYEOSjB+hPckMUlhMnUCplCicQa+jsSuZAd2A57Gzu8MTCMHMF1hd+pi/EA9 KAnYU2EvSgb2phTje1i8bsC+5AT2A34HzU4DDqB04ECFg6i78S1sjcQh1APo ol7AocBvaBj1BmZQH6BbfcvNpL7A4dQPmKUwm/obp7CvBgBH0EDgSBoEHAX8 ikbTYOAYGgLMBZ6kS8gFHKtwHA0DjqcM40vomMQJ5AZOpEzgJOA/oJfDgZMV TqEc4+/Q4JHAAoWFNAo4jUYbJ+CXSJxOY4AzFF5GucYX2OeXAItoLLCYxhnH sWvGG/ILvMRZlAcsownGMXi3EufQRGC5wssp3/gc963JwLkKr6Qpxmfw16cC r1J4NRUA5wM/hd0pBF5LlwIrgEexL6YDF9IM4CKF19FlxhHsiiLgDVQMXEwl wBup1Pgb3USzgEuoDLgU+FfswtnAKpoDvFnhLVRuHMaZJ/FPdAVwGc0F3gb8 BLeyK4F30DzgncCPqZquAi5XuIKuBq6k+cZHsJbXAFfRtcDVVAHErdD4EPt3 AfAehffSQuMQbMIi4P0KH6DrgWvpBuMgTlyJD9FNwHUK19MS4wD9mZYCNyjc SJXGftpENwMfVvgI3QJ8lG41PsCNVeLj9CfgEwqfpGXG+/QU3QZ8mm4HPkN3 GO/BxtwJfFbhZqoGPgd8l7bQcqCHVgBrFdbRXcY+nJOrgPUKn6fVxjv0gsIX aQ2wge4GNgL3wqbeA9xO9xnyG+oDxtuwj2uBL9ODwJ0Km+gh4y1YPYl/oXXA V2g9cDf92dhDr9IG4Gu0Efg68E16gzYB31S4hx4GvkWPGG/Q2wr30mPAd+hx 4D7g6/QuPQF8T+H79KTxGn1ATwH3KzxATwMPUo3xKqy3xA/pWeBHCj+mzfBo P6HngIcV/pW2GK/Q36gOeIS2Ao9SPfBTet74C+yqxM/pBeAxhcfpRWMXfLcG 4AmFf6dGo4n+QduBXyo8STuAXwF3wqq/BPyaXgZ+o/Bb2mm8DD+qCfg97QL+ QH8xXqLTCs/QK8AfaTfwn8Ad9C96FfhvegP4k8Kz9Kaxnc4pbKY9wBZ6y9hG hsK2Nt2ibLrl/0ubnvqHTf/Dpv9h0/8vbPraP2z6Hzb9v8qm/7/kp2f/D216 7h82/T/a9Gv+sOl/+On/0aZv+6+y6aS+1Unu6Ptlbr33F7m8jXSSvxXuLH8j SwJhV1g0F6zXaNiNqbARl8IeLIYGbrbF2hLkb2pRMhWWVJbJhF3ylyn2lelo GMbnv0KlRunRPx994Ge/Dv7FhwPo/A+MhZA/UbqoAKake39GEBxCFGYNj2gf 2SEqOiY2Lr5jAo4OO1GXpOSU1K7dnGnUvUfPXr379O3Xf8BA3wzdqJidM2Lk qNFjci8ZO2583oSJk/InT5laUDjt0ukzfs8Q/weP5gu31mMn/f7nv3Z13Jn5 7oxhQ11DBg8aOKBf3z69e/Xs0T09zdmta2pKclIXR2e7LbFTQsf4uNiY6KgO ke0jwq1h7UJDgi1B5sAAk64JprQcx4gimye5yKMnO0aNSpfvjmIkFLdJKPLY kDTiwjIeW5EqZruwpBslZ19U0u0t6W4tyVabi1zpabYch82zN9tha+BpEwoQ X5ntKLR5Tqn4WBVfreKhiNvtqGDLiSnPtnm4yJbjGbGovDqnKBvN1QZbshxZ ZZb0NKq1BCMajJgn2jG/lqOHsYqI6JzBtYLMoRiUJ86RneOJdWTLEXi0pJzi WZ68CQU52fF2e2F6moezSh0lHnIM94Q5VRHKUt14ArI8gaob2+VyNrTcVpvW VL2iwUolRc6QWY5ZxdMLPFpxoewj3Il+sz3Ri4/FnH9F4xFZBbe3zY3XqnNi LrfJ1+rq222eTRMK2ubaJRYWog3UFUkjiqpHoOsVEGLuJBt6E8sKCzy8DF3a 5EzkrLzzK3PkyJSiK2yeIMdwR3n1FUVYmrhqD028wV4XF+duxFEel2Orzi9w 2D0Z8Y7C4uyOtZFUPfGGrbFuW+yFOelptdZwr2Br24X5IiGhbSNlrXkqporL WO7EVsmyHJFjNBTCYyu1YSQFDsxpoISygVRdOhDF8BQyanlmYUUu9wRlFVVb B8t0Wd9jSrI6bNVnCBrgOPXVhSnFvpSAJOsZklGpJ62qhnx/3ON0erp1kyoS mIU1xRiHqfd+6WmLGsTljvlWGwKIj/Ig2+LCwT0gfrtdLvDyBjeV4MVTNaHA +26jkvg6cvdwFnpEkcxp8ud0mCxzqvw5rdWLHNDkerXFO3jMya3/wqxR7XPK B3s46j9kl3nzcyc5cidMK7DlVBf5ZJubf8GbN39ga54v5mmfVaDFC19MxGsq F0o5vbWwfCkI8ehJ+BeglHpWQ6AZWqlS2DbCYy0a5cVCi93+Oys1GN/KWio4 X803TM9g54XvQy54v2B4IdUaBqwni9z8adXVlgvyRsACVVePcNhGVBdVFzcY VSUOm9VR3agla8nV83OK/CvaYGxbHu8ZsaIQkyjnwdBWQcNrHXzHhFo33zFp WkGjFUb8jvyCOsEiq2h4YW0X5BU02mBzVapoTZVvNvlGuQxNrxNmlRXf6Caq Urm6SlDvpQ1MKs3sT2MqbRDeNKtKw5O+DU57k9ZUN7mPuwHBYBVsbdeld5UM g0NVWBfUJyOzh9ZE88FbwPvAOs0EVvpSNEoEZoBl6iqVv0nbTh5wE/hdsEzZ hpRtSNmGFOmMZGgNxNqL2gt1XRLRdf3W2C69v8mM07aSARbaGm05zvVE7TJf ONMXrkLYDeFqX7hSW143JDEsMwjvTN8ADbDA3NbXjRzfu1FFBrhUZJ0/Zd1W pCRmxmrrMar1GNV6jGo9RvUNkNHqOqSvQ/o6pK9T6euIVVP2rr6mfJH1dWFR vhREMi1aoTYFd8tErcAXTtWm1PVO3JlZpE1G01sUbtLygasUzlQ4XmGlyq1U 8atV/GoVz1DxDF9cYo82mKgwTKI2UZsE3yFRm6CNUWGeloN7c6I2Hu8yHKeN VuFYbaQKL0F6DMJclItAOEZTvwnSRuM9G+EovMtwpDaiLjuxZ+Z8vM9EnkB/ Mj0bY8jGmLIhJJmyCrwJfESlzARWgveBNVWStWxQFihTy0QNN9pwI8dNmuYG ZYCGacOQMxRlhwLdmkvN0YVSLvTkgqxcaNmF5XFheVwUqLmANq0f9QS7wXng IrAJ7aShXhrGlYYe0rR06oK27GIFRSK0+cJEsVz+DkvrJJbXdUp0ZwaJesoD F4Hng6tEfZ0pIiwzEuVk2R7g8eCZ4ErwRvAWsJkyvDnuYJEhMrTxYrymQ7u7 bnW5equwT39v2DHBG4bE9Q7LvFbrCjF1pY1gDUPuiiF3xVT9b4lgAdVJoZ3g feAjYCnwFAgjBcJIwQRTUD9FlQpQ5b4BG2ANSpSC9i8sY1K1E8E92rQiU1OR koq3VNRJRdlUpB4Bsqoh8/PAq8A7fXmdlTJ3VsrZGW11xmh7ADNULAyYqHWu E0FhDZAvDw7LHAC5jwcjU6yENFdCbiulhgi5iXsgJ8NXYhV4C9ikNYK6glJA qaDOIDvIBsIKap2weqtBq0B3gVaCVoCWYzUitzh3OsXMflf3q+y3qt/Gflv6 7ewXuF0Ug4pEkdtCUVE4CSPCzXGZVqHTdArlnxRuVnitQrfCaHfc9NBj00Pf mB764PTQ+6aHFkwPHTc9dMT00B7TQxu4xB3tDP3EGbraGTrFGdrfGdrPGdrH GdrVGZoZzoU8lULpZYXDFfZW2FlhAk+tC6WgHXwp2c3QeE6pt9+ceNzeoHNd 4q32BjOCW7xvl3qDITLxhcSe9jmJad6UZG/Qxf6SjhZoMj9Lgex0pwW+GTgz 0B04KLB7YHpgamBKoCMwMTDSHGG2mtuZQ8wWs9kcYNbNwkzmyAbjqNspb12R AVYZBOgSdRW3yl8mqQsay58mmwWNIU97LVfkThrOuZ6mUsotsXl+nORoYAvO VJNjOHsicik3f3iMZ4AztyHQmOgZ6Mz1BOVdWlDLfFch3jziDhxZ+QUNbMik ZfHSfW0k5rRlK+N9YWGhrFNQq/PKlYUUtSgjJiNiWPigEdm/AEU+dJ5/Ypxt XzCSBM/9uZMKPM8kFHp6y4iRUJgLyUlvt1EMFP1zshvFABkUFjRaqsTAnIky 3VKVXXi+HNmQnt1IdhmocmST5ch2UblOYoAslyQDb7lOqlynC8rVDrXnZNfa 7f4yQ1WZoReWmXNhmTmqzBxfGc1bxt6mTOBRsqsy9sCjPyvT6XeUSfrFMm2k WTbc+R8ebqQxfLA2a7G8KhQ5csrARZ7li8pjPFUlNlsjZfFB3y0iuaiktFyG xWUNfNBRlu3JcmTbascs/nm+Z7HMHuPIrqXFOfkFtYvdZdl1Y9xjchzF2YVb RxZ323xBd3f6u6vtVvwLjRXLxrrJvkZu/oXszTJ7pOxrs+xrs+xrpHuk6ktp PdTSTMML4ZuqcKsItkCBi+LthcOjrPOHKW0eYo9ZGr9NJ36KguGqh+DaFwqW WemZ6ZkyC7tMZrWTN0JfVszSIfb4bfyUL8uK5HDHcIrJuTwb/yoqfJHf+a+i omLBZRWXVchQ/atYsBAsl0n+GH0BYQaZIep8S4Q1lrZ5OXiFstFaRUXhAlJr WrGQZGsLJJxvvDW2EC1zRVsloIqLH6kZTvIymqtYyCglCy70qU2F/JMlNENy kL5WiPQT4LspHmEnrQQnNhlHfPyZ/Itwmd/SbBjiEArn+9j75IPuU5jPY70h zaL96rffDyCtD79DT5ObwpC+nzQmLiAX3UPX0QGabHyHVDs9St9QGg2icqNF /davhZfQo+z969uB9IH8vZtwaU79JIxjN+6p1fAtlI5W8ul+iqZ9aLGbYcH7 VpEgXKiVT29pM81pRk/je27S3zRK6BF2iYP6c/Q2neLOOrXcaiw31hnrqR2d 1hKaXzF6GfNQazIV0UK6CSOoog20lwvFULHTuFP9jXUZUl+kt9gJhSqCRzcR pf9Ea6mRXqZ99CEdZ+YwTuUq/oD3m6h5d8tuY7RRYlxNOTSO8qgKuQmcxJli mjZN26wdav685ajRCW3n0yK6nm6kVervzw/RR/QJa8Ii8sVkbTPF01D1l9Fr ILMNkOSbdITN3JcHs5tv42fFIl1r3o0TXqcOkOAoJf01tA4yfZy20G56l95D m9+pX3zGYvEn83Rewsv4Lr6XH+dn+Tk+KUziQ03TbtZf00+2HDQsxkPG0+g3 njqSDb5uGtbgEqznXvoS8+vGaZzB7wunSNNYD2luaeljjDQqjVeNQ+SgFJQd Cr82h8bSVIz6BrqVttNrqLuX3qEv6J+QksYWjoAsbOzgiTyJF2IUm/kbbhZR WL+B4kpRJ/ZrTm2vPlV/rrm+pUNLXcs3LYZRY3iMV4y31fr2Rz9ZWIEZNB9b TK7Y8+jnVTpG/6Az6COAEzHWUZyL+a5F+0f4HNTJLJaKZ4UB73e19qYeq69t Gdcyr2Vty1ajrzEWuqXB6YqlviD5jVD+1q9C/S73UfW3IVuhPQfpa47hTtyT R/MULuAiLuereT5fwzfyTZDq01zP2/kgf8Jf4+oYIDpATk5RKm4R94h6sVsc FMc00ibhDnONdqN2j1avvav9XbfqaXpPfaxepN+gLzbBJQuIMr99LvrcvOaS 5oeaX2np3pLdMrdlecuuloMtnxnBxk7jOFzRnhhjIc3BGJdg/rfRXbQR+vEM xvgpnaCTWPPvIQuNgzgOI05U65aFcY/FyKfCZZoNKucrIP8qruE63sFNvIvf 5Lf4fT7M3+Dy3EF0Bw3BLpgsZmMOD4ka4REfgc6If+Nanqb11vrgVlGE2dyu 3YH5PKAd1o7rQu+g99In6ZX66ybNNMt0v2mdabfpDdOXAdaAS3024rwFkd92 3xa79GHalbQJtwNN+1K8L1y8RJzlJ0UC70JvCbhv5YksMQS+0XZo+TyKDFwX YA+wi0iyBhbJNsSDIl2bqidrIbRA/lWImCZuE0X0BO+gs2IUNG2RtldsEjO1 dfrd+jA+hPvFLp1EKP9ImZTJw7B2H9A1WKF0bYsu/y6UTGbtnGmeCDVu10+Y hPY+7OBQFtoensanOE9EQVpDxF3kwLuVTyEcjR34ETS/EW7nQP2otkKMEZ8g 7Uq6h3dhjtvpSrGdH8G6DMR+vJbzeL3Wi5byNZDGILpC3EudxXzRGfo8mX7g W7gDdu5ZrE0XMZt0LVSU0n5RiFV/lyNEd14KPZ1Hy7ma0riZm+htsYb6c5n2 8rnY5lTB505xrTaKavms/qb+Jpzvs5BkAjTXDIf7U+j0OvTyGtm1ZGjNQDIJ 3OOwn4qw18PFGb5JXEmX81rtH/y4yKTxVKZViBF8f8sZPVPrA4ltgzXJChhk JpPLlKD3xYqfoGHqb7QooFw/YrpFxrUPtNNGoWFvmWlq13KYFkM6o2DdlmMv jaKPOYov4wm6IXJ1w5hCNWKLftiI5hC203sGdljL8+ziLoaNrzGCeQI0/DL5 /0jRl+vL9IX6TTibzsJq3kZ300P0F5wmj+HcSoEcL4E0p8P2XI4zoif1pn6Y 3TAaDqs0Gnl5NAX2tAhWcjZdRdfA8v6ZnqVanFC5kMdlqDebrkB6BU6oG2kp 9v/ttAI24H56gt4Tz4iNuOPeIV4Vi8Tl9DF9rL2uuXkK7dfv1CtpEu7AE7g9 eh6AVUpEvRXGB+itK8XD+vfFLoXeGyeNg8ZTzfvQ3hPyL9IChtPJgCxKpfH8 ox7HJtg3yFCfY5L/ySOQRtQGBDZwSL1gMukyopElwITIC5om4oICZdoLTLHm 8TfGOMdZT7vGNrvGWX90jbU241LvanZJ7tWzT7g9PMkebp+j0zmb1nTObaKz ZNObsJ9OGp+Jz0wmnESJNN4ddjD4eLAwB1rIyu0XxKH5F93tQykuOOo56zC2 DEt4DteoQA7cIUbjdGjhcRTjtP4449SxY9Zjxygj45T1FIdHDMK/Xj1hFrWA AEfn5BQtuV/f/n16R3WI1BQGOJCKJPFisogOj4gWSaKHw9G9LMU5dFg3Cfrd zdNscXE28URMcOfu3R2Wc+ahzjTX0G7pLnk/sogntV36++pvHYtq25kaxG1u C1uC5P9Rx3IoaJt4jILFy+4QW/jO8H3hR8K/CTeFb+MoEuLlrWbs/Qbx2PM9 zVfjXrZDPIjT/DvO887j9ClrM2Zz+hRk57K6IE9Mw+6bxfkI+hoRYIuNtQXw HBWNibOZ9Pdb4pITE5P5C29ILGa0nIM1OYGzNM+d0jWkm1WYotu1t0REBQSY rNFR7TsMa28aGxTUflO7LkRWLH1sxz3boAMxHLtMruaMsc2nXdZTVkgWCwmh DpLClaKdwX0jIgZ4ZRqIgyYyIlrJtXNKskgWM1zPpIS0i4gNvOqyy64KjI1o F5L0lJu/r2DBEx3BMeGWkD0tDY893tLwZoglPDa4M49pwX0wveWcqPSNtmuQ CIqLFbFxuhxxUERAdJTVFIDRWiwYNMYbBnURFJfw2Db4fb7x/ijHewwDVsO9 YLSRQgQGqEUf0D+iX1+R4tWI6KiIKFH5i6P97v9w9iVwTlVn++fc3GRu1rtl u1lu9ptJbpbJTJJZmCEXR1BBZKzIIo7gXhSFUepWrVKrCGqhoraKClbBrW7D 4jCI2FbrVivWtbWt6B9xqaPoR6nbZL733GQYQO2v3z/MnHvOSTLknvd9n/d5 3nMYzq+OVB+M2iT4tM/hI+9eh498Hj4t+EN1M/m0avVV6mWcQ2bUonl/h/6M dqI9QIM20/h/qN+iP7MgxKmGx/GvkAWdg4M18+4a3oXyQ/oHiuD6x4G0x1ff 8CtSzIBzw282xySLjcjwQaqBFqnLIQp9mg09CfdqpCT61AdImO3idqP8VPKD XJESLX5zD3X5RRfBZ3px5F2guJ8hOwqAP/YzVvpNq+Q4ZwuWkR6dU2Fl4F2J g4Pg+Hhbz7GtpPlsWlvHMeQb/v7dIzMNHxnPAbc4R+swm91YMhvaULt5Ej7K PMd8tvkCfJF5GbPMfDO+xbwO32fejDbjZ/Bz5tfxbvyheR/+wuyxmrF1AD+7 yWAdj+aYB3A/fKg5zLa8ARve4Afw1kcfh1XZ2zsM/l5fl77eXrx/Ycr1kN05 fCLv5yULdZfV6eAlY/yrWQmJtbmM93ocEmsFN3gP7vsDI2FPefzgBoGyxAZH PkeGkb39WSY1wQz9xpG9KDnyb+SGb9fIvzcHHGYH46AGR75A3Mjn/UFHlrwj PfK5FksZA46QIyqcw8gBAeVw0miPxhyRLiHTZRSMRruvC+L3j5sL8S6H1HTn IDaB+2Wuqi0vtw9WuAIRMwSOR3CoveaB3RdrJ1A5TvFKHsktuSSnZDQF/EG/ 7A/5aVNSaVRSSlqhTVabxWa2MbYGm9FkUKJ8XENh0adh1ZTQUJbOazjGRjTs l6BRbBkN5ShodGmli6k0PNQlqK3+wG0HPkAHai5eFqWKU+Y9FZ40blkWKtGB ka81DTpJZ4CHxs9BI7HQeByVGGmSTrcdetAYnPA6gyxYK1kLNG7SCzqlCPkh H2se6LBOT4i8K1ShLBw/3kMa/B01BPKxZ2MXp8dlUoGvUonTIcXjhq+GIswk lViUcrmcMPa4W5qFkuGDJaffOvnKXHAi64HelJ/m5MM59/TutNTYfsT1a7tV b2P7kdetpd7aUf3sjkvHlSI3dM04fwfmSD96Q+eMyy98sSsmxao7n9xy4Z+6 olIcR54k0bYL0t0H9BeAPY/2C4x/YOQLjeVNiDH7NX+P0OOnzewgdR+y4dWa mbPZWO4JM0ORGSPMCNhopPATTH2rvEHwOwdBq/LUmY8ho5mxSZRzK7UEcoWH +pNmQWfyPD4T8hu3jVoEIudOkKi6B5E81skND3E6/FeGSCbztCNuuEtoz3sx 96+9Tx00KDShXt3KfKQWzxE9nlsivHEU6lqplTgs+3zy8ALS4nD1E6eZlSyM RH/x9YkeUfB6BdFDN80wSTxrZ0j+egBW4g2IJRWHHzVR3dNnPea3qkbaidAA nrPJYnN2RY2AIpVh8uEKTf4tEFP/0DL+ePFI9hLH1cmrG69OrW9cn9pq25g2 2wWLu2RrS9OpWFpWnUm5MWZzWomn2D8ShtxfCcNuupEZXcm/PVZfSOM2vAuA 1YrtAGpzNprNFptvAH+5Uf+7twIDgKCHeeYdvisxwU4tBKrlgVkZXm+lzgFC +ovRqOT27SVBCQ2BvqEKrO8uoAj1ZUS1ZYToDITigtedCCuuiFdDYozXsCfk 1LAQh6YeXUuW1NYbHqgP96mzWyN1WgEoHG8dT5WK4K6mBlM909Txy2RqQA3D 1FVeWO1vXsXo877poYd+fO79ksls43jP/C0n3/6uMueC6puD0yPESD+6dPcn C384rXHB+p/0ehssHq7p7pP+urzj5PMXV/92J/HV34+8S8NCITD8hgVtGA0A arU0N5f4jvhR8cmJ7rbzkOnyyNVtN9GrSje3rSutb9siDnpeEF9wvuh5S/y7 52PxK89Inifv2+SMguH4AbBgADophrWqjbwhDx/Ei4yxAJLkcKOSkcD0G8Jh ITOAr9+gdLU44LpJ6DLFusoD2K5ZXF2GQKDd4OvID4IJAtSSx6xSe4vRZP94 EF9RMwTAIiYQuWvXMdxuWPupHGE5xBrDu2A4BDhJ4FJ3efjia6AZKJbiCdFJ GxPFmIZFo0vD8ZKiYSctaAjpdlkCD7i09fa1obY+7K7REGV/gm9pLoNdlJpF Wjz6SLfSaIzUjGQQF1/yr4EFH+RYD8c5Vz94w9Mnb+6VfZJ0ZN+qWy+deUOG 4628d+bFt6754ynUA8VNp/zy/RObOIHzsuc/tmjKyuNILOHlc05a2Vl0mj1c Y9fx2382/WbITa+TeAJWE0SgKzQ75PMwJUeMwVDADcu6e3Mw+ISbdQkDeJ4m OBxPuMKRyJmUAfiKgYqEwrDwjxkMtDEi22Xo9yMHJB/IV8EACQM3YmHO7TIM UFdqLDY6zgwGQ4iVMYSCPEidiyJ4jmaFGMJSlKZdNshWfwZzxPebo28q0M2+ TuCaw53A8rjOIdL5BCgUsE9CQIc7+Xbj0px6GfcURAsEzr9e7Ry9soWmPhwp 4RZ+lE+MdupA1MLzMWwwDL+CX3l4UsjnC03S2+qzpL09U52J555sSH7zR7J2 1X+NohGeS709HAE/f4r4OaxcBv1Di1r95kDUnJI6vMZs6ujU3NS5qV+lnpPe 8v7Ty0jEid3EiUXo+MMxxsmF4+6QD4eCEbQNk19Kh8n2C96lmYNdNG1BSkIc wP9PM3u6LL4uDgTFIHUVSlELNsErz0zEB/DfH+OkbIK2jLrw2JpN3QuShhsa 7q25L6HF+SFAbeLCOuEURr3X6w0YzQEj5G+vGRq/KahhifGMeS6EsKr29mF+ FCoIfz7Ec2PRGpyMgjy+fPI1XXe8tmfjheceoylejhd/2b/qyfVXXHll2A5k djKBEPqG6umh0D82PftFKdEacQuScP1z9/z8wYmc101lCQ4BfAqwuj5AkRhq wvdrtlzUGS9GZVWOyMrgyD5SetUcJXoc001PYY6nT2BMCVjgDbC+4fo1ql9j xfjAyKuahaAHvDvO2AfgnZfTNM04aSej0AqTFjvEKeIc8SzxYvEa8ar4VnFT /K/Wvwr/tItWbGQawiZFYuPhROT08KmRiyMXN56fX9S0Ibo1/brtXctum3AC A6SH44Ww6Ay5ZHfQI3FeexTF7baEVbHgpjyVy0AWSTWoaaPH5LDHCxAj6zZl uwwGs38A/0Nzh7qcxmSX2e59x9SF0lw6nG5K0+lt1Iugz+M4jmzU+seiXU0O 7JAKW3EbXrKf0vVOJbljuBeIO+S8oSFi6101helpr2VAAlOJTDhCixzLswJr MNnsVjtlytBpDYfF6AD+jeZCigW4XCLeyMCkasxqOMKGyDNWnLAnNZRqSOpu QRyD69SZHMG1Pj3h6GyplnpUPOYquqdA2iG+UvedWBS5nECfxlwHLzhm3elX 73jinnO2lbsrTWtfu3R6m9fN24VU1++r2yXlroWL1qw9/eQTOinx/HPfvvvm L6++9sE/33HN/DWnR1lJ8Fic1Uffj7y8+baHr7vyN8e1QlS+MlI1vA5R6UJX PGo2kMRtAuhKUyaTgXrCbLPbz3Qhp8uFXEAmbB6ry4YMHKbOtFp4lrPQnM06 CJGIqXs3esyS++MD6POuqTrxqejAA7jj0aOJBNNSR051EAQ6JG/jUqS2ECXo 4FFANywZXk+wxGCoPsS4HYLXRC9Q9LBYc/XXz/p4L2cRAIXfB83wvq4ZEqiA l2qHC/dEn0efoE9stI8OutTsTPV0ymh10F6/w+ld7r0R38rcal2VXKPelr0P 35XcRG23DNoG1Rctz6vixXhdhCo4s8Bs+gMxeWDk7/1NsdzgyN9BbHyxkWca G+NkLt0YHRz5GCVGPupPRiOEBglqo8bEulIpU7BLNOa7TPbYAP6LxqVSbk7p Mrzj66q4p7kp9wAe0qwt4S7unUyXWWo+RHaAi+4lVQMCRbt1RyV+qrtmU7bg D/EumpGFsIYCTsChXANohiYjpNEQD4jkd0GTZfIaKoDAGBMTJLF+W0mgXtzb h/q6yQaoOvLBBlADcCMfbACRQK5aE2gEoxdGRi/0MOlhrz7ntFVcXni5i8y5 yJyLzB0kDWbvz9+Aga2jUKjXGFr1tA1SAHxbPKBvEOefvXPt2p1nn3ViuuO1 m3/5akfKfuePFt+55oIL13h+c8UVv3nw8ssfpK5tuWfeTX/9601z7ymW2o89 ZflLLy0/pafjwwWrbzvrlFWrqg0L77773PPuvRdwUQRc9IBfJFAL7tGyDQyd blBR7v74YNykEJCMZaBxeKGxO+Tmoi0KTbO7JZPMuAgTY+cU3hO+jP1Pem/O uB3hAkFJ8q4BYnQ32P8j1AzrlIV3mZybCk8VXinQJzH2OFIctqS10ZwG9Qc9 uwITdpqNp7osRoJnmiUPgGaJdLntyiBglp1ar1niXayv5HunoSuzjboXFceg i9s7DERrH7jGe6jmDbsqNT3B68q0DlzJZC4ao112h81BmXigMyLn5GiTMZE2 g480WsFHkkrUFSdIJeIcTcQmk4JJBzQxLgLzm1DWlN+PXQeAF+pVCWD14f0Y Bn09SOtW9eh21dnyATkPlYpJZcy8rWXD9gkbTpp517zta897vNjdrqw68SfX nNDu8/I2T7LlNdzsLN0+/+xf//qMcee3RKg/nL/4tN+edevwz5c++F7/BT03 5ytRzst7rCJueT/95gurNl6/bIOmqWBnvVZiOAXZQfMVNDPb77Yy/cgkbMVu wAQauzdZrZIUGCuedE7laiqClFDwQSUU8fsKKmON4ZSe1nHHkO/hFQdUWU5B E+h2eipowys1+VETZszmOMJOZLYgUk+MIx76DOKZOXgA378BWebwE8z4fmTB j0PWuhk05gOIwY/3m7bgAeoB8BH4mZKApi3xDuAYUBYpj716Gts1NARfSNrr HZI4aJYyNUyFq1fvkKqUiOvRhnE9o5xiuM5t5aXoN/sM5qjEW93UEfgrm8RL YrWn2iNCxwZ/441wF2frd3G1Ft1uetn2uc1w0Kc/8K7m8PqdwB1NsMKdkLsg d1O/E0gND2g2tCVvwia4kZ4fw41EDryR4V3/xY2MFZFw3bPos79ZrN+JwfLN v+t3UjXpd4IfwY/U7oSCO0D0dvoGlEY5vFlTyzwkIP/4TGv2COEo39GZSdke occ91zc305P9Is2qKJ3O5DBFZS3cAHW35ravsK+xU2/bsT3F2+0cH7TwQixF nnIoSktaUVLpYCydMRv0KZOpRU+bQTOVlUR9yu2eIbjdohCUBD4aIFNHhlDo itDKkGFHCIdS/lAo4A9G/T5fJp2W/T6n3+8TeF6msqAYsvFYzALrjWWVzYVy VC5nlrIZxScqPonyDeJZoIzHa8604tdYcwXxmPWH/Dv9e/w00KTM5iZK4bOK MIjHI37kyQ28pQLC8EmNg9eyPEb8NP5TfoSnwXyZDfmJC8AwtaJFH4Q9Edi1 7rBevSA6gmSjXn0LABL6UqMuIpaCkZZeBlqC2V/J+Ky3L7/3qQMn/k9D/d0N QBrId620ajhEhuC6+IvgQ54wGGIGw4+H3+y7k9CD6h9IOwGf/4VeK7kH3zpB n36GyJW1qz4IvYOXVl8clSmGjzyi6Pn6d/tly1Lq1OHbya7JTPCh2eBDAZRE zfgMbdvD6QfUP1ietr5hMa5IL1dvD69OrFEfSph+HL88cb76o+wKywrntfEV CeZ47nTucssibhG/SFgkNkwOT40cFZ+iXu0wNrPjwh2RjkQlPU6dyB7BMea8 FA5E/Al/2p+PsWmVuZh7PP5M3jApfFTigvDV4eVNN4XXhTeFmQwDQlNFKOim GKOKcZBpCjsMsUZHczgZTCnupMLIQbnQ3OxmKDcTS7C2kC1vq9im2ebaFtoa bAP4Si2VTSCe4ymWX8k/ye/gd/J7eBPvKyYbQWqSjYM9BHZaJl9c8wkSp331 naBeXWISXgf20oUTV9P69eLWwZJST0pyPCM4LVZRURNpZzaLE5ZYFmeEVBbF rUoWozF+gvp6cV9fXy88EvyokXUA02nEfkOLkebWss6IIyCjyrWCQASjPmJf irv96XVXXtKz7uTh68j4aZyaO63r8BsvrG7A9x170fjZd1xb/fP0mrk3XXLr 3PxtJ02/9hRicqocC5zVOu2qb9xHntWuXTSenPEdeZs+mn4QtaG3tYuyTpxH FTQNGYxul3uG53Tnae75uUXO892LvBs9ltZAuWmye3J5jmdO6SzPD0tXBW7J W1oKbNgfxcjAONye1uZwTGbtyCBYYxtVIdFqvZaWE2qrgaZUs0Nh5kUUxdfh V9hCqJAvVAp0QWpfeoARpg4RDjA8TJZfr0rXVl8nAfXdHE874QPABtCUR6zH TXkkfuwJwOwCwGMBuwlZDY58vMnt9gS87joDnE0IIET6aO2rLkWSutwgf2AK 6Zm7ztxIHskZSqWiADOGN8k6ekTeQxlnLL7x5BmaclgygLmNCx7o4V2CW/3B i/PnnHTkScuar3p/6Q46NI6Y5MOQz+ufPmG2GsoeM3fSrFWPV/950lyXm/fk T+yN+Y984BczH7gUk+Ph5Pdk0RdA7AUB6mxa5OeWZdZrhGXiMud1rhWhFeHl keuTy1Mr0jZrI06GU4EIORRpviW5KUJ1M54gwVurL4V8viAKehiKjEvGlF6V DDJ8jg3JbndQ9jCqbDZTMkPFFZbFLBtmKdaXy8gyDoO1KSRlt+J2zIypyLFg IAQCgkBviL75T+VdiIViOG1xOVg7a2OtLG1SEslEYyKVoE2i4BQoUySRtsRz OOyK5XCCVXM4KoRy9fIC2QyolyxBRx4YH6SYTuzWMIaEelQQ5pXUIyN4hA6B T531cG5aKnjeVaf+tNpJZlbjwllbeqX4YfHrjq2+VA+KWW1zz5o6f/GSz084 jETF8t+e9Ktjumb3ZI6CeJgF9siDPUpY0HxzQwtNl5sMvNWhCkLQGg2ESrFY MGAwmyDPbGDlCrlqGVaqmGZQkBWdPo8qikFfMUccnCqopVIwl8wSBU+lVUUJ ZkFCL9A6fRRWrLG44ishJSEjZPVRViaqsAH8aWAkQAUmGBRkxj3mteYd5p3m PWajuaQoOZTlslR2ADKiO5EAeiKbfyDmhU+FPYJBkMqTF3rrlhsaJvWxvSST cb19QwBtdTQbrhXIyBeg1xCI0t5XO/d36oimD1V19In986R4j/nRAjK/v2I2 aiV+VNiOvaY+g4+nribL/s3JxCJ9OoYZziczw+uxXt0BK3ipUjWk57HqxrFs VX2bzLxYnTJXf+YT0s4FK60BKy0GKxXRZ9pJ84yYNdtUjguaI365FI0G/S1Z tinURDWpxWIwC2mkTNKIILlUng9KSgaluBSVUhOJYCYaU6QiSsQVhCSwilmi zEwxkU0oKMNlejKGDFnvTDweQ1jhogryh/1Uj3+tf4fOQ4z+H/BhDiPuCm4l t4ejOam0bwuJo/0pBRafq9uDlChJuWC4c8wWh64+OtAKvd9hBNx76O5J3QSt /9kGt9W2Var+URuwVtlwO1n44csONsJBfMFu+W4TgA2ugMxxFWSOTqxobdeF bw1Tea7CTeMMR9kmxWdYe20z4uut6+OPmwZtZjrmiSm2ZEyJl+OmMmpfidrb UbBcyhPAamGbcXM519yczwVLFiaU5LIilj1eSE/ZcjoU5AwRf6dSzivlM0ol WowkHAagf/O1sNMpUukEbZbPyOWyMsbINz6psEyIoRipa+nCQ9KKfsSD08ti Op4RtrdrLL3USqH1As5BMNdbw7nagND1AzLPBAviIOcYye96AKGcgu/GkY82 xd1Rd2w0/0AC6uslCYgnmSVH1ROLp77fMpqPakV+GNIkF40GmLG2I0Pn522f u/TFn09b9sl1L1zXQKpEXoH3YNPLP1689dgyRu8c/dOZNVPhG2Uf58T91V+V yj0r+5fduhwbly8sOFmf/ERI8gSPX3D6z3svuOXlfeFG3Aom9mKPaHc3gEXP hqhaCFHVjX+n2YQ73Q/lN7i35+maVLDa1bpC8IV15s8FcVCNBIPhSNCXadan UB7nUy35fHNLMNN5GJni2EqoQlXU7krlsO5gZ01HWE1qXUbURITVnaprCDWh /xy2ETeq8cbGRDyojiuRqW7UhtvUYltbqRgcF4vKCGOz1KxkMmpY8SUUVa1p hs5x4ywgKFrkeFGOd2uBUHFN98Pd1Irut7up7gFqq+afKMiRCC83URq1kjJM o3ZQFEvNpRZSBupxais6nBwTR/ouP0QuIX8QxmqnrqNJxHYSpaBzQtLydYp4 qKt85+j7B//pXYf+DB0B9GJWHlKPmXVW3Bo0eUhEjzlEGEBTK0xFvrW5UYfq /ZsfkW/NHCo3rhx+RYfr6t/0sC8SYfGljiBUdpHsk0Jfkpni3NHXSKFFVLkq Hyw5dCA/Gm8c7X/jHn0efO49ECAfgs+F0BtaNk/njDFb2B52hl35QF4eb2yx NTmbXJVART7G2G3TnJprSmBacJrsIv+GBzzHVtY3t8GTQvo4UEaBQAgFpRoX sgLy17iQVyDjpKvMu1wCH/SGFElQJC9FKQyrmM0MEaH8NA5zUvi6t737ORCx OhibWH3ovzHld1nrW7vdkQOIvylG/eKQHe+dOsm/Ud8XGT+2WGOLSdB3NsTq LbBuh1Gnab3erLfsmxBvKbW0lo+IzJlwZmTBhAsjl05Yri2fcIu2esLDE7ZO eKFFZFG5ZWLLzCLNRtXypOKE0ozCU5Xfa09OYPxRf2F+dH7hxuLD2fvKH0S/ zH5ZtjQfhlBhdJ3Vg9bZgQI40BKGpQ4HpXSTXkoIZ1dmqaYszmZXFrLZpkIw XUA1KziQERtbDjKEFVJxzRCpGBn3KKwSUpoUg6JGCRIGU9HIhKJWpiuHRQtI QHIk6oxEoihSiNJh3KSkY0o6lZIK0WgYLAmm9FJtrcr4SoVhOEUzM2iAumRj JOI1Nw/gWY+FDzusgA5TmgfxvShKXaJ5tJ7CvMKiggEVtEJPwbCzsAfY2oTW rXgWCqMKLmv84ZEw8QjE4T3EKbonD+LpY/RYF4udnRK31zfshWGfj2wOEzjw SToqDHkrviEdMIY7derMddb+1BPO0pxKTrdISJM7K0gLtEIjNUPjyULjbKzU /onD7KXGy55C5A3eAysI+f+MJQfWHnr7/iOcNDi4zs7asYktKDqyc4MULxKN 0Q9X+AiziQPr4un7wCQyCh34ECzB5EyMZ3REKUk8Y7W+mbp2jAXieWRmNXX4 ieT6bzIVrTafeU0lPm8+mfn1zzYuxc9Xl387BIa/poz7seXU9E8WT9ijb2jP fymtcxOIjlkQHRG0QGsD+l4i9J2QQ4SCfqDvb9XZeomwdUqx+gkBZ83Y7AOe J4uCFF138QHHQ3f3Am+rlVPH2Nm3OBusFUDq9/Hj+mboa1ROP1cxj9zss8/q q/DeaKjjYwiEVk86JNwx8sL9PAn300YltY53g7tlahKa3PYk2oFewW8GXg7u Q/vwvqAlgZLBpKy0HRGYGbhX3iK/il7FrwY/wh8E7bNkbNMjT1xDBGAIBGBK ZFlBDNpCetLlULQnSkVTSjSaUIKhvJ52rc0t5ebmUjmYtxr1MdNCM4yRDlr9 rtoP82LWG/JS3pTT63U5g/5cYy3i1R6VUlNJVW1MBnMDI9dqgSBG4UAwKGPK iUkrtyEkB2UnTEG0BjWrnFBCIVkOBBVMxpMDAX9bK2VwKX4ql0+WlXzearXR omJjlGRbW1CWg61lOamhl3AoOTe5MPlwcnvSmNSSqWJSE0psckVyR3Jncg/M DVDvaK5gCM/F1Ar8EvkdwXQgQFMUDQL6Ys0thg20k5aniS+Jb4ufirQotf+u rqamkiD2SdyQl2/P1756+2DYq6p9Xm63Tz9vQGYJtR+uxTi5VAg86INa5IPn kILi0stqZV/jZdxTqvf7k37f/x9z6NMzznnANvtwDH/7dMNoiGL8vQcgYtQd 86rbuNV6Rn+etEeUSPsnPB63/0nP9rUzES/IfghdgRx+ODRHDWeoVw9O9IaP SFSC0KeXgBdn8ELNzVDYHJAC1DMUtmKT34/dftrK607mSAkOBw8Rm1BrzgR0 MJVpbFQzwYSF1l/S0GJoaKANQEad+hh0t8fjhGCOy2QcjbQEIxE5GIz7KSxg OeB3gjdhPxJVJZGQlXgcEtMlm/1OBSI/AF3Ngq0WC2aCARmDbND8CGW0RInN TMvMzSzMrMi8nTFlfDnKIAt+8nJRmCsuFFeIe0SaFbEoZTvO3i83+ogG52r1 ExVQY3eNRnTWaYR+VkUvpYxmARYzgPjYyQeg4fz6DuNsvej8f6Yc36aLOnxH Yt8L4C34UCinqQXDN9Ww+gX9EIyO1X+jFqwm6ITLulPQnm+6Dqksv294eoyh UOiHoA9/CPrQjiT8jTbyHPu0RAm73bu9X3JfCnvdeyXTM+6/cH8RXne/4f2Q +1Bo8HE+weV2e+lnhK/YfaLhdvNNtrup+4z3me+2PW96nmGupK4zXs9cYVsm LnPdSK02Mq2mVqbF3Gnr4FqEFneHl0lTqi3PJYSEO+8dRzU8zm7n+oV+sd/1 iHu7d1BiHmQf4tYJvxbvct3tfth7v8TMFI9193rXcDeJq9y3eW+RmIniRNdE 92Tv0dIJ7AncDwQm5e1gy2Krq917DDuZmygwVpOF8Zv8TIpNikkXKDYJ04zI 2mnU4AExyicsBkeCFJnDqAmtRUZ0oTPRIG3wdV9SP9JMDuKQTTm9mOnRz/3r D1IVhsjt7QWf2OS2BPiKMDCybwNcuYGRLzYI3oqbHPN0OP0Vt9cdrHhJY4Zk vYGVyFMfkatxYOT1/WOrQMa/I1dz/SqSq52vuMj7ate9msPGVVxhuzBelKHB ZHtclCr2+pUiV85VsdWvXrJrbOfF8dgBjS1Ket99Wpb4MSJn2UHhIp5D4IJC Q5EiR2RJxVWgf3jNp8teqL6ASy8s+2TZ8Z9se/Rr3LBu2yfUpHur76zFs7ED s3jW2uq7972IJ1Wf+9tH1TfIf5xIoQ2AJHMASWIoi/ZoXtpH+xtkFBL9Qijh L/kn+reolrSQHBj5RON+5PuZj0oyaWaV76YQdSif/W6dUNhPTzO6SoghOSGw 8Uqcise9IBZSCRYIsC+fBYrISbl9YyXs0cIpqZuSOk8v0iM8rsHax0GvQWNl iUKbXf+3Jv+9kCCnOElp9HsKQKMBrB/nTNR3DWIR/MihlR9gHB88+NYRzVN6 OmZUv8S23rum3P/T6mt4Z3XxwRH9x2XH/jTR5hOnH3fR+FPvqMU0r8d0DnXg 57S5S9Wrm5YXf6neUry3cX367hwjnFWY30JZkgbVn3SqzqyCJjd1F7vLR7VP 6eiNn5CYkextOq7l+OLM1jntJ3acpp5WOLM4r/WhpruKa1u3NW1u6S8+0rql 4w/qH5qiTbZW8PbNHZYmJk66e/sLTAtx1tmqLcmksqn2UmMl3ZHtaD8qfoR6 ffza5JXqz3I/a1pWXh1fnVylrszd1HRLeR1ar76iftj+VdO+4r7yVx2Bcmt7 B11saTJklCgGAhKLOmMgN86AGAXgn9FvPaNhAC/TREPC06Ygc3Mi5UkZYmbH GRk0gHv78VCYpAdvKZ8gBcJwpimzNmPMXFhKKNI4iPCB/UdcIMq5fcO7SMGp kif1Jm541yjRbhh5st/MFdXZu6T3vDCvUwPHZU+NIcLouV29Fq6fXtEmxTol tpI7TRYqaiM0OYIQZRmaImnK5BR8kTRlGV5XJqfgi6Qpk1PwRdKoTgh4fEiU zsa9xob6UYb9OyD6Cb7a9kituNiqUCUSvySKxQMimDpv0XHlWcd3RjqOCNgE j8U1ua2cvnFi4cjTu5xm3uvZes+nENwQ4NUdb+0P78h0PuzJCx6RtXrDUtnG 80av08ktTeHJH5CAr95b/az6r+o91GkHhj2l1+afgKjPolZ85xYUGXlKOyYc Ga86Pd7xc0pnFH5UMDSoHYXJhRN8swqLw4szF5WuL61L3194SXkt9Er4beW1 7KcKD3K/MDE0KXJR5qrQ8swvQr8OPZB5NvxcZLdql7eOfIHMiP1OhPhfzr4E MIoqW7tuVe9rVXV1dVdvtfTeWTrpdIdAh6QgEFTUIMIASgQBFxAn4DKOy5Pw xhEYVFBExTX/U8dREJCABFBxFBAHZ8BfHJVxBvRFdOaJMv7o+MR0/ntvdSed IL6Zh3bt3Z2qe8653znnO6eHOrD5QQshSqkK2aBUVYbFaqK+6I1WEaF0NVL6 aqTv1dUm6OjGUikUaRB3krcQVWSXaifgjYToumiAiIEYFK9tSwKrAhCPgISK mnFMUrqUQ8pJRacgPOxkVBqk6ZM0SQsN5y0cmrlsX9zb3ttO41gzrunAeANn tKEhLjmh5XnMf9bsNBATN7PFaOcW0Sbt7D+FGtxurbDleBHOT1uyUi2ca0ps q2KwE1HQf9xlNPJDvMNo3YDBmnqmn/j9Y+/98tFLOu9W0d6iR9d3FL7+5Kfd Fz17c+EAaSmcN9RsvfFvlzyRa3r0K+wQel7JTZm0sGHKQxB/7oCIhIPWaxzx JzU1uu58f1tde91N/J38Mt8K/10j1421nCu1jiGRSDw75jdj3/Uc93ztMfrR Tbq89YiuO6NCTY7O+7xOPUeAEY5MTZiqzqJ8J2MVYo2NWSbaYl2pq14Zz0bl FkoHpx0Zpz1HRGeFOkJkyNfKRdXaWDimjulILkmuSj6R3JTUJ4Xxj+0EYhmH s/cEBIpafZiWCy0lQ/sYTD3XqJwaedejFQ8i5htA8GF4nlOjJoVIlEQrkmRK JMQiq6nIvozHBri81BoNybEeoH/yjpVPVZ8/+8r1Y6bNOP76n36BHqt2Ztfj j29vHV/z0NszZ77z/GZdUwCNzh9DKPV556rLM5PrRCYQjP/qstUHVtSgU5+h rOjMBx9fOPaqkNsXPuecX97xCvILVkG9bsSz+T1qymm25VAqRwmI9SjZRpr0 OZS9cQl8PfTihTALHQ8SqpHQAzpepGkmBD8CbqoSHUgHZgcOBnTOQHOgLTAr sAhq06bA0YAp8NcocuhQPvNUkTnejCffYemVM5ItZ4hwKcUyuEGuPoKjdzh6 caTwG8zkfB49vqHBu8KfkVSDmwor8DoM7/tiKI+3wfuuAcouIoCaT/d/u0Wk A6jIyw+RnnKTv9dwPPA38b/Jrw1f+78VT0tmK6kzAL9V/KX/EYOB9Wqeu5t2 k+46we32CkFWC8c5iCpQlSSqqmqIYIqxaBH8pNlut5iDjBZzmxCrK8baaqBl CseSSW+MtcRYhgxCHKvIIQA64NiQTqKNmIXK+jKCL2QytZlnmTvMS8yrzHqz UFvm97TjDAuS2vZiOW25w/O/CoTjCjtsVhqA9sDhEx9Id5V8WMy7q88N82Oo vs+fWbTxlgkhn8MW0ryWR17594tXXIV9W+2Arqlv7Asn57zxc/IVnOzC3uvY la+d//hcfKQUf4F4XvcUHKkE+XdtDle9bi/Je/QGHQT/CR9niEk20hwh3UnN vCLhasQlqLjmSL24w9fh7wh0BJfzd3pe1b/KfcabZ9OzmdnsbJfuIAlonvao vOrReUm/JySIwVAi6akn6/laTyvZyo/xzACX8tM9yz2/8bxJ7uePeDg7Tp0w 9CQa0DmOpl1c0M655Tg6GopIkUURkojQkUmRVyOHIvrI6kQkEk8E5QRhM+BL zE6zaCad5t3mo+Yvzf1wMFfrzWaDPmjT6yQfuoQLzgqCYE4IBn1CUBK8BLxh qafwnZp16yiJ0+t0ITfHQTuTgDjKK3Ber4B/xjzk9cBtD/pRcyrk5uEVPBnz 9JA/U0PeGAEA5Y5ROlM8JvvQ/5LkitkNMbsN/RJdJUFAK9hOCFCn29XMQQGI AhDUVE5Qs/VZoTMNN8KRrKDG4lkhpjoTYmJWYkliVeKJxMHElwlTYhd5MwQK HgjRPDx8G6+m4Qu+lVd9OSf/JSYmT99KqrEcnNVv3qKX3C/Dr+MICn61DlSp bpEDr3KAi9F6QOjb9Kv0B/U6/cvwbJIYjyPA8zQK2QloSr4Q6F4f3VfRtxhB Ke9xge5b7POe0Jij7b3wrJf+ghjQgWIeAQWB+3A0yIT4Zfpq7+DGIOEMfh4x POT7YxS0Mw+ksfpM3ByDk3cKTt7byU7S5/HxvuI0PXGzb4A+Q/Z/voU0eXr6 T77A06VpHIV929tnyGHEOhsWI3C56lyuYceo9+744q933CZi9WpAVm5Px38u /eu1ezV9QwdEqvn73+qaBjJBCpX+/m3qL2WaNhdq2tVQ0zLgURSQ/rTbI6JK zU/VHPREX1SAOWzOCGEhMz88P2O4hL2MnxW8RNaZ5HnK/crTiu4f8rdh0iCb w25ZCOtKzl6uCOW0zKV9IG0pKxW18Eg3XQ2qe8jXVGumuro2E6zIECXQlyuC PsGFauR5dM0A3TEVwdnreEU4Ho+Eg6mwogBaYQhKMGfCrtpYRSRWkZJiKZ/M sjg7CSetcGxSBmR6yN3boITHGBpuqU45RrBt7CpE46grt6cXnMCVO6faTxSn Ky2BgHNRjY0lBFA26F8PEYEzDK3pbGmCH4B9KIYIkZ8ARSQKRaSb8DLeIpVq MfFD4O6M+P/wA+SagYlSEI8UVmXQ3qdocTEYBeomI/k4jnYzJF0YN8BSfIms Hgj0x8EHZTkwcnShj1qr+5RgiFY1xlgdXxFExgrxwlcAZExWC21iCRAx05Ya yyQLZRHYK54tT+w1/1D8vnRXzEBy7i3sPB/TnGjdfd/tRt+u/xsuSoLGrLHQ R96P/4YmVRr+N9BW1myJgGbMcda+/fvStw//bv0gk6b4TMnmA+UZwU36MYii 8R3GFNDIrYbo4SdUJ5Eg6sEc9aLnjE+Jz1VTMWNUzOtucN3k+5m/k/ul7z5u rW+9sYt7yrcxvc34kuMFbqtvR+iA41St2wIEkALUw8z9PvLW6l9VP1L9nGN9 9d7ad2s/qTUloM+xUfVF03I0qshKgg26PMl6mahPAqrOZq6s7wHH1EvA8gRh qZMpq1lG7vCiSqoymbfZEtyjtBw0ohN2QpJk1c43O2WQlpvlNnmW/IS8Sd4t H5VNsq/Bs6pGNqDzHYYnDLsNRw06gzAitWtQCUDFBX3HL9SoutqjK5U1pdtP IISBq0gG0PBIZuQwUS5KMTJ0u6Hn/S2R7T9J5OBL6D/VzZqqTUWSBjR3RWIH By/dRYTgJa7+V9EZCKrb5VyxygNB5rIyN1S0rKV8irJDxfC5YjUANX37oQef O/beqOVtnZ1zXpDMtMfimPvopCe2LEICvzd/x7nbr7rwpuuu3TX35ofXddzy opNePv7KkRYvy1icvtRjc/sOYz/mPxi6LT/5/KunzUJxmCo49tOg1AWIBIi8 gKDARtVKpzEMUOwBHu27hLRbEHi3EggZKWCVYrZ2aw+Yuy0mmyUZIua5aooK EARlNFuDshM+edLgS4WnEDbJzSG6tZPr4I5yFCckL7unfDjQIPSWQlxQi9A0 By2S0OvtLTJofqwAfOJmW3Ew1CkLzKDGWhOZkPhJYl7iWeXpyHaww/pS6MX4 Hv0B02Hdh6Ze/d9MDK+rBRn9aGsLaLOeG/oJmKpvN7Zb54Er9QutN5K3Wm4N 3SyuCO0UX1a2RXkAp7AtVjoBPdIXQrxW+dwOFs8ADBwjws0RyPsJD3NIQVl1 Dkg99F4PMBT+se3DNXvL+GqPH7nvviPopfu07519ha9f21M4ue9pXIzehBN6 +5/485+fgC9UkQ5HZyLUzBRxcptsge6/G7qQaiXceMP9YfSD+DHxmPxf0b/F jRF3nB8nXRC9ID5Vao9eEl/gXCDMj64QbDwKsV7v4ma4fuK+Jnpl/Buf3uAT aLcvSSfZqO9X9CP0A961vqfdT8NrwxCyOwXOjzm4QsCj+aPEckZOGq3dOkPg Pzxy2OrIm2Z0iWC1+KpIir5KTo6hQe6KAZR4Xx2jYkLFnrJxhtqGWVPtiy84 pVWiw/96i1ypQRqu5noijA5nDOT0l5xPQ7nzyZeza8MKkcsS0Mfci8wZwMxa w6b7d732x+fmHJjsphnPFU/uP1A4DawHfkvZA0hLXhF9Hv+Ezr89+OThcyZx HqZi7DWAeuMAsCFduB0+7fWoEx983h+9eG7q6hSJZu+NGu0gjSdwxRTyokO0 P+3x+70eJWThlYS53QLVoDshw+cN1UFSZC5E2KycEbUV9YhmqRP1qAPAVxmV OyHM7gF3dVekOkt1BIuLzweFXBoxYRnOKL3w/1NID87u4tTWTNzMF5Wg22Fi TcjEDOrFDiIF0ZjExZEbGIMIKGyKCAM2amCKCudKlUkoeFcS5fJCMx2pmZj7 Prru7Ztvfvv6Dx/A+4veX/vA++8/sPZ93aenr0W25Zn9Nx+76edHb9kPjmiS 3PXhh11IkknM8UtDSRYIiTikzrfw69xkhhxLTibnkvvIfa7fCUfYI8KH/v/0 fiJ+x9uFQCqQJRtC5/nPF2f6LxE7/AvF2/13+dcF1oW265038jsDe6g97JuB N0MG017GJ0lwBmWCsseokxmrbYov30WARVCDesAnqkeR8iDfxYEObjd3EJoi HSfIqQ1lInrBCVzCcaK3VEGI6fpDjMwWnjNAk7DVz4khsqf/8wFTD4EMkHl+ GO1bk0zCqJHxdFXf/4b/5NnL/jDG5aC9dM3XS98vHAXO/X8AlmnCu2vWHPaB x558o6nOKTAMnZkG/G9uh5bj/y1duXHD3Siu8R7EspdAycwSB9Soapuk79T/ wra0tsu2xba14rWKwxUWj8lptu2nacWcrSZqAQSjuhcJQqmGAKIHqKoPQMmN JBQi2p6UgwTBSkJ1lddgNlkUKIuqpZ6oBJLvIBbNtao97Vbdi9yH3Dq3kLtx B3irSEO9AFOBG+njGEU2omBgHy4JHlbN0D6srMGRqvDDAa0UiQp/UgSoTebS pWfln8KNYkncYG2vwe0u4ag0wHa0rwMtD7yIli9uuOemZXVuL2dyPXj1T28C K7ChtfdNKGE/cgeSxyULHuVNPMt6KM/C8Us03EUS/1a4XXc7lMw4UQdCau14 bhFHfii/E/1c7o2elk9FDNckr62am55bd4v9tuTiuruSnXWPJe+tW5/sqtsZ cpAmZA3mYANh1utNZoUkQhW1Xon2SHAsHaE1tbJkqZCJNTGjKU8agAEkghKQ LBba3GXebKacZhQG2WQ+CP1mX65a7gyvDneFN4d1u8MHw8fCJ8O6sJBNXT5E WLG1QCwSOBgIADb3IpPaXKowGTnMSJRJ8S7C33+K8PWf2pIyZXr6v90SMhEo I1JpqkGrpK0OHazi04OB2KKgI+QCcgPZfs7oIMODnSVG1OeQFSFzWbYuM6RG dak290W8i2ZegCm/fz/vpji/7N3nT59+/t1lB+6++3e/u/vuA+T+h7HF2DFl bOVlCcwlPf/c1JjvdwCwbRsgChPvf+v3a+7//e+hLkyFunAt1IUGcJ1atc53 WiJ1wA3mGW40rAb3k13gKXIz6CYtTxt+bdyq32bcZ3zfeNRn9JkYD7bbTk7k SG6ml+M8XoVJpjHgqZxZU1mZrlGStEWz93Zgn4lDXAqt4VdrdGYRvzZk0H44 l67N5TK1SgNAxRS6ZCIBh7uB0Blpi8ksCUe9AM4TT6rWUYQs1e6uOVhD1vSA /+oeOeHygeoxzSVr7CuZfBxpZ85q8P9ZRig8VUoPgf5XUb8CgHhYjK/Iw4IK Sfv8eqMh6tcLIvAZA5pKoq4MgxH6HYSh/9Q2ySZyGvqZoYWEtX4Ngxh1QHU1 HGs8W6geTJ605tI5K2ZeJgqCWPgSTR+X/eLGmWPSC8vZ4FizIS46PW3C+FVt ff8Y0F/q0luqpJv6Ph/o29Ok9XIgXobSwOuhqwwR7BI1pQgZQRUmC3OFG4Q7 BKPLTk/nII412MzT9XrFxgeEtW6IY6m9ZA+4/8WAwW6zEGAXQEFJErohDp1O L7nbOMAJwYuWDPp4dB8epcbmb04Mc/WIcj69O5xzncHRLD4AcvVtS8B56L77 vNgZO+9rxHvRMx98ULjo+6/KLBXEMsgubS3cTjXgOwsST6gVNGqbRNLUpc4Z AYjuAjc4O4lO0El2UmudjgtNq0xPmNYHdgb0AZMfJVYCUJv1VlMPeP5FnU6x ajesOqwG3xRBYl0Ofk0IBbtnqQxJUlRItNmlYLBNB3RCaCfYBt4mvIOBWExO LgW7+3qbv+kbrORA9fFwAkR3PnDH5eU1+kx9jjx629KCHTnr5ITp00dPKXyN H4D5mjvQ3fd9jzV/7jWrq0Ss+HddBbV8NxzXNVDLc2TPDiIJxZi3NydRrQxn w2u1jbU2X+X6tYvckwUpLhWtTqayidzISHN0dLI5u4BbELZe6QJhV72LrODa kh9EP8h+Hv08ezp6OmsaFR2VXRBZkFvPrQ8bIrlwmNDMuHXAhgeQ0m8lRCCK 6EttdLOIC0Ih8hZnhkVRCSuBMFFVh61FTU1rtqamLqtUZXOMFX+QI21xOKwW hUHsNuhBadQ27zrMbVP8nKsyho5PSCZnRpPJWFSpjEaikYiUy3K5XDbMuViX RIQ5gggTrlyE04eBkg8E3Hm/IZavrMtXVVVWktY8yxCmPCAtHHKhzR1hEH44 Gpma2wm6iCg8Yl+U7cySUrYmOztLZZE1Co5wwbkfzj6LzJ1mkjZL5hq4geYh g1mo3wUeIzq1wOQgNRW1YkS1PyeK0aNS5BGTmYv8I8/IZTpMQNoB/dzD3aFG RA453B0Yoa2FjLb2VOH1lkFSKkCs1GWOIo/N+2Olr2cYvLNfC03ZGZcPoae6 +o91+yJZDjNemKwLmUe4xm3ZcKRzEEGHIYLmTFHUIi/b/015DQa8Al41qXjV t91RISsN1Aii3PgAHWoQ1wzEtuSB2Nbwgl3wUpmzuBdcUYF1xY4Mx+WFHvDE 5TileRIdzRceBD8r/KrMdfwOVCLzgbYLXxRmDIS+rocatQtqFAc1yku0q9k5 7uvdv3BD8GGbjjAjRInTEUJkve61DKN4CQgMCSAxNN1G76YpWhDKrSFu0XZ2 K3hWC3jvUPv3FbJ/JdehzKjDv9WNatEhJmslU2qjc4SzwTHSOcrZ6BztVJ0t zvFmNmart231b6nUxUE9IKcG5hjnBG4w3hDQ1xszgfHG8YGpRn2NacRorJ9H R4FRrU2jRo1uUka4nehQSGLBJPYQe4w9yeoIlmZVlmJbHSzrdCjuqIiBAqHQ Cqm0hhRFDCnR+hrtYB1dR9a1puvqatJKfauKDl5xtAW0tDa3tKjNSlXaEIpV VyWCAQMwpkaoeaLVkJIpn2w2U8YR9fXRqNtid0geXhVzNXwnT/Lfx4IhKR5D +7HOGBn7volIS81NKJBFNO1uOthENQkTUs97y2ImcKOicWA1UE5SLC8oRXPZ kcT/oi6k/Uyad0lrDMgKYzAxHFQUUYWUSHoFi02nt0aTurgI9AbB4hFBQp8S gdfmE7X6ZdQmAzdYaW+HcMM/WP5k6f+C0MGXsf8I/K4jELy8U8KeQOu6YkR/ ga8J10zCNfpLtsC11k6x3eXGETXsxQ4ClDCjNT0bul+GVIYr6WfXLBwzR264 ftSl9RNwLegjF9ZVXzmmFW+21VZVjm7Bhz/G7EW8Sc2Zev341tbx+fMv6duG pJl8UJ0y/oq+d/D2vS3Tgsl52s6gMwKlfCGU8mlQyhvAMnXEu4Z3TeQewx4T +aRpi2GLiVps7DSSc43zTPP81CP+pw3krWI32EpSAXGBSBJAR5IhE6vFIpxu 0U26W3HaVmGHY1ptSnIQDuBoLc5KGqaliSgdJYcBW3uuVQO2mXyDAewExwgJ zFVdQVlnhBiXZRmL2SL5jgpAQBMKjeHt6pouCG8FhG0HIVMR2WrC2XcKThb/ es3Sv4prOX9AbzKaDCbSENBDgfObghq2TWFs6x9gn3DwrX95wc9p4rUYF9O3 t0MEV190PM+QjqFSdAa8nTb9nhmz2xouxfLwESa7/vu1F9+yuBzdFmVlyYxx ydDKc/u+HES3M25t+WXf34cJCMSA9/Yf1TVCCbESHnCO2sDyOp7z8NSb4E3r u+Sf9H82vms1XGOcz5BXkFfo5pvmWxbYFzJXuK70mNwy5ZTNlNVstMkErjEW mvHa4cFr1e7ObSYATdQQsyHE7CGXqV5WNqioAlmF13QYdhsOGo4ZThr0hh7w cbcXmqCS3wIntxN97YuRy1Dq+TqklHEXwUMEyvWf2kpzDs6zs/9jOON+3G0P MaFBf7IdJ4YQHc3KI6oyhxYMCm+6nKFmKwcXJgtcGNGCQQ2jghDxGTkrC0/C Bc8xniYOLVyck0NX7FFZuGGxQLBmQguScoqNoEQfLWu0hGK3pfhMeZSrsXDi tT2FLwC75zXgmvpRV9dH6AU2vVo4CZjdqFnxyd8+/pejjz167CiKnBdux9qL emhVqc21FufIOHzlqi4CU8l2+zwAx8Rwjf0GcGvqumrr64ZXLR8YPzAfiX9Q e9zwicUkUJXUrca7qHXUBsrAB7DKCumgIASCCq/NUlZ2/5ApaYySLs5GwJ5M O/PuQB5KqiMtWy1JGazRGQkxHzXEZKcJmHx1lYRDCjmDbcFZwY6gLihkyoPv GNqVQu8nGnEA4YfiBz9O6SoPjyVsNcjvqMKELrsE0KjX9v/5hXh4SPEq6pii aRmK7qAg+llVakgsfeKGG2/7v9cX+l7+6C4tj9ZRFlJ/7J2H1h0+vO7Bw9Sc dZfOvOHgddsK/dsLBo1fBHFFHgOi+fcePLT63kMHUTQSjt1zcOzCRBqcj7p5 fbPFOTKJhK/BOXIj8Yx/Y5SaTMzyzSN+6lsgX0/c5vtZ9S+Iu313Vq+LPVr5 YPWzsQ2Vv65mngqDR5LrpfVJSvMfHOVhIM02W937i2ZZM8OTkRkuOQeEL17l zbMIyDuq5IDFjCJEcZlYoxgjQDALUqcFOC3HLCctlMVXm5JRM5wucbOoOyge E0+KlCjUlILI5ZEhXGoCTS8cVETXa278obDQj1jZoQPr05phpCEQjnKVqM1b gqvogSObHDayWtT+rPUgWlA0Miw8tGEvjiTjeHJhEQ7prfz4pUIfoF45tvLw Qw8dRi/yzXVoBE/vLY0o+G47ANte7C9MvPfgwXvvPXRI696ru4S6CVp7t8rd 5gCV5jbLAvZmdgX7gOExlzGghXHE/UXvze/eSW6Ezo6qmotOGSoZ3qi2JS7E 9cJKhdXB4R/91RvtwEVwDtoSieaJCoOlmYaTIfTFkEvmtziNJ42k0VdFcFLE GZ4U1gJ4J8OGsFDZd4+3rAkGKv7Sar9wP17sWJd6kgFm5D9LpfzRSRCOHFMc uW0uzsGzgRKCKmrdkCLxswVgSfKpJ8dPXCq4LA5XOCuMeGQ3uAFD92uRF38A l29Qcw7fP/UKn0swusK+6esLWTw4LOMhXyrim4P9R6kC1LJx4O/qcq45MIZk zydmEPPHbZA2jPg/DW+53hz7F9cf+T82/Wnsf7l6s5+N/d51KvvtWNbqMvD6 JvNY0eXm3U3+sSuVtdldTus01yUN8xsW5G9puD2/omFF/mluC2e5J79NJC8y VSTDsVp1dGPW53U6jG7bSCKbqQnrquudDhtlIShGyI8eLTNyi6UH5LZSEqJp gAfUQKxelom8cepIuS2EiJVUyNdaOyWcT7plFc2SPJwP1RkdSZAUxrcYKUPM IlsvK6ocZlMCLS4OKhAre4Bnica4fZBkObKMZlnsEcBqXegaRoxlpUDUFfU0 uUUi7x8pghESXLBj4S7f7BUJj7dp9KhgI8Qyvnxjg1gvEtwYBkNpBKy0RZGJ jTFOafS35rmsJfBS/6eEB2rvOKi2TdwIqL3dCt8YGIzrYhpGO0bXDXCONUO3 I8/BRQOacb20G+7BxTg0xY7j4KQ6jrM6mwPoc+CTQRdtR8CCQ4uyKRbO7j/U Igc16Cwjj3KGMvLoYPPOeCxS7JNH3aZ5syiv1zB52d0X5ltr7tw07vJZf3jj jSUmtx3TRwVPeF3HU10XTS68sfz8w2s2UhVBKKmrQz5eaIw3jKzINSYCTpc3 fNs51zxzhcI5fKHnofi6q8Wa5lvGXZhOS9mrGxcuQV7nfRBt5VFVGfGmGjnt B3a/z08+Zdlmec3yjqXXov+Z407HWsevHfusf7QaPCbUOXcjoQPXqW6TTmc0 KYDmzG4G/Zg7pxdsyR7wpMqE8pGIMQ8AYbDJgpVbrusBz6pcZaXJLMXkfUSA DkiBRYHdAT1EAJ90VyFHD/1aAk6znCq1mEDFf1qi9Iy+OVp+xee3WK0+s0hY /DaR0PIrOF3dDkoaznDDU1Sx3NB8C++GcB/XkRYablw8dd8Izk577dI/Fq/Z iImOj6DBoOYg5e57+9w5dZIddU6XL/jVjWQaHcQ9V9BzvBQ+xxnUHCIOLbHN otvGkwke+ExOM7bAtrTJZjObFKeWSLX6LywmUuMy2q9CbWlbpUhElpQ44J2c JOeJuMXjzYuhkNNkztNOAydTVkkiCA+PfBBzkmYk00EjMKIAe2J4gL2xUWtd WGQ9abUy//R0WDK3qgWoyNhKQ8LorAt1jHTpGJFgDZz25DU1dBXV8GXCDdWP h2CI7f+4mDHEBJB42ePHYzNicLfE/7hzw/5b1Yu1SNDVF/5+PR6GL7Ebceuj LdNvJEN4MO6evOAlbVOLI6MxyKPflYNjEAaz1Nr1YD27wUVJFskqoaYIDskp Qc8tDxrYUa4ryauY+dz88CZ40XMuVhUBatOxUXXbCTttT9sp+4W4XYdiYVht EoV3K4KyMCjqxbER9fSbiZtxKGYSaGHPZq8W97xwIOzJkABILMNBP5ILE4Tk 4jiXi3OxgLAUA5x+Om+h8hazIZznesAC1eoi82mmmdnEUMxOsIBwAbNqV1lQ w3awXewhVse+DDZBmYkCuciphEDo+Kn24m8JDLCGmxvT6VLh7A914vsfWu39 MCcSRQLl8BlBvbrhR8jN9xSe+QkOe+GuXitBNgqqcc810IgyIlMpO+6cg4Zz gub/lWJhDf39uvvhSCaoSvXpBB/33Ek9xz/t6SF38Fs9JoKkySX8Kn4T/wp/ lC/wpi5yM3mQpEw6k9ur87oTZFKXcMc9DboG9zm6c9zTdNO46e7pwvTEleAa 3dXuqzxXCVclbtX93P0Q/4Dn1+R63W/cXZ5t5C5dj3uzZ7uwPfEm/4bnT/xh z1/5Xk+FlffzFWQFX+FZJixLbOB38fv0+7gP+c/AZ55vydP8tx5G4xA56AES kcYl3qhWLooAIiJF1Ah1Em11RQ5FqEWRzgiJyMVkJLIOM4uVIrN4o5qchcnh FOIXt5mpL81gEyYZU6i+3rwOk4yVIskYSmUwmMYMY0USvGsxw7j/PDVTYhhL AwxjqYxhLJUxjKUiw3g3OAbd7RugNB1DoUhwTA3riCkAUFN0lnhe9uUlV95u yNtkSbLbbYYOL/C+LgCURo8RawS1JieoiYqsoEbjcBEMwYXggwsnkxXy6uwE SOwCz2Bq8UrVw08l1dqRWRJdR6LrSJVmsmQPeEa166XZbuB+ndOt4fJ6FOqq yaFVd8PILN6t0Hbh1+A1/AS8hu/Ha/hhaK2yvCerV925JfpVehIxkUn9y+Bj IlmmMd+0tw/M3ScQ27gdkZHhvz5MRW4vUZErTh1HJwlvc2MpBYDR7KlGuhdt /Mtk5DOC/O3tixefeezMg0VGcinisC1hEkw6ehDQgOtkI0XFqWHM0XKycekY tfzqHT1Xb0wOkEivWds9r2fVAhSdPo5AbwKQgb5eUKahV5Jc3+fkw+VaegW0 twuglraQ96lrRUZkSbaBmcaQfhRjEZXZ4Fq2Q+4Iz255HbxO/4H9g/xW+K3M a9nXWpwmwks8pFBEBrAtDNsSppUwLWfrMkDOZsI0S0sgwwGQybawLCvJWU6W s2Qe5J15aChdeTYv56W8rzafyUfy4XxqbL4ln8tn83m1paW5oaE5HI5XV8eb Z+izPaB6q9TycDONkkV+APQ2WeZtNj3BA54Pgoed+g4oGr7xGXi+O/xwnMXX yQ/HZziD6WIYQR8UxlksPkvKkDcc3wmMAz9wUQLCvQPNaREWFi7o9aLKVYiC BdTcAI3eCUR1P+Gle9FBdKC49hFe+sQJVK00ZKFfVkwssf2/Q4kktphIgusN 3VxCK2xmw2j9MYptwfVftvgbm4pAtGjtUZgpTNfD99OV8M006otCW+Db6BB8 Dx2CgJdWBt6F3+aE/7SpfxvjtTuzdT39n22B62IvE5wDwn9YXf/Hqpm1NjMh K9tch34C4Dy4wVh4TxMDp8ymljEhthmgRcuIANMM0KJlhJ+GW3DRgn5tCKCF bAlKTVknXGQ4wd9EI9ydQUAbrtniuqWnf083zaHI9x7VDjfCjXAho8VZC6cR GAcZfliWaYh3Xg8PFHtTn4V0bQiTXWBpjHNCL/0rpBQrCzsKu/AEVvgy5HO6 YmBp4bmIC57/BM1n84AfBOchFfoEnY2AvYVVRt5eTEeNLLyhxTrtvBE6pueY 8BkUo/kSMJpW2XgT1Kq1hdt1D0GtyoCXIJggvKxXqbDLnhzIMW121XPa9d+K 1eya6DpPuRpczfzc9XNluWu5soN52bVT2ae8pzigarIZlsm4NEwTstvTA2DG r4Q6QyC0TgmFFMWvhBGDf+PW6hrsG3qKFH6lIuMyayRAvX6dRgE0AwI1i4BT jqfGAzxp3DBC8bkyiMe/Ub02Hk9jIr+SCiuuTEbSKoMZqL6oEzTrIkAGnmAZ QJhCetaMoI/fz+V9PqjRJII+kXyqNl9RkXIQoUkhclHoWOgk8kyzk1ApCa2X 9Iv0x/Qn9Qa9UJfaia249jMC7Yvp49D8lYIMZeCnyLREHaP1RWv8PyRc/1lA VNqlh19tNNGNpkasKjIo/SrQWcVrWB5UJhcWbhFCPrubx0z+xWAamIyB8Cfi /2fva8CqqrL+1zn77MOFc0EFBETB4xUuaHAvipmZlZWZqaiROWRGIqCgCISI H/mamTVmamRmZuaYmZljZlaOOeaUmTnlOI6ZY2a+Zo5ZY59S4/gqvL+9zgUu ar3VfDT//yP7WWuvvfbaa3+ttc7el/sR3zzad+b43Wx7/EFBLQSxOTK8ZSgH 54H6844JwbgaXzFSMfozIvE5rCmWPukZFqFeItZcEWH6K3XfUnjdSQojQ91H Qvz8hSCesBg2mV5R/mZRUc2beWIiND1St8MjosPDI8LdeoQWE667tYhmNsXi 1Gtb7jDtVuOyZmFXhpWp1+taxdxa5tbcreLGB71ElxV4v/ORhl+IvLTxt1MQ 6pwvZNOdf5rr6jGOcMU5IhbyfesQr+pDVNMfhTj7FyL4E98XaS21+m9wDGl3 sdbwqxFi75n79W78foszpFec+da53PU7c3klf59QP31LhSLeVN+RoB8WXxkf UyhFUa+eCZbeWtdFuBbSoi4sTHPfEmVVhp2I2t8SR6YTuOKdeClao/xNcXgs aPwbVDX8E1SBX9Thj6TjKRx4CaCRemH/r0MTY9q0uh95QkxCK+Pj2hti3S0T U7UPAgRG8r5+2GgVGMmVPZu7IjUjQg0irNI60eI1Nzrv2awlVWonQl7T92MY b/7aGUbNZ4HfwgoeRmbDN6U3UtXv1b4fl9gyMVQf9l7tgVYJMYlhGEj71MTo 8FjtuQChPq2RrM/R3+aRdO8Zm0ZTMLgQY70W+ppO67QTzfS2uo5TXOkLYRot f5l/BFGN48ytzlp8FviRzsafQtzY8FOIxscNP4VIlwTSg/SXxqT10B7i9Lr2 AQ6uN4vJos7YJZ82e5knXM1c40LvDBsXtj5svdUKaapK7qXhSyJym3mb/b35 b1ssjzwYNTlqcsvQlrfjVP923N9bvRRf0ya6zaGEYYmdEjvhzHPUPm2fbncF 0h1O8kxq36d9XdKzyf2TT3l3p7yX2jv1jY6lHbemXZLexxfjq/EfzHi6U13n JzMLu/TtmnDJ9m5fXHr//0NpV/eWSH0upAvpQrqQLqQL6UK6kC6kC+lCupAu pAvpQrqQLqQL6UK6kC6kC+lC+v8hkfrrrm8m9dul6m80Y0VrFMMlResUoWUE aEFDtSsCtBEkIylOWxigTWqjrQ3QIbStQcZFGbQiQIdCZkeADtcXacfQo/N3 sTE9QGtkGb8J0DqFyPgALShdtgvQRpCMJLccEKBNipBDA3QI5TfIuCjOeDdA h0KmKECHa1myCpo1Q6Avt/k60xJ0c/Mdpk3mf8R0CPO/YNrFdB3ToYE1dGhn DR3aWUOHdtbQoY0gGWcNHdpZQ4d21tChnTV0aGcNHdpZQ0WHBY3fUmMLaca0 O4gfoeiQtkw3V2ML8TMdBToy5HKmo4PkW/IcHTomiN+K2w5kujX35ehMCJJp G0QnsfytTHdkegzT6UxPUrQraPyuoL7cQXx3/VyeIZs6Y0UyqBuowVREhciz qIxKAZU0icqZcw1KFaAVzgO/mCV8qLmKSpBsygZvFNpX0jguFSIvhHQVcAEk lYbxKBcz16YByCcgL2b5PEAl6y4AfyzyChoDXhmN/AnjUlpLWaPT7iaUilFS I7HpRlB5XHJ6LgXXzxps1l0UGGE+j7iUx1XM0j6e1yhwS3iEZ4+n+3fMsjuv QgU01I/vYujqhGRTKrQUo68K1Izj+VZSBxryHfJN9TvaB2FGWVijPqibwONS s+yHukqkEpa8mdvZvLKTkI/n3XFWyNmBkdxTJa+IKpdzu7G8bvUrN4Lb1q/q tVjX/th/p21FUE05z6YAveSzRmc3JnBf+cDn79cpK9l8jHo8W0IBy5YBF3B9 Oa/8pIZ9c/oqDmjID+gqZKys0z5n5kqihKlUtOuAXNnbiIa+zjeu0nN0//BV atRewJpGgVfB1uTYVX6D1Z5/9o2W3HRclwWtgZqJM5dK7q/eH5R+Z64FbBtq 5mXsY+efqbPSeU1WtTDgF2d7h1rVSsiN55ZqtFU8m8IGPUqyBBLfu0fP2J0z MrrZg4sK7ayy0rLKSeWF9jVlFeVlFXmVxWWlPvuqkhI7u3hUUeU4O7twXGFF VWGB75qy8RXFhRX2gMIJdvE4O8+urMgrKBybVzHGLhv5nbrs4lK7EnU3lRZX FhbYN1bmVRaicWmBv6zCLkNNhZ1fNr60EqrH+bILR40vyauo19M9qMvuVYUV 45S+i32dOtmpWcX5FWXjykZWdhgSxA/IQ3zQjVmD+5RNyKsosPsVVlaWFFbc XDbeHps3yR4/rhADwgRGlpVW2nnj7PLCirHFlWpwIybxUK+9qf9VqK3gQnlF WcH4/Eo1jQlFxflFQW2RF5fml4wvQNPKMrugeFx5CTrA3NCqGAL5kCosrfTZ dn3nZaUlk+zU4g524dgRqlWjrtJ66fMOicULiktH2RWF47BW+Wppg7rnRQ7o uoxHkFqMXioLx6p9qChGrwVlE0pLyvKCO8Wg85yhYo0btqNsfGX5+Eq7oLCq OL9QyRQVlpSfNSMEwTJ2wTwYWymMvUw5oBYOAxuN8iccoOvrndCvnIbDpFgk nheviN8BXhYbxeogXUq6uKH8IesubNJXYRNtrM9INDoZ/YzrjMuBL4V0HpxC uZvzkCjS1mpP4LymgsBVkK8IPF7y6s+M+Kttj0hODWe54D9B6qSURFodn5XA UV862IvPdrnAe/l73v6Mun36bNL0OfqjJPRF+iLQj+mPgV6sLwb9uL4E9K/U D8/rX+knQf9dSNKEKUJICJdwgQ4VOGWJMOEGHS5akC4iRQw4sSIWnDgRD7q1 aA26jWgDOkF0BX2J6A3J60Q/cPqLO0BPEf8F/lRxJ+hpogb0N+I06DMG5mNo hvoeAqFOdEaYOl8Z4TgpCSPGiAUdZ6AXo7XRBnSC0R50kuEFnWLgrGVkGJ1A dza6gL7Y6Ar6EgPnLuMKoyfoq4zrQfc1+oHubwwAPdAYCHqQ8Qv0mGOMBD3K KAE91rgDtVOMO0FPM54AvUymkCZT5UUkZJp5FWnm1WYfEub1Zl/Q/cwbQQ82 B4O+ycwBfbOJM7BZbI4m3Rxj4jxmlpgloMeaY0GXmlWgJ5gTIDPRnAjOJHMa 6LvM6eDfbT4Autp8BPyFrrdwYnvb9QkJ16dWOGlWhIU1t2ItjMdKtTqCvsjq BLqzlUm61cW6DnQfC2Ozrrf6g86ycJK0BlmDQN9g3QA627oR9GDrZtBD3f1w 8uvvziLdPcD9HKzFCFiagjC4yx4SeRV5Iyi6qHBEBXUuyasspStQo92U3cum aCJYnu7YKlNKg9KhSpo6vZLef3Afm2KyB2bZ1Ib51ARLFaTJZtyRcZexY8aO oaGMRzTcnfQmVAuc7E2c4l04sYeRBbsPpwhqhv5aUCRFYWQt2QsEj8bJEzHy 3nDBIfCNkXCzKppK99JcWkBLaDVtph10kI7S5/St5tbStC5aD62X1l8brA3T CrQSZ1W0rtCjIT+J/pG7bYwCeUQPJ2/u3Ke05isduRY9Sb3nWIuMRjkEeU+H Hzk8kO928uiNLGfElsROi50fu5JLZtzBuK9bma3iW/laXe3Ux2+J3xv/aXyt U996beutrfe1Pt6G2kQ7ehLmO3niNCdvO5QlXXYXu4+da1fas+yl9np7B3PD kzYl7Uo6knQy2Z1sJ3dJ7pM8LLk8eUbywuTVzqi9BQojn+Vo885z8pQSJ+8w 2ck7rnXk0jYH8m1sCVpaLXIl2/l/Mv/1CX014+hFHLdcHLHCEKWiyOIIFG6Y uHFGwo9TKYo9OBq+O5Bam9nwYBu+O4Q8Zg48OAl+1pKS4SVDKN3Kga9kkBba K3SZuiMhqnYmSusNgIf5diLPBuSA3oMccTetAFAFmAnYTJSBSOjbD7o8UN9d /YBfAHC3zbwa+RTAXMB8wHTAIsBSwIpAvhqwDrABug4h3wpAdPAdRb4L+XHo WQnoAxgAwDMjE7f1zOHIRwJKAGsALwI2Al4FbNNbp7l9qelL/CPTknw+ho6+ nmkd/RVpV/sK/BP9U9NdvlNpB32n0uN9uQrSSnzT04YzzE8b7p+R9qJvs4L0 zr7PGSJ8uf5Zjmy6F3DUdzh9j//qtEToVhAXgDVopyDS1x3QJf0Q5PZDbija V6OfSMhE1o/H1x/jyfVP9BWkr4LOTajP8PVm6AP+ApS7glYwAOXFTcY5E+Nc FlSey1ABeiTD3LTdgKm+1QwzfKvT1yNfibGtDIzxVcA239YAvMWwA7SC3aB3 M+8Aw0HQB4PKR0Ar+PL/gIO+YwF4C/2+lTYRtILToNewDmcfsL7p0ZjfEYzp INY9sC/paWet/xB/ZPowQKU/MX0yykv8GQzLfW/5oT99lb9r2hr/mrTBzvql rw0Gv7t+/ulH/X3U/iEfwPvo2MWL2JPeDAcD47LRDtCwv86+dm/Yx+D1XNOo N62Hr7d/Y9C+nb2Pau+d/R+Nfl/FnmczDPaV+7ehfLb8ue1zYM870L4K7Xdj TacHYG4AmpYb7WQRgypXcHkpYEWwPGw2WH4Fy8+C7Sio9q0LwAaGWQFYgLoF XO/wF/tW+/ehvAz54kB+EPlGrNPGgO29Gli774N6uYA/NtjnPt8uwN4g+93L 0Gi/exm2+Q4zHIS8gnr7/RS292mQnX7LNnksXQd9mu226f4fYZvozTYJWzyn /lPQiCkcG7xcz3bcYM8uh4Y91zCcHVfq7fwKlI+gDNr/Kcq9UP5S1fspvbP/ 2/QIv9s/y3+aZbsB6uMR6Awd5b6+3AyXKvvNDN1vpsf73eleQDc/ZegZEY68 KgfkB0Eefpc+wh+ZEQ+/mga/modyEco2yveivBDlUpS9KM/2J2Z0Yz+Mgx/G wQ+T0if7Ozp+l5EG+53i35bRGb7WNW2lf036en/X9J3IV/l7NNYj/jIf5cZ4 tQh2t0jFQIYt6KvRbyMVnGMba84P6dvPgp0BqPf548i/5phc4K/GWOrljvp6 on4w5IYiH55+EuunoNaBINva1cS2jqCsoD62Yd9gszUcl7o5+9R5X+cFyh/Y J+qfLTsxt/XYi0Ce1jHTy3C1f6p/AWJ7V8QHBQMy0+BDBU7MyOzMsWqBfyri Rf+0DJQHo4w1zezm65/ZraH84jnyKiZVw47rn0UjA2t/3hiBZ+CszCsAvTL7 Zg5CPqRh3c9+Rpx2fKfepzJH+I4xDAM9rLE+QJ/rW2eVz+cLDPW+oPyAfSGz yD8rszRzmj+DoRL9TcYzoOkz4VT6+sx703dm3lu/Lpmz/V0z52WoNc3NXA5Y iPKSxvLZz5iG2HN2DArM/198QtMpVv8Cd1jC3RMlkYkbaIy4C3fMeNzybqC5 xmDc9aplmnyS5ssV8hnNLdfIrVpzuU1u01LkdlPTUjEAqY0wXWa4VmA2N2O0 0WacGa/dbrYx22iVZqJ5iTbe7G5eqT2AW16B9rA50izSngi7Pex2bTnuZYna U9Yt1nbtWdwR1uoRjedFTwygDWlJS5B7AKmgl6uvUwd0AeA86ckB4AzoxV0i aRXonoH6MEDzAODs2CESeX8AzpIenDU9OH96cI704HzpqQrkOE96cI70zISu tchxrvTg3p+kvsJ9KfJN0DMREAdIBCQBOuJMn4G8K6AHYCpgBmAWoBqwAHcr L1a6O/XCPSoHt7MS3KKm0SyajzvUSlpHm2gb7SLdezrFlaKnYP4pYd7alOYp Bii3tyYl0nsKlO79NCXC+yXkTqaEoTYG1OfevSmRKXGgjnh3eE97d4Pa792C 1mFoYXo3eI95N3PbNd5Pvd+itta73LvHuwrUKe8i717vYVDfequ9r3oXgPra ey9a7wQ1H7pXe3G39s5CyzXejaCmeYu8C72loKq8uWi94l9um4Jf5yCzDLd/ F9+5m8NGIrUpuCm5aSNdRNT2awBG0LaWyMa91ca+29hzG/Ziw0Zs7HH7w8jb OHVtcfZve9wBG/bl/Ry5+jYC2IgN27FhOzbsyoat2NmBHDZmw25s2I0NO7Fh LzZsJQX3BW8N4BRoXGFTTADsDDtCKUMBuEek4B6Bux+lVNBFycuTVyWvTV6f vCl5S/L25J3Je5L3Jx9KPpp8HHh98tfeKkicTK5NXu41FAbUJq/1hnmbe2MA b3mneKd7Z3rnYncWeXdh9w54D3uPYZ1aYBewDnqN/g3p+t+wIwbviMk74sKO RFIo70gY70gz3pHmvCMtsCMDKI53pI05BDuSiL2IpLZWNHYkiXfEyzvS4d/Y kwZ/KeJd7kghWG14oo3bnY1bnY3bnY2bnY2bXbKXQpK2Je1I2p20L+lg0pHk ePUfWv2EfgJj/Fb/ljQRBWvUzYGwOgF7u4kMtjdpRVlRZP5o6T64mdv/hFt3 hD5Hfxi9PqI/SqH8uqKbX9cKd+1w/ZEiXH9y7aZI117XXop27XO9Ry1d77ve p1jXh64PKc51xPUXauU65jpGrfkVrTb8OlVbrNcaepFXLVK9poKYmeXxeFI9 Pk8XT3fPfE9PT29Pf+BsT0675Z5cT4FntKfcU+WZ0m5nu52e6e3Wema2W4tU 61nkyfHM9SyFZHa75UhrHfA4f8EaG/UVKF1KU5Ce+ajPATUPnHlNk3q1Q0fU IVNfqr+CtXhNf4MS9Tf1o9TenGxOpmvUE4J6WW0tL13Lr9WqbzOLDLzSFtPQ 3kB7PBX0FfpGkvom6IrnNnhyUDx5eD3Uf3ApyQ0YSZo9Vb0ixq/gQgf6UNbW s3Hd7OEUZQ9F2m3vAxxUKWkaUt+kQUlDkoYljUgqSipNqkyazGNYCN2h+tP6 0xjDszqeYvpz+nPQv05fR0J/SX8JI/wtRiUxt+3k4lmF8QgtRLOZ2nZ+4mVT i0B0+umgtX+LstouRVoBWM2Uk4Lp85VVWncWf915ZFTa8B38H5u+b4xnj++7 xnK+8az48WPBDoSxFxJ7ocZeqLMXmuyFLvbCUPZCi73QzV4YDi/8hJr9YCvW 9N76PNiyG2eAeKIExJwgoPPAd/G/SzZYl97uEOdZCbPPSauQ6um1SOdKzE6Y hzQ7YX3CofPWOmlTwlHghUhN+VsSdjbQ2xOOB9V8zZyT36MzeFQ7E2qB9zD+ x9P3z9qZr9Pj/iYjmX3WHINn92Pn9Q8nFS8anh+PIPY8iqdImOtt19uwzV2u XbDNd13vwjYPuA7hWfKR6yOK4udEtJVlZVGsNdAaSHH8zGj1o+JvDmAQoJQj cKz6tQ5aTnNR6hGIyrEstxWAszrtb5TTmtMplKIb5FQEfgy+hlOe0z/3lsi9 qffquNgHiX3QYB802QdD2AdD2QfD2ActfhKG/5M1qdUgXg3Jq5H8M2tS66r+ V4DoRHt4DeOYp96xpv7nUNvI00xnn7Q2QbxE3iVN6xLE6+rsk9Y/iDeYd0nT Rgd4Oln/kK0pK4v7zr0xWROxJo016axJsCYX6wj9ztYGRjYHI3sQ49N4ZCb3 F/KdLYQ+V68OzEXwOI3v3KMfI/v9Izlfix82c+Vhi2gG76fjOa141x2f0+B9 9TwdZ7+FvJ/Bcsuc3aQNAd4/z6++33+Da8+d/Q+rVXPaE7B5Z07xzPuaDrDN B/G0MKoJWiOH1yVg88G8/gGbD+aNDth8Pe9fa/H/PJv9x/zpP9XiNVpPO/gs rnaH4nDXjsNdu+Vmyore9p+a1Jxd77jewewOuw5jdh+7PgbvB58KaR1tbLyn ROHUFjuFsqL2Ih1QOHYw0w15oOZAUOms1CgZfbUDQe0a6oP0nasriBO9sWlS Pur6s2v/T51hZC1DVsxUpBlIU6MioyJVKWof4+GMM5w8QCPFzKovqxaOZKNM Q5oRtaNeY6O+ejnWE6QhZmpkTWRN1NSmiWe4x3X0R5yPdC2Jb9+rA5GkNXhC W6Yt1tJQXhjM1V26rqkb8PQm3FK9SDtJ/IskQdw9+k49F+UhwVzRXXTR1Tmr ZxPuUrFIdES5YxBXN0hUB0W41kFzi9SX6U9ibk/pKxB1n9GfgV+v1lfjrrpW X4uZb9A3UAhm/hq59K2Yf6j+R30X4uNu/R0K19/V36Vm+j59HzXX9+v7qYV+ SD8EnR/pKibalo2Y2N5qTy2tZCuZd/77osa/dyzq5j6H8YM/Y9+P/ix9P/gz 9j3vZ+x7/s/Y98M/Y9+PcnTqrOKQVv9utTbM64iYpdGXTXgevjccaMKL19Qp cnsTXqTmRunFJrwwTb27aWkTnk6nUZodzMNdsCboXNcmcK47HnSuc3if0pGg c53DO8znvx5NePv5TpTahLebzxHRDTwVyVXEIT6HaHwO0fkcInAOOYjT8CGc RkKaeEiDxboONLFehR8K4jv0nkYrU2echl2fE0Q/2EgHywTaPhyk06E/aGI9 al6p5AGOUe8M5JklNMphFkpuHTmvjWoURhKn/rCGcpOncMQRombdKMsq/U9N QTeFH3jO0FZqn/PrqRWYN47npEVENIAqnw0OXw+CYWeVRzTQWkQRoJRzh+ei rLCMnzEd/Fl7/8npn3bH+qGnz8NaDNt9b8Juu32ALkSh5ecHd1iAzmkEdwxl uXr/9OSmf6T1/5V+4r3+J/lUyBrSQqY2gCqfDU35w8+VccU3yoKuh3pelnng PzgdDsB/WPq3+5R6v/OpoLuE+u+cq7b8zJHg9COeuuqEobGXqufY9rpu9c81 PU+2ZJwIXMB4nMxgWmN+KvBo5ueoT+TqHiOL+SnAxTIfuKeRB7ze6M/8Zqqt cQPwMCOba5XMWK69xZjPtYq+xLiF6SOKZv3ZLHlLQF7VbhGrgDPUp3z1DHML 018ynauw2KOw0Y3xVq7FaIVb8YXbWKywnM2YGKvXY7eIhQobw5nuwvg0c5SG TawtR7XSauR2RQc4E4G9igP+AUVz715u5ZUFjGczVu/Lz1W1Wq4aA/BWxk6P e7ivbgqz5BbjW6YnMuYRcu9bVFu9F+vvpdrqvXgvenHbQyxZzXRaAC9mvtJZ zRqWy6XAUxTWZxh3A9uMJ8vDwCflk8Br5RmsTLmEfeiz1DqLPWaawmqdQVcr vuKgVq28i2e9ifEsHtssh+axzeIVmKWv5JUZzqvB41QcrVqU85i3Mr2H6bVM u9X4WSaNtd1W14mxsrGKukuBq+puBC6qU/ueXfcM8Od1j6kdV5aszz+zX9EK 06la9brsKbbw7Uxvr1XnvwUK65GKr61RfD2ydj3jY2pPAxw1qoozsFItQtVq FSwfUVvO+ArFYX4at83h3nO4bY7qXdsSGIOtaG6by72f4t43sf5q1rOFe0lj mWpHksd8qna14vOMIh2s5EEr39nPPUayTJzCupf15NbyGipMp5hTrUalVSsa OqGBjvJqrGJtLtZTIFvxyijJGt6RvoEVUyM8xDtVwztYw9ZVw3YV4czXsXCe dRpr2MGSfXl9apQd0myeb5yjnz0oR/mOFse125Xd0gGlEz2u5tHuZ/5i5i9V r+EoPr3IlrxTvgkNd8uXgDsou8VM9/NM2QKVrZL60+oWM17LZ/jOTG9l2rlj 8U2mbrQODXXNmd6nMG5wip7JuNJpVfc3YFNJ1vIrT9py1uDco06xTH+FMQKq vzdh7VQ0yGHON4x/x20rmH6W8XvMmcK0cxt07nVPM17H+I+Md7NkNeNDzFnA mO+VWhzTnzJ+QWHdeX3rlQCN24m4lld4G3t3l7ohaLVBYfAHMT9a0cZ2RZse 5mxWMUHJ0DYDtzK9zZltTPdXbRUNDbjb6h+aOYx7Kqx2VsSoCCls9Xkz4Byl R8mLhQrrBeZAxi+w7W1nerlaK44wA8wpihMSyxFeRZ5eZoSqDclh/i7GTJs7 OB5OZLqatbF1sYZeAc4BrmWdZ9RTpqB2DPCiMyquVp35jXrKnPk91yr6euNG fgbV8jPoWX42KR9/UOL5qd9Z9ziwz/iGNV/ObR9i/SNVrfmU0mAqbVWMXzLv Us8+5hcwna1WWM+WHn66/Yn172e8nXv8hvHvVK16l4ReJdXIbzH7Mb4aOMp8 X2kwW7LPckxgb13K/pjBHnpXbQvgnox38NMqSsUu+jNHsC3qOQWs7n5fckyY zXo2qTiMJ53CLoVpO3tWrvJoOsV+natWGLR6TkUpi0Kvyv5Ntvk+jk8Fbs3p yt/ZPnMZb2EZm23Sy7gX8/n1VedVE8QjJTOX8WSFMQKFjzDexJr7KM1EdTHc y2bGOC3U5dZ+ojDreYvxa4w/J5xD0EbRz7GGKxmvcuIEqc8U3quVUvBnCvvw ZwqHNHymMJE/FxhC6vtGXNSMWqgfUWCeOqOFUCjOVM0pkiySDZ801Pm1hKaf NUwM+pShhhuCk0dQVH7+2HKqZDyZ8bSCkuJRNHNkcWkezWU8v7i0uJIWMV5a PK6shFYwXg3BPFrHeENJWX4JbWa8lfFbYwsLimkX470VSucBxod57noD1vkz i8SnQ4VlEA4JwkYQtoKwCKwl8QlTYTMIuwI4AivgJR91Pe+nHp125YG8yvkc H812Tq3aMOBQ5FWBvNrJzd1OHpYGeeTh25x2EccDn35c4/BbBD6N2CLwOcEW 6qcMsHvuAay/Ur1nkIwQd0h4SERIM/7f0t9VdNfaajZ/cnALtMSRh9Iw+p7U lwZjxMpLDBGp3qnJ1HUNVJ8G6voGqm8D1Y8pEz1GUzzZWJM01vIVa/iaW5/g ljXc6htu8a365htYWRxWMUngJqGfFLHcKp5bxbB8KyWvbgXkFi1ZTzS3Vf81 /Aq9kggRIRTC78R08a1TmNPMO3W2WOF8+U+YCOMztJvXARLiEzNaPKQkzBgz Bm4Qb+JGqd5/riS0IbRSJApbJIlUkSZ8orPoKqaLGeJeMVPMEnNFtZgvFohF YolYJlaIVWK1WCPWinVivdgoNostYpt4S+wUu8VesV8cFIfFUfGpOC4+F1+K r40bjJtkuvTLTjJTXiwvkZfKy+VV8lp5vbxBZsmb5M3yVpknC2WxHCvL5O1y nBwvJ8hJ8g75X/JOeZe8W94jfynvk/fLOfIB+ZB8RD4mfyWflE/L5+QL8jfy t/J38jX5unxDbpd/kH+S78r35AfyQ/kX+Yn8TH4lv5F/l2dMzZRmqBlutjBb mm3NdmZ7M9lMMTuYF5nppt/sZF5sXmJeZl5uXmkONXPNEWaRFWfFW22sYdZw q8AqskqscqvSmmhNsaZZM6x7rVnWXGuetcBaZC2xllkrrFXWGmudtd7aaG22 tlhbLfUfz5UiQSRgN9qKttiN9qI96SJFpGA3LhIXwYrSRTpJ0Ul0IlNcLC7G nt4l7iKXuFvcTaHiHnEPhYlfil+SJe4T98Ea5og5FC4eEA9QhHgIu9lMPCwe pubiUfEotRCPi8cpUjwhnqAo8ZR4iqLFM+IZail+LX5NMeJZ8SzFiufEcxQn nhfPUyvxkniJ4sXL4mVqLV4Rr1Ab8Zp4jRLEGwK3WvF78XtqK/4g/kC2+JP4 E7UT74p3ySPeE+9Re/GB+AAW/KH4kJLFX8RfyCs+EZ9Qivir+Culis/EZ9RB fCG+oI7iK/EVXWQMMgZRmjHYGEzpMk2mkU8ikV9m4JaaITvLztRJdpFdqLPs KrtSpuwmu1EX2UP2oItlT9mTuspeshddIvvIPtRN9pf96VI5CCef7nKwHEyX yRyZQz3kMDmMLpfD5XC6QhbgKXmlLJJF1FOWyBK6SpbiiXm1LJfldI2skBXU S1bKSrpWVskq6i0n4pl4nZwsJ1MfOQVP7evlVDmV+sppchr1k9PldOovZ8gZ lCXvlffSADlTzqSBcpacRYPkbDxJb5Bz5VzKlvPkPLpRLpALaLBcJBfRTXKJ XEJD5DK5jH4hV8gVlCPXyDV0s1wn19FQuV6up1vkRrmRhsnNOLPdKl+Vr1Ku 3CK30G1yq9xKw2HX2ylP7pA7aITcJXdRvtwj91CB3Cf3UaE8gDPSSHlIHqJR 8og8QkXymDxGxfK4PE6j5Ze48Y2RNbKGSuRJeZLGytPyNJWaKrCXmYZpULnp Ml10u+k23VRhNjeb0zgz2owm9bmURBpv2qZNVaYHp8oJZpKZRBNNr+mlSWaq mUqTzY5mR7rDTMPZb4rpM330X2aGmUFTzS5mF7rT7Gp2pWlmd7M73WX2MHvQ dPMK8wq627zZvJlmmLeat9I9Zp6ZR/eao8xR9Esr1oqlmer3YOg+K8FKoFnW LdYtdL91m3UbzbbyrXyaY42yRtFca4w1hh6wyqwyqrbGWePoQWuCNYHmWXdY d9BD1p3WnTTfutu6mx627rHuoQXWfdZ99Ig1x5pDC60HrQfpUeth62FaZD1q PUqPWY9bj9Ni6wnrCXrcesp6ipZYz1jP0K+sZ61naan1vPU8PWG9ZL1Ey6yX rZfpSesV6xVabr1mvUZPWa9br9MK6w3rDVK/lniAxgiP8IqOIkN0ETVitpgn ForFYqlYLlaKF8UGsUm8KraK7WKH2CX2iH3igDgkjohjiJfHRY1xo/ELeZm8 Ul4jr5P95I1yoPyFvEXeJvPlKDlGPigflo/Kx+UT8hn5vHxJvixfgQ6vfFO+ Lf8o35F/lu/L/5YfyY/lX+UX8oT8m/wfWSeOmZbwmFFmK7OzOcwcbhZYiVau NcIaaY22Sq0Kq8qabE21ZlqzrWprvrXQWmwttZZbK63V1lrrRWuDtcl61VLv wR7DkYw4kmkcyXSOYYJjmMExTHKsMjlKhXB8cnF8CuX4FMbxyeL45OY4FM5x KILjUDOOQ805DrXgOBTJcSiK41A0x6GWHIdiOA7FchyK4zjUiuNQPMeh1hyH 2nDsSeDYk8ixpy3HFZvjSjuOKx6OK+05riRxXEnmuOLluJLCcSWV40oHjisd Oa5cxHEljT0+nT3exx7vZ4/PYI/vxL7emX09k329C/v6xezrXdnLL2Ev78Ze fil7eXf28svYy3uwl1/OXn4Fe/mV7OU92cuvYi+/mr38GvbyXuzl17KX92Yv v469vA/79/Xs333Zv/vxGaA/e2oW++IA9sWB7IuD2PNuYM/LZs+7kT1vMHve Tex5Q9jzfsGel8OedzN73lD2tlvY24axt93K3pbL3nYbe9tw9rY89rYR7G35 7G0F7G2F7G0j2dtGsbcVsbcVs4eNhhUep3GinUgWHYRfZIoT4n7xoHhEPCZ+ JZ4UT4sXxG/Eb8XvxOviTfG2+KN4R/xZvC/+W3wkPlZWYWSLE0a2MUTcL7vL K+TVsrfsK7PlADlEDpW5coQcKUfLajlfLpSL5VJE7ZVyrXxRbpCb0OYdkSy3 ybfkzv+t7jzAosbaPZ7JFMrQBESQ3mRokhnKMFQBQUQ6CC5F6b0MXRApI82C qBQVacIqIFhWEBAWwYJIEQVXrBTF3nBBRUThZo4w4n7u3fs8997P52MeMu9J Tt5kkvP7n/ecJCf4Afwg/i5+GP8Q/wT/Av8GP4H/gP+En8U+xesQOLHSBH6C MIGCN0YtV8Imgjd+gChKdCd6En2JgcRQYgQxhhhP3ErMJO4k5hBzifuJh4il xApiJbGGeJJYR2wkthDbiMw3mkX9hxHHrPPFAXcSgDtJwJ0UqNWlAX0ygD5Z QJ8coE8e0LcC0KcA6CMB+hQBfUqAPmVAnwqgTxXQtxLQpwboQwB9ZEAfBdCn DupbDcCgJmBQCzBIBQxqAwZpoL7VASTqAhL1AIn6gEQDQKIhIHEVINEIkGgM SDQBJK4GJJoCEs0AiWsAieaAxLWARAtA4jpAoiWob60Aj9aARxvAoy3g0Q7w aA/qTAdQZzoCNtcDNp0Am86gntwACP0FEOoCCHUFhLoBQt0BoRsBoZsAoR6A UE9AqBcg1BsQ6gMI9QWE+gFC/QGhAYDQQEBoECA0GBAaAggNBYSGAULDAaF0 QGgEIDQS3F3NhbZwPKByqBZqgNqhbugPaBh6Bk1An9EWy3z7B1KCELQlpodF 2zpoW2MKnaZhp9FpFnYGne4mpKJTCUIgBONVCcHoVI0Qik7JP/DwAXj4CDx8 Ah4+Aw8M4CEIeAgBHsKAB7QFRwhn5gAWnWVFsKxIlhXFsqJZVgzLil2wuCxZ lhWw0PYbqjqjEISqwzi61Qn8JIRDVQJtNaJKMQOxo4S3M/snMEWQCKQNGUOW aGvaA1W4aLQtncU6dnehR8xHsDCCGAkMCUPB6GHMMLbgzjgckYS2Cw8CS5Fl KS1Y8FXUOgCsPpZ1jWVdZ1n9wMKC1r0gPMBMwechmGgNj6F2Achzg5X7D5Z1 87v1BsF6F9BpNnwRneaDPLcW5RGCLzH9wR1oO/YA+n2b5ekOy7rLsu6xrPss a4hlDbOsEZY1Ciw2iA8tHVLzvRR6cBe6tWJ0e11gq8VwJ3iurRtNlaDpbjC3 BEajG3T6gOXrIbCYzz5+vd+3DD6K5qyCayFO+AR8AuKFT8G/QXxwHVwP8cMN cDMkOD8CryBzVB/wrBwEriAzn707jC6ogWtQn/VofizcCreC+4ZhOA9cjWQ+ V8Vsp7OhPvCgP0t2fkQ1cTCWmgTqow2SBFcXDcHVRaZ/C/CU1ApIA/QV8BEp aH2AljjsiwWLIARKhDqamkTb8EMgHw82Ga090GVfv7EvQK8Bs2UJgTYiBl1z BPSX8ENfr2Di4KfonjJ78DFwGdguHj3GC/0ooJ8C7gG/pZd13h8x70oB1mOW 9WTBIiQwc/+3x2ahH2p+1DBRZo+iIJgLiWYgDFEGgUMpwzxjihvDBpcxRKPQ WeEwBkMmIhwEvDIPFl6OhxBPAqcyAYPDMKgwBlfmgNghKovmiJVLpIhBeuBj A3mBQVFDwGCmvpAB84NIL3KGE7RMqkoWeekvE3Hm4frKoWPdvdR1QWUMoTUI A8ePMOBPZVgYA8O80Hlop55e1pJ+gw/er0ZWIdysPWWOUozQycqIIgG7HkcU kDEJp8dHMoeclCJ5K0qRaTSqFGuQRzCg5EqyBCL2NfPS75fMDzVJlkYkmcux AsLfltuHh0dLGcVEB4RHBkbHIxLLuGlUhExGECqC/rks46YgZIo6eT75E/aI gZFZfFgweAjLwPBC6HxOmIHBQNVw63n6E90Ja1FS6f7NG5EX5dXZ8ps+zuZb VjTOFpdLGSTalR8qz/GgBPcb+8S/qY3tcrw78bIoQyynNM2vriM4wUt2UFxv mBez71nBpTZVv8LCgBUHr+uotHGd2bDivNlTTgPtApVqEq3q1dptxmNpvC2F Ies9axmJhz1U4yyfH6z30S20FSOzywmWVj/dqyz8RP+At6DHBrxvqTjVPnOq cjwPvix6o229ad32lDadV4551ie+VCaERlufFO4t4CBJQ857PAKpLev42fSc 5lxnfvXjZD86kOrkPN6gu1EoNQ5398O5Eyn5s6euJg9WLo900+v+/S17hQxS R0jvqpOKE0gfgbFowa9IrUJSjyCp5ejRFMfgUguR1P0pfK7X6eOBkSWydkmC p612z/Ucjvz3nz/GP5RxLPMc5j8jtmdP7hfWfN2Ekbsdt2TSzYNSWkLsMcDv zcrp0nkiPfHWOVflTNmaK17jn2/16uq6VGs5Bs7KhRp29R4bxicOkbP1S/no QS2z/DbCge2fr5uMLXGRsnnhteXkMZErylR51XO+h/l3yPN6V0w5ik1Ldw0u nbSvDTOhsH1hLPv42D+E2+5D65/2na1PLyGfpcgcWeL5isutborDR/5MGcXW u777beiK8xvftZ32jg31WBL/3J7Bt+w5SU37O2qoKo8SHlXFjcWWQdeDDM8P aO0YNeKv0gwSDbqn+eAPMdyjKlPcFRd17TArMW6vRs7yXTduOhqaXRVbf5R+ j18nMzemtHKgDFUFD4SBtfyqCpwra5bct51zK+5pX9AU8Z8lBij32hT0D1UA CioGZAqa1FwQg3igoKgTggC83oEsgCxhJtgFOJ09owICw/yj0c3wITzMmWwC bPa+PqHhYT4LO8b5dzsmi0h/3bHli5f7+Eo5BPqHMYd4tTUx+kdVaIzfOuhe Z0qr0qgl352W11wb1z4jWdJpGjHeb/bsj10Xgy3tvd4dhC9a3V4boiZn4NvW J9tING9MjhkybT2Ww2PbIa88UfaUW1ay30juk9fBayKmR3ItJA9erVOTuWih mhh+Z6mE7i4aH22oVfGdn64qhjI3q2B+9EwIJrNopvm0dzJj2q0sNS1996mJ pryKa9pHbdOXKWRaDyEfIP13l6f1U89lvA6hVa7U+FC/8iTnVq+9m/2KDkRx Z5ycuDQpddaGP9u7R+UOxVTkTYtFga6tg3Cfn138seOZV5wMShm2WWH43zTP b5FrtffTP2jdq5ykHpa2htBfct0iAw7LgH5tzxxxmFeFT0jqFCLAFAV5HBfC SWBHKzQ8ng2L/c+QCl7mPgpgMHM4PIJFvxBx5gwenBBOsFe8Lxaiu5788+4l 60K71SsrVnu/RYjMxbw4HIpRxiJ0gMZsqTmRZLFiou936+jyDQrRSjF1GV9q LPM2Q1bPu18K3w/s4ClPnIRNLndn9n506L1Q2uoU/tZ7dfVq6E3BlcKbYk3E UhHuvFt3JY4rbh1/fTSqNmeYtlv/QNDv2qEDWSdlv4w8Hwzk2JvVOvsAatGY nEqc5uNfiX+pWJBrHEyKaNTOGWXj7nIPuNqaYhTsV9XS2LJbo3sCy5eY8H5g 1Hhky+yDB7WzH0ZuctfRB/eN2TRolyeq/qF/T4PoRYVLU4Nkt39w88455dJC u+Wxa33acvX3ugfKGFzlm3bWqTQePtJTc1eqoQ0RSZcS5Fb63f6d0ehGZGwf KTDzPP3hZGVNX4pxZCwPqjEJqMZ4zWuMJ0EhFURI7Is5wqM68xOpZgqONqo0 FAqZoqGpyRQcBA0/0KQ6M4mkbvt/2TduUHDQoouzsrG1X8iO/Zvs/6g9rZH1 25+KlaZ3Rjd5uGG19Iu+HEwoVDSTOVWZ6fD6jZlOpyue6FzV2I3vvWEZt4ae Xve4Z8T/acWXaIVc/9JbO7CrkctTXc1dOuLsTqttlrFzT9eLBByTE5vBO6c/ 77Bmk6ZWvuxTUWswviqNrxx8coPk3Cma0KeoxXa1ZH1vy58yL6tkf+VWvDBz /aKLgbd+p8pa4pb49LdZ4xGtJi5jFXXck+tn5EcfSt14Wrgx74i6KinZWXR9 EBdl9bhfSPhb7aJx+Hjh4aEDbHw8esKBD+OtzQRHz+66HhNaVAsVqRq/t2ty ebfZdNvzlYnKLe5XRTxJx/NMODuCjOfOUE78qigzLPTsxrz2fERS3/9Ye75R LNsfpWTZOvNY+lOExMGl/cumLx3dAU6fOC+TehRkthSgG+KyOGFEKOXH2K9m ZpDE6SO6CK2MWqaZoR4QHU3XUVPzjgxZGbpwDld6h4eq0YMDmXPV5octj1Iz cUAL3kp0FmK+sIdoXKKH6CDaC2kEzlCZdxgXF/cjh76RizxF/wUooD4mite8 W0PGokIvHrwVypWle9k8KkG+T+UhdUuxRmmrbN+5kdtu8UuCBeykMN5nI6fY xy5vtVMSIv3R//SQ0jVh7gGBiL2Kr5xapwc7uNVO+qqGWpkqOkWm2RgOBIkb eVXHu+1+2xm3owcmrSzuLFJ+fFaJY+jV/oePE7I38mU5HB7ysIk7EOFR5Urb e6OGXxL//KJp9Y0LdmdPNt3/TEiD3kVX3JvrFS+TxbM9UtC8sH+PyDGGh8Kz mTRliX5cz+5rDO5bVVYmq2IGhofixne4BfNm+uTUNzc21/g7Spseswh46rhx p6Cb/+ZXe9ywfHvZi+Wk9j8bgZbQq6dPR9IbTzy8UCoEo+pTjKpP+lf14Qsi HrRph+RrltwzldyQ4F/+Vw36ObGOFkIjayFkREODypQeGpr8CbGOY2Cob1S0 Zyj9fxrr3KeGzZy8YmwRIXylz9zAof1TjWCzCqWF38b+yrbXBup31pL3kRr2 +oxK2qY1X1jXn4z/OB5zbmdn1c0TgXS/zQp+zxoax9PPXn1z7Av/r8RfZBTV rq2644QTjT0T6hNq4Xhv6M/httJtnSkjyZYwNe99ewm7k0TAmqt32mPd1LY2 yOPqnVyDxLznUhL13tzEyVvR4qLZ3C+43c6gqsR08byQoHEkxs4Wh4QljL4y yNlfEsGzSclG2MuDUjKwzVpZxi3AdOewWhqf7enpM8uzQ97IHxL42MN3K53n HSM2SutyfkJ5rwfhFf5UhnrjxzzXNKO0Del5YackVcx7w4tMRoOeJa/YHfxV bxgYEnpE5H6kOOz/GdEOH4Fjvr9hKYYZwkCLhDL8mbXh/rMaNesycn4velGr a2Ry+ToiwlpBEMZxSXBCDlAM5AWZQEbfR0L/Ekb9QKDyrJaQLyTatizZfdiT DcOzi26aPR7l2GrIgVeda7JzSBd7TdvbWOFEHN7VoCvaP1Nb2dX4m520aDh7 YFIwtlzG7HVIfWiiTJPZjbTJbN5zbDu0zr9Mek53Ny3dN9DbN7S7/UGb0tXE V10nKDczz/Z4X9LqF5Zuix3WLawTjSqRzrpdX8/vuOtd0QVfi0LSiiKPHby6 nQK+m81brh3fpmNzymvDMPL8OU18bPvEXVrqtID0Lp8UbwKuYKIQNlHbYpbV PAff8Z22GL6Ljc6tw4dx9RbfJ3kmmv+5rGiJtDYslllL6CigND1eddlBv7V6 +/AzP2r2O5mCot5TcY52OoORq0/LfkAF6hgqUPtY4VGeKgiPOH5eePQvQgDC I4RK0USliUIGGqX+NUlmJpHUun9HeKSAyH9NSoSZBNKZb8RY7WAqZepgrUM1 0qaoamlrG6nSzGgUsjwi+/U3iX3/m1QdmD9KysE3kvkGjX+Ut/xUTiljYbuE O/mvD325n9k/w5Mj8OIYlcQfO2tlWxO7Xyl3zWi1UyD8OC/JKv1ecsR4DHSv xSRkJrw24q1yf+K+vrxlxYc7mqenkoY8H6giEkUrVGMNn5gV7D5xezv1du/4 5DXXi58DRid8cg49u8g/XXEu7fPgzj68fism1lYB+zGtUSgj2+Ocu6KK3rUj Xw64aIrbCLVr35bwNNTXqnMSXBqXr8v3CTqV+9CdWqPQ4q1iLpi6fizkRbVy fnYWT1IFdCROju2AEh3bpCS3p3C4o1xmXZvlL4Q4x0iTUwY+Q7lp7BsaZp9n ruXQqqv7qF6dZFken0z5RZGn5Mz7Ub0Sw1dmuovDqW+CQMrPaoN1X97Na95q xvup511S8Vz/d5HSDxXjfxMpRUfRvT3/TyKlBU/RPxbr7+I/QvuP1Ap6U/v5 4UCWX7fimMvZqxAjaZlbh9wv/C1VU8G3Mmeze87ESorKfJh60F1/1giznHrc nFpA/9SrXkna1URsiBYgNdbFPFDieLjTZuSA4f5GDf7UF3xD4vebfa5Z2+pa 7vgiMiR/4mZB5ot1lx6/nTZa5o556Zy1NTbhcfhsplRtbtGuwrZNy8uWInKj 5Umee8UVFS+u3aNjsm37m+Gb24ZsVDR1nxoZYY5BXMSJwbWifcbZW05Nqma7 Kz44l528d2lsvceMoMKxcH5vY9IGnR26O1c9auzo3ecsZuYUnNOzz8oJD3V/ RFaZWo+IZLW+53s7tHyEJFFvNxE3umKshSOV/76EznVTMgN3HFWsahiDQVIz f2KT7buG5LcO8LLU24ggq3YiYchsWDy45MGss+ZPJgeWzLW4zx3dm28pIpkH Wbx0KaolrBVxZBSAgAjHCZth90KCmKCB8B5SVjH/8TzEa9EqXGRHxL6MlLLi b9/y9t170w6vSJH727IbHU8P94/0pAfES/1Fq3AMDGQwwXYl2RBLOT1mJz91 8YXjp+5chz2O07SmYgznpzbtX0pFFJPjJvfdNii1SOA5+0Tx8nO7GIWM16ay 0TviOWRlUgYYLR15/DmFv8utCTjRyffR/0Puaa0LTUkpMY9P2nEK4Z7cMGsq mUsw2736WVW74ych5/zgFvnY3Vb5K/OgohUbBxVC16qvOZIXxWlx++mB2Rgb LtGEKdKddN9Bkw/krW4uN95P4WTkOGdX0Y9eorzoJphnVr0SqNGjf9xacSvU I0JyRt7wQmilneDOUMOTSltWNNTb5euYjiuaTxU8vGAHdX0pZaTRbeqyJxU2 rGnfdVb4nZGhUfmXQSuhAIsHq+e4XY9PHmbAkggDFv12hghkBsyFzmL/txfQ v1aa31XlbPMFtMwdEV5cDonfLhBh0G2yluDJvGiVS2NeAUH/tTQ0Xf6lGG44 6ODfFLE/e/39EIWmOGql5dpXl/6iWMwi4neYLT3hUOdv73LIalbR20te+tg0 nz4kHrTvc3h3X2Bf/8hdz1lzZ/8Zaa/2EZnl/LhNdjstomlCl3GXnOS0rQ39 aAJ5RmfaB1QyC+7L598wDyssnQ4/cuqy+Q7lIrlpmHKRe0rEzOWl5fs9vifr XAVySb7ZY1tfsRk3Z2pFX7zXAI3TtkdNPpKLm2kgxZo+zobvvFXnju+lbxa6 Nltv/3qMw315rHxzdbwIzy2rRopIfD7sbjXyxWZLGCN8F0cxm7hk4hjf+Tv8 seGpki5Itp31pZ6sLUvb5o5j9p77zOn6ON7IhAtr1tcTNf5k7YbOrV758gEi sucD1yQHmL0PDI34s+bSUQj6L39HS8cNCmVuZHN0cmVhbQ0KZW5kb2JqDQox NDAgMCBvYmoNClsgMFsgNjAwXSAgM1sgNjAwXSAgNVsgNjAwXSAgMTFbIDYw MCA2MDBdICAxNVsgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDBdICAzMVsgNjAwXSAgMzNbIDYw MF0gIDM2WyA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMF0g IDQ2WyA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwXSAgNThbIDYwMF0gIDYwWyA2MDBdICA2MlsgNjAwXSAgNjRbIDYwMF0g IDY4WyA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwXSAgMTc5WyA2MDAgNjAwXSAgMTgyWyA2MDBd IF0gDQplbmRvYmoNCjE0MSAwIG9iag0KWyA2MDAgMCA2MDAgMCAwIDAgMCAw IDYwMCA2MDAgMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgNjAwIDAgNjAwIDAgMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgMCA2 MDAgMCA2MDAgMCA2MDAgMCAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMF0gDQplbmRvYmoN CjE0MiAwIG9iag0KWyAyMjZdIA0KZW5kb2JqDQoxNDMgMCBvYmoNCjw8L0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzcwOTAvTGVuZ3RoMSAxNjg4Njg+ Pg0Kc3RyZWFtDQp4nOx9CXyU1bn+Od/sW2YSMlkYYL4wJCyBhJ2wCANZ2Ncw mABCJskkGcnmZAIEQSOg0oiKu6hV1KpVXIbBJe64VK0b1tpq3YqtbbWK1VZt XSD/53zvnBCo+vP/u73X9t45H888z3nPe97v7DlpR2CcMebGh54tKSmfO/vg plEnM6VjNGP9o6WzSpYXjnDextiuXYzxp0pnLSi+qqHMwdgFVYwpo2eXlJb9 6YlPIdv9jOk+mr1kcXm4dupWxi6uYPwa++zywCydbvgXTCmoZazs9cXlhWO/ eLN7I2K9hrdW1TQFW9Nv6/cBY0O7EeTumvVRNXb1ky8zdvKVjBkG1LXWN33+ +UI7YyMaGbP0rw+2tbIBzIf3L0F9V31jR93I331+CWOr74b/yw2hYO2Hb489 hPirUT6xAQbHHcbXkb8U+SENTdGN2Vt1U/CuIsZyz1gXijTzwfwcxjpFe7Ia W2qCy4eXH2SsegdjgxY1BTe25owZIvqO9jG1OdgUyr7ttNPh/zFjjumtLW3R Hg9D/QtGi/LWSKh13V3KUcbGof4QFxNja+heNoH/PrTWOe0zlm1mIj34webn BT/3+v5tX3155DzLh6Z7kbUwhVFCPSM7yviT1j1fffnlHsuHWqQ+SbdbWJx5 bDEzaAaFuVghCzGWugvv1Vz0+XwXSs2G3YZxCDmIWPcSO0dhZqY4DYqi6HWK /hBTevzs9h56L2MLy1WVYT7ZHmqD6VolT2X8Oi3ofYYU0VNETznWGn6Q/Z9P xlfZ7T90G5Ipmf63Jf14VvVDtyGZ/utJeZbt/qHbkEzJlEzJlEzJ9D+VlKu5 9Yduw39a0k1g5/3QbUimZEqmZEqmZEqmZEqmZEqmZEqmZEqmZEqmZEqmZEqm ZPqBki6BAYlvh0WQg1LWMD1bgbwLj04rcbDBbCGrhceenp6ERe1j4T2fMdbz d3Yv799Tk4hm7/sm3TzdFczIP9Ryn5z4bTTklcR31xT23Yn3ifffkUr+f5x5 /+8o2/lfbcr/cNL9S6P9t6wg/+zatWtOWb1qZWVFYHn5sqVLFi9auGD+vLlz ZpeVlhTPmumfMf2kaVOnTC6aNHFCYcGokcPycof4Bnuz0lNdTofNajGbjAa9 TuFsZKmvrEqN5VXF9Hm+OXNGibwvCEOwj6EqpsJUdrxPTK3S3NTjPf3wrDvB 00+e/l5P7lKnsWmjRqqlPjX2QolP7eYrl1ZAn1/iq1RjhzW9UNP6PC3jQCYn BzXU0qyGEjXGq9TSWNn6hq7SqhLE22ezFvuKQ9ZRI9k+qw3SBhUb5mvdx4dN 55pQhpVO2acws0O8NqbLLQ3WxpYsrSgt8eTkVGo2VqzFihmLYyYtlhoWbWbn qftGHuja2e1i1VX59lpfbXB1RUwXRKUuXWlX17mx1PzYcF9JbPimd7PQ5VBs pK+kNJbvQ7D5y3pfwGOGXJdP7fqMofG+wx8ebwkmLMZc12dMSNHF3mFCudQM bUML0b+cHNGW87r9rBqZWOfSCsqrrNoTZ/7C/MqYUiVKDsgSd0CUdMqS3upV vhwxVaVViT/rG7JindXqqJEYfe1PLv6gXI3p8qqqaxoEB0NdvpISGrflFTF/ CYQ/mOhr6b7RhfAPVqETYTEMSytihb7WWLpvFjnAoIo5CJdXaFUS1WLpxTFW VZOoFSssLRHtUku7qkqogSKWb2nF/Wxcz6F941XP/nFsPKsU7YhlFGNS8kq7 KmrrYt4qTy3WZ51a4cmJ+SsxfJW+ilClmCWfKzb8EF6Xo71Rq4W+neAtnUXP TblmtULx6CrFbMGgluHDN2saClyYLi0rZnTWNLWCe5h0w1sSHkIdFwcZXW7x HFGkE1WL53hyKnMofUeTPIk2GXJj5j6xXDD0tone861NI2/RoOFqaaikTwOP C2pINDAR7ZvbqYixSLwYNcxiOufIIl0udi5sCsJoJjGLWWqMLVErfCFfpQ9r yL+kQvRNjLU2v/PLffOXrqzQZjuxSpYfl6PyIsrFWA6KZUYpxhosy/fIadXy s7V8b3bOCcVzZbHaZfbNL+8SwX2JgEzFDkKnjXlzg+cVpY3H1izD6eYrC/pU l1rWFezu6azu2uf3d7WWVjVMETF8c2u7fOUV0zxaW5dVbPFsEq9KY/P5/OWz Ro3E2TNrn4/vWLrPz3eUr6y438WYumN5RVzhSnHVrMp9Q1BWcb/KmF+zKsIq jCKjioyItAwZs+bvud/PWKdWqtcMWr6mmzPNZpY2zmq6FbK5pE2BTU82v2YT CZOU1YAhxnFbqtaK6dlc2dBVVSk2F8vAVOIPj3HfdBZTfNP3ccVoj1l9oVkx m2+WsM8Q9hlkNwq7CQuDZ3AMjjiTuqp8OKewoCqYh9NS1ImQandPz/KKnBc8 hytzsNRWAysrYpZ8nP2G3Hnwmy1QBfPsWGdNULSDBSpEXVPu3JpKLFsZEC5z YxZEsCQiwKNMqyOWIyrVYG4wgVr9TmRinZWxynzx0opwpbacXTE2xzcF004x DXniRYWVXWm+sdrexFaw5p4ryIK2sfIKsniQxcsqaZBMdrS8xoeimioVo61n NeVY6nSWWj1kCeFI1OeFNFg9iUImuqXLtTmsMUsBAuKP0LYCsSUNuabKSmq8 ljs34YB3u2I2tCivz1AmKmB0UDRXtAV/zkVThetjIszSbrbMtxEni2i0FsmE 4pgjd24Qhz/Vt8HiK5KVzeKMsCViPElWk+i5HeOuy13e3XOLryOnTxo10id+ OIiFyTz3Y2Gzyq4TDbFV+aNGmk+0OjRzV5fZ8c0VaLzMjl4WRrUUPzUYi1t0 arey/W5LFp8HsU2KrVKcJUWnFGdKcYYUW6TYLMXpUmySokOKjVJskGK9FO1S RKVok+I0KVqlaJGiWYomKRqlWCfFqVKEpWiQol6KOilCUtRKUSNFtRRBKaqk WCvFGilOkWK1FKukWClFpRQVUpwsxQopAlIsl6JcimVSLJViiRSLpVgkxUIp FkgxX4p5UsyVYo4Us6Uok6JUihIpiqWYJcVMKfxSzJBiuhQnSTFNiqlSTJFi shRFUkySYqIUE6QYL8U4KcZKMUaK0VIUSlEgxSgpRkqRL8UIKYZLMUyKoVLk SZErxRApfFIMliJHClUKrxSDpBgoxQApPFL0lyJbiiwpMqXIkMItRboU/aRI kyJVCpcUTilSpHBIYZfCJoVVCosUZilMUhilMEihl0InhSIFl4IlBO+R4qgU R6T4WoqvpPhSii+k+IcUf5ficyk+k+JTKf4mxV+l+ESKj6X4ixQfSXFYig+l +ECKP0vxvhTvSfEnKf4oxR+keFeK30vxOynekeKQFL+V4m0p3pLiTSnekOJ1 KX4jxWtSvCrFr6X4lRSvSPFLKV6W4hdSvCTFQSlelOIFKZ6X4jkpnpXi51I8 I8XTUjwlxc+keFKKJ6R4XIrHpDggxaNSPCLFw1I8JMWDUjwgxf1SdEtxnxT3 SnGPFHdLsV+KuBT7pIhJcZcUd0pxhxS3S7FXitukuFWKn0pxixQ3S3GTFD+R 4kYpbpDiein2SHGdFNdK8WMprpHiaimukmK3FFdKcYUUl0txmRSXSnGJFBdL cZEUu6S4UIoLpDhfip1SnCdFlxQ/kmKHFOdKcY4UZ0shrz1cXnu4vPZwee3h 8trD5bWHy2sPl9ceLq89XF57uLz2cHnt4fLaw+W1h8trD5fXHi6vPVxee3hE Cnn/4fL+w+X9h8v7D5f3Hy7vP1zef7i8/3B5/+Hy/sPl/YfL+w+X9x8u7z9c 3n+4vP9wef/h8v7D5f2Hy/sPl/cfLu8/XN5/uLz/cHn/4fL+w+X9h8v7D5f3 Hy7vP1zef7i8/3B57eHy2sPltYfL2w6Xtx0ubztc3na4vO1wedvh8rbD5W2H y9sOL94vBG7N8UHTvbgzxwe5QVspd1Z80BRQJ+XOJDojPsgO2kK5zUSnE20i 6ogPnAnaGB9YDNpAtJ6oncqilGsjipDxtPjAWaBWohaiZnJpImokWhcfUAo6 lShM1EBUT1QXH1ACClGulqiGqJooSFRFtJZoDdU7hXKriVYRrSSqJKogOplo BVGAaDlROdEyoqVES4gWEy0iWki0gGg+0by4Zy5oLtGcuGceaDZRWdwzH1Qa 9ywAlRAVE82isplUz080g+pNJzqJaBp5TiWaQtUnExURTSKaSDSBgo0nGkdR xhKNIRpNwQqJCqjeKKKRRPlEI4iGEw0jGkqh84hyKeYQIh/RYAqdQ6RSPS/R IKKBRAOIPET94/0XgbKJsuL9F4MyiTLI6CZKJ2M/ojSiVCpzETnJmELkILJT mY3ISmShMjORicgYz14CMsSzl4L0RDoyKpTjREwj3kN0VHPhRyj3NdFXRF9S 2ReU+wfR34k+J/osnrUc9Gk8qxz0N8r9legToo+p7C+U+4joMNGHVPYB0Z/J +D7Re0R/IvojufyBcu9S7veU+x3RO0SHqOy3RG+T8S2iN4neIHqdXH5DudeI Xo1nngz6dTxzBehXRK+Q8ZdELxP9guglcjlI9CIZXyB6nug5omfJ5edEz5Dx aaKniH5G9CTRE+T5OOUeIzpA9CiVPUL0MBkfInqQ6AGi+4m6yfM+yt1LdA/R 3UT74xkzQPF4xirQPqIY0V1EdxLdQXQ70V6i2+IZOK/5rRTlp0S3UNnNRDcR /YToRqIbiK4n2kN0HQW7lqL8mOgaKrua6Cqi3URXUoUrKHc50WVEl1LZJRTl YqKLqGwX0YVEFxCdT7STPM+jXBfRj4h2EJ1LdE7cHQSdHXdXg7YTbYu760Bb ic6KuwOgzrgbhzE/M+6eCDqDaAtV30z1TifaFHfXgjqo+kaiDUTridqJokRt FDpC1U8jao27a0AtFKyZPJuIGonWEZ1KFKZ6DUT11LI6qh4iqiXPGqJqoiBR FdFaojXU6VOoZauJVlGnV1LoSnpRBdHJ1NwV9KIARVlOVE60jGhpPN0PWhJP F29YHE8Xy3tRPH0baGE8fRRoAbnMJ5oXT8e9gM+l3Byi2WQsi6efASqNp58L Komnnwkqjqd3gmbF08pAM4n8RDOIpsfT8POdn0S5afHUStBUoinxVLE0JhMV xVNngybFUytAE+OpK0ETqGw80bh46kjQWPIcE08VHRsdTxV7s5CogKqPojeM JMqnYCOIhlOwYURDifKIcuOpYpSGEPko5mCKmUPBVIriJRpE9QYSDSDyEPUn yo67TgFlxV1rQJlx11pQBpGbKJ2oH1EaVUilCi4yOolSiBxEdvK0kaeVjBYi M5GJyEieBvLUk1FHpBBxIubvcVZ7BY46a7xHnLXer6G/Ar4EvoDtH7D9Hfgc +Az4FPa/AX9F2SfIfwz8BfgIOAz7h8AHKPsz8u8D7wF/Av6YUu/9Q0qD913g 98DvgHdgOwT+LfA28Bbyb4LfAF4HfgO85ljnfdUxxvtr8K8cjd5XHHneXwIv Q//Cke99CTgIvIjyF2B73tHkfQ76WeifQz/jONX7tCPsfcrR4P2Zo977JOo+ gXiPA48B/p4D+HwUeAR42H6a9yF7xPugvc37gD3qvR/oBu6D/V7gHpTdjbL9 sMWBfUAMuMvW4b3Ttsl7h22z93bbFu9e2xne24BbgZ8CtwA3AzfZRnl/Ar4R uAF1rgfvsa3zXgd9LfSPgWugr0asqxBrN2JdCdsVwOXAZcClwCXAxah3EeLt si7yXmhd7L3AWu8933qTd6f1Fu/Zulzvdl2Rdxsv8m4NdAbO2tsZODOwJXDG 3i0B2xZu2+LZMn/L6Vv2bnljiz/NaN0c2BQ4fe+mQEdgQ2Dj3g2BB5RzWJ1y tn9aYP3e9oC+Pb092q77tJ3vbecl7Xx0O1dYu6tdbdfZo4FIoG1vJMAiSyKd kVhEPzUWORRRWIRbu3sO7I94BpWB/ZsjDlfZaYGWQOvelkBzXVPgVDQwXFQf aNhbH6grqg2E9tYGaoqqA8GiqsDaolMCa/aeElhdtDKwau/KQGVRReBk+K8o Wh4I7F0eKC9aGli2d2lgcdGiwCLYFxbNDyzYOz8wr2hOYO7eOYHZRWWBUnSe DXANUAfoXKIBiwagJczDZ432+D2HPB979MwT8xzw6NKc/b39leHObF68OJu3 ZJ+ZfWG2zpl1MEvxZw0fWebMPJj528y/ZOr7+TOHF5SxDFeGmqFzi75lLFxe pvGMEuIxE7S+Lszw5ZU53dzp9rqVUq+bs9RDqR+n6tyPug66FKeTO509TsXv hLszxZuiiI+eFJ0/ZcykMqfD61DER49Dl+F3wCIiDrUvWV7mtHltSmCGbbFN 8dtmFJf5baNGlzEdVzln3AXSmUUruNtbhn29P4MbOH6e71tenp8/v9vMls2P mZesivEdsdxy8elfujJm3BFjgZWrKvZxfkHlPq4UL4+li//HVsufff75bNbA +bGB5RWxPQMr58c6IfxC9ECwgfsy2KzK/DVt7W35+dE1+FjTFs3X/iDH20Uu XxjFn7Yo8uJp1/Is/zsTuYHWtiFFpTH63bX+3RP/oRvwn5/2MfElg5k9ynZW q2wDtgJnAZ3AmcAZwBZgM3A6sAnoADYCG4D1QDsQBdqA04BWoAVoBpqARmAd cCoQBhqAeqAOCAG1QA1QDQSBKmAtsAY4BVgNrAJWApVABXAysAIIAMuBcmAZ sBRYAiwGFgELgQXAfGAeMBeYA8wGyoBSoAQoBmYBMwE/MAOYDpwETAOmAlOA yUARMAmYCEwAxgPjgLHAGGA0UAgUAKOAkUA+MAIYDgwDhgJ5QC4wBPABg4Ec QAW8wCBgIDAA8AD9gWwgC8gEMgA3kA70A9KAVMAFOIEUwAHYARtgBSyAGTAB RsAA6Gf24FMHKAAHGKvlsPGjwBHga+Ar4EvgC+AfwN+Bz4HPgE+BvwF/BT4B Pgb+AnwEHAY+BD4A/gy8D7wH/An4I/AH4F3g98DvgHeAQ8BvgbeBt4A3gTeA 14HfAK8BrwK/Bn4FvAL8EngZ+AXwEnAQeBF4AXgeeA54Fvg58AzwNPAU8DPg SeAJ4HHgMeAA8CjwCPAw8BDwIPAAcD/QDdwH3AvcA9wN7AfiwD4gBtwF3Anc AdwO7AVuA24FfgrcAtwM3AT8BLgRuAG4HtgDXAdcC/wYuAa4GrgK2A1cCVwB XA5cBlwKXAJcDFwE7AIuBC4Azgd2AucBXcCPgB3AucA5wNmsdmYnx/7n2P8c +59j/3Psf479z7H/OfY/x/7n2P8c+59j/3Psf479z7H/OfY/x/7n2P88AuAM 4DgDOM4AjjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzg OAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4Bj/3Ps f479z7H3OfY+x97n2Psce59j73PsfY69z7H3Ofb+D30O/4enyh+6Af/hKWvt GsZM1zJ29JLjvpW9hJ3K2lgnnnPY+ewS9ih7g1WzbVC72R52M7uVxdhj7Ofs 1X/lV8GPdhiamF13HzOyfoz1fNlz+OjNQLchpY/lEuT66dVjlh5Xz0cn2D46 ekmP62i3MY1ZtboO5WVY/8aP9HyJn6/I90wUeeVcaKdW4xPTtUfvOnrLCWOw lK1kq9hqdgqrYkH0v5Y1sDBGZh1rZE2sWcs1o6wen3XIrYUXzhJNH/NqYa1A hEVZO1uPpxW6LZETZadp+Xa2Ac9G1sE2sdPZZrYl8blBs2xGySYtvxE4g52J mTmLbdWUZLJsY9vZ2Zi1c9kO9qPvzP2oV3Wx89hOzPMF7MJv1ecfl9uF5yJ2 MdbDpewydjm7EuvianbNCdYrNPtV7Fp2HdaMKLsMlus0JUofYk+xe9id7C52 rzaWNRg1GhE5LnXaGLZiDDajh9v6tJjGb0PvaJ2Bvou+dSV6uhH2rX1qrE+M o/DcBk+KQvMgomw5YSR2oQ+kj/WIcpdp/T9m7Tsq32WV43FNn5G5WssJdaL1 2/Tl7MfYgdfjU4yqUDdAk7pO033t1/b67tHyN7KfsJswF7doSjJZboa+hf0U e/s2tpfdjueY7quI72R3aDMXY/tYnO1nd2Mm72X3sW7N/l1l32Tfn7DHey33 swfYg1ghj7ADOGkexyMtD8P2aML6pGaj/OPsCeSFF+WeYk/jhHqWPceeZwfZ z5B7Uft8BrmX2Mvsl+xV7oD6BXsfn0fYS4Z3WQqbyZjhAYzzNWwNHgNOpTbd yzhFdMzEJrOFbBFb9RBz4Md9BpvC77nHXVJiHmV6BD/KFabiMmBmnBf7nXrF cV///jN8900wnq9LndvNR909w3Q+rrkzjrx95MXCI28fTptceJgXvvXO2++4 PnkxdXLhuHdeeWfMaJ6ak6ohPUUxmdKNvsEFyoSheRPHjRs7XZkwPs83OEXR bOMnTpquGzd2kKJLl5bpishz3ctfr9QtPmJUzvDNWDHOMKi/M91hNCgDstJG Tct1la/KnVYw0KQzGXUGs2nYpFmD5zeWDn7dlDrQnTEwzWxOG5jhHphqOvKG IeXLvxpSvirWN351qc44dfWMIborrWZFbzR2D8rKHjE1Z+4KZz+X3tbPlZph NqWl2oeVrD5yjnuAiDHA7aZYRxYyzm7v+dKYjxGcxm73u6qmt05XHKNHZxYW Wguysvp397y338UXgj/e70ywQ+PP99s1fm+/TbCS6h80ZIzdbs2Cu9XlFB9w tFrhZc2Ci/UB/A7Ceg74s5FhQyYutWVlOgqzxhQYvcOWegNpAUOAzUBKy5yc Om4GL3wl/x3tR+DY1HGuXpU6+aTCceNSx40ZfUquHNhUH0/RCTWU+1J7jePF nAxSMvk4jokQ0m3MN6d7szNz+pmVo+N0NvfAdPegdJtydDY3p6vZWWo/00hP gzp6SJaFbzDwc2z9vXnZTU5PP3t/s91kMJjsZn39V5earCad3mQ1YuB399pv HjHE3n+Y5+uTdTcPGpFts/Qb6MaCq+o5rLsGPzPzsDLP83tnTOU2z2QxKpPF qEx2ucQHRmqyGJ/JD+I3KMYKew6JAS5MDHxhYuA1tifsNsGK1W/tl1NmmzzU o08ZIf4n6Kx547u5fn/KQsMCjOThGYcxlBhIGrxXEmM4ue/QTTAaj63NjMzU xBp16/K0lexOH6SIhT1Jd40pdUC6WDyzd6+q2XnysLHVF61dvM1vSvdmZatp lpuLt5TMqJiU7R6/YmbOSf6yodkYGb0eI7Nh4YqF2/ZVRx/cPru0WLGZHGLA HKYjpeUnT6ve7C/ZGjopbUTxGPHfA+7GT/9bdM+ycazm7tYJPM+ZWGPORJfB H9/tdPEFzsQidHbzf/jTmL8f1pM/FR8qjKy/tZvn+i358/KcbnWuWwxF2uTJ M7CZn0T/tVEQY8ATYyD6aeqzbBIj4NZ2r1G5RTFazObMgUPc2aMnTPGZ02ih GNMGZGYMdJlyZ06ZPNCRM2SgXa/juuqMQakWi8WcXrBg0pGY2WbW6/Gh2262 WXQ6i828bWLJUKfObLVaUjyMKdza8zl/07CGudlwlnKPIdez0FWG5r71Ig4a 2SJdXqJF/U48SB42iY08IM2Uys1u3wCPz21OsWQP83qHZ1ksWcO93mHZFt5u totW2M26B+xpdoPRnmr/anJOvsdm8+Tn5IzKttmyR2GlnqerU64ytMuWePJm u2ajJS+M7duSxItNJ1gy3Mo2oyszLS3Lacy0pudkZuWkW/jRc4+zjc7TnSOb wg9KdXTM8TaXS7vZXf/v8fBFyec/5vnD//5HWZN8kk/y+UGeG/9tn/eTT/JJ Pskn+SSf5JN8kk/yST7JJ/kkn+STfJJP8kk+ySf5JJ//a4/2/yeLv4U2HZ+c GbXsTt6/512IUcpgJv++3FrtU6d5p2g5oRWWotMz+TcsD9GlJbS+j4+BZekm JrSxj93E1usWJbSZjUAJaQtTdU8mtFXZ0+tvYyt07ya0nY3QT0loh3KlXvqk sEbj171/6/JYU0NCc2YyXZXQCjOZ/yz/fmWWZpZ/S7O+j4+B2S26hDb2sZvY VIszoc3MbWpJaAtzWeYltJUv6fW3sXzLyt6/5ddtOTuhHXyBRfqksInWP4q/ kVpvSYwzaRpn0jTOpGmcSev7+NA4kzb2sdM4k6ZxJk3jTJrGmTSNM2kaZ9I0 zqRpnG9lKhvLRrMx+BR/x7H4BmSEtbA2oI5FYSvWvjlK3x8NwhKGamYFKJnJ GvGobBls9awBZW1aLgQOwXs9PmvhWYx6jfCphi0Mj7DmFwSaEKtW821Grg22 Zq2M6ofRAhUIwi+MCB3IbYCK4l2q9n3VauhG+Kpam9tRu1b7Pmy9FqUlETUK j6bEO4WHij62aO8Mad97FX2Zq/W1Dpag9n3MiNYLVeOg1kvxXupHDUpGapGb NEujFjGIMSK7fEsT4jRqI9aaaGUzLE3aWymm6Ge0TwvEG1u1vsjv69JoU9vF m1owAqr2TdV6bRTC2ndTxXd+o1pO9DjaOx80ZvQWVWt7c6JfLdrYVmuex1rc t0di1DZq9ajX65Av0NZD39kcqkVr0iJ0aOPQnpj5vuMtZoz6H9LaL/pP8xLR VoNgeqOYaxUxWnt7Q22sT/i0IbcpET2KXtAMre+dpaC2RoKwNh3XL7maa9CS oPb+msT7C7QVW6/NlSj55z0w5Z96vSKxcsKJNTYBUSZhB337So9q76zVVqJ4 y7reOZBj8017rz6xrlt7vcXKpRlvhn9IWzsL4FHDhmljOhw+tVq82VrdFi1+ FE8r+lGIZ4P2FGh76vj3FSSiF0J3aCuwXmt1KyJ0wCpGrE7rsVipx0eV9jrt W+oRbb3IeJVaH2iVdGiz26a1MKqt4zZt31FtVeuD2AMhbQbD2jtC2hxWa3Xl aJWyAPo9M1E30qeE9k+tNibH9sSGxLe7G77lvZQXvjWYwXZtDGt711itVt6q rZCOPuuqVetpc2JlUayQ9il2yon9FuW0I4ehlpgpsRqqe9/0Ta1q/qfI33+M jkWXp6KaONeiWrtrjjtf/rnv8jQ5sV1T+4yA6An1hU5Z+XMi0nti12pnVrN2 dgW/tac0zsHjxpR2fEvik3pFul1bee1azVpt/4vehHrjCM9Gbdd81wz9q/bF sT1RqLVG7AE6+Qu0uWplG29Vx44eM1ZdGK6JtLS11EXV4pZIa0skGA23NBeo Mxsb1WXh+oZom7os1BaKrA/VFhQHG8PVkbAablODalNLbSjSrLYFm9tUlIfr 1LpgU7ixQ90Qjjaobe3V0caQGmlpb64NN9e3qS1wjYaaULO5Vq1piTSHIm0F 6tyoWhcKRtsjoTY1Ego2quEo3lHTNlJtawqiBTXBVmhRpam9MRpuRcjm9qZQ BJ5toagWoE1tjbSg3aLZiN7Y2LJBbUDD1XBTa7Amqoab1ajoB1qGKmpjuBnv aqlTq8P1WmB6UTS0MYrK4XWhAjXRzaFtalOwuUOtaUfnqd3RBrw/tEGNBNGX SBjdRsVgk9reKl6DiPWwtIU3wT3agg6tF10KqhuCkSZ6lxjmmoZgBA0LRQqW herbG4OR3hmYIl+9AoOD7qgTCiaNPW7Qo5FgbagpGFkneiBac2z26jHWrcJc 04KON4dDbQUL2muGBduGq7UhdXakpSXaEI22Tiks3LBhQ0GTrFcA98JoR2tL fSTY2tBRWBOta2mOtiVcha4L4vXrhF9lSzuGpENtbwvh5WiQKFaDmIFQpCkc jYZq1eoOrVmlgQUzURrRMpif2naaiQ0N4ZqGPnXB4eaaxvZaVMWI1YbbWhvx AjFWrZEwHGrgFWqOFqjy3S3NmMhh4eFqqKlaVDoWqlk6f2OLNHexFDEtbdFI uIbWS+/bxTKRsaZqDRgWxluwZMWeiIiFXduyobmxJdj3pWhzkFqKiUd3McZC tEdb26MY9vXhmpDwaQg1tp7Qoe8zF9pMFNaG6oJY/AXBttaNvb83sZ4sds43 /Mdi4ncSHe7gVtaPmXp6mDPxL8LgNzA+DDySsd7fY745leiusNs5fPjy7+vv cGj+nd/X3+nU/G//vv4ul+b/2vf1T00V/or++/r36wf/Eu1fxDHjdx/hL+oa xL9mw/vjt6qdrL9uHsuFx1jYp5zgO72Prxu+PvgWwGOaiH6C79Y+vpnwzYPv WHjMhH3eCb7P9/HNhu9w+E6ARynsi4731f4lHenrge9I+E6GxzzYy0/wberj OxC+hfA9CR6LYa8U68Vs5mbrE0/chLR7t9nAzSazeeMOpI1GHTfqD3WKZObc rNdUJ+vU6bjZsGfPHrOFm22PdT7WeQOeS/HswGMxcAsiyBB6bjTEDoh6Fs4t iRAUwyJiWKzcYj+AdL3/ev/F2rMTj9XIrWa9Xh/duX379p1Rk56bEmE6rVyx GnrjdOr13GrchWS1cavjQNWBKkTdc5F6kdqFZzsem5GL/0rgG4PZuGKTwRLR bFo0m4PbnAeyDmTtGbZn2K45u+aI7pxtPtu81Ww3cbtFQZpSthWpbIpZz83G RMBOO1fsxs7jQ9pNIqQ9hdtdhwYcGvDxtJdGvtb4WuMzC55//smdT+98wv6E 3WHmDqsOaWr9EyLVT9UG8rVDByg5FMVhPNCb2IEDBiN3mJ8XKbHqrewGpYLp ajoijSy9PhJax6Y0BqPNuKVaGS9fNktlWThJerTVbmQOlp7Icfx2n8Lcmp0s ClaPk2Xg0c1dsmQOG7Js8UKVjV6+bL4q1r/mI84dF8vUcjq8IbU3uh6//aex 7ETOgN//+7H/R9yZgDdV5f3/JDckaZNUKFsLKIZNNkEBxQFZVFxYLBUHhsEZ 7SAuQWXYKWChWsRdXBBxGRdkkEEHHTI64zKZihVLWSzYtLVhKG0JKfG2tKX3 Nlb0vJ97G0pB5xnn/zz/933O88nNXc7J+X2/v7PcyvsOeXr7/EXzxWbzc5v5 +Z75+YH5+Yn5ufMeNhki3/zcb34WmZ9l5ucR8/OY+akay6JoMD4tdvOzm/k5 xPy82vycYX7Ove+e++6xrDI/15qfT5mfG8zPV83PLebn9tbZ4z99Wn7mpxMl FTSwo7BTGH8V+b+7ZsUHz399TBIXmO+nxhvVg+JZsUnsEDvFQVEpGixWkWBG 6oxHqwrjb0MK9TqZ/ytpzC2WUS3HR9a2HP8Qa1OHfKvddNa5xX3q7POkfmef d0g++7zjS2ef9/3h7PP+59wf2O3s8xGXiARr2/PGNvftwnL9lWefT3mMYyI5 3V+kG39Pow5zvPUSa7pYbd1sLRGvK39Q/iCKbIttb4hgu6/sj1iUxJsTf2f5 MPFhl8WS727vvtZ6jfsW96vW5Z45nrnWf3hWe56w5iVZk5zWg0lNSU3Wr1la dUMbe7Hng58shZQyz9E2JRovhT9RGpN6tZb+lFGUCZS5Ztl4bvEUJm1K+mv7 DfHyepuyzSgdxE+WxA7preWxDutbi95Sknv8RBlCGdHppTZlc0sx75xTOu3o lN9a9nc+QjlmlC62nyrJQ7okd+nf9bE2Zb1Zdv5kKezafLqkdErp1lomxMuk nyzpZpkRP55dsuOfxnO7zFLUWlpqH06pSx2YOif11dStRjm39dTtP1VaWk/9 e2plvDSeKcavpDabv5VtcP6U3qNay5Te01rLnHiZS8nuPbfPMMr4vkP6Tug9 l88hfXf2y7+o2CyN/WdR5g/oRxk8oHJADCoH/DAwf9CrRhlQOeiTQdFB0cG2 wUmDOw3+iFI0ZCwlfcisoa/ES+DS7OH9hlePePbyEZSxI1NGzhqZecWOePnk il1XFI0aSLli1NrRh8bYzfL0mJ1mOTX28rHvxMsHY05x/s7YOvOsbpx1nHXs O+MGj39q/CdXDbl2JuXw9XePebrlaY51LU9NHGs8N3HKpF6TLpk0dtLWyf3M kj55rlkyJ6+d/AqfmZMLKEemrJiSPeXwjfMpG9IyeCo9bX/a/skFfB4yvlEq 09S05qnZZtkyda9ZDk9V4fBUPd02Vee+mj4r/VB65U2LKc9Ou5DntkzVW+5M WzFVn3Z0Wu309Bm7Zs78bfJve/y23122u2bdVXpX8+nj3YMpO+a1n9drfub8 B+fnzq+cr87XF9gWDFswYcGdC+YvWLHgkQUbFryz4IMFeQsOLpy/8NmFWxc2 LBKLkhfdsGj2ok8WFS8esXj24leWzFjyyJLAksal9qWDl1639J2lx5ZNWNac 2SPzusyMzIWZr2Ruzyxd3mv5b5Z/sLx0efMK94ouK65YcfWKOSu2rChdOXDl hJW3rty4ctvKQyv1+8ffv+L+T7LsWeOzFma9l7Ur69SqbqvuXrVllbp61OrM 1duz0//NXPXBufPR2bNN9tIzxZhHsl8/U1pmkH8z9iadO+LOHictmf6Ts87p madNOXvuyN51phizQ3bRmdIyLxhzaPttKbu6rmceLhtbx6xpzsHmkfm2Qzrz 68akTe03eApb50ye7aD3nmPU9XyQtPHM3NmiErPzBHP+bXmqV9Km0+oZV425 2Hy2zLhvPh9XkHY/8BxlJt9EjTKztUJ6t4FjmVnOrA7Rc1aFCW3WgTMrwSaj 3z+a/bf9aPZPjM/5j5nzvTnLm+1QO2kC3zeengnxY2vcL+amlvmnZX6L+8ic yAxouDandXY87ShzXMqk7EqjxhmPe0/LrsyupDXjqUbupadW9p7245xgHixq M6P+xDzbdl798Zwan7l3mdnUMotOOT1/GvM6V/jVbDV1K1empaRfPiJtfxdb yzpmHlmzujZ3PkJWJZ9efU6vKsk9utjOrEAtWWmsbebTNuMJ6u7skmzcMa4Y TxnXk3t4Ck9nakq35B6sgMlGfeN7y9Uz62jbldToi7lqxtfNNitnMi2cu06u P2t1LIyvjJ1O9577zS2/bvz+5PTOR1Im0J+z1DdUMzTGqTYj9rTGLSPRULMl U3rPQe9JhpuGEinpnV4y/d5qeNNmVI9K3U6sp1fYopZWs9WU7Gy1pRi/YBx7 TzNcMb61ZJpxzFb7DukzrIWWFa7PMHNValOMFa5ldTPXx//HYq6pbcqPnzBX 2jYlvuK2lh/XMFba/66Ya/HPLq0r9r8p5ypllNZ1/N8Uc2X/2cXcbfzMcq46 5h6lTfmxfubepU0x8r7F6f+u/Ljl/9y7n1dadDb2Lkmbxtgn9RpzylNm7HrM 8rR5xW7sdMyzpyf1MvZA8XsUdlBXGLumlqvG3G98M4q5O5pp7qyMPVTd2Dpz f8TuiG87xzxt7k6yW3cxRtkyNTvt0NRsYwdjnm2J73Navm9hF1RpXDF2NEa9 tHgxdzyLzb0Rz5p3txifqdt5eouxm2K26Jd2yNx3ZcZLunmln7HrMs/S0w4Z 81L8HoWd2yXs1YwdmlFvrfmNYu7T5pv7OZ41d2qt+7XJ6eOspiKnDC1uWtyi xBi7GQ89bunp5AKzbeOX1pptme2ePRJ/7GjbPLiouOVM2C25sky5UX6iTBfn KTOFW1ko65WAGCms3CnkLGx+U5Xp8qiw8NkkrHzuVmbKQt7Q35anRJ48ZckQ HS2/E9Mss0Wq5XbhtcwRHSz3iA48OYInxyn3yn8KC+1UCRvPunm2A8+6eTbR bC/MU7UiwXKr6MH93tyfzv3zud+btvrSlpfaL9Ofw8LFtx30t4NyP/3Ikn+j v6OUKvmCclRcooTFMCUiBinH5QElavxvjtN6Ia1XChvfrMrMH76jN+tp6TOR Kc4Tk0R7GCUGiNEwRx4Qd8CdsEhGxGLZKJbAUlgGmbBcuMUKeVCshPshC1ZB DvXXwEOwFh6GR+BReAwehyfgQ3G1+AhifP8BpBhgEWCBdDHachNMg5vhl+AT Uy27RE8i9ikzxJXKLcKp3Ab3ikeU1eIC5QFxoZIjLrC9Jg/aXoc34KAYYPsK iiAIxVACpfA1lEEIDsG/xIB27eWBdkfkwXbfCHc7le81UCcP2tuJSfYBHIeL AfbLOd4rD9jvg3nwe1giI/algDZ2tLGjjX0FoI39XTHa/h78DZrEaMdA0dMx CG4TAxwZMBsWwEJYDtnwAKCR42l4Bl6DN8TVjrc51kAt1EE9NEAToKHzdpgD d8AS0TNBiNEJnURPM3ePkdeJ5rfjuN4kOpO1frLWT7b1I9uuItseJNtuJttm k20TybbxPL2ZfBmizJBPKb+SK8igy8ib52khQwnILUoVeRYWinKMHDwubjHz 7ChPHWKbeXpU3CqGtmn/BtpfSvvX0v5Inp5F2+tp+2/UGk7bG2j7Zdr7hPZm iCRaOUErJ2ilPa1cRCvzaGUorQyllUG0chG9PExL/WlpDq0Mo4WtZqS7+fau SKGNf9LGP2mjv+U2+RHtDKWd22hnBO3cTDvjLD75JW0NtWyUf6fmx7Rno72l 9OxO2uxIz3Jo7XGlUjbSuwKlmtF6XFysROMjtgOtDqRVH62OpNVrabUPLfan ta+o+RUj70ainC5c8Rnme2YSY2Z5UeRIVayBh2AtPAyPwKPwGDwOT0CBjIk9 sBf2wX74EgrhAByEr6AIglAK/5JSHIZyOAIVUAlVco84CmFokCFxknHeCBro 0AQxZrdvud8M38Ep+B5+oC9SqhYBFnNWrFJmkWG/kSeUWzlmyBO2g1K1fQVF EIRiKIFS+BrKIASH4F9QLWO24xCFb0CFGqiFE1AH9dAAJ6ER6IvtB5ByT7tk uccxXsYc18IkmAxpMuL4JcfpMIv7t8CtcJtUHRkwG+7h3gKOC2Ex35dBJizn /H6O2RwfgLV8fxjwwbGO49Mcn4Hn+L4enocN8ALtv8b1TXzfzPe3+f4u3z8G PHLgkQOPHHjkCEnpOAR45MAjBx45jlCnAioBjxzHZcgRhW+IRYUaWeiohRPc q6PtemiARs7xzqFzbOIcj5y3wxy4A7+s4inRyVy5FPEUuTudHDZWr3ac/Zmz SZxNJMvzlC/FIGHhqi4mkJkhMjNEZobIzBCZGSIzQ2RmiMwMkZkhMjPE0xEy LUamxci0GJkWI9NiZFqMLFLJGJ2M0ckYnYzR+b1cfi+k/Fa0U34Hs8mg22UV WRMia0JkTYisCZE1IbImRNaEyJoQWRMia0JkTYisCeGkjpM6Tuq4GMLFEM7p uBbCtRBu6Til41QIV0K4EUL1GKrHUD2G6jFUj6GqiqoqiuooqqOojoohVNRR MYSKIVQMmSO2TDjQ8ipGspO19x+sve8rhay1B1iFWG1MfaNEeIAIK0x97+cs hbMe6PsgLZSImayTXtZJL+ukl3XSyzrpZZ30sk56WSe9rJNe1kkvv3Q5a2Uf 1so+jNkixmwRY7aIMVvBmNUYsxpjVmPMaoxZjfU0mTEbZsyGGbNhxmyYMYvf YjLr5gjGaQXjtJxxWsE4LVdmi37K7XCvWMM62pN1tCfraHfWTi9rp5e108va 6WXt9LJ2elk7vaydXtZOL2unl7XTy9rpZSyGGYthxmKYsVjE2NMYc0WMuSLG XJg1zssa52V987K+eVnXvIyVMGubl7WtD2MlzPrmJf+LyP8i8r+I/C8i/yvI /wryXyP/Nda/ZNa/ZPI/TM4XkfMaOR9mDfSy/nlZ/7ysf14j32UDWjewP3tK PoQDNzCfVzCfL8GJG3Dij9x9gmy/VjnITqpI/qAExWzTvRBPl/FUKSvmU3IV Z7Ope5C6X3F1PHWfou4X1J1E3SLq/VrY4+PoVzwZ5Mkinpxk7q+MnHnLbOkO 7o/j/n7uF3N/NC09yt33aOlqWiqgpUvM578294mHzU9dJFrOEz0ts+BeuA9+ D/NhASyExfAYK30HS67w8CsP0nom7ew290avi67Kx+Iy5VP8rxS9WbVvZpeY zMrdjV1ib6WameE4PYhy7RtxGev5QvkpNbqwp+xlrOnUv1dMZAWbRc7fIiYq t5q7r4kiiZ51p2fd6Vl3etadnnWnZ93pWXd61p2edadn3anZiZrzqNmJmvPM mh5qeqjpoaaHmh5qeqjpoaaHmh5qeqjZj5qXUrMfNS81a7qp6aamm5puarqp 6aamm5puarqp6Y7XHBGvOYJIbhED+TbQ1Nhv7hGaUCtk/JttuAmmwc3wS5HI 3i2RvVsie7dE9m6JCcZ/p7WhcEfqpMd3GnmmRxWiyNJfVloGwEAYBIPhYhgC Q+ESuBSGwXAYAZfB5TASroBfwCgYDVfCGBgL42A8XAVXwzUwAa6F6+B6uAEm wiSYDFPgRkiDqfASvAyvwKvwGrwOb8AmeBM2wx9hC7wFW+FPsA3ehnfgz7Ad 3oX34C+wA/zwV3if3Voux09lmWUnfAZ58Dns4voXMmjJh91QAHtgrzxm2Qf7 4Ut2ELN4W7lVFto+ZyexC76AfNgNBbAH9sI+GbTthy9lsF0HWdmuE3SGLtAV UiBVVtrXwYuABvZX5TH7FnnC/hZshT/BNvgr1z/jyG7T/jnfC2XQ/hXPl/Jd l5WO8+EC6AkXgleecPSC3tAH+kI/GXRcBP1lmWMAkAsOcsGB745hnA/n3mh5 zHElx2nyhNMqK50K2KAd2MEBTkiARHCBGzyQBOdBeyBeZzJ0BOJ2EreTuJ3E 7SRuJ3E7u0F36AH030n/nfTfSf+dXugFvaEP9IV+9GmYPOYcDr+QQecoGM21 8XAdXA+38dxsjndy7y6euxt8MBeWcC8LVsFqyIZ1XH+T59/i+a2yzPknzrdB A9c0WZlgAWJN6CiDCcSR0FkeS7iQHFppQR0L6lhQx4I6FtSxoI4FdSzUsKCO BXUsKGNpLyOWDpAMHaETdIYu0BVSIBW6sWe9AHrCheCFXtAb+kBf6AcXQX/e sgfAQBgEg+FiGAJD4RK4FIbBcBgBl8HlMBKugF/AKBgNV8IYGAvjYDxcBVfD NTABroXr4Hq4ASbCJJgMU4Tx/xrWZUmDqZAuj1pugmlwM/wSptPvGfArmAm/ hixZY1kFqyEbHoAHIQfWwEOwFh6GR4D3DcvTssnyDDwLz8F6eB42wAvwEnPk y/AKvAqvwevwBmyCN2Ez/BG2ACugZSv8CbbB2/AO/Bm2A3OthbnW8hfYAX74 K+Qyl38KO+EzyIPP4QvIh91QAHvg3Flkuvwds/RM1oHzmPmvZB04j9n/Smbt AzZmPBszno0Zz8aMZ2PGszHj2ZjxbMx4NmY8GzOejRnPxoxn2847yrvwHvwF doAf/grvw99lje1D+Ag+hk/gHxCAf0IufAo74TPIg33CbdsPXwp3uw4isV0n 4WrXGbpAV0iBVOGyPyFr7E9K1b6O7xv4vlFG7C+yJuGBOZu9zj1isf+Re/TZ Tp/t9NnOLG1/Vx61vwc7uOcHY5b7gOf/xrUPuf8RfMz5J0A/7fTTnP2+4LyA e3s47uXaPtgPX0KhcNu/4rd5t7Pzbmcv5lqJbDJnyjL6xvucPUJd3lnsKt/Z XdvZXdtPAO8sdt5Z7Lyz2E9CI2igE1uTPOpIkjWO86A9dIAU2eRIhW7QHXrA +SLRcQH0hAuhn3A7LoL+MAAu5dowjsOBVdbB6toy6wq30ypcTgVs0A7s4AAn JEAiuMANHkiC86A9dIBk6AidRKKzM3SBrpACqdANukMPoJ9O+umkn0766fRC L+gNfaAvXCRrnIN4RxsMF8MQztkpOC/l++mZeATfL4eRcAX8gjhGwRS+3wi8 5zqnUi9d5jlvgmnwa9nkvI1+3slz587SvO86ed91LoMs+rAKVkM2zz/KbzP+ zVl7A8eNtPsivAQvw1u0txVOz+Jvcw0PnRp1v5NNCUIeTbCwV3JKNQE9ExI5 duB6R+E2Z3ZWqISuXEuBVGA+Tuhh/F3SGOnxfVUWIzRo7tF2tl6fx/Xl5t9R jP1WrWhnvUH+RrlRfsbuNNH42xb3asRg6yUyah0BI2Ec3CAPWCfKPdbJcCO7 8unyMLuLQ+wuDiXOlHsSZ8HDMpr4CDwKj8Hj8AQ8CbzLJa6Dp+EZeBaeg/Xw PGyAF2AjvAgvwcvwCvwBXoXX4HV4AzbBm7BZRt2DZFQo9FS3zuSdeCHv0KPp v0b/NesoGab/mvUajo/KCutjvLvcIi5m/rqYJ/ck3izDib+EGfAbuF1WJM6F e2EezIfF8LDUiE0jNo3YNGLTiE0jNo3YNGLTiE0jNo3YNGLTiE0jNo3YNGLT iE0jNo3YNGLTiE0jNo3YNGLTiE0jNo3YNGLTiE1zTZIVrskwBW6ENJgK6XCT rCB2DQ9HyhIc2ms1fZT55l8OexL7VuLear1FbrfOgfvgUZmLBrnG+zexbyX2 rcS+ldi3EnsusecSey6x5xJ7LrHnJmbK7YnLYSU8AA/J7fQrl37l0q9c+pVL v3LpVy79yqVfueIqHPDhgI++VeGAj/41kUGNZFAj/SynJ6X0pFSZ/kOjMvMH jdXFgzNDWV08uDM0/o6fR3Y1kl2N9K6U3pXSu1J6V0rvSuldKc74cMaHMz6c 8eGMD2d8OOPDGR/O+HDGhzM+nPHhjA9nfDjjwxkfzvhwxoczPpzx4YwPZ3w4 48MZH874cMaHMz6c8eGMD2d8KFCKAqUoUIoCpShQigKlKFCKAqU44xPXoEIG KmTgxW5UyMCP3dYbxPlEn0b0afG/tz4ef58eiApdUGE4KnRBheHxvxL/Gq92 49VuvNqNV7tRIw010lAjDTXSUCMNNdJQIwM1MlAjAzUyUCMDNTJQIwM1MlAj AzUyUCMDNTJQIwM1MlAjAzUyUCMDNTJQIwM1MlAjAzUyUCMDNTJQIwM1MlAj AzUyUCMDNTJQIw010lAjDTXSUCMNNdJQIw010lAjQzjIhUYidhPxM0S8lIiT iXAVES4TqWiUhz55aFOMNsXokIwGydx9jvjziD+P+POIP4/4i4m/mPiLib+Y +IuJv5h+FNOPYvpRTD+K6Ucx/SimH8X0o5ix4pNvnTPfNYqLrTcxx80EH/Pc XOa4e+BeoG16fKR1rstizlgt97hWyqjrfsiCVbAasuEBeBByYA08BGuBudHF 3OhibnQxN7qYG13MjS7mRhdzo4u50cXc6GJedDEvupgXXcyLLuZFF/Oii3nR xbyYlACJ4GLOM2b2qNl3jTEeZoyHGeNhdDPe0/tx9yBjN8zYDTN2w4zdMGM3 TN81+q7Rd42+a/Rdo+8afdfou0bfNfqu0XeNvmv0XaPvGn3X6LtG3zX6rtF3 jb5r9F2j7xp91+i7Rt81+q7Rd42+a/Rdo+8afdfou0bfjTlrpvwatfei8Ket c5YRUbkYRkR+7ldyvwk3TuHGKdw4xbPlPOvkWRcjJZFIhzBSEol2SPxvQLtw 6BQOnSJKP1H6idJPlH6i9BOlnyj9ROknSj9R+onST5R+ovQTpZ8o/UTpJ0o/ UfqJ0k+UfqL0E6WfKP1E6SdKP1H6idJPlH6i9BOlnyj9ROknSr+4jEhy8CYf b/KtPtEDf/KJ4HZGwLeMAJ1I1hBJ1/hfZroaf5khkheMv2bhXT7e5eNdPt7l 410+UeUQVQ5R5RBVDlHlEFUOUeUQVQ5R5RBVDlHlEFUOUeUQVQ5R5RBVDlHl EFUOUeUQVQ5R5RBVDlHlEFUOUeUQVQ5R5RBVDlHlEFUOUeUQVQ5R5TCOZ5rj +Aqi+DL+35yuo9fP0esdwkW8+4h3H7HuI67OxNSZO88Tzz7i2Uc8+4hnH/Hs E3brEnxdKr+1LpPHrGvIiydlrfV54y/tXG22rpG6sPD5rRjAE7o1k4xYDmtk 0LpWOK0PU/sJWW3dYPzf1cvvrC/K71zsb13sb13nwwXQEy4EL/SCOTxzB9wJ d8Hd4IO5cA/cC/fBPPg9zIcFsBAWwWJYAkthGWTCclghvzPjaaanVdYsGSGW o9b18oSVNz0xy7qQbF8ES7iaSZTLYbUstGbDA/AgrBGdrWvlu9Z1PPe0PGJ9 Bp6F52Cj/JD4PnRZ5V6XAjZoB3ZwgBMSIBFc4AYPJMF50B46QDJ0hE7QGbpA V0iBVOgG3WUtGtaiYS0a1qJhLRrWomEtGta6RslC12i4EsbAWBgH4+EquBqu gQlwLVwH18MNMBHmEMcdcCfcBXeDD+bCPXAv3Afz4PcwHxbAQlgEi2EJLIVl kAnLYYX8UNjInMOo+BUqVlg3yHpyaY1sIE+aRDouxHAhhgPNOGBkWAUrjs6K o/OEjsoxVI6xwuisMDorjM4Ko7PC6KwwOurHUD+G+jHUj6F+DPVjqB9D/Rjq x1A/hvox1I+hfgz1Y6gfQ/0Y6sdQP4b6MdSPoX4M9WOoH0P9GOrHUL8Z9ZtR vxn1m1G/GfWbUb8Z9ZtZ5XRWOZ1VTmeV01nldFY5nVVOZ5XTUTeGujHUjaFu DHVjqBtD3RjqxlA3hrox1I2hbgx1Y6gbQ90Y6sZQN4a6MdSNoW4MdWOoG0Pd GGNuKdltjMUsNF1Fdq8RSahdhdqVqH1CzEfjABoHyPRqnsxH6yq0rrKu4DxL HqdWA5mvkvkqma+S+So+fI8PAXwI4EO99Sn5BSOghBFQwggoYQSUMJb2Mjfs wqMgHgXxKIBHATwK4FEAjwJ4FMCjAB4F8CiARwE8CuBRAI8CeBTAowAeBfAo gEcBPArgUQCPAngUwKMAHgXwKIBHATwK4FEAjwJ4FMCjAB5V4VEVHlXhURUe VeFRFR5V4VEVI0RlhKiMEJURojJCVEaIyghRGSEqI0RlhKiMEJURojJCVEaI yghRGSEqHgfwOIDHATwO4HEAjwN4HMDjAB4H8TiIx0E8DuJxEI+DeBzE4yAe B/E4iMdBPA7icRCPg3gcxOMgHgfxOIjHQTwO4nEQj4N4HBQ+HAzjYBgHT+L3 Tlw8gXNlOPcNztXiXC3O1eJcLf678X8H7qm4p1of59qTOL1O/hkHq3GwGger cbAaB2twsJ48+QculuNiOS6quKjiooqLKi6quKjiYhgXw7gYxsUwLoZxMYyL YVwM42IYF8O4GMbFMC6GcTGMi2FcDONiGBfDuBjGxTAuhnExjIthXAzjYhiX anGpFpdqcakWl2pxqRaXanGpFpdqcakWl2pxqRaXanGpFpdqcakWl1RcUnFJ xSUVl1RcUnFJxSUVl8pxqRyXynGpHJfKcakcl8pxqRyXynGpHJfKcakcl8px qRyXynGpHJfKcakcl8pxqRyXynGpHJfKxSW4pOOSbo7GFhcacaEeF+pxQMcB 472pHnXrUbcedetRtx5161FXR10ddXXU1VFXR10ddXXU1VFXR10ddXXU1VFX R10ddXXU1VFXR10ddXXU1VFXR10ddXXU1VFXR5161KlHnXrUqUedetSpR516 1KkXA5kZTjEznGL0q6znidbHieIJojB7z/cNsJH1/kXW7e7s6nrA+XAB9IQL wQu9YA7P3AF3wl1wN7CDROsmtG5C6ya0bkLrJrRuQusmtG5C6ya0bkLrJrRu QusmtG5C6ya0bkLrJnE3WlejdTU9VumxyiiIMgqijIIooyBq6n96BKD7jzKf HbzV+MvGv8/2avyoxo9q/KjGj2r8qMaPavyoxo9q/KjGj2r8qMaPavyoxo9q /KjGj2r8qMaPavyoxo9q/KjGj2r8qMaPahRUUVBFQRUFVRRUUVBFQRUFVUZD lNEQZTREGQ1RRkOU0RBlNEQZDVFGQ5TREGU0RBkNUUZDlNEQZTREGQ3RnzEa ojgUxaEoDkVxKIpDURyK4lAUh6I4FMWhKA5FcSiKQ1EciuJQFIeiOBTFoSgO RXEoikNRHIqaa3yd+V8hL8crFa9UZhuV2SaM9iraGxqraKyisYrGKhqraKyi sYrGKhqraKyisYrGKhqraKyisYrGKhqraKyisYrGKhqraKyisYrGKhobMarE qBKjSowqMarEqBKjSowqMarEqBKjSowqMarEqBKjSoyqy8iFJbAUlgH5Rowq MaqiPXOxdvaYIdMeN0e6zpyq/6cxwt59KXtU3kwZbW5Gm53RVsFI68xISxRp rTPKElbjLFjFe/kafutRWUdm1/F0jLFZx+rcSK0hKKyjcGObXVMd2V1HdteR 3XVkdx3ZXfe/NNvUkX11ZF8d2VdH9tWRfXVkXx3ZV/f/dVdkvK3EUOqL1veW RqHEr8Vw6TsxHW0L0LYA/2rwrwZtjTebMpxoh74R9I2Y8986ztfzjvA8O6WN XHtRRtA1gq4RdI2gawRdI+gaQdcCdC1A1wJ0LUDXAnQtQNcCdC1A1wJ0LUDX AnQtQNcCdC1A1wJ0LUDXAnQtQNcCdC1A1wJ0LUDXAnQtQNcCcqqGnKohp2rI qRpyqoacqiGnasipGnSPoHsE3SPoHkH3CLpH0D2C7hF0j6B7BN0j6B5B9wi6 R9A9gu4RdI+gewTdI+geQfcIukfQPYLuEZcR5xJYCssgE5bDChkxNf42PhJi oqP1fdHF+ik7zp3k5Wcy2/qF3Go9yT5Dk+us38pChZlTuZi316HyXWWEDLf+ a+UZor3yK+GO/5vCandI7sexzbS7HXYyAj6TRdY8Mv1z+ILfzOe4R4as+3nT LeLXghyLoVokWI8zUjX2uDo7oSZolvWKkEcUBzghlbf/obJKuVSeVIbBcLhM 6spoWenOkKr7DrnPfQ8wR7h/z3G+DLkXAHOCeyXHLI6rgD20OwdYMd1PAqPS vY77z3GNuc/9Aucb4RXa2Cy/df+J9t+F9+RJ919gB9f8nH/IkZjchVw7AAeh hPNSCPH9EBzhuRp5xH0SmuQRTydZ6+kMXYC3Qw9vh54+XJ8r93nY03vol+dh 2eh5Up70PA8vwpuyVkyKq1qGTzFULUHVGlStQdVTqHoUVUtRtQRVT6JqCaqW oKaOmg2o2YCSDSjZgJINqPgtKmqoqKGihoI1KFiGgiUoWIKCZShYgoKlKFiK gmUoWHqOgmUoWIOCNShYg4KlKFiGgmUoWIOCNShYgno1qFeDehrqaShXg2Ia imkopqGUhlIaStWgVANKNaBUA0o1oFQDSjWgVANKNaBUA0qVxJUqQ6kalNJQ SkMpDaUaRC/rNrnS+r58D6UC5OB3KLQFVb6xHpZ3kWdLrMfla2T3DGsjO+1v 5VjybJeiyDzFLp9S3HIe2R5UOkmv0lPcqfSVi8n8XsoQeTWqvUn2X0fOvayM lauUq+Qt8X+dVa78Sr6uzJRzFZ/8h/Hvl4jqI+akT1klPoMv5L/4xWP4cZhf DPMLx2m1jhYrafEEY2k0Y2kMb4TbcOxTeYBaxnjZa46RanEBtQ9Sczc1j9K3 MH1z0UKROR5GyCJqfip3U+sYtT6gRkdqVPB75eb45a3aHMM9GacXcz5UHqbW EXqZJ84ns06aNfPIrM8hn4zZQ+39ZFURu8ggx2J5lOw4SnYcJTOOkhkVZEYF WVFBVpwkK06SFSfJiBgZESMjYmREBZkQIxNiZMJRnDuKcydxzZj5q0US/bHT 88383jZ+9+/E+iHky2Z0PYSeYXem1Gm/gfYbaL/B/SLnr0qddhqEjVqN9Hwh NSqNvGcnvI255H1i+UwWcjVkPcA8Ymh4WEbR7QDtltBuiZjJr67j6WzGVJWZ LX+XWfx6FjXrUaIZJZppoQolJEo0xsdVI0o0Wkvldlr0k0mFVpXsSYRO8g6l C250hRToLRcpfaCv/Ebpj88D4GLcQ3dlHPevMv/t8qX05lLGXhXqNqJuI2Ov CoUbUViisGTsVaFCFkpLlFiHEutQYh3jrwq1m1G7GbWbUVsy/qoYf1Wo3ozq zaiVhfKNKJbl/jMz0Xb4WC5y53HcC/tgP3wNZfAv7pVzrKCNSrnII+QuTzu5 3WMHB3g57wdzmaEekOsYg1W42ezZICs9L8BGeAn+ILcLFxnZQDZW4vRwZp/v mX2+Z/b5HtdHMtK/Z6R/z0j/nlH9/f8Qd+fhUZfn/se/yUxmkskEFBEErYos bl3UWluxltOWWnuqtra1x2qlttp6oNCKghYQgS7auu+iSNWKiFqFSl0Bd6vW BhIywDAJNLInhG+IhB3z/F4zpudn+zvnOtdZruv3x/v6znd7lvu5n/v+3HPB JDrEehTXcgfbb2X7rd5KiVEdYlSHGNVh7p3m3mnunea91by3mvdWc91qrlvF lw7xpUNs6RBbOsSWDv7dIbZ0GGuncW4VKzrEig6xoqMso8dpPOAuq/+y1b/N 6t9WvsiKvohXwpvlr8uKb+DN8BAv2Fu+1PUc38qH8eUrw8LyAhrRhFVYHa4t /6vjGqzV5jrH9diITdE03jK/vNXnzWjjeVscY7SHy8u3osPn97AtjBSb6kTu vMidt4O/LUYtLt/r3j68HxaVdzkGWbgM5SjGryRvq/A5JU5lwtREtc/ZMKYU z3o67of90Qu9wym89XTeejpvPV1uvSbRP1yZONi9Q3BY9J3EAMcjMFDMG4TB 4buJIc6PxFHOj8YxPn8UHwtfFCO/L7I8YdWmWbVpVm0abz9TvLwxcZJnPo3P hJ8nTnYcilPClMRnHU/F58IFdsXpiX/y+fPhMjvj293/YvYJO+TKxHnRQYkR GBmWiK+/z44MddlRuDTstUv22iG32SF7eck0XjKNl0zLTnP/5/g1foPrcEPU J3sjbsLNnr/Ttbtwt/PpuEc7M5z/1vH+MCb7IB7CrHBN9uFwpWw2JfuY88fx ezwRTrOrTpPhpvDAaTxwGn1wjSw3JfvH8PPs03jGc8+7tsBzC31ehBddf935 m66/pd0/u/YO/uJaLRajTlv1WIoGz6/wbB4r3StA9Obd0+za07Krw0I79zRZ dIrde7rde1p2rWt8MMsHsxvAD7Ob0BJezvLDLD/MtoEPZtuxFR0iwHvY4fOu sCi7G3t8fh98LsvnRIWpNfyuht/VJMKimqRjRRgvSowXJcbXVDqvEj0y4IM1 2fByTQ16+NwT+7m+P3rhANd7h7xMn5fp8zV9tXeQZ/qhPw7GIfiIZw9z/3AM 0P8RromwotHUmimhzg6fVnNt1KfGWtdY6xprXXM9bsCN7t0errTzp4lUp4lU p4lUp4kC00Sr02pmaGemcd+vzYe0P8v5w5iNR8Ll0QBR4jJR4g+lzPxqKZ+/ IRJstONvtrMvsLOftmvn2rVvy7nb7diX7Ni1dmW93fhnu3CRXdhg133Jzhph J821Y260Y96wYzbaJXfaJQ12wYu8/2He/zXe/zLvL/5PhZN4/JLoB+LVo0by exlraflcWeppMeE5157Hq/Lca+69HpaLnstlrpfFrC0y19Ny4BajbZG9npa9 nha/Zhn5G+JUi5EvFoteN+q8eLNGvFlj5BvF65yRt4vZOTE7J568bvRPiAVP iAVPGOVeo/xGUfPIXkuz3xdpfxielsGelsGWymBP25tb7M0tMthS+/NR+3OL /fmo/fmo/fmoDLY0+0vv/QrX44awXFRfLqovtze3yGZLZbOlIvxyEX65vfmo bPa0vfmovfQEv3+Cnz/Bp1vkk5x8kuO3LXJKjq+28NPX+eUsfjmLX87iiy18 bQ1fW8PX1vCtFr7Vwq/W8Ks1/Op1uSjHp16X4Z7mU4/KcEtljuX8Yxb/aOEf ayjIRfzgRbxCob0ZnmPpdbJDPV/4gmjeJJo38Yd3WLWZVetYtY5PPCtyr2bZ t0TqJpZ9i2Xf4hub+cYG0bhBNG4QjRv4yEf5yE5RtiDKFvjKSn6yXmStFVlr RdZaPrNMNF0piuZFzgYRsV5ErGf1day+jrXXiYD1ImC9CFgvAtaLgPUsu07U qxf16kW6ehEtL4oVRLGCKJYXxWpFsVoRLC+CrRTBVopWK0WrguhUEJ0KolNB dKoVnWpFp1rRaaWoVBCVCt1RqVY0KohGedGoweq8JbI0iSxNVuktK/SW6LJa dFktgqwWLZpEiyaRoUlkaBIZmqxUnZWqs1J1osJqEaDJStVZqTo7v8lKvWXn 19vx9XZ8vR1fb8fX2/H1dnyt3V5rtxfs9oLdXrDba+32gt3eZBXr7PImu7zJ Lm+yy5vUxJuo46KuPjHsiz5llxXrrB/bUdPtqOl21KvWeapds9u6zrau863r fLul1bquta5PWtMnremTdsQuu2CXtZhqLabaAbusx1Qev4uXT+fl03n5dGsx lZfv4uW7ePl0Xj6dN+9mryfZ6UnevJutnmSrtWy1llfvZq+1PHk3+8xnn/ns M5991vLm3bx5NxvNZ6P57PMk793Fe6fz3N3mPN8cXws38tidZrDI2TZj3x4e 45uro/5mts3ZejNrMbMWM9tqVrXiQKuZ1ZpZrdFtM7pao6s1um1GV2tU24xo mxG1GFGLEbUYzTaj2WY0LUbTYjS1RlGsZVuiw/S0XU8r9bReT+v1tIkNizVq nd469Vantzq9bddbnd7q9LZdb3Vs8R5bvKfX7Wzxnp6363m9ntfreT1bvKf3 7Xrfrvf1el+v9zq9F+vD9WqE1eLltrDErJfouVOPTWLZ8yLuChG3WB88W4q4 KU91dtdQrd3/h+kTiXOjE0qWa3anyZ3m0lmxtttbsmNF91vvOWvT/nLtd1DD eZq2jYX3mGeGJSJU0KQppDHA+RDMDFu1sbq0MvWebpRFimPsjIZo4w13nmO/ 97T1gic2/K2+L+WbSHxJoxKZ8IJZnW02F7Hje+y4mh1Xs2Oxvl7Nfu8ZwwvG 8IYxvGEMb7Dl39fdB+OQD9XfAzw/yF4c4jjT8/e7Vqy5y8w5jvoaX4cxdRjT ZmPa3P0NTrvRtxhXu3G1G0e7cbQbQ7u+O/Tdoe8O/W7W72b9btbfZv1t1le7 fjr0sTkapPUFZv8nM3/rQ1E2x85P6GlHKapmSv9S5Ffda7nS7EcW/0XP36KP Gb+l1wV6XaDXBf9u5ClGmgGeK0aZIY7FiDHTs/8YMapKWXQbHbBbbZ2yrueE S7v/dccSPX+n9C9GTzDu1Z581qrVqguWG/9LrDT3QxGkmBnyLDXTWhfz7gbW mslaM83nJa1er7UnrWIt7bacBWey4EwrWcuKM+2IvB2Rt6K15veSXZE3x9Xm uNocV1vVWhpsOQ22nN5a/g+RI2+Va61y7b9FjgHaGBRmmvtL5r3aKteWosfB rN7I6o2lbyO2iyK7w2tGvYXlG414ixEXv8PZwtqNrN1olFuMcAsrN7JyIys3 snIjKzeyciMLN+ppCws3sm4j6zaybiPrNtpV20XdPbIf7+Fh28NLUbksuIdS 2h0lqJE3nXU42xgNcBarYXbRJzF9EsuUO2XKnTLlzu7vCFtplq10/C4Zr1Wm a5Xpdsp0O+n1XbJdK42+i66IafJdsttO2W2n7LaT7t5Fd++S2XbKbDvpjlhm a6U9Yplmp0yzU3bZGVXJ5buN5D65O5azi7pug15jK/iQFXyoFFWqZPvORG+R 5GOhzQxaPNWW+FTUU4RR80TH6ycfJbWzTjvF71x3FWdgxtnSNwitxedZorf9 9Kmwy/Xit7Ke8N6a6EBnxdl3mn2n2XeWZn4erTAiLPvQzDvNvLM06zrHeixF I5pgdmbWaWadZtYZHa63xey7nX1XsO+KD1fm+m7Ty3q23a6H9XpY/2/V+FOl b/zWs+12tl3Bttv/rkJf4Txf+hawVKmz7Qq9r2fbFR+u1qMyM98eDUrU+NQ7 3E8txdRSTC3FxvSMMT3DWtspphaKqfjt2hZ22kwZxVZgnxV43Ao8ro7spY4s /uvIouppoXpajOsZ6qaFummhblqomxZqpoWaaTGeZyiZFiomNqZnKIoWiqKF omihJlqitNH8Qc/b9LhLj9v0tltv7+jtnWigu++y20ZjXGmMKz25o/s77P+7 Qp+i7E7h159nh1lhIxvuYcM9/7ZKT7k23/nzjgsorTcdP7xqK5zn8bfVW+WZ Zs+vCSv/bhX7sFozqzWzWjNLNbNUs3H/tfs7qWYWaWaRZtZoZo1m1mhmjWbW aGaNZpZoZolmVmhmhWZWaGaF5qi/ea4yx1XmuMoc280xZ44N5thgjg2UatHr GsyngapspSpbzWUVZVn0wAZzaTCXBkqy1TwazKPBPFaZwypzaDCHBnNoKP0v yoGJ70UDo+nRxeGe6If4ES4PD0QTw63RJFyFybgaa8P0aB3W4z3P7A63RHuw F/vwfril7KhQV3Y0jsGx+Cg+ho/jEzgOx+MEfBIn4lM4CZ/GZ3AyhuIUfBan 4nMYhn/C5/EFfBHD8SWchi/jdHwF/4yv4gycibPwNYyM+pa9HF4qeyU8W/Yq XsPreANvhkVlb+Ft/BnvhEXJ+8OtyQfwIGqdL8YSmGuyCyHcUrFfuKeiV5he QWVXUNkVVHZFXxyEfmgOt1a0eWYLtoZbU0fjJIwO96TG4Cf4KcaHB1JXgN1T N4e6VF1YlFLxpIeERekjcVR4Nn00TsAnnX8W54Xp6fMxItySvhuz0Oz8XayB NUu3hAfSrWh3r9P5jnBLZXmoq0wgiQqkQClWUoqVVcigGlnUoAd6Yj/sj144 ACeHRZVD8T2ff+Q41fERxznh2crtoa5KW1UH0McXRL3C4ugAiH7RgeiDvjgS R+FoHINj8VWcgTNxFr6Gr+NsfAPfxLfxHVwc7uO59/Hc+3ju1dG4MDMajytw JX6GiWEOb57Dm+fw5jm8eU7yurA4eT1uwI24CTfjFtyK23A77sCduAv3e+8B PBjmWPX7KlaExRVNWIW/otn1DY4b0eb+Fmx17f2wOJVCGlXI4CD0w2AMATuk 2IF3zEmd6HiS4ymOX8YFGIHv4UKMDvfxnPt4zn085z6eczXPuTplvinz5UFz Kn9atE10a6iLbsPtuAN34i7MxiOYg0fxGP6Md/AX1GIxlqAO9ViKBuSwDHms DU+JCU+JCU+JCW9H29CJ7diBndgd5ooTc8WJueLEXHFibnJTqEu2oBWb0QbV STJGO7aiA+9BxZLsRPG9LoQw1357Ki0WpO39tL2ettfT9nn6rPB2+luO5+A8 z5yPEWFu+sfOx2E8rsTPcBWuwbWw39JslGajNBul2ch+mpv+neMsx7mOC8AO aXZIs0OaHey1p+y1p+y1p+y1p+y1t+21t9Ob0YZ273a6zh723dyyj0fJaP+o AimkUYkqFH+9uxrZ4k9MogeGRn2iU3BxmMTHJ/HxSXx8PB8fxcdH8fFRfHwU Hx8VTdDCxDCGn4/h52P4+Rh+Pib6RdQz+iV+hWtwLX6N3+A6XI8b8Hx0aPQC 1oaJVnSiFZ1oRe+wonOs6BwrOseKzrGic6LiL0jvDpOt6mSrOtmqTraqk8vu DcvKZuA+/Bb34wE8iN/hIczCw5iNRzAHj+IxPI7f4wk8ibmYhz/gKczHH8Oy 8uOinuXHR33KT3QchtPDpPKvhMvLv4qznY8M08pHhdHlP8boMJpm+2ri/DCO bvtq4nuO48KfE+NDfaIuqkjUR70TDVTvMlX58iiTWBvmJNbRIuujoxIbHDcW fxvIcXPUKzku2j85HlfgSvwMEzARk3AVJuNqTMH9YYx4MUa8GJNcGvVMNiCH ZViOFchjJQpoRBNWgT15+2TePlmsmVSxf1jG6yeKMWMqNkcZ8WWS+DJJfBlT sTfaP5UA30r1wgEYiKPDmNQxjsfjk1EfMWVM6tM+jw6TxI9J4sck8WOS+DFe /BgvfowSP0al+FJqIvhS6p6wLHVv6X/QL0t/BIfiMByO43FWmGOnTbTTJtpp k9Njo57pyzAV03Ar7nb9fscHo0Ptpsnpx31u9vy7WAM+Z+fcYefcYefMsXPm pLdEVekY7Z7vdJ//2UGT0zujnpW9w7LKA9EHfXEQ+qE/DsYhMNZKY6001kpj rRyAIzAQgzAYF2nrYvwQk51fjSlhWVVZWJY5N1yeOQ+Tw+jMFNg3GfsmY99k 7JuMfZOxbzI34ibcjFtgvpnbcDvuwJ24C3djOu7BvZiB+zATvwX7ZB7Ag/gd HsKsqGf1JFyFybgaU8C21Wxb/XPY39X2d7X9XW1/VxtntXFWG2e1cVYbZ7Vx VhtntXFWG2e1cVYbY7UxVhtjtTFWG2O1MVYbY7UxZo+NevaoQgbVxb9qklhi p6wVjYqfir890rf8StEsW/rrAimkUYniXxvMoBrZ0i/YZ0WzLAVQoAAKFECB AihQAAUKoEABFCiAAgVQoAAKFEBB5DtA5DuAEmilBFopgVZKoJUSaKUEWimB VkqglRJopQRaKYFWUfISUfISUfKS6F9DHI3EKPwYozEGP8FPcSnG4jJcHkaK qJeKqJeKqJeKqJeKqJeKpsNF0+Gi6XDRdLhoOlw0zYimGdE0I5pmRNOMaJoR TTOiaUY0zYimGXm3Sd5tkneb5N0mebdJ3m2Sd5ui4vcdc/AoHsPzUT+Rt5/8 G8u/sfwby7+x/BvLv7H8G8u/sfwby7+x/BvLv7H8G4vWY0XrsaL12GijWnYT WtCKzWjDFsRox1Z04L1wt8g+W2SfLbLPFtlni+yzRfUJovoEUX2CqD5BVJ9A 0+dp+jxNn6fp8zR9nqbP0/R5mj5P0+dp+jxNn6fp8zR9nqbP0/R5mj5P0+dp +jxNn6fp8zR9nqbP0/R5mj5P0+dp+jxNn6fp8zR9nqbP0/R5mj5P0+dp+jxN n6fp8zR9nqbP0/R5mj5f9vWoT9nZ+Aa+iW/h3pCTiXIyUU4myslEOZkoJxPl ZKKcTJSTiXIyUU4myslEOZkoJxPlZKKcTJSTiXIyUU4myslEOZkoJxPlZKKc TJSTiXJqiflqiYVqiYVqiYVqiYVqiYVqiflqiflqiflqiflqifllf4kyZbVY jCVRRhbLymJZWSxbPrT4f1Qdv+h4epgim50lm51Vymbnh7byizFSdvtQVisf E9pktlNltlEy26ky2yi1+M2Jy8MTiQXh1cSLUY/EK7LfEvV8vTq9Ieory7XK conECvX9B5muQqYbVPqNyVbXN8s846KsLJeV5bKyXFaWy8pyWVkuK8tlZbms LJeV5bKyXJaSbqWkWynpVkq6lZJupaRbKelWSrqVkm6lpFsp6VZKupWSbk3e HeLkdNyDezED92Emfov7w3CZc7jMOVzdNV/dNV/dNV8WzciiGVk0I4tmZNGM LJqRRTOyaEYWzciiGVk0I4tm6MyYzozpzJjOjOnMmM6M6cyYzozpzJjOjOnM mM6M6cw4uT20JXdgJ3ZhN/ZgL/bBnpCZJ8jME2TmS2TmnMw8Vv2XV//l1X95 9V9e/ZdX/+VVCQVVQkGV0KpKKMjgwyvWhVilUFApFGTyS2TySyqMqcKYZPTh MnpW1VCo6HIeQpyKUIZyJKKsTJ9VURRUFAUVRUFFUZD5szJ/VmVRUFkUUod4 9iMY6Npg50Mg1qoyCpTBcMogmzrOfT5IHRyg6ihQCMMphKzKo6DyKKg8CiqP gsqjoPIoUA6XUA6XUA6XUA6XpMTRlDiaEkdTl2McxoeR1MRIauJSauJSKmK4 ejZPSeQoiVzqt6VfZOqTmoc/ln6VqU/qDce6MJ/KyKWspbo3n9oZ9aE4chRH juLIURw5tfB8tfB8tfBCtfBCCiSnHl6oHp6fPiXKqInnqwtidUGsLojVBbG6 oIlKma0uiNUFMbUylloZm/5uaEtfgBFhgvogTo/22Z5K/wQ/xaUYq83LYF5q hya1Q6x2iNUOMYWToXAyaohYDRGnr/P89aVfFYypnox6IlZPxOqJWD0RU0ET qKAMFdRPXRFTQhMooYzaIlZbxGqLWG0Rqy1itUVMIY2lkMZSSGMppLHpddpe jw0Q69NiPdV0N9V0N9U0m2qaTS1NoJbGUkuzqaUJ1FJGrZ9X6+fV+nm1fl6t n1fr59X6ebV+Xq2fV+vn1fp5tX5erZ9X6+fV+nm1fl6tn1fr56muHNWVo7py VFeO6spRXTmqK0d15aiuHNWVo7pyVFeO6spRXTmqK0d15aiuHNWVqzzBmD6J k8P8yqH4nrYvcn4xfogfuXaJ479iJEbhp6GVQstRaDkKLVc51Ts3u/6IZ+eE hZWP+vwYtod8VRT1oeByVeZWdUCYX3VglMl8M6zNfAvfxrnhLMrurMx3ff5Z aMtMwCT8TelN8/lXuDbKUnxZii9L8WUpvizFl6X4shRfluLLUnxZii9L8WUp vizFl6X4shRfluLLUnxZii9L8WUpvizFl6X4shRfluLLUnxZii9L8WUpvizF l/3/qPiyf6f4DoxuCp8tGxGdWXZh9M2y70c/K/tB9KWyi6LPll0c/Uv56dG5 5SOjbyfOCV9InBs+n3ghzE68GM5MrAlv04a9EyJcYkO4NbEpvJloiQ5OtKq3 Nocd0WHRTV2vRY+HpdHrYanWP9f9a7Anaf1YrR+r9X8qGxl2yK3r9aKaU5Wd E4bq5VS9jE8sDAsSi/BiV1vi5fC0HLci8Wp4I/FauEnvv9TzrsT6sFHvQ/V+ s94Tev+t3l+LKhOLw6xEnTGp5BNLw0WJhvB8Iuet5aFRVlxFpz4e/mRsf/Lk d+TOxZ6+29OTEku7ujz9oKe/Io8+7Y0rvXFv6bcdP2G0k2Xzj8jeXyk/UyYf GUaW/yRKlD9GJ78WflD+Zphevjr6VPl2Gbl31DPxifBwYmGUlaU/YQZ/0NOb 6tFEYqlac1n4oyxdofUuM8rJ1JO6M3WiuyZNmNnGRItZtbq+OWwp+5coGZ6P KpBCGpWoQgbVyKIGPdAzLIj2w9DQGJ2CX4R50S/xK1yDa/Fr/AbX4XrcgJvY 8PlQH70Q6svKQ2NZAklUIIU0KlGFDKpRg/2wP3rhAPTGgeiDvjgI/XAoDsPh GIAjMBCDMBhDcCS+HlaVnY1v4Jv4FibjakzBVEzDz/EL/BK/wjW4Fr/GLWFl 2a24DbfjDtyJu3B3WFl+XJhXfiKG4ezwXPlvQqH8ulDg5edYlTZ+to+PzbMS bXzsa3xsX2JH16bETjtiV0gndnftTOzpakzsDanEvq6NiffDsESX6yH0S1Z0 bUqmwheS6ZBOVnbtTFZ1NSYzIZWs7tqYzIZhyRrXe3huXHg+OR5X4Er8DBMw EZNwFSbjakzB70Jj8iHMwsOYjUcwB4/iMTyO3+MJPIm5mIc/4CnMxx/xNJ4L q5LP4wUswEIswot4CS/jFbyK1/A6loZ5yQbksAzLsQJ5rEQBjWjCqjCvYm94 PpUA/01VhAWpXo4HYCCOwfH4ZGhMfdrxhrAqdRemOzfP1MM+m0/KfFLmkzKf 1FzX5uEpzMezeN71F7AAC2HsKWNP/dnnd/AXn2uxGEuwHCvCylTBvY3YjA68 h23oxHbsDKvSPdAT+2F/HBRWpvuhPw7GITgxNKY/jbFhXvoyTMU03Ir78WCo Tz/uuDPMqzwyrKo8NjRWftzxOMez8DWfvxNWVl7k/sX4IX7j+nTX78G9mIHH sTesrIrCqqr9He2vKvuqqj8OCY2Zi0IhMwqj8RNcinGw3zP2e8Z+z9jvGfs9 Y79nbsRNuBm3wHgzt+F23IE7cRfuxnTcg3sxA/dhJn4Lc8w8gAfxOzyEWWFe 9T+HQvVXcQbOxFn4Gr6OszEpPFd9FSbjakzBVEzDz/EL/BK/wjW4Fr/Gb3Ad rscNuBE34WbcgttwO+7AnbgLd2M67gnPZY8N83pUhed6ZFAdnouScsU8kb81 sSz6uLi8L7ozmhhmRJNwFSbjauwOBfVzQf1cUD8X1M8F9XOsfo7Vz7H6OVY/ x+rnWP0cq59j9XOsfo7Vz7H6OVY/x+rnWP0cq59j9XOsfo7Vz7H6OVY/x+rn WP0cq59j9XOsfo7Vz7H6OVY/x+rnWP0cq59j9XOsfo7Vz7H6OVY/x+rnWP0c q5/j4q9wlf3JON8MbWrWNjVrm5q1Tc3apg6drg6dru5sUHc2qDsbymeFTaV/ H/nBvzp6t3xneFc2y8tiMxJLosPky2YZ7AY13Aw13Aw13Aw1XJsark0NV6yf CuqngvqpoGaK1UyxmilWM8VqpljNFKuRZqiDZqhTZqhJZqghZqghYjVCm9og Vge0qQPa0seEQvrY0u9xttH+RS1foLMLtHWBFi7QwAX6N6Z/Y/o3pn9j+jem f2P6N6Z/Y/o3pn9j+jemf2P6N6Z/Y/o3pn9j+jemf2N6tY1ebaNXYxq1rXK8 tqf6/EjxV9NCTG/G9GZbVW/76dwwncacTlM20JQN2clhU/ZqTAmbanqHd2sO RB8chsMxzfWHwrtRuazye3mdjku8EJ2cWBBdkHgpOjHxcnQQ+z6beJWSei06 MrE4Ooutz1LXV1AMn1Pb90rkohPY/a+Uw6F0zhpX10bH0Atn0QtDEpui07T7 avd32cfq6ZXwuOdvL/U5z71RVMWCqIdrbztbUvxdyv/3t3TLRkbD/v3f0zWe 4+2Oz+r1DPnwK8bwwZXjZcudrn5BtlwgW7aWfqN4c/GvUbp6iLPPlb5T7OvZ wcZQ/FsEG6KPeeLjzpZEw8ywt3uHmmvxV9/ODbWJcdFQ4381eSq9Vu7KW87e 8bTcRBO2O1vlbHRU42yPs7eiI6NkNCyqQAppVKIKGVQjixr00OM50YGJ82i8 ERhtTgvowJfpzFdCfXJcNCw5HlfgSvwMEzARk3AVJuNqTImGqeWHqdmHqdmH qdGHqdGHqcmHqb+Hqb2HqbeHlf7+RQ1126mnVWaxIfGSlSz+NZNXwjPU7WZz H8cmLxjXIk+ZrbnXRL3K6qKBZfXRcSwzgh2+mDjPU+dH5ydGlH5j7vzE6PBK 8VeJEleENYm7opMSd0ef1k9spQdTMk8mT45OSA6NjmOt86NDvXGofk60muOi w/W0pdh/qaea7r9r8mbiu96+wPMXOn7fcRwPqwsraeQ2+nh3yX+WR5XeSkSp 4l9C8XQfT/bxZJUnY0+0R32itaIoDRWtp5su01NxTa8IDXR3m1XvKeLWl9rL WcFl3tJmURFX9Ar71PD71PD71Mj71Mj71Mj71Mj71L779HlO2FT8H09aPMZO SZdaWxY6o75/1+d3xawLMcbcxlHiS0KH0bWbR8zjDtT3dm+9od9q/e76T/ut 1u+a4t9m0Vov/VZocbsW27TYqcUqrXV0z2KffXaOq8XfC/wuJX8hLnNnXNTP m1VGnPLmDm/u82aNsXQVrebNvXbF2ujL0Tqsx26evQd7sQ/viw7nqFzODccl vitaXBB9L3Gh4/cdx6h9LjOeK8JDiav4xV3RZ4p/NZvF6/Q4tLQ2S8PMUm+5 sNye663K2dPtIycktZ3sQoiOrOgVfTl9Hs7HiOjI9N2YhWbn72INjDPd7lqn 4w5jK/7+Y7uR7Tbn3UZ2jHnvNrJjzLu/eRcjRqX5Zsx1Y2JFtF/J6xZ641Vv rPNGf2+s80Z/b3zG0/sZ84aS5y0Ne417lzfXld7Klf4uwXn6O58nj3D8nuN4 UXFNdISI1y7GZETGfiLj/uLdwtJf1CmuX8FTCVfarcM5Pp1b2hvFX8Prk7ic V10p320w7k16bAlxyd+avbfOexmtV2q53J1C1C+6OHREP8SPcLnVP8d6nmdc IzCeZxafXstLNrD0RmNqUV+2amWzPHlq1Ldiv9BR0YYtoSM1GmPwE/wU43GF dnt0/02gvJYLWi4kLjer8WL+Guu4lhets4NKsxWHN7FRS/hLqRbva3x7jW+v 8e3tnn3xO+XVWlmtlXKtHGOM+2llp1a6tFL8pflKLbxb/HtExrfX+PYa317j 22t8e41vr/HtjT4WXRydEf0QP8LEaHg0CVdhMq6Ohuuxpx4/KmZVsPDZYlYF K58tZj3C0k+x9CJ++iY//Qo/PSPxWLjVnN6RIYZ8MBp5qziaTdTEydFQPjo0 eWrIJ++PhicfwIPR8Ir9ojMqmh3bHLdgazQ8dTROwujojNQY/AQ/RXF8lUa1 o9tvyrv9pry0VkULtoSNpW8jnjTu2d1P9el+qo9xx548ofQNREto4Bmju15T C25R+zWr9bao7ZqTR3Wt52uju2JX211pTx4VPqfV0V2rEzvYea+394kN74fF yYqwU124K1kdOj252JOnld59xd16V+pdyZTejRN79LeXVd4Py9SYXcmqKOXd Lk8tU0t2eXKYuDS6a4NeulSpnUbWltjtuFev+3jmB2/u02uX6rTTiNuSlY4Z o6h2/YOW9pnBdl43Wl27MyrTSrtWurQStLCp1HcqKvN2u7e7vB28ual7DEcX 7dR1izGs8fZAbzd6e0dijx1bHP0+fvw+j+uiE0J431jWaG2g1hq1tiNZFXKl WVVb52y0n0q5VcvvG9MTxSwayrW4yzhWJbqicm/t0veqZI3PR4UBxSe6lnhi o/6Klip4YqM2i1YqaGMr6/7Deln97nXy9n+yPqVnS+vi2f9kPczxf7gO4ul/ 0f6izP+y3c3xP7B36c6/a+eoR7J3VJU80PgOijLJ/lo72DuH0Awf8flQ9w5z 7wj3Bjkf7N4Q946UD5LJPno42N3DHQdbk2yytzM1RLKv/vvr4WA9Fds61PXD XB/g+iDXB7uuHatQfLrY88HdTxR7KrbVy7jK3V2f7ONKXxwUHWp8vTy5XpuH Gl+58ZV7a33ycPcH4AjXB3lmsGtDfD6y+FfJtbLKWIszLE/2M9b+UUV3K8W3 Vxl/cYblyYHuDXLvg7fLzbc3DuR7fYz5IO32N5eDrf4h+vpIcV7uH+b+4e4f 4f4g1wa7P8T9I83PLKzNgdrt42pfHBSWG0MX66xJHmItP2LOh3rmMM8c7v4A HOGZgZ4Z5JkhnjlSZiuuU7Zk14Oi3sZRtNgu4+htHNXGkS3Z9gjng0oW3GUM vY2hurgqUaI09/7ddv5g9EXrJUrz/uCN9u5Rl0c9/7s+YdfG7PcPfmG3fyKq +a/6hreOi9L/kX+4Ozg64H/LR7T2UbP+b/qJt4+K9v+f+opWTi7O6H/HX6zE n0vr+N/ymVJuqPmv+k0pqh+V2NHVIpJeKOIcIqqdmdjT1S6qfSmxr6tV9LlY VDtcVBuarOhqEVEvFI0OEdXOTFZ1tYtqX0pWd7WKTBeLaoeLakOTvbt2sMjH WORoFjk6eZDzfuGjLNLDqI5nlSGsMjh5qOuHee5wzwzAEc4Hem6Q5wZ7bojn juQ1VSq3rJprWKL4d31eiw6gdntTuoOois/QCm9Qez1Lf1vohbIR0SllF0an lX0/ur7sB44Xqdz/D3XfAV9Fsf1/ZmZ3Zu/NbBKSAEkgNJEiqDRBKQqKFX3o s4MIVmyoDxERKYKNpjQFFKQIqIgPOygo2FCxokgR6UhHQHqf/3fm3sTEBJIA T3//3c9OZmfPlLt75jvfM7N7crUZJa6BLXKtmQ7mMcr9p7rqR5Ga7aTs/0Ba 6FKzz97MOeOw5Geyj82bLmb/u90qxJJgJZ9KRA1hk55CzbDXohZ0JdWma+ha pF4PLteY7qABdAk9Q6/RfTSdZuLsY+yD6WtaQENoEfYxtBTWyVhahxInsTKs DP3EyrFTaR67lF1Gq1lLdhWtYa3YDbSJtWVtaQu7id1KW9k97F7awR5kI2g3 ewF7JhuFvQwbjb0sm8ReY1nsY/YDK89r8TrsdF6PN2B1eEPekNXnZ/NzWAN+ Hm/OzuIX8AtYI34Rb8Ea88v4Zawpv4JfyZrxa/h1rDlvzVuzC3lb3pZdxG/l t7GLeXvenrXgd/J72aW8I+/M/s278KfYtbwvf5q15wP5MHYPH8GfZ534BP4W 68zf4bPZ4/xLvoAN54v4avYK38A3sXf4Vr6NTeXb+R72Pt/HD7CZ3Ahinwgu BPtMKBGy2SJJpLBvRZpIY3NFKZHJfhQVRSW2QFQWJ7NFoqqozhaLmuJUtlSc Lk5ny0VtUYetEPVEfbZKNBSN2BrRRJzN1ommoinbIM4V57KNorlozjaJy0RL tllcJa5jW0UrcQvbKe4RHdhh0VE8xEl0E924FD1ED67EMDGcB2KKmMKj4l3x Lk8Q08Q0rsUH4jMeiu/FQp4uVolNvJLYLQyv6fleIq/vpXnVeFOvideEX+11 8p7i13j9vPf4Xd773kw+zPvO+4G/6P3kreFjvfWe4e/6UT/Kv/W1r/l3frKf wr/35/m/8B/9Jf4Kvshf7a/mS/21/lq+zF/vb+DL/U3+Nr7S3+5v5+v8Xf4e vt7f5+/jm/wD/gG+2T8kff67VDKR75bJMpkflimyJDcyXZYTQlaUdUVUniHP EFmygbxQlJMt5dXidNlG9hb15ePySXGD7Cv7i7ZyoBwobpaD5RBxi3xOPidu k8PlKHG7HCvHinvkeDledJAT5URxr5ws3xH3yanyQ9FFzpKfip7yC/mleEzO kfPFE3KhXCSGyMVysXhWLpPLxXNyndwohss/5EExUpHi4hWlVAXxmqqi6onP 1VmqiZinmqqmYpE6T10oflGXqH+JZeoKdYVYra5SV4nf1DXqGrFGtVJtxVp1 i7pVbFZ3qjvFFnW36iK2qq6qhzikHlW9PK6eVE95nuqn+ntSDVQjvEC9oF7w UtQoNcpLVaPVGC9NTVATvFJqsprhlVafqTleNfWjWuCdrn5V270z1E6137tM HVTGuyqoElTxrguqBad41wenBad7NwT1gnrejcFZQUOvbdA4aOLdFDQNmnq3 BBcFl3i3BpcGl3rtg38FLb07giuDq727guuD670OwS1Be+/e4L7gP94DQdeg q9c56B509x4KHg16e12Cp4K+3iNB/2CA1yMYGAz0Hg2GBEO8XsGwYKTXO3gl eNXrE0wOJnv9ginBFK9/sD3Y4Q0IdgW7vGeCvcFeb2AEwOcNingRzxsSUZGo NzSiI6W94ZGMSIY3PlImUs6bEKkQqeC9Gr0y2sqbFG0Xbee9Fb01eqv3dvSO 6J3eO9G7o3d770U7RO/1pkbvj97vvR/tHO3sfRDtGu3qTY92i/b0ZkSfir7u zYp+HP3KWxOdH13ibYkui67xdkf3JWR6hxNOShjkV0gYkjDOfyZhasJMf3TC Dwnb/Ve00un+N7qGPt9fqq/Td/h79d36fhnRHXUnmaQ76y4yRXfVXWVJ3U0/ IUvpPvoZWUEP0oNkVT1EPyur6WF6rKyhX9Ivyfp6gn5dNtBv6HdlUz1Nz5AX 6I/0R7KFnqVnyUv1J/oreZn+Vv8kr9Y/65/lDXqBXiTb6MV6uWynV+pt8na9 Q++VnfV+fVB204dDkj1DHnLZO/RCKR8LgzCUT4bJYSk5IEwP0+XQMDMsK58N y4WV5fCwSlhFjg57hj3lmLBX+IQcG/YJn5YTw8HhUDk5fC4cJqeEz4fPyzfD keFI+Vb4YjhOvh2OD1+R0xJ5YqL8MDElsbSck1gmMUv+kLgncb/8iXgU/J1I n1vicqpGFegEbWa6WW3WUi2zHvFfC5Q4bEaaN7BvNf1wdrlpjTyzEVsfv77e bES4Mn62O19+e3Wj2Yn9z2uqgHp24Hi20PY+guOjPCnLUEMpW8sRN1hekPvF HEBcYyS/gUKcr87bxuxfU0Cd35oVZov5DiWswq9dV1gbi7AFKHVYvPTfzGYz 26yJn23PV/smHEvNcjPP7DWXUAT37hSqmOv64cIqM7vw7HaihD9bjvsPxhK7 OtFMJI0j5xn+JffvONaYxShjGU598KwqdDZi5d3Vz833ZgH0B7oDu73g+l8z L5nR+NsHxznmNPOg6YRYrvuY/esR25wv92HzhVkHDfrCfIN24DnYu5c3V47s t4XcCoKdSpToYs/EU7ag7O+ydTO3VsRTduKXb8e9/9XsAN9PQlI9PIWc2s0m 94Q2ZUvny7/ZbEAf25J9x+3MqPu7JLdMYe2Oyy3Oc/afPGdfFa0MbLWdfFzT zEI8v8AsLKTmPbn6dm06sxDp182rtkebL4rcprz511rtsDqb78r8IuTGLzNP utjUv/Znc3MR8kNHzLsOt5bZ51bczUxyaDoJ9zX/FhSphK1mukPNIupFASVs L7pWFZA7jrDmp2PK/aYLF1rkOOFb3SLUvzY2lpkD0KMdxa5BH/VqVRz/drVk j3grY3v8evkC8lTHXh579TytfDn+94fYfpT8tQvMH7+70JJdQKddR2ow8PN3 8wcQbIXrU1ar97r0oe5yOfOxmWl+tiP6EfIfzBXvTxnA/2uppe0h8bSlGBtm 5MfinDwHcsUHYeRJooupHeJT4mmrcfd+PPKoml2/0+jnkT8C9OkYR3Kb/rZ5 g4SZdsT8f9VCH+ypPdKfjl//ynyJ+/91/Cw/fu/PFe+H3Bl0GVkmdE487SPz AUr47xHr/63g9MN4YhYfzRXmX+ZW0zIuPSZf/t5AsYnmv2au+TlXMqc29BgN QOwZGmi/maHXoblTaBrY4QyaSXXcrEJ9+owWUAP6hdZQC1rHGF3H2rF29AAs +n9TJ2vLU2drxdND/C7egR6GPb6IuvNf+Wrqwdfz9fQU38g3UR9rm1M/vpvv oQH8AD9Az1jbnAZa25wGwzZPoKGivChPI8QNog09L9qJm2ikN9WbStaqNTTa T/FT6Fv5nnyPvpMfyZn0vfxVLqG50khDP1mbjuZZm44WqcvVFbTU2nS0HDbd tbTC2nS0ytp0tN7adLTR2nS0ydp0tM/adHQYNl1/RrDmBjOphqoRLGJtOpZk bTqWbG06VkKNVxNYqrXpWElr07EqsOm2s1NhzRnWMhCBz1oHQRBlNwY6SGQ3 BSWCVHZrUDIozdoHmUFZdldQLqjAOgQnBSez+4Ozg3PYA7DabmMPwjrrw7rA OuvPulr7iz1ibSLWzdpErHvCIwmDWC9r6bDhOlmnsxn6df06+1yv1tvYbGtr sHnW1mC/WFuDLbG2BltubQ22wtoabLW1NdgGa2uwbdbWYH9YW4PttLYGO2Dt CHbQ2hHskLUjOE+MJCZwlVgysTSPJu5N3M/tmsJCpzHMaQyHxgyDRTGcXoBO j6QJSJmIXdHL9BpGqcnQJ+n0SUKfPkSv+whaFXVaFYVWzUH61/QzJdB87Bxa tgCs+hdaAna1lFahj62GzlWkdfQHevx27JVoB+2hk2gv9sq0jw7RyXQYGlnC aWSW00jhNFI7jdTQyHsomXeAXmqnlynQy6VUii/jyyiVL+crqTRfxVdROl8N fS3r9LWM09d0p68lnb5mOn1N5YYbShWg/5QGreUIsVFJ6K5CHA+fMkQEepzm 9LgM9PgGqiLaQJurQpvbIX4TdLqq0+ks6PRSYt4ybw1xb623jqS33ttCCd5W byeV83Z5uynJ2+MdpPLeIWj/yU77Kzrtz3Lan+W0P8tpfxa0/zxKU81Vc0pQ 56vzyVMXoD/46A+XIKWFaoGUS9WlpNRl6jIK1L/QT05CP7kcea9Ab4m43pJg Z0AoVNeizySiz7SmiuoG1YaS1I3qRjpZtUUvKuF6UQnXixh60d3IdY+6HzL/ UR2R8oB6gLjqpB5ELZ1VZ5T8EHpaAnraI8jVTXVDenfVHfI90PdC1/eYnU+B TB/VF/X2U/1xdaAaiJRBahByDVaDITNUDUPKcDUcLRmhRiAF/ZOitn+inNFq NHKNUWOQPl6NRzkT1ARITlaTkfK6moK8b6g3cB/eVO/izrynPkA7p6vpuCcz 1Ay06jM1G639Qs1BmT8qaKaar6CTaqFajNJ+VcupglqhVuOe/KbWo64NaiNV UpvUZtzJ39UWqqy2qq2ocZvajjbvVDshuUvtwtXdajfS96g9aMletQ/l71f7 UfIBdQAlH1QHKVUdUodQ+2F1GHmNMvb/qwY+ZVk0QQg0QQg0QQg0QQg0QQg0 QQg0QQg0QQg0IQY0eQphn6APcYsp5FlMIWYxhTQwpRvC7tGelGyRhQSQZQHp hIUJiyhM+CVhOyVblCFhUYYygDKrKVX/pn+jNL1Gr6FQr9VrqZRep9fh6nq9 ntL1Br2ByuqN+nfEt+gtkN+qt0Jmm94GmR16B+I79S7K1Lv1bsjs0Xshs1/v x9UD+iAl6MPaUHpoTetUi18IvdBD6IeSUoBiAZUOI2GUSoYJYQIkdRhSWeBa KlLSwlKUadGNSgHdMhGWCctCplxYntLCCmEFlFMxrIT4SeFJkK8cVkYc2Id0 YB9SXgxHo5Yx4VjkGheOQ8njwwkoc2L4CpW0aEjCoiElWzSkZCDWW3E0HIRd ODT0gYYjEB8JHBQOByVQ8HXEp9D7CD8gaBvQ8GPEPwUGCpoNHBTAwflAzAXA V+Hm7wOHg8LhYEmHg6UcDkYdDpZ2OJjucDDD4WCmw0HNklgShawVa4XwHtYB 4X2sI8JOrBPCfqwfhUDJK4g7lIwAJW9FaFEywaFkxKFkosPENL6Zb6YSDgdT HA6m8kP8ECU5BEwWnvAoBdgXIB4VUSohWolWVFa0dm+yWezLcthXXtwobkR6 W/d2m8XBLIeD5cXN4hYqk4OD60gAAXdSAOw7SFGHepkO9UrZWVv0z2aqGXrv uepcEg7jAnUhMM4DxrVA3KKbcOgmHbqlq5aqJVIsugl1pboS4VXqakhajPMc upVy6BZ16JYJdGtHWt2sbkZ4i7oF8rep2xC2V+0RWqQLHNJF40jXSXVCyoNA OukwLlAPq4eRt6vqCvlspOuJeAzjeqvHELdIFzikEw7pomqAGoBcT6tnkGJR L3Cop+OoN0QNQbrFvsBhX6ZDPeFQz1MvAvVEHPXGqrGIj1PjgGgvqZcgb3FQ OBzMzIWDwuFgABycjngM+z5UnyD+mZqL0GJfAOxbjLhFvZIO9Uo51Is61Cvt UC/doV6GQ71Mh3pa7VA7kMtiXymHfekO+zLj2HcQGCccxumABYxEDK2iXaIP UyT6SPQRhN2j3Skh2hPYlBDtFe2FlCeiT1DE4RRPGJLwPHGHOGn6d2BNsv5D b6cUhy/JDlnSgCx7EN+r91ESMOUw+rnFlBKhCAUlAU0UJTocSXE4kgYESUHc IkhqWDosDRmLHWlhVpiF9PJx7KiIEix2pDjsSHbYUcJhRwqw40WUOSYcg1zj w/GQnwDUSHGowYnX2WZnXhusPa8+XULXHYnn//+xmfVmgz3iZysKsrvsPI+b 6ytu2b/ZGS5neX/szn/NrtOFc+PW52ZrfzpbdLFZZdblndEpvN7sGTpzf/Fb eGI30wKWp/17RNs7X471sLS/PPZ5mZxyNv/1zPzhwng6bMWduLOrzBYcOTN7 uSzRtFy5F0NqEdl5j9KIxWcYs63rv2mL5rQmd72arndpmwqaXTAb88/Nme1m pfkFV/KtQhzrlj1LnvfM9p+4VueaL0DbRU5885Geslmef1bzRG0Fr+AUmmuC Gef+HnSz4V/Zw84PmUmIzYnLZGuW7cG7zA/Z6cWq5zeno6v+PLezYGZpLomn 3XyQnStf7mK/oTW5ESp+f4v6fN2s9arC5Yq/QdNylWt2m4M49tu5LnMoj9zR 1qX+j21/c58vwmZGHUfmywsobxVVgw6WO45Sj75VI4etFk8dpha4ARuKvIZ4 /GPFX8rL06rcfa+I+d82M82b8fWBNDPGzHSpq+3onnv0Pib+sAjYuMLxh3WO mzg0s2OSWYG/k+NSW9x629c4ZmNfl3fm2iFZBmXPzX6OsWCO+RHHKKReYuaZ b1z6zzEW4Va0ry9+S/O1fEOeMzeGmrdypdxlxpsOpq+d5Tcdc1IbIe192+/y rzqSXXPNvxa60XyM37L4xPXUbH2w4xgQLJsXzqH4+mzuNgCXc9ZG7BpLISV/ d6LaeKwb7lLo/g626835rnYyn+eRjf1ditFttdWQY6hvvtV6x7fcfbIxjG8r 4ncNobnTfO+e9x4SBYxhIdXKV+YW9IPf46tLAsiRveq0J3b1+Me3P9eh865X ZrMUy73cuP0b9i35uOdyxz0L6O3ozScYuwra/oJn8/JdP/jXlHj6fwpOp+Ks oxd7M7cXM0PsHYs+5gn3d6tDgHfsgdirZmos5q5l8zO33okn9cExtO5t8z4Q 87342efmNbLvB02zcRxATqDY50CJbBa8Fej7TRwnYutnifnK/NK8Z2bFy0yz Z/H0POhgTPFb6/Khl5pfcs6ybZeVNpZtV8aYuEO0OVY/Yu+IxPvPdofIbczl 7mwW2dW8+3E8hNggMwJj3UPxUnK924I7MMN0PYbW3mS6m5dMB8Q+Ra9+ybR3 +PA0RqOXcJ9nmVHmDoytW+0aoPtl080UMzZWc3zUyDSf/qXMdWYBrMpYzz0j JxbnnWZf7Cg6Y85T9k7X33PeCso7SrlxOsfydcx3hXvvIfcbF6flfWPl79ry ruK6N5h+L7wl7hfle//q79jyWrL2rkKHdxSGn+7pnDBLtzhbbv6B3mCtrIX4 e4SV7hzJjcffXvOi6WYeN8Nd/Afo+zj7pkx8HIrxxV3mXRwzj68eV1Kt2Jss x1XGarMWI6EbH/FM10IPczh37KmbbeAc2wpigMWu6xg4d67c38SeKtpicfC7 +NnyeP+Jt/qf6c8FbeZ2c5v50Ewl7s66m85A63YxRmCmmb04G2D+Y84yJwFH 65mHzJ3HUVeMP1Y4rvbGMSlm0+a8bzgu79UTuZkJJ6AMq70LYqgOfpvv6bvr q8xPf47C/+yG1vyKPufmPKHD1lLMsVRiTBdXv8RxhHdV/+4N7X0md88Fv5r+ T7bnyBt6WyfLnWJvupoHwI5+Ru+LXZvlwl/NB6a16YvYQLMklnaMdX15/O0t Zo07c7/n9X93y+G424//7cqC3nU/kVuMHYJ/r8GodwJmLAp7R/moeYuoUeYN N7e/6dhryrVlnJBSirSBCx03czWDT0RLCqkjjnRgt8c9L3+CnlJhtawGs/0f 95QTt4H17DxhdyblONpxIvr737gecSzaCN6zKpYz/mVH9rzI926d4fujZr43 Lvtm8ev9u7dj+QYiXxlHXA05Sh43W29nimKWcGxGJ2ctOHo0+9jN7WZQB5LF r9flP4avvMw6N3b8+S1Z9pxcUW27BLqw+LX+o1upY81Y/JUnsm812HXpHMve zHDh78DnQlcj/q9t4P27jvzNRC65vf/7thRtKxpCHuuoXuC3UoXW5d4g+PPb QbdikaNZ0QIzZcvauaqy1Bp97h/Y8nL3GGrAeioEZ91KzD8w32f+OIFlraT4 jHKBXxxVd1852RX0Hwq4WljZ9juqldk5s2Nuhn9lPCW7zkaurr+0K9fZU3+W md0W+71WvlbZr7Jq21WaY7HazSjzspme8x1YPGYZQXxO84ecdtTO196Xi19f nvzH8KaQ+cmtSnydc+7eAQLflEVe6SvC13tHqLvAb5MLybPWzVrZkdxhgTv7 HH0vhgzRo/FLN6Ik0dlF+16zgPzH8v7DPPu9pTt2x85dGJ81Pzo6xH9L2bzv G0G//jA/umMUlQYn3RBfTVoR69NO1+4qfksL+R2xFbZc1rppZx4yr5jRzm9A zjs9poV5u5glf/73MGbbxiPXYw4XtKocW1H8S9ofha/iHOvm3pGJI7PZDj6x HfxokVn8JxKZzUiza8Znmmvc+TvQgAWmjZltz80s86z5ws6Yu2tD85S9NDu9 WC1qaTqYXuaS+JmLQQPbu/jLZrzpCD0YBbY2HSOvlZhq3jPvxkdtOztfimq5 Necu5h6XFnsfcTR49Yv2eVgvCTlvAeWZCzL7sr/mL1Z7nzeTYKu9ED/73tU9 yuH89+4e2NXXN81O84kTiH21H3/DIK7FZxS/1n9q+598jZ2/lpXZiBVbd/6n tmNZp8KT/p1yzTrkeEgoytiTSvb9nStdvCzVg+1ZweVdA9axxo0mZaiumY8e avelZpk5C/2lPWkTG9fjdip6Z8ymKh0/fzu+UsEp54tpl/76UX6He7fCdMU4 F5+BNM1MWxwtzO2UamJjcLYPje44zjeNzNUm/mWD+coscW9L2B67EWPSyrj9 WoOquZGzhpM6+uxGwe0aZ8YjnJRzPt3acnnerLgqHmlN/6YzqY7zE3Oyu5L7 t0cP/2QSDu9xI+WH5m7zjh3DTA/zmI2h1H55qo29A3b3MbT3HnMffv997iRA 7B6Hm4+5kfpHPMt1h2Nf0k9zXkGyN3dnzQPxMopg4xVY94bCZfLl2ezeCLA8 wWmT0+bPce65y/qofMfmSqLGaD2neYX4sWsV92PXmy5mnJWkW513ui7OO10f 552uH2vF2tAgdie7k551fumeYw+yfjSCDWDDaYr1TkfTrXc6mmG909GH1jsd fcQ+YT/QLF6L16bveT1en+Za73Q0j5/Dz6GfrXc6ms8v5i1oIe/IH6DFvAt/ mJbwQXwoLeMT+ARaxV/hU2g1n8qn0Sb+Af+Afucf8pm0hX/OZ9MffA6fQzv4 d/x72snn8h9pN5/H59FevoAvoH1Ci5D2i2SRQgethzkyzsMcOQ9zvqgsKjPl PMwFzqtcgqgv6rPQeZVLdF7lkp1XuRTnTy5VtBKtWZq4UbRlpey3cizden1j mdbrGzvNm+bNZK2s1zd2s/X0xm6znt7Y7X6yX4K199P8DHan9ffG7vOX+CtZ Z+vvjXWz/t5Yd+vvjfWw/t7Yo9bfG3vS3+UfYE9ZH2/sGevjjQ23Pt7YGOvj jY21Pt7YBOvjjU22Pt7YTOvjjc2yPt7YXNlGPskWWu9unFnvbtyz3t24b727 cWW9u/FAjpXjeaL168ZTrF83nmr9uvGy1q8bP8n6deNV5Ry5iFe3Ht34Wdaj G28o18lNvLH16MabWY9u/DLr0Y1fbj268busRzf+sP0+jvcIeMB5z0AGij8a JAQJvHeQFCTzx4K0II0/EaQHGfzJICvI4n2CikEl3td6XOP9rcc1PsB6XOMD g9pBbT7Y+l3jQ6zfNT7U+l3jzwVNg2Z8uPW7xp+3ftf4KOt3jb9o/a7xMdbv Gn8puD1oz8dbv2t8YtAp6MRftd7X+CTrfY2/Zr2v8clB36AvnxIMCAbwN4KB wSD+pvW+xt+23tf4O9b7Gv/Ael/jM4J3gpn8w+DjYB7/KlgQLORLgl+CX/my YGmwjq8MNgQ7+GbrlY3vsV7Z+N7ARBjfZ72y8YPWKxs/ZL2yCRbJiJQTofXH JlIjlSLVRFqkRuQ0USZSJ1JHlI+cETlDVIg0iDQSFSNNIueKKpHmkeaiZuSC yEXi1MglkRaiVuSySEtRJ3Jt5DpxRuTeSEfRIFohWlk0tt7dRDPr3U1cbL21 iUustzZxv/XWJh623tpEL+utTfRNuCrhFjHZfrUnZlhvbeIzrXSS+Nb6aRPz dWt9h9hm/bSJw9ZPm+dZP22esn7avKj10+YlWD9tXknrp80ra/20eVnWT5tX wfpp82roCXqyV9P6afPqWT9tXkPrp807x/pp85paP21eM+unzbvY+mnzLrd+ 2rwrrJ827yq9Uq/yWlkva94N1sua18Z6WfNutl7WvDuslzXvbutlzeuQyBMD 795EnZjoPZiYkpjmdbGe1bxHEvck7vF6JFES83oSZ6uAeomw+JIomRiVwC4o BeOwR+kYu32M6icjvQp2RVUxCgZUEygZAR42Ig08tP/n4Wz3HzAsYiY6xEwC Yl6DXNdiLwHcbIMSb6RbqCndCgxtBgztCObwAPZzqRN1oZL0MPZS1JV6oOae QNh0IKymDBayRMp0XwiXYcnA3FOBuVWRUo1Vo1qsOjsF6TVYDcRrAoszHBbX Bha3RHg5EPl85y80g7UBLtdxuFzH4XJd4HI3pHdnT1E91of1QZl9gdRlgNQD qT4bxJ6jBmwYULu2Q+3aDrVrO9SuBdSehPhrwO5awO7ZGA++YF9QI/Yl+4Ya s2+B5k0cmnOgeT2EZwDTpcP0ZIfp3GF6ssP0NIfp5zlMP91h+pkO08sC0ydR ef4af42y+GT+X6rIpwDlKzmUr+RQvgJQ/kOEHwHryzmsr+ywPgtY/x3C74H4 FYD4cxH+CNwv53C/nMP9k4D7mk4WIdC/ikP/ag79qwL90+kUkSEyqIbIFJnU 3I4EiGMkoOoYCaoirCaqIxfGA6ppxwPkaigaImwkGuFqE9EE4dnibMhgbECI sQEp9lvrC9231he576svdN9XX+S+qb4A40RPOtt71HuKGEaLQZTkDfaG0Vne cG8EpXrPe6OpoTfGG0elvZe8/1KGN8V7jzIxokyjOtabKNWz4wo1tuMKaTuu IEz2k6mZX8IvQbXt6EJ1MLr8TMKf78+nCv4CfwEl+Qv9heT5i/xfyMeoswQp S/2lSFnmLyPlL/eXU+Cv8FdQSX+lv5IS7JhEoR2TILneX08l/A3+BkrByLSJ mL/Z/x01bvG3Uqq/zd9Gpe1YhRp3+bso3d/t76Ym/h5/D9q219+L9uzz9yG+ 39+P+AH/AJ3tH/IPoeTDklOqFNKjs6UvfWIY4RRhsJABhTIio5QkE2QCCaml pnQZypCayESZCBmMgva/ustU5E2TJZE3XWZAPlOWoRRZVmah5HKyHFkPqBUR VpKVUMJJ8iTIV5aVIX+yrAb56rI6lZanyFOQXkPWIE/WlDUpUZ4qT0P5p8vT kbeWrIXSasvakKkj6yBvXVmXtB1xUVcD2QDpZ8qGkGwkG6GExrIp+bKZPB+S F8gLSMkL5YVoc0t5BX7Xv+XVKL+NbIfab5I3o5Zb5O0op728m5rKe+R91Eze LzuhxgdlZzpXPiSBHvJh2ZVKyUfkI2htN9kDv6WnfBTl9JK9UEJv2RslPCYf owT5uHwctTwhn4DMk/JJ1AIGQGUsA6BaYACDqZ4cIodQXcsDKAM8YDiujpAj KFM+L4EDcqQcSY3lKDkKd3usHItwnHyJ6lgfsJAHV0AJk+VkhK9LaKmcIqcg 7xvyTTpfviXfQslvy3dwdaqcirzT5DSkvy+nQ3KG/BCSs+THuPqJ/JTqg2F8 gfQv5Zd0GnjGHMh/Lb9GyjfyG0h+K3+A5Fw5F+35Uf4EmXlyHlr4s5yPNi+Q C+hUuVAupAZykVyEvOAoyLVMLkPJy+Vy5Fon16G09XIj5DfJTZD/Q+6CzG65 G3djj9yDtu2VBynD8hiqCx4TIp6oSlA9laJSqYxKU6WpvkpXZamBylIVqDZY TlVqrKqp6nSxOkXVoEaqpqqJlFPV6dRE1VK1UEJtVRuSdVQdyNRVdXG1noLt CG50Fp2hGqqGqKuRagT5xqoxrjZRTVCX9SnALGeiOpYzIQRnQgjOhBCcCSE4 E0JwJoTgTAjBmSjTciYqYzkTQnAmOtVyJsTBmaix5UyUYX3V0mlBs6AZcoE5 IQXMCTJgTgjBnKi+ZU7UAMwJlkDQPmhPTcCf7qOk4P7gP5ABi0JesCikg0VB 8tHgUZTTK+iFeO+gN9LBqNAeMCrIDwwGUr1gUDAIucCrqC541TCkDA+gdcGI YCTirwSvoK5Xg1fpYsu0kAKmRVHLtBCCaSEE00IIpoVwQ/AHnRNsD7ajlh3B DpQD1kW1LOtC3ATG/u+tCNH5ERZhlGEZGJUBA1MIg0hAZ0SwUa1INBJFXEcS ESZFMP5GkiPJVD9SIpKClNRIKjWOpEXSqG6kZKQkNYmUipRGekYkg+pFMiOZ dGqkTKQM4mUjZVFLViQLV8tFyiEF3A5xcDu0BNwOIbgdQnA7hOB2CMHtEILb IQS3QwhuhxDcDiG4HUJwO4pabkfngNtdScnRq6JXkYxeHb0a8Wui1yB+bfRa xK+LtqI0y/yQ8lR0AvHoxOjriIP/IQ7+BxnwP8jsS2DEE3hCJp1nWSCdGfPd YFkgccsCEYIFImytW1OWvkHfQBV0G92GSugb9Y1UXrfVbekk3U63o0r6Jn0T CX2zvg3x2/XtkG+v20PmDn0HZO7WdyN+j+5AlfW9+l7I3Kfvh0xH3RFXH9Cd qByY5UNI76K7IB38EmE33Q1hd92Dyuqe+lGqqHvp3pB8TD8Gycf1E6ixj+6P lAH6GZQMDopahughCIfqZyEzTA9Hm0foESjnef0C4iP1SMiP0qMQf1G/iDJH 69G4OkaPoap6rB5L1S1zpWpgrhOohp6oJ1Jz/bKehPhr+jXITNaTcfUN/QbC N/VbVFO/rd/G1Xf0u7g6Tb9Pp+gP9HSkzNAzkAK+ixB8F+En+lM6WX+mP4fM bP0FVdFf6i8h+ZX+CrV8q39Aylz9E8oEG0b5C/QChAv1Isgs1r/i6hK9BOUs 1csQX66XUz2w5JUobZVeRVUtV6Zy4Mq9qWz4WPg4VQqfCHGXwJv7UM2wb4h7 FQ4IB1D58OnwaaQMDodQjXBoOJSaWz6NFPBpqmn5NKVZPk3c8mmE4NMIwacp zfJpqgNm19Tx6Qscn+aOScd4czZjtvw40fHjRLoee6Jjxhc5ZnyJY8Ypjhlf 6phxKceMSztmnO6YcUYu/z2+898TOP89vvPf4zv/PVHnv8d3/nt8578ndP57 fOe/x3f+e3znvyfJ+e/xnf+eJOe/x3f+ey52/ntaOP89qc5/z2XOf8+/nP+e ls5/z+XOf08mmHoCeHPIQsfRM+gMlskywaEtUz8TTL0lNXRc/Ep2Nbse6ZaL N2K3s9vBsB9kDyLszLqCN3cDI28ARt6HmoCL90W8P+sPecvIG4CRD6em4OKj qBlY+LsI32Pv0blsKpuFq5aFX+tY+HmOhTd3LPx8sPBaJBwLF7n4twD/Ps/x 74vBv1s4Fm49DHnOw1AJ52GohPMwVNJ5GCrhOPoVjqOfxfvyfnS29exPV8WZ uuXlNfgb/A2qzv8fa98D1cZ1p3tnJI0mWMYYE0IwIYQQQgilhBBCKSaEEEIJ IZQ4jpdSJIQQQjMS0ugPQojRH4TsupQlXtelfq7rOn5+Xur4eb1eP5fnutTr er0uh3II9aN+LqUu63p9/Cjrpayf4yXvd3/ChDTdNnvOO/d8n67v/NHM6M69 38eZ+XwGdPmTqMifQkX+NPtT9qegv6kWf4KdZCeh/eegv5/A1KLH2F+wvwRF /iv2V8A0wSgHU92y2Tn2n6Dlt+xvgWm2WyomG2Ww/4edhzrNN8pk/4W9A3Wa cpTFfsjehzrNOnqcXWY/IqmYeJSuYBQs1GnuUaZCpVBBnaYfpWP6UYZinWId tGwA9Z+Luj8fdX8B6v56xWZFCrRT9Z+reBLU/+cVmaD+c1H95ymyFdlQz1Hk AD+neJ48D07gRagXKYrI5xRfAD+Qi37gOUUJ+IFcxUuKl2D/1A/kohN4G53A NnQCb6MT2IYeoBLU/14SC7r/AIlHxZ+Ein8zKv4i5WlQ/F8ExX+BbFH+RDlG ylH3V6zJZFJhJtMGzGTahJlMdegEqtEJvIz5TK+jHygGP/AB4dADqFW/AA/A oQdQoweIRfWvRvWfpJpTzYHKv6H6LbRQ3c+h4n8EFX81Kv54VPxJqPgfVS2q FoGppq9ETa9GTR+Pmr4SNT3LcaDp1ajm1ajmH0XVXol6XY1KPR6V+qOozitR l6tRlyehLq8ELQ6+l8sFRc6hFo9HLV65osILuAJYv5ArhPWpFq9EFR7V3GrU 2WrU1lWoratRW8ejtq5BbZ2I2voR1NZJqK0fRfX8KNfP9YOm/Ab3DVCTVD0X o2Iu4fZye6GdKuYXUDG/zB3gDoCOpFq5kDsEWrkEtfJm1MpbuCPcMOj474NK 3owq+S3Ux1u4U9wp2Iqq5EJUyW+BSj4D2/4AtPJm1MpFqJW3cH/PXYA9/IT7 CaxPtXIhquTNqJKLUCVvQZVcwU2CSi5BlfwyquRCVMlbUCWXoUp+FVXyC9wv uV/CUqqPo8r4Be42twAtVB8XoT4uRn38FrfMLYNCpcq4BJXxFlDGj0CdauIy 1MQvq59QP0XKURlXoDJ+B5XxK6iDX0Yd/A7q4ArUwZvVL6pfBKYK+FVUwBXq l9QvwT5potgGzBJTYZbYBkwR24ApYipMEYvBFLFaTBFTYYqYSl2vrodvp1li KswS24ApYq9jitgmTBGrwxSxZEwRS8YUMRWmiKkwRUyFKWIbMEVs05oUsQ2Y IhaDKWIbMEUsGVPEVJgitgFTxFRrUsRUmCK2AVPEVJgitglTxJIxRUyFKWIb MEUseU2KmApTxDZgilgdpoipMD9MtSY/TIX5YesxP2wD5oepMD+sbk1+mArz wzZgfpgK88M2YH6YCvPDVJgftgHzw1SYH/YlzA97HfPDNmF+2BuYH1aL+WFv Yn5YHeaHJWN+mArzw17H/LBazA+rW5MfpsL8sGTMD1OBh9lEisGxPEVeRn9S zj/NPw3eIIvPAq3/LP8sKeJz+M+B38jlc6E9j89b8S2FfD7/PHkV3UshX8gX AVMPU8F/kf8i7Id6mHK+kn8NuIp/HfZWw78B69TyteQF/k1wMlv4Or4eHMI7 /DuwlPqZMl7La+F49LwetoomMVKHUwEOxwzfRR1OLG/nJdiPg3fAVi7eRV7h O/lOaOnh/XAW1OcUo7fZjMmNhehwSvgBfgCY+pxX0eeU8N/kYZRAn1OIDmcL /13+u9DyHv8efDt1OxXodt7h/5ofhq2o59nCv8+/D+v8d/4E8N+C81nHz/C/ Af4n8Dzr0PO8hp6nnF/kF2HP1PMU8x/yH8LZUc+zDj3PW+h5XkbPU4JupxDd TjG6ncKH1oPDKQGHs5GUocOpQIfzCjqcV8HhJIILeuShJFjzUXA4RehtNqOf KQc/8zR8Szb4mXXgZwqACx8qBt4CHmYdeph14GHeBKbuZR26l3XoXl4D97J1 xbFQr7IdfEgDOpbGmEZoaYlpIaUx5hgzsBgjAltjrMC2GBuwM8YJTLPoNmIW 3UbMonsYs+gexiy6jZhFtxGdjwK9zZfXbV6XTr6wrnrdl0npOsM6L9mKSXVK dDtKcDjPgougHuZZ9DDPaFrBwzyhadeYQalT3/IEOpZnwbF0QN2msYNzcGvc 0EK9ypOabk03tPRo/OBSqD95Cv3Js+hPngF/sgtavg4u5Rl0KU9r/lLzl7A+ 9SfPar6p2QtLvwX+5GnwJ9+GvVF/8hT6k6gzeRKdSa7me5rvAb+neQ+YOpMC dCb1mr8GZ/IcOJNj0P6+5jjJQ2fyHDqT59GZFIAz+VtoOaX5O/I5zWnNaVjz B5ofQDv1J5/XnAV/kqs5pzkHSy+AM8lDT1KAnqRec1nzU1g6phmHdupMntd8 oPkA1qSepEDzC81VaP/f4EmeB0/yS9jbDDiTVHQmeZpZzSx8L/Un+ehPPq/5 jQY0HqYD5mAeabbmluY2tNCkwHTNvGYB6jQvMBPzAtMxLzAH8wLTMS/wccwj TdX8u+bfgWl2YI7mIw0oQEwQzABhDgoQcwQfx2zSVEwTfAyzSVMxUzATMwVz MJs0e33s+g3QTvMFM9dvWr8JWmjKYBamDD6+Pml9MiylWYM5mDWYiVmDWZg1 mLE+fX06LKWJg5mYOJiOiYMZ683rzeQJdGJPgRMLohOD/rB+x/od4NB2gvt6 Ct3X8+i76sF3fRPqe9cPkTx0X8+v37d+H9RpcmEmJhc+hsmFOZhcmIXJhZmY XKgkzOY7KQEQvxrFLvIrQnQNAB3ACBABEsCz+snYhuFTBoQBuwCDgL2A/YBD gKOA44BTgBHAKOAiYAwwCZgGzBA2cBlBdHMINjABuAL1W4AFwBLgPiHNLIAH xAISAMmAtOgxNGf+B5850X0156+AblMEKMVlpLkCUB09XtzmUPQcm+sA2wCN 0faVTzZwDcHYTgBOQ/36alsUNwHzK/UrgMWV+r0ogmQFHEADiAckAVKj6wYz cH3SrAeYotep2bp6zaPrZuN6pNkJ8AICgMjKOfRHvy+Yt3KuuwFDgAMryw+v LC9cQQm0we/YTM/nLOD86rlEz/k04CzgPOASYBwwBbgKmAXcWPm8vebzwfp3 AHdXPq+ubHd3zfJlQvRKQAwgDpAISPn4k/5++nRA1mf+ZIPlH/9W9Nz0uSu/ 9X8WyZ8E9u9d0e/BfpUcXQ+/dy0KAMUff67uI7pfNlgF7WWAypX+B8v0NR9/ 6usB25Ubm2Yt1T0TunAHQeaQNcC7OuKBBzuSgPd2pALv78gAPtSR3TNBt/I3 6o525Pn1TTcsdT1Xmm5btvVc0x3vKEQuWa2f6ijvuUaX+k1NdyyNPdd1Ix1V Pdej9RW+a9H33NSNdtQibwW+iPWLWB/raACe7NABT3cYgWc6xJ6bdCu/FdgE 9WWLtWdeN9chAd/q8AAvdMg987Td79QqLc6eRd1SRxj4fscuv1cbY/H23Gtm OwaR9yLvB+abK4BjOw4BJ3QcBU7uOA6c1nGq5x7dyh9ozuwYkfdr4ywBGa5s x6hMtImWiMxR9ke0KZZ+WdOc33ERuKhjTNbQFn9/tH2F0y275XhtlmVITmou 7Zhc5YqOaTmJtvt3r3Cu5YCc2lzdMYM8B1yH9W0dt4AbOxaA9R1LwKaO+6ts tbH+oWanjfcf0BZYDssZzV5brJyBe8teaQnYEh4wbfEf1hZbhuW85ogtGTnt QZ22+4e1ZZYTcmFzvy1TLqR1/wltmS0H6pWW03JJ825bPnLRan3IVgp8wFYB fNhWDTxsqwM+YduG9Ua5hG7rP62tsZyVy7X1lvNyVfNpm36Vz9r0/rPN520m uUq73XJJrtU2WcbxGKzIztX6JZsXjsRgmZK3No/bAqs8ZYvIW7Vmy1W5oX20 K4AcQe4Hvti1G3isawh4susA8HTXYeCZrmG5gW7V522f6zrRF9DaLLOyTuu2 3JCN7be6TgMvdJ1FpvWlrvOykS7ti2h9ltsy136/65LMmVnL7b7+KGtDljuy aOa7xpGngGOxHov1hK6rwMlds8BpXTeAM7tuyyLdqm838F2o77Qsy5I5p+sO cH7XXeCiLmih7X1D2gGrUvaYS72UK7wxfQe0e6wxsmyu9sZRNkewnghc500B 3uZNB270ZgHrvbnAJm+BLNOt+g6brd7ivmHtPu11OWx2esvksPagNU7eRTmY oT1iTZQHzV5vJXDAWyMP0pa+E9H2FT5mTZH3ak9a0+X95oi3fpX7vdvh3oH2 vtMrfMaaJR8y7/Y2IRtW60NeM/ABrw34sNcNPOz1AZ/whoBPe3f2nTWf9Q74 9dpz1lz5qPm8d0/fedzb8ZWWS959wOOUaUvfJe0Fa4F8yjzlPYh85EGdtveN ay9bi+UR81XvMXmE1vumzLPek31XtRPWMnnUfAOuPLD3zGr9tvcc8B3vBeC7 3svAy94JeVRQeq8Ax3ivyaN0275Z7RVrpXxRe81aI48Jcd7rf8CJ3pvymPa6 tV6e1N60bpenhRTvPPLiaj3de0+e1s5bm+QZIaubrHJuNyfPaBetBnmu+aqt H3k38CzWb9iGgG/bDgDfsR0GvmsbBl62nZDn6Fb+83ql7bT/kvae1Szf0hGr TV7Qx9jOAschJyKn2M7LC3Spf1zHWd3yko6zXaJM6/p027g/Vqex+uT7+izb FPLVP6jn2maBC2w3gIttt4HLbHfk+3Qr/5Qu3hrys7ok604/r6+03QWusS0D 19uVwNvtMX5el2od8Mfqm5AN9jj/VV2GdY8/QW+2JyKnIKf7E3QZ9iyo2+y5 wG57AbDPXkzbYf1ZfcheBi077ZX+G7ps6z5/sn7AXgO8x17vT9blWQ/Kk5T9 t/X77Nv9d3SF1iOw/kF7E+yh0G6gDC2z0fYVLrEe86fpyq0n4diO2M3Ax5BP 2m1wZWj7Xf0ZuxtmT6zrqqxn/Jn6c3YfcmiVL9h3Al+2DwBP2PcAX7HvA75m Pwh83X7Ev6y/aT8WUMJ+zvlzdKn2k8Dl1gvAtdbLcJzz9jPAi5SxZVa31Trh z9ffs5/7JNP2ANhW+wV/ZgtnvxyI0zVYr/iLWjT2CX8RrQcSdQ12aNHprNfw vKJ8/UG9Jd5+EzjJPg+cal8EzrDfA86WCHCexMG5023v6ozW6/5SnWi96a9o KZQ0f8AlUry/QidZ5/3VOo910V/XUm7bTVlKWuUqKdVfp5Ot9/zbWmqlDOCt yA1SNrBOygukUE0SSG8xSoWgT0AbBLJaRKmk52aLJJUDe6Sq6AweyKXzYKCg RZZq5dSWsLRVTqUzUaC4ZZfUQGclSQcMc02grGVQMsqFLXslEeYXuF8ClS37 JUmeo/02UNNySPLI91uOSjLwcSkc7WOBevr7Bra3nJJ2+TN1VdIgMFyHQFPL iLSXXhNpP3D0TEelQ8AXpaP+OpxxbggF3RqYfejIf1so7o6XRaGsOwm4sjt1 ZXy+Q0e5vrtCTXeGfEh7pjsbmI4zy0J9dx4dc7oLgWEkiSiF7d0lMHo0dZfL 09jzZ1vGpOMBQ8ukdCpgbpmWRgK2lhlpNOBumZMu9lxruSWN9VxvWZAmAz5Y ZxrWWZJmAqGW+9JcYKeBlW4FBgy8tBDYY4iVlnrmtTXSfbnckOBgA/sMyQ4+ cFC73REr1xrSHAmBI9osR3LgmDbXkSanGjIdmf5LhhxHTuCkId+RHzgT1RuG IkdR4Jyh1FHaM0EVReCCocJREbhsqHZU01/BUfdgZjfUObYhNwJvg2ObMDQ6 9IErBr3DFLhmMDmsgesGq8MZuGlwOryBeYPXEQgsRjVtM+uIgIqL6ihUKYaA ox+0K+pGQ8SxG7jfMQQqjvaNe816B7Bht+NwkBiGHMNBznDAcSKoMRyma2qV jtM9i4Zhx9lgfFS56fY7zvdMGE44LsE9jhrVcNox3nOzOdkx1XPPcNZxFb7d 5JiF63DecQP4kuO2nGEYd9wBDTbsuAvHM+VYBr7qVAYGdEvOGNj/rDMumGS4 4UwMTNArEEw13HamRPt2MMNwx5kO+7nrzJILDcvO3GB2q9JZEMyLKszWGGdx sLA1zlkWLKH3RbC8NdFZCSodtHqwKsqtKc6aqAIP1q7hrcgN+C06ZGNrurO+ 52ZrlnN7z3xrrrOpZ5Eq6qDYWuA0rNQlZA+9v4LyypUEPRwMI++iRxUcbC12 moOD0Try3tYyp02Ob610ukEPgyoO7m+tcfqiGjh4aA0fBaXqlDNa650h4O2U qWoNHo9ya5NzZ1SpBk+1GpwDcl6r2bkHGNqhxebcF1WtgbKPOThC7/rgKPLF KLe6nQdBi4IiDY61+pxHQHmCLg1Otoacx+Ta1p3Ok8A25xnQnOPOc6At6e8y HeXWAeeF4Iw+3XkZ7m46Mse27nFOwOyZ7rwC9X3Oa8E5XarzOp0RnDeDt1oP Ouf9d1qPOBeDC63HnPeCS60nXSR4v/WMiwuxK2M7jt66BpcmxLeec8XDaOxx JYVioyNh6wVXaiih9bIrI5TcOmGvDKW1XnFlhzKjGkBvduXBXICzTOs1Om5H 5+jW667CUE7rTVdJKL91ns62rYuucpj1YNQKFeknXFWhotZ7tqlQqX6Pq9af bCSuraHklXn5iKvBH2vkXDqqJVxGec6ocYl0TndJ8n1jvMvjTzAmuWT43muu MJ2/XDAGGlNdg9Ce4drrT2jJc+1/MFMYs12HQhXGPNdRODbQEsF4Y6HreGCC nl2o2ljiOhUdaf1TxnLXCOynyjUKswDMuaE6Y631ZGgbnadCjcatroshvbHB NRYyGXWuyZCVXreQE/fjNRpd06GAUXTNgMeBMTwUiaodyoGmKD9QNVZ3qJ9y tCW0G3mIHkPoAPJho+Sa87NGj+uWnzfKVI1QZRJoMoZdC9E6zHfAsBXMBaFh OuqGho27XEtRXRE6scJwFoF646DrPswXWMfzGjbudbP+NON+Nw+KAnRF6LTx kDs2qiLgqFY5NKQ/4k7w5xiPupOBj7vTojM+7Ac4dNZ4yp0ZneVD540j7hx/ vnHUnQ8M7dBy0V0UneVDl9bwOJ2nQlPIQ8hXjWPuUpi7YQYPzRon3RUwU8M8 HrphnHZX+6uNM+464Dn3NpjFat2N/m14zW8j31m5Mrfcen+RccFt8lcYl9xW f53xvtspz7Wxbm/ormDororECObu2nCtYOveCuzubpAHBV+3TjYKoW6jzAk7 u8VIHKwjwdKBbk8kUdjTLcPSfd3hSIpwsHtXJF040j0Ibuhg9155l3Cse38k S7un+5AsCye7j0ZyhTPdxyMFwrnuU5FimDFH5EPChe7R3p3C5e6LkTJhonss Uhl1B9rL3ZPyiHClezpSI1zznozUC9e7ZyLbhZvdc+DjbnbfWtXh890LkSZh sXsJ6ve67/eeFImPjRhEzsdHzKLGFxuxifG+hIhbTPIlR3xiqi8tEoo6UHO1 LxM8V9TpoKcQM3w5kZ1RlydmQ4sk5vnywXPBXB8ZMB/2FUUGhCxfaWSPWOir iOwTS3zVEbM5h66pHfDVyR6x3LctcjDqs9pHfY0P/GzUY4pV6CurzTeo4/Pp V7992GcCRq8k1vqs4JiiHmcZPOaouLV7IVhiLvU5Yf8NPm/kiKjzBcBnwRWI HBONvsiKVtktir5++ZAo+XbL06LHNxQ5Kcq+A5EzUT8ohn2HI+fEXb7hyAWq cyKXxUHfCfDU4KwjE8hXxL2+0zBrgIOG+QI4co2yHz115Dr9lsjNKIv7fWfh jA6B55LEo77zsof638i8eNx3aaW+iHyP6qUdZOVKgnvdwa0wHNUOjXjKN75D E60jx4sjvil5rzjquwruFTzsjiTxom826lh3pK7hDPMl3w24YmO+28CTlKnH DGyPsjjtuxP1lTuyxRnfXfmUOOdbBoZ2aLnVo4x6zB15a7iQqrgdJcjlURYX emLAOYJ/3FElLvXEgU8EF7mjVrzfkyhPWtieFGC+J12etsT2ZEWa6O+yYyty g3agJzcyb0noKZBHLMk9xfKYJa2nDNbM7KmUG9p4dyC0jN4B5yMcu8CztMW6 I73KtgR3f2+MjnPvDsa3JbuH6NzhPtAb15ZGGeqHexPbMt3DvSnAJ1Y5x326 N70t3322N6utCLbio56urdR9vje3rcJ9qbegrdo93lvcVuee6i1rS6bjJ/Ld tm3uq8EFOlr2ViLX6EPuWX9CW6P7Rm99m959u3e7rtB9xz/bZnLf7W1qs7qX ew3IZjpO9tpWvBVwr7vN2ans9UV9Vpu3M6Y31BbojOvd2RbpTOwdaOvvTOnd 07a7Mx14qDOrdx8dM3sPIh9pO9CZ23sMuMDPth3uLO492TbcWdZ7MjqntJ3o rOw903a6s6b3XNvZzvreC23nO7f3Xm671NkULMFRlG8b7zTIxrapTnPvRNvV TlvvlbbZTnfvNZ3Y6fNXtN3oDPlL22537pRPRWcoyr3XdTLMhlDvHAh5o8qt Na5zT+/Ntjud+3rndaTzYO9i293OI7332pY7j4WW23I6T/amm5SdZ3pzTTGd 58LEFNd5IcyZEjsvhzWmlM4JedCU7h4Kx6/dmymr80o4yZTbeS2cairovB7O MBV33gxnm8o658N5psrOxXChqabzXrjEVO8h4XLTdg8XrjI1eTThWpPBEw9s 9iSF41fY5kmV50xuT0Z4q8nnye4NmUKevHCDaaenMKwzDXhKwkbTHk95WDTt 81SFJdNBT23YQ3/fsGw6ovOEw6Zjnq3hXaYUD4z5ppMeXXgw+tuZzniM4b2m cx4xMGC64JHC+02XPR7gCY8cPmS6ApseNV3z7Aol6Ko84LBM1z17gW969oeP m+Y9h8KnTIueo8D3OovDI+3Eczw40855Tslcu8YzEh5tj/eMhi+2J3kuymJ7 qmcsPNae4ZkMT7Zne6bD0+151olgSXuhZ6a3uL3EMxeegTVvwZrlnoXwXPRb 2qs8S+Fb7bWe+4GJ9q1dbHhBx5my5KX2hi4+vKQr6Yr1p7XruhLC99uNXcl9 bLvYldbHt0smXx+v29oFs3O7pyunD7RcV75/W7vcVdSX0B7uKu1Lbt/VVdGX 1j7YVd2X2ZbfVRdcoNyXE3X97Xu7tvXlt+/vauwrouqlr5SqlL4K+leUvuro HYd/wehf+UvFJ++Ocyt/K8C/DPTVtR/q0vdm0fm9bxv14H2NtDf26aN/HcLx 4W77UfcQ7B+VWPvxLpN/qi2zy+qfWvnrDf5dpf2U1dZnarvT5eyzRl1/+0iX t89Jf+tAPWHJI8wC8y+EML9nlgjL3GM+JErmI5YhHKtiOfIQu47VkHVsHLuR rGcfZhPJBjaZ3Uw2sunsk2QTm8U+Qx5mv8N+hzyiqFJ8iSSpKlWvkWSVpHKQ FNWPVT8mqbFQyOOxabFvkLTYuthGUhurje0jX4l9N/ZHJBR7KfY2+ZvY+dgl cgWO5stEif/7QSzZQB4iG8lWso5sI3ryJjGQr5NG8g0yQMJkkHxAIuTn5Nfk MvkNE0P+F6Nh1pOPmA3MwwzD0HecePrcJPMI08C0MSlMOxNhspmdzB6mihli vsO8zfwd8zPmK4r3Fe8zbqVT6WI6lQFliOlS7lR+nfEp31W+ywSU31J+mwkq v6t8jwkrjytPMF9Tnlb+gOlX/kj5I2ZQ+RPlPzDv4vuYe5STyg+YbylnlLPM t5U3lP/M7Ff+Tvk75qDy98p/Y75Hn6JjDqs2qTYx/031gWqZOcqpuAxminua e5pZ5J7hcpnfcy9yxcyH9A0P5iPuFa6CVXKV3Bssx73JNbKxXDNnYFM4Iyex aZyLk9nPcV/jBtgXuUFuP7uF+y53hK2mb06w9dxx7qfsW9w4N87auQlumpW4 a9w1tpub5WZZH/db7hbbQ5/HYoPcv3KLbIRb4pbZnWqiXs++q45XP8x+V/2I +kn2PXWm+gX2hPpltciOqh3q3ext9TfV31Ro1N9S71esV39ffVyxif6/qopH 1P9DfUaRoh5R/1iRSp8HUmSqf66eVhSor6pvKIrU/6z+N8WrfCZ/UrGV/9eH nlD8OvbD2A+V9H05kewE1pBU+rZx+YkV8IAckinqq+6KpoqqL12pyBOtolP0 Vs2KATFSIdYNiqfFs+L5ihHxkjguTolXxVnxRk1MTbrYX+MWd79a/apJHBIP iIfFYfFETfqrFdCrlNDHF7CP/54wzEfMR4SFHh1HFLDsMXwSlbDfZ79PGPZ9 9n1YdoL9G6Jgf8j+kKjwSVSO/Rn7M8Ljm2APsR+wUyQGn0HV4NOn69lfs78m sfjc6Qb2d+zv4O6gT5bGKxgFs/q/BqsUHEnEN8eSFImKRPKoIkmRRJLxSdHN iixFFnkM3wpLVZQoSkgavgP2hKJM8TJJx7diMvCZjafg+DVMPF45ykS4QHzC BeGyMCFcEa4J14WbwrywKNwTibAocqJGjBeTEKlihpgtzIt5YqFYIpaLVWKt uFVsEHWiURRFSfSIshgWd4mD4l5xv3gIcVQ8Lp4SR8RR8aI4Jk6K02uLZZs4 I86Jt8SF1bIk3rewFn5NibUkWJItadCa+YnSaMmEdXMs+ZYi8f6DYim1VFiq gWmps+jFBYsJ1rVa9BanxWsJWCKWfthnpmW3ZchywHIYzp95SFwZNeg76xvx miRBUZAUKEqSSZ4mKpIDRU0+D4UnxVAeIiVQYkgplHWkgryKT5e/DqMOfe9y A/kL0kDiSBOUeBh3DGQTMUFJIA7ixDcuvfiupR+fKO8lyTAevUs2k29BeYz8 Fyip5L+SI+Rx8n0oT5DjUNLJD6A8Sf4nlAzyQyhPkb8nF+D4LkPJwv8N+xky TX5BsskvoeSQ30D5HPktlFxyh/wrHPtd8n/Jc2QZyvMMy6hJARMDY18xPj/+ RRj74kgJPj9eyqQyT5CXmCeZJ8kr+L5nBYyGdfhGZwOpZL7K6MhrjJ7Rk9fx WfIafLvzDUZkRFLLdDAd5E3GxbhJHdPDhEg9jJ0Rsh1Gz6+Rv2C+zvSTrzCD zCD5Kr7d2QQj6RmiZUaYEdLCjDI/JgbmIvMPxMj8I/OPxMT8lBkj7dh/BRgF sojIZ/PZpAOfzrPxz/H5xI5P5Dn4Yr6YOPlSvpS48E0iNz5/18nr+GbSxbfw LaQbftsbZAn7fiFNljCfAowARgEXAWMrmFzBNGCGvGMeMY+aL5rHzJPmafOM ec58y7xgXgK+L7ACDyVWSBCShTQhU8gR8oUioVSoEKqFOmGb0CjoBZNgFZyC VwgIEaFf2C0MCQeEw1CGhRPCaeGscF64JIwLU8JVYVa4IdwW7gh3hWVxp6gU Y8Q4MVFMEdPFLDFXLBCLxTIolWKNWC9uh9IkGkSzaBPdok8MQRkQ94j76P8g qtKr2mES/GpsE+YrvPr/rX+/AWUD9vI47OUbsZdvwl6egL38YezlidjLk7CX J2Mv34y9PAV7eSr28sexl6dhL0/HXv4k9vIM7OVPYS/PxF7+NPbyZ8gYlGzs 689iX8/Bvp6Lff3z2NfzsK8/h339eezrL0BfZ0kh9u8XsX9/gXmMSYV+T3t2 CfbsLdizS/H9iJewN5dhb34Ze3M59uZXoDf3wD3gZ/xwD9C3JF7D3lyFvbma +Svmr+B+oH26Bt+PeAN7cy325jpmDPpxPTPOjJO3+Lf5t8lWvoFvIG/z7Xw7 fV87LhC3C34nDVz7dYSxN0G/ywcUAUoBFStt1YA6wDZAI21TbjQX2AuFyT8N XGdamjIX20vMZfZyYeaToG3mSnuVMAe4JV2lMNfYa4WFPw26jrnevtW83d4g LH0M+m9zk10n3LfrRFaaNRvsRpH/08B1YqUbZrNdFBPsotlmlxBuu0dMBqRJ VqxnSrfFHOmO2WeXzSF7WMz/GPjvIumuead9l1j6Z1AhLYvVDqV5wD6I2GPf a95n3y/WRUHr9NzEbR8Dz/Wg/ZDYaD9EPxFH7EdF/Z8HXc98zH7cfNJ+SjR9 EuYz9pEH+10L8zn7qGj9GOYL9oufBbYm9z7zZfuYecI++UdxxT5NYTO4D1KY r9lnPhOu2+fMN+23PoV5+wKFzewYMC/alz4LbDb3EfM9+30KgUgsgpN4Cpvb fYx+dlhdw4JO0gsaKVaIlxL+EDaf+6SQJCX/OdhC7jO4j1QpDZEhZQrZUs4n kCflfwqFUtEnUCKVfmaUSxVClVT9KdRKdcJWadun0CA1fgL0vD8DRKcjRjBK JkGUrH8UsEz0OuLEgCMR15Mk52eCR/IKshT4FOj+IoB+R4oQliKfBeJuR7qw S+pfxaC0exV0+RDggCML64cdueKwo0DYKw3h8f4BxBOOYqzvlw78OYinHWXi WUflJ/ZxSDr8CRyVhj8Fuu15R41wXDohXnLU4+e4Y/sfO57/EKek08KIdPZT GJXOCxelS5/CmDS+FuKUo+nB2L52LH4wVq6OcVcdhtUxaNZhXjuOrPaTtb/r g9/lwTW64bCtXtvbDvfaY8KxZCeMKXDv2waiY4BtT/T+xftqn5SM8wb0d9tB wBH3uQf92XYMPuF76PL/x973QEdVXXvfmbkzRIQRacqfGGhMEWMICAFpRAqU xpDMP5Ai8mgKY+be+SczGcjMgJRGoJGmlNLAh5QiIh+PYkyRIkUKMSDl8a95 NAJFQIq8fEgxhTTygBcoH4Zv7985E0KIS7ve9631rdWus/bvbvbdd99z9tl7 n3NuXOOMKyXzZtwoWTijpaQ8pJYs5fUl1LlkBct5bKFuJatDPUrWcX0NpZZs 5DoZSi/ZFMoo2cprQGhQyQ6u7RgzxXtoWMnuRH0OjSjZFxpTUsvjDuWVHGFf hBwlJ7h2sk3QxJIzoSkl50LTShpCWklTKFhyLRQpuRmKRxX2L9Yg9iX5MDSP 1km5noUW0voj/RwqJztLoxa2gXsrol1Cq6Pded1pXWvbzFGrTSa5piTWAu4T r42hddFe6NvGaN/EPEOfaz/NPdZlWvMwtk3RfiwLbaU1fIQgXq/Zv3eRQ6zL vF5hPab3JNZivoIofjC2dmss3kUU2jGzlInX2MS6mqDQ7pkVTK1rJK+Zcm1s u1betUbKdTJBoX20DtIcY+2j9TBUO7OaCXHL69xuQa01iyh0JJqJ64no4NCZ 6HDIqX6EzkVHhhqiY0NN0fzQtagLcs5hXks4bymPOJ9CN6OTwkp0KteisCXq Rl4k8kDWRcQW2eE6F+5CtUnmCOaL6hY/n6iB9+RWu7xqrS+J/pMNrpvh7lEv z3m4V3RG6/OsT/kW7hudFe4XncP9DmdGS8ODo2Wo4TweGkN4eHRxeGS0As99 Uf2R/QqPlXU8keOL2ujIPmOs7epx63i4Difo8971OfU0nC+vrllbeEyt1L5O tq2VXB8TNbJtTSRd2GEdvkc+CE8qcUS2xvdFdsRrmXhvw/ONfc3u+BHIqGaF j8WskX3xE4n9S6Q2fiZcFt2DOkb7jsiR+DnsKaimhTdHL4ZLo9WJPUHkRLwB NY3Xf943cK07E2/iNTpyLn4t0hC/Gd4TvRVpmq1Ers22RG7O7jJTmd19pmV2 r5ldZvfFnkzWSzzLezO5b8KeJ7FHYVvSBt+b2X12P66X3K/WvV1iH3btTg0G JfYwcu/Btng/NrPX7Eze78zsO3tw4nno03jwb/IX8oTGNrPf7OGQ8b4xQXKf eBe13wvKvd9dJP3afl/XSrwXS1D7fV1ij9bB3mxmpqAv3Jvx3qvt/ov3XIl9 V5s9FvcVz7KO9Mk9uUX5F54aXXlPXrmjaxJ7rLA3uj48I1rJtSihF54V3cxx HZ4T3YZ4StQB1uGco/jDdXH0QLgiehj8yuix8JroKaa2+RZeHz3LNSJcGT2P +NwWvXzPPoYoXB1tBlE8MiEPuW4diBlxPRxLSuQg50T4VCw5fDaW0pp/XIPO x9JQay7G+ocvx7LCzbFsXnsSxOPlMxbyj8YcvhXLKTbGRsE21Y/ipFguxin1 i60xW3FybEJxSmxycVqskGtRcf9YUXFWzF+cHQsX58SivP5hDeT6RHuC4lGx ucW5sflcj4ttsUU4s9BaWDwhtqR4cmx5cWFsFfuruCi2ttgf28DnhOJobAv7 qXhubDvrF8+P1RQviu0tXhI7xHtArv+J2ly8PFZXvCp2HET2eJ3h2C5eGzvN fi/eEKsvropd4Dgr3hJrRA2jeSzeHruCezWxG7CxN9bCtbz4UFwtrot3Lj4e 71Z8Ot6juD6eWnwhnl7cGM8ovhIfxP4tvhEfhjrG42+Jj+BrRI2P4XiIdI7n RbrFHZEe8YmR1PiU1vihPTjvPyLp8WmRjLgWGRQPQi5rbmRYPBIZEY9j/ihP ImPi8yJ58YURR7y8NVYT54DEGkV8ZGJ8KetEpsRXsEwxKgbrImuFovzzLyj/ QH9BaVSu3Pk7gNaszNBT9DS9v56lZ+s5+qhJqp6r2/QJhJP1Qq1ZND2NSS/S /dot0fSwHtXn6vP1RfoSfbm+Sl+rb9Cr9C2Tlurb9ZpJu/W9+iG9TrfKthx0 XD+tJ8tWr1/QG/Ur+g29xat6O3u7eXt4U73p3gzvIO8w7wjvGG+ebkw00nB4 J3qneKfpSaJ5NW/QGyG9OHrIPWJNvsfvozfwd/6uVRTbBf9XvoM6KTfGU3sQ 30G74zvoV/Ad9Kv4DtpD8StBpacyg1oKvoY+hK+hffA19Gv4GpqGr6EP42vo 1/E1tB++hj6Cr6GP4mtoBr6GPoavoZn4GjoAX0OzKOcOK4OUOmpD8DU0G19D h+Jr6BP4Gjpc+UT5i/IN5RK1Efgm+hS+iX4T30RH45voGHwT/Ra+iX7b0NfQ V8nFN9Gn8U00D99Ex+GbaD6+iRbgm6gN30Tt+CbqMPzA8JLiMiwwLFCewTfR ifgm+h18E30WX0MnU6b/VnnOsNOwU5mKb6LfxTfR7+Gb6HR1sfoTxY1fGixS d6g7FY3y+oDiVRvUvyh+yt9m8qVBmaOU3olVD43Yc8JzxnPO0+BponbNc5Mc b9G6aN21XlpfNK82Q5ulzdFKqZVpi7UKbaW2RluvVWqb0fppmdpgbbg2Em0s MF9zEU7Spmpubhw3xgEUNwNl3HTH+zlijDRHj1L0cKyo5P9sih6OFQtipRNF ytMUQ/zN/D6KjqkUQxwf9yM+uuA7eVca1wsUSRwN3SgWllE8cRx0pyjYSPHE EZCsvE3tq4iAHoiAnjT/+yhu+Xt4b5rzDynCeNYfwqyn4ht4H5r5i0pfzHGa oRvN8cOY3XTM69cxo/0M0w1u5RHM6KM0oxElwxCnGc3EV+4BhiU0i1mYxYGY xUH4pv244beGHcpgxZA0PGlkm/nIVB/0ZLZv2lxtvmewZ3iiaf09I2Ub275p izz5Hpdo2hLPJM8kbTlJ2jVtlbbWM5Wam5qXm7YB1xmeWYmmVXnm3Nu0LbAw x1MqW5lo2nbPYs9irYaw4t6m7fWs9KxpbetZV7ZK2Ta3b4HNgW2ebZ7qRPNe 9uyR7UD7Fqj2HE68K7DHc4zaepK0a/owT7PnFDV+31lu/gzNStfzeAJNb7rX uueAPw8WDiQ867koWuCA57LncqCSsPneFjhM47vV2lyasbUlidaBpw5pdZpV S25tx7UUtNN3PJFoWr2WpvVPNMz4BS2rXWskuqJlo+VQuyHlLbpKOKp1RC5P qd5Zy7236d00m95Dm6BN5qanaoWi6elamCRFWpGeoRW1sdPa9EGei5q/tYW1 aKIJ73vO0oxQfOsjELv5+hg9j2NMd7An9IkcH/oU4qZhtFm6pgfRoyDGKixx pBzDLB0OnAqcRTSch/cvwtONeoRyZzD5b7hnpB73VOrzyMtWfSH1r1xfSrHs 1ldQvM/RV2tGfR3FckVRub5Ry6H3LqU4KSPdTfpWfYfnlr5b36fXUo85/iv0 Ixilm2bskKdMP0EaLv2Mfo5scdZiRNAUucKzW+aZpDdQ/5tozNdIvpj0hlPW LdZvEjdYn+ZVPCO9Fm8Xb3dvL29fbz/k8iTRvJnewZyv3uHekdTGevMpW2eI jPW6vJPwNnqTd6qnzOvmnPSSZdKc4Z3lneMt9ZZ5VnoXy/zjDKz0VnhnUKxZ EW8pdHelZtNyvGu0FO96b6V3s1bo3UbzS7OlL/VWe/d4D5DnsrRc6tNKrc57 2HuMtE9RO6tle6sRgTxKzBXrUaOIYS95zxNd1HIphyu8zSSPem/5jN6zviQf vduX7Evxpfn6+7LI10FfNse7L8c3ypfrs/kmcIyTZzHnvsl6BkVbjq/QO8NX RM3vC2ujuNG9qC/bN5dGYNMm0535WqFvEccpYZFviW+5b5Vvrbefb4Pnoq9K 8/u2UDyGeWy+7b4aemcRRWiUxxe47NkWaPZrVBn2BG7R/Jyl8eRSvFQEjcEk qgKVQStVigPelb7GYLKnl6e6qNY3IZgSTOO8ppghbwX7B7OC2d7KYE5wFEUo V45mqmbsncpAdaBaaHgq/EeCuWSL6x0iGJqiylAEk61jQZtnZXCCZ3NwsueA ZiS9aurP5WAhcdt8hcEizx59hC/bPyLoD4aDUVRBWcmCcwOorL6cwLHAseD8 4CKqc+dFrQsuCS7H2+hNwVWei8G1XM0ILwfXBjcEq4Jb/D2CVNF9haJyoXYl BS4Ga4JLtMLgXu6Jby/NE8dOoe+Qr47jRzR9KfX7gO841yTfaZrjem0Czc4F iqssqgdZvkby9QbfFW2U74avxePyq36qO57z/m7+HkW1RbX+VJrBDRQ3lz1z /On+DP8g/zD/CP8Yrch7lv3u2abl+PP8Ds9l/0T/FO95/zTKnsVUYIJamN5/ ltbHC/4xlMFWqllFdCfij/vnaSn+hf5y/1L/Ck+pluRf7V/n3+g55t/k3+rf oVn9u8mq1b/PX+s5RZbP+o9Qn6zUlxP+M/5z/gZ/k/8a9fEw2U7yXCbNmwEl YPEsDnShatOdcslFcdOLnsmiWMkJ9KX4bQz082z2Z/gafY36Ul+956z3WCAz MDjQj/xgDAwPjAyM9R4O5AdcgUmBqQF3wBvI12x0neFtDswKzCHtUv9SX12g LLBYiwYqAisDawLr/UsDlbqG3dTAf54w/4FOmH4lgv+qoQf/32TclYrheaOS 7N5ArYraFmrbqdW4a6ZSc+91751+avop9yFqde46yI5TO02NZfXULlCj56Y0 TWlyN1K74uYzrNHqso6nd3TDiUbBicaIs4wJe14VZxkzTjEW7Hk74RSThFPM fTi53I+TSxfsea3Y8z6APW83nFkexGnlK4qhm9YtjDHhvzt0D1MMbgddR9B1 ovpg/kZ33pchm42um4i2fg7tEGQrFJS/+0vSPqLaDuiIIFuUrie+HNnm0/WM pHOSGgQVnBVX2yqitcQ3EV27l2xVdL35xWTbTlRDdhVJFqIudxPG1o4Kurej Xn8H9SXq1wFldmCXaXA7Gv7lyEV+LxhJNPZzKF+Q64SgAteXpElEUzsgtyAX zVuB98uRi+a2YIakWZLmCHI1iKuznq7HiEqJyu4lF8VAweIvJtc1aaNC0kqi Ne1ofQdU2Y42/x20jai6A9pDdKADOtyOjn05sl2g6yk38qNDonu2RqIrUu/8 l6SLRJc7oFPSZgtdm78c2VW63rpDNuMdatXpJq89iFLpXtKdd7Ule7p8v/WL yZ5BNOju523J7SilA+Jnh9E1ja4j5HVMx/35PLL1J8rqgLKJcjqgUXeTPa9N /W5bbxP1UtYxu8PdWl/sE913149EnLSdV+nvVh9NaePbaXf3qbWmtK0BiRyW ucVrRiLmx/dqF9PN4r5dIwoSRUSN4PXFPk/IeUz2hUTlor66eb6oTtpXEK0W a4B9nazvN0W828knifpspzXNvlWM175D+oFscr1kmyC2S/Npp7poJ9/ZqQ92 ttsg/Sv9yc9inUysYefa+JnsOBRhg+85aL1wdJH9aj9P7eaodU1JzFO5WBsd 3UXfHL3aPH9TjAX/3irXPvq3o6+UbWpDOzqg9uvykQ7oRJv1tc0a20pNbajd +tq6Xv531sm+7rvXwkz3nTWwzXrXWrOIHGPlldYth0vmGNUPB61JDlqDHLT+ OLxSTjnM6wfyNk/kk4PWGccsUYscc2ReyDxI1EWOLbbDdQ71KZEj5aJu8fOt NbB9brXLq0R9ac2tctn/Mjnni+88D33KNwetTY6Vot8OWpMcvAadlTWJx0Br kGOzfO6LalD7Ot6RTqLPHdTj1ntJd+hza90X1dO0u+meOtm2Vma3qZFt6iF0 06ROjvAB1+jxFD/jMwXx3obnm/c04wdLGcWKM5d4rmNy/zKe9kaOZlnHaE7H c2yViXrmZN+zv+SeYHy+rGW8/q+UdY7jj9bo8WRvPNlzUn/HU9yMJ3vjKc7G s02KsfGlsn4m6uVmuTdL7Jtm3amjsCVtoI9lol6iX+3rcLsa3LqHSdRhHifb 4nsUU+Mr2jy/WI5nuPAX9lw0tvErpWxkG8rvgNrvBd0dkPRr+31dK5W2ofb7 usQe7b+zN9vmvnv/tcd9Z9/Vdo/lls9Wt/FJ+9yi/HMcdt+TV45j7tY9loPz +qyoRa316ryIa8dFGU8JOes0y/jjK9UVp8w7J+WY0yqobb45k0WNcKaI+HT2 72AfQ+TMkpQtCHWQ7efI66g7Ocg54aS1zjmhTf6RnnOyyDcnrdHOIiK/WHsS hHpUJfzEY3aGiaLSNo3DOVeOU+o76UznXES0hGi5G7XIuYqIznDODURVYv1j Qp2kPYFzC9F2UY+dNSJOeS107iU6RFQn/XWc6LQ4JzgvCD85G4W+k9YO5w2i FrEH5PqfqM0uWgNcnQWxPawzFNuubsLvLtqDulJFnLnShR95Hl0Z8t4gaWOY qOUu2iO6aH/o4tpD+zEX7cNctK9y0X7KpQn/uoKyjtH4XRF5jYt4cNFeyEV7 IBetEa6ld+KHazfvB1y0F3LRXsi1TsplzXXRfsC1SdjnPHGRj1y0B3DtbhOr iXNAYo0i3rVP6LhqhYz/a4yue7vu/+d/jfGP9K1MzVT38V9UjbXKrxWlUxpR f6IsomyiHKJRba65RDaiCUSTiQqJioj8RGGiKNFcovlEi4iWEC0nWkW0lmgD UZWkLUTbiWqI9hIdIqojOk50mqie6IJ8Z+PnXK8Q3ZDE+i2KkqQKeVJnom6y b43ySmNI6kGUSpQu5K3XDKJBoq9Jw+6MOWkE0RiiPCKHsJM0UbwvaQrRNCJN yoNEEaK4sJs0j2ghUTnRUqIVRKuJ1hFtJNokr1vbXBP6O4h2y+s6+dzuNvf3 EdUSHSE6QXSG6NydK/snqYGo6e+4JnxxTfjx7yXMQVuaIIjtY77qpW5DO7op /rfziWvi+YTd+yxEXeR8k/y+7neu9/Ui6qv82p5vd9kn2afa3XYvaIZ9ln2O vdReZl9sr7CvtK+xr7dX2jfbt9mr7XvsB+yH7ceonbKftZ+3X7RftjfbbzmM jiSH1ZHsSAGlOfrj31nUsh05RKMcuQ6bY4Jjsr3CUWivdBQ5/I4wKOqY65jv WORY4ljuWOVY69jgqHJsoX9vd9Q49joOOeocxx2nHfWOC45GxxXHDUeLU3V2 dnZz9nCmOtOdGc5BzmHOEc4xzjyng++TfKJzinOaU3MGnRFn3DnPuRBU7lzq XNEhrXauc260z3Bukm0rtY74HdR2O/c5a4k/ItsJ5xnQOWoN1Jqc15w3XYrL Auri6k5rQu8Of3FBkb+4kIRfXOiMX1zogl9csOIXF7rhFxe64xcXkvGLCz3w iws98VsLva1p1iHKQ9ah1lxloNVj9SujrTOsM5WnrVHri4rdWmp9SXnGWmZ9 WfmOdZn1XeVZ6y7rbmW+9ZD1krIQv76w8f/jnhkM3Q0R/Pcq1fx/k0/PlkSV JX2UpFxJtjY8E2VN+mTJs16h5Isk+SVR1U2nqptOVTedqm76Iqm7ROqzbHmb f6+S17WSNrR5Z5X89xZlgK2W2hHbCdsZ2zlqDcBztiZq12w37YrdYu8imq3W 3t3ey97X3o+kmSTvax9sH247Zx9pH0s5iay0XaO8dNndNFcP4Jc2FPzGhhG/ sWGyZluzFdX6tDVPMVsLrE6lE35vo4t1urWI5iFgfUHpY51lLVHSrHOtP1DS rQutP1T6W2usNUqG9T3re8pj1kZro5L5/9i6oeW76rcJp1J0GFruB98Z/BDw Q8APVfMJh5mjkBdB/nPwSwizzW+Dzwcvnh0CfgKefZxwEOTD1DDs8LPZsF+o DmU0f5f/2yfzXOKT1bGM5hjhVui8zu/9DPxnu9CHhZC/AH4o+KHgh4neSpwL nAkdsvnZ/1IHENbLEQ3A3e+iVxip+iTGFUDP/cybToFPwl0FT70JSQjP2iF5 APxoPDsb1h5AT0YDzdAZDh0v4WDwg8FnqyMgD4IfDguQA4fibjbufkN9itH8 AnoyAprMDzVdgY7wwxJYq4E1novH1UrIBeYAJ0JHg83tsEneMD7DbzQONLsJ XzZTdhvj4EcDT5lnEZayjsEIfAX66KdRYTR5ofmK2UO4ETYfZInhJPOGq7i7 DPpPQ/9n4JNh7SqwHvo31X8nuVHdTzhRPc5vYd7wKSRe9SThSNZRmhkNNuDf gLsYTSZoFsDOs6xv+BgWKsG/hbvjoH8b+pngLwD3At+B/iW1mDQd5n8j/gbH rdFifo/4FpYbisy1hOdUigRjCusol8wLCP+L0XBBSghN2bCTAkzFszpwGbCn eht3nyf+fUbjGfA1wCPAV9RCniPLJeB2YBWwHNjE2KkXvWuYmEFovmzh31Ap Aj8a2FViFbAcyM/2hOY+3N0CySlISiFZJ+adecLtwCpgObAJyPoF0JyHpxSB 5l9wVIB/BT3fCL4auFFKqoDlwCZgLo1lj7kcUeRnxNtPAq/i2WUStwOrgOVA trAM3vgZ65hWAX+GPl8F1sNOPffZcMl8mPAa8JL5NWAEOB2ISDA3koWemK8b 0KwHXpS4ADGwl2MDkhZYaIGFFlhoQVScw91zkJyTkmpCE8bysHkfYuYwMAKc DjzKiEioFzHGPEUaWzsK/hLt6bkPJDGOkEhjMR7kKDWmQpIKSSqyO5UtE+4H ViMyN9EY54r4hOUK4DL5LOdFCWK+J/+fuOldrwEjwOnA/cBGINs8g2fPwBtH YO0I+FfAvy6RvVeLfj7Tia11FSgiDfxGgeZ3MbMRzCPfvQr+kuWb7GGB3CsF EjrTMqZAfgQzewSSrciR/sA0VKEhqG8vWzIIX4L8E9Sia+CX8wpi+DNqWldR D1nT0NnsI/wKqlkZsCe8sRk6WciFD8A/A6yUNZDWFwPsGzsxWo7y7Ft+wt4w o5aqbvaJZQfzlizmTQ2I7UrESTai9zCe2mHeys+qm9ErvhsU9dzClXMAI+Xm ceTUceQRZ8cj4Jfh7p/lGEvQHy+e/RX0fwU/o8KYG9g/jFSrGcV8DbTQ+miM Q78r+H3QL5XVowp1oJxXB+SgF/JXgA8CH8FbTgJvd8rn2ey0Ce/lu0/zLFPm Mp8skW0+IWvyWuJ7ISaPQpIGPG15iOcX9fZ1xPNzqNvbuIqajyEmj7CmOQOx l8QSmjuO4WSu54bDIovprEwrAublGHuY6kA1YqwaWSlwP/KlGrgfKwjX6hR+ lvz5Hp5agAxagDjkt8S4V6YCvmsqEFVFpb2KoQ9yfCye2mG5jvrA+jncW4pk llzgTKcI/4BXFvQ8W9afBdDkt2wALgPutTzKvOWnyNzxvMogc8/gbo1EkaHM T7IMwN1GSBrRf/bwcMtRrnXo7Wu8Ghr+gDUxBb39DPK34fM+4NMwlnO8UzJO UNl+nWolbODdo7E3I83XAlQVnrXVGONazjXTEKyDjzGa0lSSGH8Py69C8yos /wf4/wA/DvYPs+cJ2bINfQ4zKlvAXwQ+Z+6s8L6C7T+FmcqEhTqx/vI+ivYJ z6P6cYQvxu7lohrEKDjevo67q9Hzo3jXLlhL4ZGqf2RvmOET9TrmN87ru6kH WzN9wLz6FPg8jLcJo7iOWnEdmZiCfqLaG2u4h6ZhGPt9srfck3TwWSrtXQ0H MerfqrQbNIxB3w7hWUS7cYQ6g3McT03iPbBxkumvhCvUp8nyKMzjNlXj+DS+ SvxxWPtEIlt7HXaegM1sVSX8mJGiro/CuzLygKkT/PAGnpoFrEAMNKjsvc2w kAH8Oey4wMcw9tfg57EYYxBPfQI8Awywx2iXxaNYyLtW4u/jqMAaFIK1IvRz EuxYzCu5Asho5NG9i/7ctPRjNF8FfgDcBXk60MY1Qew5WdM4GDjCfBLrCPN5 YhcKO0eBB2HnIOwchJ0/Qd8LfS9LjBFIRkLiErtW5pVm7gnhB8BdkKeDZ/2u YmeLt+wSiH1UAewU8LPGZ8E/K3i2Q7gL8nRgH0hSET/Yb8Dmx7B2DVgJfAu4 SeUVcBxsjoPNcbA5DjbHweY4eGkcWzZlsqYpEx7YCwt7wb8D/h0eBXl1LfrP +BsxXuapb2thZy2eugoLLMlBP69LrEVmcR8mmh9HtvLsLFB5t7lHng74LfvV E8hZnA5YUxE7+fPY2/fGKSAf+HtY6w37zcATwE14dgowD8/ugPwT4GGVotSS zuOyVDGqQdZR68w7KdPxLsssM69ThfBVBB74G/St7FVLFfJ6CHp7FHHyMbBC nlNOYnYOICZPYtZOwjOIT84y8kB/nilzT8I1OBMZodkXmkfBl+HtI0W8YS7e ZInJhJkyQV4A/Y+B14GVwAPYyVdaLuAtLLnN80Lzy/wFiZhr8DtE5LCEIsGG GbRhxukcrZSZ/kjnSpf5fkYLnVs/e58z8bP3zTTLplexU6pln6hP8rqj6syb 3gb+D8greT+mvo6qCH3aG/O+6Gt41o590QvQ/B2fN9WDXKVNOD+anuXzstoN d3+Dp37J2OkhyHvAwi3gJui7ESelPBemd9i3prPgxwGHMqppPEdqOmKjHPrv IaI+ZDRvgM5QREUKa5p+jJn9K/gg7j6Gu70QLbmwIM6qm4D5eNdo7ApexwqY xx4zfYwVpBy1cR9WjQO8PzGtw450Kdag9dgfzoPkZexqmmBnN/A48APgh7Bz HlgHnI216UOsszsYzb8DXwrcierajDXoR7x/UwdgF/eh5LcDq4DlwCa+yycv 80X4vwCaXYBPWv6FUJzIcEI07ZRYBSwHsoW3oTkHT73DEkKWTGCJeRqiohB7 3dlAOzCCneEs7D/zcCbFDlbtj/h5F++Cpqmca6kKCSGPogGWH5G4HVgFLAeS NfNjfCa1vIeYOWjuQU/dD2vrgB4gzqdqMsb+IvjtErcDq4DluMvjepF9pe5i vlMfyy+AU9g+nlIlsn9wRjBtYj+YRmPXN0/ia8AIcDoQscQ7N0tnzPv3oJnH tdH8iPkg8Z+af0f4C8hPSIwApwP3Ax/neMPdA5AcgOTHvNc1/Zoz1PAD7KX7 Ar8JnI29ZRrOQU9i75qFXfFSRNRsROxS3gca82D5N+BfxOl1G/r2EeQfsR3V jv6fZYn6kMTXgBHgdCDn16PcK/VrfIa1vCFinjPCeB7W7geuww5hPvIoGfuH mYj/Nbj7ocTXgBHgdOB+6JA/1Yf5Lebf8XdFQtbZiad2gk+GB5rhpdPmKuRC X74rECfWC3xiVRtYYt7FPVG3g/8UvIo4UaE/z3wJsyCQT6/v8+mVvMFRUafO R984YhXwO9Hznbgrqugo4P3mZEKF58vc2/IM8etZbn4YkfwR8EVZS7ny1KCW LoPOYui/iYz7K/LoflTUHFTg1eDf5QpMcUVPmfdgXg7AJk6vpuWwHIK1AeC3 8/mXTrh8NwLNGsakXRzhSQpOWz+HZXwz6SSq/b/jdFOODL2IDHoH2fEEEKdj 01uw8AasKerL9FQN7PyW+6biO5WKEzHNBa+hOs7CJcyThSbgceR1E/A4srUJ eBy9/Q3xP8Ubd8BLt3gPYHoV1ekgUEXf3uUzsvqvwCijCV9OTLWWRbzeIYuX gX8H+q/j2Z8i08tZYvFzNbC8APnvoF8PfBa4ztLM2Gkqr3TQ+SVHTqeHwPcA DoW1W9BfgT535tVB7c7fqdTHzSmIH+aN3DdzI8++2h25M0+cNxEPm8yHOE5Y rn4sz9T8xbIKZ5wnkdfjeI3olI+5+wAz9RTzls7mrnT3BtasnXwipujlmpDL dzvlY2VZx9lE9aoauB91qRrIa6gN35EGQH4W8rOQfwr5ecg/hLwQ1j7CW8TJ ax5WxuPAnfxecz2PyILvsaatOHGvxxq3ivWN/8bna6py0+Hh6+gz16Un+axt 6Yqsb0J272YkTx5GnXkcPWGsw937sS+6n3c+VA8/Qy68horBd0uB5bJ68FMn UTfe43M36ayGfDX6j3pleYn47ejz0+pDhP+TUU2D/7dgpH/C7MSh85zUZElf nIN+z2NUH+QzsglflU3i1HYKp7ZDqMnfhx9SMe8DcS77BaKll5lqkSUJT13H DuHXfB43B1U6WahLUWPDeDaMZ5eAr+R3Gb+BNxZhXl7HqV/DiH6EE+5xZIQK yU/5VK4OQD+/C/3LeCN6ZS4DP4/P5qZi8EInBAvDgd/j/RLtGzkrd6o9eV1A Dz9BnIvT9LcQCeMw9sdNNTSuqWzHEgXOZVTXqW+hcnJGfJt58xzzHPSK/TkJ OuLvHbtQzcx811TCq5jZADvd4P+d6OEv+dxtOg3+Uz6tm4aAH8enddOvMJYH uCdmZJD6nNqbJGvR//mmTwlfMlEkqBf5rzyWf8We8Hk+rdPouD8P8ZndtBg2 SySyD7sCn+Nzunkn8F/4HGH63zx2Sw94wIYz+Dk85eZzuumr4Hfj7jX05y/o 4VbI/xN/y0hjz1gy8PZRwOkY7wzgcLm35FW1N546zCd34x/55G76EfzTG98P 69HD54E2zM6PMY92njWKXkLjW5Ckop+rcYpZBhwteJxQliHXluGks4xPVXSX TiLmR7Gj3gPNHwLfMb+Mesi8FWgXCAt2WLDDwjhoNuGsN4Al6gBITkKyWqUZ N+BZYz/gIpyXv4Pz8ndwCnsS57tf8FmJIoH0jX5ofog39sD+cyCsDeRn1Vzw CwRCsoCtEe6CPB3YBys7ecZ8FKMLqnQqNK2BzSdhX4xuFPD7fPak/mMUsDkA NgdgpE0YaRP7Sn2OLVtyzceAP+QogoUtAuGfIvD58MNoiwO+YhyP8/tpPr/T KBz87Us9ivc6kEF/goWrsObg1Yp7RZWH8VX1EcJp6kKSz0FFxXmZztd898fA VEhGqWXER1Tu20BIUG/VPpiLvwL/k9FUy2iuY1QHAhfws+ZBeMtXYbMAOAK4 AdbKha9g4VNgBjz8IjDEFa/TQfZAkgv+vIFz3wv4Sh9ivpMFq97zfNf8KDxc C81c8DrznQ6ytSQX70zMLTgPPolxidjIwSznYl7WgE+GhZHQ+RV/HzC52f9q CmZhC2LjYV7FTBd4dKa3wHcDXwqds8CBeCodmIzZ7MHPmtfzjJs3QD4Umm9g ln/MvPGvkDxpGQ5cwfEGzd48mxQnL6MGMh6BzU3gH0Gfk+HD77OcNG+gtzeQ ofhL/e03FYNiuv178G/x37KB2bffAP8YsJz/Si7vvglcD/254AX2Ai6DXDy7 GfxmWNsE/AiSj8Cfgg7Jjc/c5i+iA4EvA+PA0cBTwFJGg5FRuQZJNlBhNHnB vwLcCHxQ8vxXg5N49ioky4BP46mfgU/G3XrgTUjwFuNESD4FL+yPxNubgR/i 7t+Au2DNBJ0C4LOQfyx57kMlJG9BMg78bTyVCf4CcC/wHeAlaDrA3wBvAd8C 7AU815LJO0P0B/rKf7HEJDyTCkxhiQGjNjwHfB/yM+BrgEegI7z3TMu3yMIw MRfMG0cD1wLXiVkAnw1UgK8AN7bw7nSP8D9LDL8GXsXdP8DyKjE68D2F56HT Ap2HxVggqUevLoA/KsfyLYwriZ6di2fnsUSBfwwvQTO7xYVRrEbPV6O3q9E3 xmWQXAVeguRhRkXwqcAU4Hm8sT8wDTgE+AneJSJwOfg/A1NaxhJOAv8VzGyZ iEmWGzeDz2rh0/cH4EdAjqgwdmK0INIssxnVnbDwGXvAEmLeXIu53ig8c/tV /msj9H8iYgPWlqMP16HzN/jqGc5KyqleiH/GCjHLn13hjMNI4xKNwDTCnsDR wFLcLYW1UpaQP1meB3k2UJGYxusC+FcksqYL3j4pPZ+GWVgLZP5plpt+hrvX 8NQT6KGI8GsYEfxvOC1mBCN9XcQzeA062+ClY6J6sK/U4/CYyN9k8KnwzF7o 720Zw1+lwMdhJwb+NUYTsthUgAi8Ab8tw13MpqEP5JfYh4Zb6LMF3kvBiJLg pRZGiivB8xjhK8NPgCIOn5eYhmfXwg7rvw+bx3D3TSD8qVzGqC8CXwP+4fZX CD/DGDtD8jb4PuDTMGsTwNeh5w2425t5qhiVJBmDuyXA1bi7Fh5AtJuGgBeZ nsIeMz4GuciI3wNfhWUdFnRYPiG9xLyobIeR1/uQrZ9gFlBVDCo8/xTsiEpY B/zL7aHsSfC1ogZCczE0vy5qIN5yFHJknzofuXMQ/PXb46ifYh1Zj2rzAftK fQp8HuRNsHMdPCqh8T7gAGC6yFnoHAT+VlanJwixUhgOQWebyGggKoBxBbw0 CjrHgaJuIG6NWBfIq3SmMCH3DW8AZwFFrcgA/hwYgzwKfiwwiAh8EfI35VrA 8bxQ8uwBsXYUQh81xFgk1hTMpgX+7wVcBnwfWANEPTe8jfm6Df5d4E08e0TM F3h40vApeC/QBS81g++Ku7vAFwCfbWnmHkL+MWxWAN8CbpL5K97FkX8Qkd+M jHgWOA7yveBzoL8A1rDuGPbj7S2IDayMBlRyU29o7kK0gDc0/x/2vgQ8i2JZ u6Zr5uvkm/maCAEhIoZ9UTFAREREQVRAZImoyKasAgZECIuIgMgaEVFQkR0E RDY3FGUTEcIim4jssu87ISCGLLf7nfFcyfH/j+eee+/zP/9zHh7eqamurq6u rq6e6Zlvgmy8A/R88JuB9vMqRj80FxEVA3wdGQbXJ6Fi0OZnpCdh7Ze5k8wz JmjIzXkD/dVopQEzkYeTkEkWAFtDMhN52ENf/HUqNsir8YhtkxlqgFMD3quB rHIV/Aj8sDxAk3sZkvUCNBrmoHRBgPFYd5Lhw3jYafJSPEo3Ar9E3cbYY8zA Hn5R7DQWDX2hJb3g7Rrzdko1vJOTjb3l8uYtR2uLQTEXz3/X4N4TO1TWMdu8 mbMSd2R42iLqhFwz0/EEZ7OhxXeg0+1duFfFMy9zfU7NRRkzLmZHgivYnU3r 9ofmGsPQ4rx9yUSjQU63Z5PZX9KStM+g1Qm16hp05mJPIwSsaPc3cxMa5tj6 updbQkOWKQ01Ra0kYCLeT7gGjLLjzIjzK8ZjvNrIGFoMMr9wEckGuTvvhzYt SesMWiX8WuBsM2ifNah7YXAGv2l6AT11zK6CSPP1oLSZQWcwNFwD7gemAj9n s59TwaBYxubuPt7c14tr4OR3msNO8xaZZzi0zdC0z6CWN/Q6I+/UgJ541Epg 8/5eGR5vRp9nwLb5Zk8btT4HVgennJF3VqDW0cASU9oMnCncz2Qb8GsGaN4j sgNtM4yXYNtXhrYOwh4WlkEnw3z1BrQQwnCsFSg1byBXsQ7jjVnzVltjkarx TrPrIpaJt0zWFcON5WKWmdeGFsPEMI0DhHm6LYy89TYwySC/AJl3Bd51FGM0 3sUjNX4G+g7+CHo0bV2GJOqKh1H3LdAFoO2yiVLrAFrPFAXMXBYmKpqJwrAz xsS/wFN+EdKcWiKfmcuirJnLRt5qCGxikK4YZIaGutD2pChicqbYAp2GviqO mFUD9HxINoCGHNS9DfRx4HeW8fAi2HDaKqklK1pmh1PnRc3JssxT5mwrw6wF IsHkVTEIT+3Nl2XPWAeNPQatWqKQ4YivzcplHTNrLrAosKJBrU0jHQE9Bpjf 2g/J/Wamg95n9TOrCXRusWZqHGftNeuRsYROQMMVY4nIIjJvodsXDYZiQR8C HcHb6S7oe8D/BBytx54e0jrt5sA6wLMG+SRwgUHHAz/LoLCBb4JTDjKtDIZ2 QrICsAFKS4BuC7oZJI+DA76dalAWA10Wpd8CM8BBK/wD6A6gBwEbgzMY2Neg BWtFTZSuB30Q9oQg8zZwLkrXgP4M9DlgI+Az4KNHnI26vraNwNeBnYE/QzIR NPrF19HiS6BXw54dwNPgfAht7VGrGiQ3gF8c9ELQk+GTr0H3AU4Flket6VKv PqFb/NExtH0WmOuPkaEdD5ws0A/6YwTOO/5IGZpbAdsCu0Nba3+8UEv6owYa Pgld8EcN8guAx1FawqAsBs63sO0uSI4CdvH9g9YfgoUrfZ8Yjl4TDe17DH62 ZwBroEV427qEUnhSLIMGRJ0zDpgG+WnAbcDHgei17UfaZNg5APKloQE+dxRs QPyIMoi9aMgfhcw80A9A0o+x2kBlMGqeqRtVEHYyZB6FhsXAWPBvQa/LwTMb IP8uSjFH7O2oVQptwbc8zp938OFO1IVv7VRgWej5AjIJ0A9/ilqouwh8zDLH j9VOaMuficX82IOeTaAhKUai1hnIjAX6EQLvcQ8/ktFucfhqoUHrEjgT0ZYf h3cD7wM2Qd2toKtAQ2XgCeBv4A9DW+1APwE96JeD1p2qkBwNPeNBw/MC+cGe CewNfBIyfos/Af0IWYrSF4AYFy6CFl8EwvMSHPsyWuwHvp/TMAdtf3Zj5jr5 wMkPRGZgRAVDm/AzFbKKuAh51LVTgB8D54Dv50bQvAWctaD3o3XEFWPuiHTU QtQ5/mzye7QcMmHITwLHH/cV4CcB44CwmZEzQyOg07cKUWHvBWJO2YgNC5aH BqLWK5DPBI2ZaPcH7gIfY8rwv9MSfOQoG1nLRjwIZHW7I3AJ5DMQM4MQP36+ mgtELnIwj/h1cPzMeR51/THFuDNGKoRY4hZAzDUeA0T0ys0GoxAVDtYvB9Ee grcl+h5CqQ15Ro7ie4GNTOtE5h7Enp5jnhY1B9YBnjXIJ4ELDDoe+FkGhQ18 E5xykGllMLQTkhWADVBaAnRb0M0geRwc8O1Ug7IY6LIo/RaYAQ5a4R9AdwA9 CNgYnMHAvgYtWCtqonQ96IOwJwSZt4FzUboG9GegzwEbAZ8BHz3ibNT1tW0E vg7sDPwZkomg0S++jhZfAr0a9uwAngbnQ2hrj1rVILkB/OKgF4KeDJ98DboP cCqwPOregrq5kHkQ9Dso7Q66NfgSiL6ELgDvQukoYBfgQ6i1Eu0WhYW+5eiv PQNYA3XRa+sSStEjsQx1MfrOOGAa5KcBtwEfB/oW+iPu92sAsDQ0oO+Ogk6M oyiDGIiG/FHIzAP9ACT9sa4NRK0olEYVhJ0MmUehYTEwFqXvgkZk2tshUwqa 4RmG/fwFShOgB54RtcBfBD6i1/FjoBO0+RHux+om8CEjRoJzBqVjgRgdAT9w D+BEaPPH8W7gfcAmKN0KugpqVQaeAP4G/jDobAf6CeiB5Q5acapCcjT0jAcN XwnMLHsmsDfwScj4Lf4E9Md0KUpfAMKTXAQtvgiE9yQ49mW02A98Pxsgem1/ XiDmnXzg5AdiTjHGkaFN+HMc81FchDzq2inAj4FzwPezCmjeAs5a0PvROiKB EeEiHbUQJ44f836PlkMmDPlJ4PgjuwL8JGAcEDYzsk1oBHT6VmHc7b1AzAIb o2/B8tBA1HoF8pmgMXfs/sBd4GNMGf53WoKP2W0jEgQyod0RuAQyiGrbzyTn QfsjhdFk+D+ECOEWQMQ8jwEi9uRmxD/G2kE+dxCrIfhQokchlNqQZ+QHvtcg 7RW7yeyKbNalpfx9DB6tOXVx393R7DbwDOwk1EPpFPPbWI4376fxeOylCMMR p8AfbfjmBQsyv7YwnJYGnW0G7YrgZ6Bud5SeNBjqAbojsC60nfcl0W6zYDej FJk9CnNvOAWcocGOR0X8ts7sotTH/kkm9kNisTcyH/yZpq7YCk5HlL4HWkDD eWBv4Bz03TMoBsEDTc0OiUjDrkUi6ERebOoaGcrFfkWBYP9EIx0yMk5l6ElC rTrYIaluOFYBe5LmFwr2RuZjD2Q+9kM05ryTa/apGuduNrkXdDNzbyu2Gtp6 GHRzlNYBvRz0Lkj2Bx0FujpKv0et0+Dk97WBczjH3OnfAZn8qJUAbIvSHT6i NA50Jko/gIZS4M8CvyroCigNgX4e9HDfBkNbu30bUNrX0DlJuVd1JJQB53Mq onEP6CmG5ny4l881yDWB6eBkgh4PyQMGnW0GbQt8AZyP0iiDVgbo88AEyBNk RgMrAIegtDdsGAe6Leg5aPEMZPqBXofSZOgJQ/8q4MzAcmNJF3C+BmcZMBWI nnJdlCpwBuUsxV9hN5pX5JidwHho7hbYYPj7zBhxTYO0D3UXAsdAG3Y8xFFw mhoZu0yOeVftAZTWyvlIYw410PwYyFQyHHHRtxmaZxgbQreCs9zQ1hjwk3I+ M/Fp5O3VKN1hSnXfzeh40JwEfmHofAv235Kbqe0cDGuvwLY9ppbTHX05Dv40 RN0AU8uqirb6gS4BPQk5WXiCkGX8CUw1qK+mDB4EpyhkjoPOb5AfglWJGLU0 tNUXmjvCwoMGQzZ8W86PkNwnTdQZGZHfcMz3d3SGxCyzY0xfQoUhf9zQziOQ 8cBp7schvF0UrXjwTH7jMWsYet0sx+zNJsPCOaDDOU+bGMsxu50FgA3Rehq8 8TDotkbSykCtBNBXIZkGDWNAjwJ/B7yxEfwy4FxG6dvg7IG2t8F5AJIXDOqM g/Hy4xD2N0BfDsGGg4gEP5LHmV7ru4D98BLGHTgII5UB+RxoqIi2qqM0AfFz EPxqBnV+N+NSL5AxeBQxsA2at/r+D7xhLK+DvhyErwqBHwE2g2Ry0G4W5kUW Yi8dkeBLGr8VM7SO7XREspFpDRwDztOQjENbcZDcjFppkJkA/BqlDYP5W1n3 JQSbF6GPm8AvCvwW9nTyJdHfbn6vjaSOIuxaI6JCgVdnIKrhDeMZqxM0v4c8 sALeWxW0ZfRUxkgV8jMVap1HrVWQzEG0J0ByESIz1tChEpQPkbYUI27sn+TP 6GCOGG0tMUalgM/BwrNBxiuCtca0sjGYs+N16af+XDbadLZ8D1ZVRi0/rxrN Q7BLfJ7aI67amzU9t4mmn0LUnYYM8gD782gU6jYUPyDyl2I0TR9X+rkRkgPB bwrPjzOo89JS5AqTVfwRmQOMQmk8el0b/d0PHA3MguY6GK8HgSWA9QMZk+UG BONoMttYkzN1PCzFbPoIUZGFJ7lZiNUsxHMWxsLQ1+C3QcEqVgQc0+sJ6GkN fxVDzjmP0VlmUCKKJFYZPgnJ9kCscXTRxKG+Bv4FOTAdOdBkmKawszqiNAEx vBVRjVykJWdA0sh/An4yJOuCfgz8mbB8B+j54D+Ssx3YHbMv3VyTm1Zyxuce xnglmdmKMX0c/Srhr2s53+N5fUFjLSwfjL7EQzIpB9c8qFuUimmdccHIajp7 gdFMhO+8kW1+pxPsNBqkMPhhwycynJwW5i3rnObmTfgc/B4kJwy6EuhKoKuY 97RzEs279JrfHfy5oJ8174+ZN/M1vQb0edBnDW1+xaPrLjFfuQE/0bwNqPXM w7dZruD7NssMmt8REJnfuefEml9z5MSa34PkfB5KNl+5ka+Zr9wYOnu5oXMG h94yX7mRF43+0FGD8gLovUa/PAn6OmhfpgmwCiTbANub794Y27IP+jaH3of8 DNB+rdOwOQP8UuDHGJQPoncVgRfQ3yEoXQSU4N8Dydpo6yz4G6CzMjjV4Rmf k4nSFpBPRYsb4KVM4EC0XguSt6OukUwAnQC6cmgd+NdA3w49Pr8MLHkKdHnQ z0DPToNREjS+5BMVhdIW4IyEtm/MN3Cg4R5oqAS6Eugq5vfyWv5H0IWABVHr YdhcGTa3xShPRk+voBS2hWaD8yxwDTADpTdrvEt+AvpT6FwBehRkvgCOBX8R 6G2gLxsLzVc4tLUmDqvguTxn54KG38yT9JxK2aeMPdkYC/PkXXPSTWn2cuNJ n5MzEBgPRC1oqJS9GpKom41eZ08GfRQ6vwe9A/R5lCKisneDcwJ6zBs4RGFr RNRp4nYv90im2Od7dHiBBiS3SelGn5O+83siqXY86TuL3FwqSB6FqCiVpPxU ke6me+lBqk9PUyutowm9Qq9RO+pML1IvGh7IR0jSrVSKCtBdVFVrqUWPUTNq rVtNov40WGeOLtSdetMI/I1Bv46iKJ0zSlMsJdA9dB/V1tn5GXqWBD1Br9Lr 1IFeoJeoD42kQsT1GjeuS/WTGj0eT22bJj0WT+Oh5WZ8M/Q2nZvLaI2VqAY9 RI/S49ScniOmCtSUBtAQ6kjJ1IP6UirqRFM8lSWz0t1Pdagh3U5vgF+YYrQf ilMcldN6q1A1qkkPU11qRC2ojbb7DnqSBtJQep66Uk96mUYFFtxELpWgW6i8 1pBID9AjVI8aU0tqSw7dSU/RIBpGnagbpVA/8y3TdpV7tuOngK2BHYHdgL2B A9q1SU7hYcAxwAnAmcCFwK/btenZgVcB1wE3A7cD9wAPtmvXtTsfB2YYtAUw BlgMeAewevvkzs/bjwAbAJPad3uxq90M2BrYHtgF2B3YG9i/Y4827ezBwFHA 94DTgHOBi4ArtOI29jrgZuB24J7kbr262geBx4FngenAa8Acg46d/GK7ZCcM jAEWBhbThT2cUsAKwARgVWANYG1g3ReNnobApsDmwOeAHYHJwB4v9mjfzekL HAAc0t3wU4FjgO8BJwFnAOcAF/bUY+QsAi4BrgKuA24G7ujZuVtHZx/wMPAk 8DwwA5jZs2u77iEChoGxwGLAcsDKPXsmVArVANYBNgA2BbYEttdYOZQMTAH2 Bw4BjgKO01glNAk4EzgfuAi4DLhaY2JoI3AbcBdwP/Ao8HTPXm17hi4CrwKz DEoBjAKqnr2695SxwDhgPLAM8A5g5RTtSVkNWBNYB1gf2Bj4FNBcjQude2L/ iSPreX4LFf0vURY+HPp/R0dnDEdnUUlR/21nNs582tJZLy9G/iKyznMuvrn8 r1CWzt5/jvn/MgqMiNBazRl2e8z6YK4S/zLe9Jfx1r/DmL+M8bCUcbT+gKYH f+Spf4isV6pCVPifpG4GJfT6VOKfOpakUv/UsTSV+SeOll5J/zH+Y59YegX/ x5jvL2ElfbWRolf9cTSTFtFq2k5HKcOyrVirlJVo1bGaWu2tFGuINc6aaS2y VlvbraNWhrBFMdFA9BOpYoKYK5aIDWKPOC0yOcxxXIGrc31uzl24H6fyBJ6r 56BpK8qPWW6Y57xtnvNRec5H/+HczlMe0tN8F0nrD+fhxBvPvRk31ldXb9Qf 2/zG84J0o/6CsXnOy+SRr5vnvGWe8zz9KbjnxvNC5fKcN85z3vdG+4tOu7H8 1mU3npe+I895xT+c6/lXOiFP+WCcC50f8vs9LNvYP5bze27rmCukc1WZgLs1 OO4JjkeD48U/k66QGBxrBse6wbHpjVZUSL2xl7dXvfG8Ys6N8nc1u/G8Up5R qFw5z3linvOtec635Tk/m+f8/I3nVfL/Ico0UTU2z3nVG+WrVstznre8fp7z BnnOG944ivfW16i0Z9pZ71JHaxKybVv9j/RMHUeWE+PchLUiP4W8eirNq6tW q5VqleaErHPWOS130bpIlpVupZOwrlhXiFUtVYts9ZB6SK+bJh4EP8xmvITI LwpqjvkFkTL2cETXrKjPC+m7kR40idLoIGVasdqGKG1VrNeEhFfXS9JYz3tC o+ldjM7J8fpuIUHf89RQJ4lFjLbpFI5pSt9piYL6/AyOaWoHCX22S2Oa2qNx ne6ridA4KqEOaltX6tJDOKapw/q4Sp8fwTHtD5JHA8ljgeTxQPJEIPm7vY/B 3gaw93HY+3tJQ5Q0QknjP5aoDbBwIyzcDAt/L9mKkm0o2Y4SQVLof3qaucK8 uR0jYrRXC2qvsveI96j2+kq1kkLaplXaU0xmxbcYO0z6fzldf7Du1WB9ms/K RwOtOOtWGoS/ZznEam61pKFWstWVRuBvWKZaL1kp9IaVaqXSW9Z46wMaY12y LtE71lXrKo21rlvXaZwJDXpXhESI3hOe8Oh9cZO4icaLQqIQfSBuEbfQBFFS lKSJorwoT5NEgmhMk0WK6EUrRB/Rh1bq7N+PvhOvigG0SgwRQ2i1GC6G0xox ToyjNPG+eJ/WipliJ63jiI6aLE7kRMrh2lyHcrke17MET+bJFtsp9nTLdto5 7azKTgeng1XFed553kp0Ojudrbudnk5Pq6rTy+ll3eP0cfpY1ZyfQiOse8NP hNtYF8LDXcvK8WK8h8XLXgtvivgk0j7SRVyODIyMEplKqCiOUsVVcc6nSqqS HKNKq9J8kyqrynJ+VV6V5wLqdnU7x6o71Z1cUN2l7uJCqpKqxDerRJXIhVVV VZWLqGqqGsep6qo636JqqBpcVNVUNflW9aB6kIup2qo236bqqDocr+qqulxc tVatuYT5k8JcUnVUHbmU6qQ6cWnVVXXlMupF9SKXVS+pl7ic6qV6cXnVR/Xh Cupl9TLfrgaqgXyHek29xneqoWooV1Qj1Ai+S6WqVE5Qb6o3uZJ6S73FldU7 6h2uosapcZyo3lPv8d1qvBrPVdUENYHvUZPUJK6mpqgpfK+apqZxdTVDzeD7 1Ew1k2uo2Wo236/mqDlcU81Vc/kBNV/N5wfVQrWQa6nP1GdcW32hvuCH1Jfq S66jFqvF/LD6Rn3Dj6ilaik/qlaoFVxXfae+43rqe/U911dr1Bp+TK1Va7mB Wq/W8+PqB/UDN1Sb1CZupLaoLdxY/ah+5CbqJ/UTJ6mf1c/8hNqpdnJTtVvt 5ifVXrWXn1IH1AF+Wp1T57iZuqgu8jMqXaVzc5WhMriFuqp+5ZY6eNsgfxEy l2VlWpk6i+VauTp7OELfB2CeOZhnIcwzKeJEHEWJEqIERYtyohyFua7Obq7T 1mlLntPeaU8Rp6PTkZTTyelE+ZweTg+KcVKcFLrJ6e30pvwqXsVTAVVCldBz vJQqRQVVGVWGCqlyqhzdrCqoClRY3aHuoCKqoqpIcSpBJeA79VWoqLpb3U23 qnvUPVRM3avupdvUfeo+ilf3q/upuHpAPaCzlcm/JZF/S6lH1aNUWrVSraiM aqfaUVnVQXWgcup59TyVV8kqmSqobqob3a66q+50h0pRKXSn6q16U0XVV/Wl u9QANYAS1CA1iCqpIWoIVVbD1XCqokaqkZSoRqlRdLcarUZTVfW2epvuUWPV WKqm3lXv0r3qffU+VVcfqA/oPjVRTdT5erKaTPerqWoq1VTT1XR6QH2oPqQH 1Sw1i2qpj9RHVFt9rD6mh9Q8NY/qqAVqAT2sPlWf0iPqc/U5PaoWqUVUV32l vqJ66mv1NdVXS9QSekwtV8upAfLf48h/DXXuXE2NdO5Mo8Zqnc6eTdQGnW2T 1EadbZ9Qm3W2baq26iz7pNqms+xTarvOsk+rHXrNaKZ26TXjGbVHrxnN1X61 n1rgG/Et1QV1gVqpS+oStVaX1WV6Vl1RV7Dv5d9fWZSIXFtex5ZjtbJaaXYH qwNZ9mJ7MYlQdiibOKpmVE2dh/97ok/nwH9H37+jL4i+OERfBXO1ZXUO7f13 jP07xv6bYsxyuujr+RirhEjkR+xmVJSqU22qT0nUXN8vdNHX7/30lWUqvUMT aAbNpc9pCa2iDbSN9tBhOk3p+sqerJDlRfclju4ZnRL9Mo69ovvh2Dv6FRz7 RL+qjymaGoBjSvRAHHtFD8Kxd/RrOPaJfl0fe2m5ITimRA/FsVf0MBx7Rw/H sU/0SH3sreVScUyJfgPHXtGjcOwd/SaOfaLf0sc+Wm4MjinRb+PYK/odHHtH j8WxT3R/Erp0sMZe0SM09o4erbHPv+CRd9HzntHvBZ55P/DM+MAzHwSemRB4 ZmLgkUmBRyYHHpkaeGRa4JHpgUdmBB75MPDIrMAjswOPfBR4ZE7gkY8Dj8wL PDI/8MiCwCMLA498EnhknO5/z+gp8MhMeGTuv+iRzwKPfB545IvAI4sCj3wZ eGRx4JGvg1j5JvDMksAzSwPPLAs8szzwzIrAI98GHvku8MiqwCPfBx5ZHXhk TeCRtYFH1gUeWR94ZEPgkR8Cj3wKj3yFSFkJj6T9ix7ZFHhkc+CRLYFHtgYe +THwyE+BR7YHHvk58MiOwCM7A4/sDjyyJ/DI3iBW9gWe+SXwzP7AMwcCzxwM PHMo8MiRwCNHA48cCzxyPPDIicAjG+GRbfDILkTK4X/RI6cCj5wOPHIm8MjZ wCPnAo9cCDxyMfDIpcAj6YFHLgceuRJ45GrgkV8Dj1wLPPJb4JHrgUeyAo9k Bx7JCWIl1/dMmHzPhC3fM2HheybMgWdOwiPn4ZEMeCTTRIr5O43GbuymNaPy 1jYxlRtwI+7Iz3MXfoF7ci/uwy/zqzyCR3Iqv8Gj+E19F3yYj/BRPsbH+QSf 5FN8ms/wWT7H5/kCX+RLnM6XOYOvRKqav6NkbbW26gammF/n8mP8GAluyA2J uT13IJs7cWcKcQ/uQVGcwikUzb25t74S6Mt9yeX+3J88HsCvU4Qn8kQqwEt4 E8VG7o7cjV2GOArbxezb7Hi7uF3CLmmXskvbZeyypmfaoivYXfevV4oGexO3 mzJdx9+7tjj5bxLlAok7zN4UJ+sSsmNt8wWwcnY5cv9Qz2831i5oF7Jvtgvb Rew48+07Lfuf7QoqRfns/HYB27FDtrSj7Gg7bLu2Z0dsZeezY2yz32Xrvg3U Rpo6wr7frkmeXcuuRUqXVaXCPJvn8Hz+hFfzGk7jtbyO1/MG/oE38qY/87jZ LeNZPEtr/Mj8rpnn8Tzt74Ws86j23Pe6vcN85m/aZ2mpebp0CS/lZbycV/C3 vJK/41X8/Z+NMbTP5tla+xyeY97I5Pla+yess7O2cJPWbvphtFek2D/V+if9 gM8OBz4z9f5idKGeiQZdz+kmFtHrNISG0jAaTiNopJ7Xb9Ao/HXRt2gMva1n +VgaR+/Se/Q+jacP9JyfSJNoMk2hqTSNpusM8CHNpFk0mz6iOfSxzgfzaD4t oIX0CX1Kn+ns8AUtoi/pK1pMX9M3OlcspWW0nFbQt7SSvtOZ43taTWsojdbS Olqv88gPtJE20WbaQlvpR51VfqLt9DPtoJ20i3brHLOX9tEvtJ8O0EE6pDPO ETpKx+g4naCTdErnnzN0ls7RebpAF+mSzkaXKYOu0FX6la7Rb5RJ1ymLsimH cnUYW6KJSBJPiKbiSfGUeFo0E8+I5qKFaClaidbiWfGcaCPainaiveggOorn RSfRWXQRL4hk0VV0Ey+K7uIlMU3sErvFHrFX7BO/iP3igDgoDonD4og4Ko6J 4+KEOClOidPijDjLYXFOnGdXXBAXxSWRLi6LDHFFXBW/imviN5EprosskS1y RK5OQeZte2abHQ6x5CiO5iacxE9wU27Jrfg5bsNd+SUewkN5GA/nsfwBT+JP +TP+ghfx1/wNb+YtvJV/5G38E2/nn3kH7+RdvJv38F7ex7/wfj7AB/mQfZ9d w/zdVnu7/bO9w95p77J323vsvfY++xd7v33APmgfsg/bR+yj9jH7uH3CPmmf sk/bZ+yz9jn7vH3BvmhfstPty3aGfcW+av9qX7N/szPt63aWnW3n2LlOxMkv a8na8iFZRz4sH5GPyrqynqwvH5MN5OOyoWwkG8smMkk+IZvKJ+VT8mnZTD4j m8sWsqVsJVvLZ+Vzso1sK9vpfx30v+f1v86yi3xBJsuuspt8UXaXL8kesqdM kb1kb9lH9pUvy376X3/5qhwgB8pB8jU5WL4uh8ihcpgcLkfIkTJVviFHyTfl aPmWHCPflu/IsXKcfFe+J9+X4+UHcoKcKCfJyXKKnCqnyelyhvxQzpTz5Hy5 QC6Un8hP5Wfyc/mFXCS/lF+Zv/0qv5FL5FK5TC6XK+S3cqX8Tq6S38vVco1M k2vlOrlebpA/yI1yk9wst8it8ke5Tf4kt8uf5Q65U+6Su+UeuVfuk7/I/fKA PCgPycPyiDwqj8nj8oQ8KU/J0/KMPCvPyfPygrwoL8l0eU3+JjPldZkls2WO zI2iKEvOkrPlR3KO/FjOlZdlhrwir8pfw33DL4f7hV8J9w+/Gh4QHhgeFH4t PDj8enhIeGh4mPuK29991R3gDnQHua+5g93X3SHuMHe4O8Id6aa6b7ij3Dfd 0e5b7hh3gjvRneROdqe4U91p7nR3hvuhO9Od5c52P3LnuB+7c9157gJ3ofuJ +6n7mfu5+4W7yP3S/dZd6X7nrnK/d1e7a9w0d4P7g7vJ3exucbe6P7rb3J/c 7e7P7g53l3vIPeIec0+4p9wz7gX3knvZzXCvuFfdX91r7m9upnvdzXJz3FyP PMsTHnu253gh74h31DvmHfdOeCe9U95p74x31jvnnfcueBe9S166d9nL8K54 V71fvWveb16md93L8rK9HC83QhErIiIcsSNOJBSRkahIdCQccSNeJBJRkXyR mMhNkfyRApHYSMFIocjNkcKRIpG4yC2RopFbI8Uit0XiI8UjJSIlI6UipSNl IhMjkyKTI1MiUyPTItMjMyIfRmZGZkVmRz6KzMHTZ+ztY499oJgqdAbFzvl0 rq/X95/5cb2+7+Tm3IJ2c2t+lvZiNf2Fu3N32q9XvNfoAL/D79ARHs/j6ShW 9mNYt45j3TqBdesk1q1T/BUvptNYIc7a99rVLcIOvHDCTthKcGKcGKsS9tgr hw6FjlsnZYJMtM5jv/1yeHh4ohDhWeFvxc3h9eFrojJ23dtiv322Xu3TKZoK Uwm95jfUV0AT9AqwQmdn3YQ7lIRaD2o+KPOMJoYKUVF3rT7f6a7TuNtdr3Gv u/Fvsjs19R1F6euJwlRMXwFU8J8eubsN392r8Qf3F42b3AMat7jnTE1V0GhU hYxGdbPRCF3Z0Pr7M5pofbZGhTWuVe4NJflQEoOSm24oKYySIiiJQ4mgaD1q CXrsqgnz15LuE/eREI+IR4hFPVGPbNFINCInPDY8lkLhxeHFJMMXwxe1PuHM ET/+D62xN66w/3+vr/87K6xZQ//quvk/uWbml+1lR9lJvqJXILNyPqzXzAZY zZrolWk01slmeo00q6O/Nnb4i6ti/3+wHv79aviBXgf/cwX84+ry/9pq+LfV Tq+L4/X6/cdVsZa++jDXHv6Vh7nuaKyvPH4Lrjuu66uOZ/QVxxRcc0zVVxyZ Omqf0pH6rInL39dO0fXGddOL8W7y8nsFvFivoFfIu9kr7BXx4rxbvKLerV4x 7zYv3ivulfBKeqW80l4Zr6xXzivvVfjT1Xbon6+3KlqFlfuXVt35f7/uqnwq Rt30d6vvWnedux5r8MY/XYV36nV4t7vX/cU98Pt6rAqpm7Emn/s/rsrZf78u q8KqiIr7L63ON6zNXvb/wurc0BJWQX0rG2eVo1irsdWUSv5He98BFUWy9V+3 Z3oYeoYmDCBZkgEk9JBEBQOICQUVBEVEyYIgiIjiyqooqKyurhHFAChGzDlg dtecs2LOAbMoCny3y7C4z31v3/v/3/fOd847dahb3TN0961763d/t7qmm95z bwwREEuaQDzEE1dIgATiBgMgmbhDCgwnnjACZpC2MAfmkQjYCCdIFJPGpJMs JoPJIqOYkcxoMp4Zw4wjPzETmElkCjOZmUpm0Lvns5mZDKI9zfHnS5QSPbJA oi/RJ4slhhJ7skTiIHEmOyRqSVuym0b8szTin6PZ23lpsfQEecTqsrpgxL5l 34Ix+459ByZsFVsFpjLsLjCTTZBNAnPZZNk0sJbNkOVDI9kc2TxoIlsgWw7O slLZBmgh2yT7FdrKDspOQg/Zedl5iJBdkl2BvrJy2XWIQm5QDbGyWuQG2Roe Gi1gi4a3RivYKbeT28MeuYPcGfbJ1XI1/Cb3kHvAQXkzeTM4JN4/g8Py1vLW cETuI/eBo/J28nZwTN5R3hGOyzvLO8MJebA8GE7KQ+WhcEoeJg+D0/K+8mg4 I0+QJ8BFTUz74RIXxUXDZS6W6w9XuUQuHW5wGVwGPMY4WwBPMM7ugjcYZ99B jYJR9GY0FH0Uw5lI5QLlLWak1iStOcy+T+tbMBtdRe+49IG4z3s21dkDpDmR feYeDZHTuOHnJVjEehWyghIqxa2yz1tluFWORVxl0wSaoNc4gROGO0/wxGO2 h/YYXPzBn0ghH/LpKpuDJJI1YU1ZM9actWDrs5asFWvN2rC2bAO2IduIbcza sfZsE9aBdWSdWGdWYNWsC+sKZ+AsnIPzcAEuwiW4DFfgKpTDNbgON+Am3ILb cAfuwj24Dw/gITyCx/BEKpFKJW8llZJ3kveSKskHyUdJtaRGUvv/sk+KqkgZ OtMgpb9W0KVzP0ZYJMQMixR7rhFq6kDEdWnOWOTYq82RJ3ph4UhLLArSlvgR JfHHwpNQLNqkFwlDfhiBRY/EYFGR/lj0yWCSTgxIJhlO6pGRWIxxdDLEBLRB h5jiGDUh5mABFsSCro6pj+O1K7HE8RpGrOhdXWs6Um0gCZKILV0v0wCGQAZp CFmQhWN6AkwgdvATTCT2MAWmEAccwXOII47gjcQJdsMe4gy/wm9EDUfhKHGl 801udOR5UE7dic46RdBZp35f58L2f54Lc8SeMmfUjBoZowfjIf42jGmLjLET 0wkZY3emOzLGUCaUsMh7YokMGc8AZIzjuTwi5yZyU4iCW8wtITrcMq6U6HHn uQvEkLvEXSVG3HXuNnLpEYofiRVGj7HEVowMxA4jQxFpIuI4cUYcP0/UiN7l xB0R/DrxQAy/TZoijt8lnphb3SfNEMsfkuaI549JC8T0p2gjcf1XCyb8qy6H P+vihLpYfKNLM6YZflfUSMJ0xVxGSjViqUYy5HdhRIPqJUf2NohoUr04qpcW 1UuP6qXPreLWoEbruE3ElOpoSXW05u5zD0lD7jH3DPUSNXWimqqpph5UU0+M fyWYHyzBLKMV1dqPat0e49Jb4o9RqRozE1Gjjkzi57uv4q8cY6hGzqKO0J2O e/J1D6FzmQz0h9Zf9zEQDA64pf/1ezgCvtMXXowX9oXYI1JqY5b2i4z2iwbt FzntF03kvX0IR3tHQa2upH2kxfXiehEeM/MfiTZmX1PR9tO5AmKGOdgmYstt 4XYRD8zEnpGW3AvuHYlFDjGOJCNbmEKGIzsoJdkY+zeSGRjrL5F51PZbqO23 YgS/SbZRD9hOPWAH9YAy6gE7qQfsoh6wGyP7M7IHo/sLshcjfDXZh/FcRo4j xzEi55HXWJFryGXsyT1kJQpSgexCl7zAGG+CGQAiIWZIgwgRM0jiI84ykG7i ui0SpPhB6UeO4/+Yw2y6ylHyu0VIFO1XgXpd1zoWEX63CAkmLb/uY0hrevdc /+v3GCLh5nKL8My7uYPobe8Vov/iXppnf7oeK3olwuezM3gWk38FWfE/DSgO EYpDQHFIQnFISnGIpTgkozikQXFITnFIk+IQR3FIQXFISXGIpzikTXFIh+KQ HsUhFcUhfYpDBhSH6lEcEn9XvBc1UDIdJNuwJ/7RfRgGONDDq7QGe3CB5uAD naA7Xl0UJEIqZCB3yYbx8DNMx7MWwmIohXWwBXbCfjgMJ7FvrmI/PIAKeA1V CP4yRsnoMUaMBWPL2GPveoA9at8Y+8KRyjCMfqLsA82ojIDmVPaFFlT2Ay8q I8GbyihoSWU0tKIyBkeeKGOhDZVx0JbKBGhHZRJGVFGmQCCVc9h6opRuYo2o 3Mwai5L/IFeIklXJlaKULZJrUVkm56ncKdemslquQ2WNXJfKWrmeKJG9qKhs pQ30PIlgh0igjXGewS0HrMMw2ovcAfEAtUQfRB3VWPcDF6wjwRXrKEAegbq5 Yx0DHljHQlOs48BHXPsBvlgPAD+sk5AvMKhVB6xToSPWg6AT1mnQGes50AXr uRCAdQGrTxjU1wDrzaw48/FBjoZBTdGrUU8p1mVy5Buoo0xczSTXwLpGLse6 Vq5JGNQN2Y+8FbHDURWO8TYJ4+wIMpZMJNPJXLKIlJINZAfGsaPkLLmKmf8T HNuf7+ehJxmhr9uiLwngAV7oTR0gABEyDPWOQy2WY2/NwR5aQWUfKKUyAlZS 2RdWUdkPVlMZBWuojIa1VEbCOipjYD2VsbCByji5uShRRwtRopb1qSyTW1K5 U25FZbXcmsoauQ2VtXJbUaLGDahsBfOp/RZQyxVSyxVRyxVTyy2kNltEbVZC rbiYWm4JtdxSarlloj3k+rTHDWiPG9Ier0d73Ij2uDHtcRPa46a0x81ojwOR ahO6qltCsYLQkQ7a4k80xCf5BtA19Y2JC8bizzNRYEh9rR71ESPx3OJRwPhr q7/oSSL2Ip7MpL5Ca/EOGeggQhEwwJwGKBIxFF/EmGZEJkAPCIVe0BNCoD/X E6NP2Kd5YWYI8yMznpkhmSNZJlnHf+Sr+Rq+FvF1HjefW8AVckVcMbeQW4RY u4fby+3j9nMHuF+537iDfCXP8BJeyrO8jNfg5dx7ror7wH3kqrkarlaBsKf4 RTFVMU0xXTFDMVMxS5GvmK3YpNis2KLYqtim2K7YoShT7FRcVlxVXFPcUNxS 3FHcUzxQPFI8UVQoniteKjWUcqWmklMqlEqllpJXaiubKB2UjkonpbNSUKqV LkpXpZvSXemhbKr0VDZTNle2UHopvZUtla2UrZVtlD5KX2VbpR+v5LV4ntfj Vbw+/45/z1fxprwZL96DbEizPkIzPRaZgz/GtEQmCaN2OmZ0SiYLMzotuvqZ p/mbNs3KdOjcq65krWQt0ZOtlq0hKtlm2WZiIKuUVSJvw1yF1BNzFeQ317i7 xE7MWJDNjMfY3Rxz9o3EF7PtS6QzZtxXSBcauwNo7A6ksbsrjd3daOzuTmN3 EI3dwTR296CxO4TG7lAau3sqajBq91LqYKSOopE6i0bqUbwBRuoxqOc2EvZX LPqvWfDfYqcvFuJobxLam5q0H/VoP5rSfrSlmjtSzT2o5t2o5sGUo4R+yvxY +qY/bHci4ryuD7Go6/9/9OI/98dPvoNH0KWeQqinSKiFZdSePLWnNrWnDrWn LrWnHrWnitpTn9rTgNrTkNqzHrWnEbWnMbWnCdqtHjH9fPUKlq9z9Tzyzc8j Vhzz1E8J9VOgfspQP5V8/l8lq13nf42QlXxFgS8jnSIHHQXUk1nqyRrUk+Wf slh4AW/hw2c2oMsYMqaMDWMn6chGs7FsPJvADmaHsEN5K96Gb8A34u34Jrwj 78yreTfeg/fkm/NefEu+Ne/Dt+U78BF8DB/H9+eT+RR+ED+EH8pn8iP50XwO P57P4yfxk/mp/HR+Jp/Pz+Hn8vP5Qr6YX8Qv5pfyy/lSfhW/ll/Pb+Q381v5 7fxOfg+/jz/A/8Yf4o/wx/gT/Cn+DH+Ov8Bf4q/w1/mn/HP+Jf+af/vfVeX/ XXP5/2nNJUN0kPPHsSr+A8b8Vn9pTTmOREiUXa2zAlgurpX5vKrm766R+bqO Bo/BeDMRX3P2T3v8EYG+5LwMvCaVyNHdGU/8hi/uC2S6MSFMLyaciUGsSkXU yxLvaX2viPex6hY8yrfF82+LeNerbhHvkX23+P6htBPvoH1TAv+2iHfT6hbU 5U8KxoNvCur8ben1vYLx45uCvfRtiaDl9+2YP5R4LIl/UlK/VxQ13xaMWt8W 4z8U62/LZ/0+XS89wn/nJv5kbgLINYyfXhjrOyDLDqbPQfny9BPxSSh5ZAqZ idlPMVlKVmH+s43sJr9iBnSaXMT+E+i93n+29vyX6sB/pf7u/Men2RElipli 3kPaiLkAxjpDmj2I9zgA7DCPZjDaz8D2TJiF7XwQ3949HzMvBjbCM/EJsPAC 85WX9B0Yb+AttivhPY2ZH7D9EWqwXcuIbyBhGCn6HMvIsK3BiE9NVTCYfzNa 9H0eOgzm2Iweo49tA8YQ2/XE93NgXDXFthljhW1rBjM3xlZ88wfGWDts2zP2 2G7CNMG2A+NAxDeaOGLbiRHfxFPAFGB7LjMX2/OYedieL2lPn+LakUgknViV +Jw4FvVlTVg/8cmGbHsiYTuwkeJzutkEbCeKbwXGWD0U28PEJ0axOWwOtnPZ 3UR8w/EebO+VIzLLGcwiGXlDzQEENJM0kelpJmstI6C1XAuzXq0VWnuwvVfr ALZ/RaYKvAXyDAmyyVqa4SEqazPaDT79xplahiFRn3+Z+zsHAcpBgHIQqPML UqAcBCgHAcpBgHIQoL/7AMpBgHIQoBwEKAcBykGAchCgHOTTFTKUiQBlIkCZ CFAmApSJAGUiQJkIUCYClIkAZSJAmQhQJgKUiQBlIkCZCFAmApSJAGUiQJkI UCYClIkAZSJAmQhQJgKUiQBlIkCZCFAmApSJAGUiQJkIUCYClIkAZSJAmQhQ JgKUiQBlIkCZCFAmApSJAGUiQJkIUCYClIkAZSJAmQhQJgKUiQBlIkCZCFAm ApSJAGUiQJkIUCYClIkAZSJAmQhQJgKUiQBlIkCZCFAmApSJAGUiQJkIUCYC lIkAZSJAmQhQJgKUiQBlIkCZCFAmApSJAGUiX54P8vVpISYRKPXpXmISImSb dJdp2ud2yK3UAg2mMNvEF3e1YgDUCkFTxjbhJYwJS4RIGddEBlLIbsqAtDBI 6CY41NljVmwxyozezvEigSSKDCYpCKKxJB3/xNs7LQWrOgeT6jeuVbWf7+8z Z7J5/B3FiBS3pVpxZwuzDRyFbGmhkC0ZXyhhgGG4SOOj0+hlxwlaXy8SWLyc THp1kh5SmYrpEaRWCbrihlzFhUYO7p8wMD49ZaBaR+DFnRoqje6xMckpA2PU FoKZuIdTGXRJiE5LGZwSl27pm5KWmpIWmZ6A/2EjWImfS1QmdT+PibUMSogf iEe17OrbRrCop6VWqwW14CK4uri4h+Gmq6D+uimMHvNvuTYtQSF+rlBJuwR2 7f7l65I/+bqQDdZ1+0x8e1Q2wg3u55hsAFLRe2eWru3tXNmNuNoOG+uVMXc2 KF2ep7XMchp3IaBo7RJf58rY+eqbLmq/VRf22I61uuC0ceyPVe5ngswubOpm EXg8buvjzUqm2i585dJxbw9bbzi3Sz7kTV7q5OgLz/IsHk72tY0JOzMua0py i9KMY6EeWQ926ISU5j+f0Mcp5tfVDTUjLKINXnjvMpw8ezyzT9i8R9Gvvnba 0fObl7rr5RYUKbh703r/XBU8d88r474+k/QWmLeasrmRaoyxS7b5q0vjzlqt 8yrepBF4wXZ5xaQ36y9VvW8WuOThy9W9ur++2qbAWTc1uvzRteUvkq2kOkGu 29cFHrgZtK5NbPuBTd/ueFhg2OaXAU69hX2MBAfEwmwwxx4xFlTYl+YNpEqB k8nRqVlWQyIRzMWdPJJtfdPu/Ctd+827J+zTHe19dmbPrQuDBlIDmmuLL1yT YlQbJdQXt22kRoLhKP0jug8On95g2BMONXVyNTTc2nkOV18IEb9QXxoodBH8 CzsWts/165+entrc2Tk6Lckp+YsVnaJTkp1TBySIe51T01JihkSnD3ZGI6Mj ohuiB/YVPB1d1Y4u6IJO+CUh7Ms1A0gDhM5Cpy/bApPb8vMphg4d+r1TxKb9 3WOn/2HYSUTPKentkbQyoCBB73ZKHlOQMHRfUkxa4/GXvP2SHYx+ONvYWXWr V6LpXoXb5rzqR1unP9FQ30t8PUR6ZsnliOay+TrVy7TK5nbzTamNnz735okR z23XuB8d06fi8u4Uj467w7jQt4Nvzn91W965RUvno6ePVQRap1ZK6zOL/Qu2 TA4fz3tMT3LV2LJsZbfCk3uv/mytV7bvevaFkKLK8ucllqE6OvMqSnPTkwYV 7Hn+cm9qxJIryV2a9pzdJbP1Sbc+YQ1WxT82DWgnWzPRrv5Cncklrgtszr3b 2C7rRkV0/hT/luxS5zVG63stWt0m6Gc5q+Nof6i5rLOZ0zJ1t5CY0jlHS2fl 2+XNmjLu0bxNiFHbEKOKv2AUazyTYqnpHzFq6L8FB6yoo+HAN/r98+CE5FjH oPTI5NTfEUpo6uLuIri5qJuJCOWC+PRlUxi9/n8DoRoJDT5tWgz0TUjtH5tm 2TbIz9IvKKB5M7+mno6eHm4+joJrs7bqBoLNJ43MvqtRUGxaRkJ07D9EtDNH WgQVL2i7cPiKLiGDgvKGLm867UdoWb2CWRi0rPbUWusDZMr9IQMrjB6M5lUH LkaSnfULM1pItaQHpIVLP/oGyYqk0q2KqflMlOezs656lU28f3i20i80Z4bl ggvRbnOj2v28c9WNS/ObvV3Wo/rE/aH33FXPwh/s6jAt0MRXo6dn3sgc/aRH h076D88eeOSMQT+5/oTpS3u3an6olWVWsnNPk6zDeZ479u1t1v+iY08Tm6f2 OvIwy4nZJU9PzfKbmnN0X9Mx17XyRxw4s+nG7KCLw+Rv7tpYaUTlhiUmGFen vg9yG13ZQG2cO+6n3T3mVC/v7G5Q3fvhjEMrgvLt+jqU3GygHXPg5ZpGQ74g mib2CFsHvDJt7hdp7ezh0N/ILio7/vyrmx6eYd+AlY3bu0vd26VyT1t/yPiw vsmafe7rtYXgT2CFUCUgVBX65fr+U2D16WPRitSI6JUUqnrWgSoEKqFDHajy +mtQ9d0jp38PweXfQ6/2ezNG91aXp5zxmv1yeNKPs1RdHdh6pjpb2hZtnPg6 5ETZGqsNMcmRZhcrHjx+M7XCt9io7b6qqmcrN4WPnJXsv9H3Q6PIYfLgEWvf r87nNqTvX/7Asev+rJqsgKLZ5xs13rzq4vW1k8dY/3z8VebHSP3kXY+Pjl1z feH23uzmR8FvosyTGi2O9q+6XVS1/XrOzNiEoDWbBuXHNIwrO/AiPGrHL6+9 5/r7EK0Tnqx+w7Cr9qz/yMTZnhfLB88uPj6xq+38RY/ftMobdjR4dp8GcYva yBqv7rh/Q/fpT64xY2Jqupyt9S/+aDfqSkWrFV5PXccf3mXd72R4C+kabkN+ steS5oFzToGhblRemwxkV+wORK9FX9DLtaEJRS/1H9GrL4UFTnNqwwnTXjrE gLGhBG2hNhbqfbNT86up1I5Ck0/j2Pb3cdw9JQVBAm2XEJcQHZkea9lmSHr/ lLSE9EyKUoLg6ap2QVBydUGUcvm86SJu/icp3j+CmnVpvcKNhZhd5nP6WVr6 zM4ISmppej7l6JEXjwbUzDLUuXG9efoYk83OhS5Paq/t9QmwOZdGrriHchMO r7Ls+Pp5/9Iu/pNKyjL9BxW017hc3eD6vCHjTywf3HbkhdFXXpW99Fh0KNzv 6uqV3jca959lsqQkbXDIi3rT71S7T08rPJ/R12Ko35gcT8OTg3uz2+K7TypZ l+B82VhRMzXd7laGc3C5vtDr3elJUdVHDvVtp+66tZHqTmvhRJqdTmPr35oG eBe6eE85VuQpywkPCMlubM+6bPa/EBh9/7Rj1As/7/ulcvK2XdH8U70nNgx6 MHx5p5ftTjT18py/YWh4Sb35k47oTg7x2lOq2Vdy5gvURGCPhAna4tBTiUSI FSQo6mDPd3mQghInkTVBrqAn0/ycRRiAlKUHxnDwdR8jHqX6lDrgTMO8GTfz +7VYqk5Z7LXjoqNg/PVL+oxUacGRIDIEMw9f0uYbcONLs/u1Dmk0624D1Uf7 m1zQjF53FgldP4FbR6G94FfoW9gmt9VfB7evH6eha4uoRIEtuA6wdRDaCW3r AJvnPwNs4oDx/XTUv2VfDJBezVqObNhu9eOU1mtdNiY+5p0HLu1Y+bjvkKed Wzhe8F2pqDny0FG90OboiK75o6z6lHo7d95WvDRk7u3U7Vs2vMvc2DGtsuWj NiMP31TWSzhSMtfSsUrRdX/IMcfbnU7vSL2/VKtYUhJyY0uef+jLGT5zX7x6 VnE7t76b15aQOc+DbHLsF2WbTbs1XcP85a2AdxOLDj9QlfwScND09OS0GfaD kgtM3pk9Dzoff9S6Ntz8WPHEskbrMqND2hZ3O/b+4cKeIeUFjF9b576vL686 m+0y8OOiGao7jxPuLyt22HmwiQ4f+/PsK2+Kq/QaasZ6Tn8xvH6n7aduhjw4 OWymUfghd8O+5dPMO/7suHOlW1uzCh0DE9Kn3L231fH83zQrcviJgcm8KsB7 hF2HuWmnXiUd3vMkdWHo1NCs6ZMKTTtIwipPLIzn0ks8njo61zt4L62p3uuU tV7x2e+7r5vkahhrweeV61yLeZ1yvN3ZM/UeZu6XbjjzweF6/bz5pdwHVaPW K++8v7lsZLvtGv3ax/ZrHbDG50nA0/UZmRc5N81ks1Hq+rf44PK7RR/uttdZ GZNf29XQacQu1mr4rRltGiXsmzZ5xqFJFwusVmmFz31evCq3/xhlouP2jAHE fObKl4Y/vDUcY7t1/InEpe3VznOu3h7kfYH8GNX+1PHxh7YYVfFpk/Ys9F7N tE6sTSiYeUtnqc6Gpl3l5/d5C9kyDcTvZ1/w27C/G8Vvs/8EfgtNBTcBEdvd VRBZJpJMcdNVEDf/c/T3H6H3gqKktdevdJhqP2KAk/HNslu3D8zuZtN15fFy owBb7YpTS051XpkuWOo+1jgXPMOg43RTn6mr8sOFhpfJgAc/lD2ZoKFdyUsx lT1a/4ir7bh5L1/Hmzl8/OH+ePNH9wMWFu2xCTo8qcrvhObJiNUn1/hIi98v TpoWf6Hx1XZBa3JP3m3czqlRaW5gj+7KOxKHD4lTpggDx73qJcyr+vH8rPUP rGb9+O606pV8c1By9w1+UxZ0IJ3ax+k2sotbOuvOGdnoTsXvxy7Rba+vmb1g 7NMew2pgjnlXeQ7REdo93XzNpt32/Y7BC1ZbDGujHnq04HqLMdOKIpmN5lpr P1YWrIPj1v7Bte/ZfXstFV/QewX2yJK/h97fJYbfoLdOXfQW30MtjM7/BL6j pwijJ30ffouiF0X+290zWydzpWFRp8KSlZ0H93ytoXKK/T+D+n+JymJf68zK 2xcuaetR/nDDyqFXjmd26wJrndIH9U5WqlYc3/nD5C1OZ/WKJyZHbQlljgRY qrrOLh/e+lbo9tU955jdNIfc0u3DXv508kkLqLi1czLHHpzU4dbzIIPywBVT 79yflHhu1J5701/KnHMkD3+xt7VO/fD2451hs520KjVupe4wCpj38wAubcaW omZz4x0PdOMfRYW3Msz/ybLVLQ0Tl/dH1Z0y1N5N0hQHH6V61+Zwqut7ucif n1/YUu9xwE8jD7g3iVi46/GOLIXPD2eD0qwqhMPbh8WG94Z6nD5/+rJ+/huv rXE91zs633+fk3u0W8iDeanTk0qbdT77NnPXcqPhUXbPigvs3GRDTaIOeVsk 189+rvjNYfsJ3/V33z/J2nh70dJ09y0BBwbZ6DXMUHh1nzgorJ2v/o7169d0 iT+4wKd2VKbVqPkGQtwDH70Ik4Pzra1O+j5s8nD76w5HHc5edBnVuaF9B9u+ YY9Cni2+Nnve4eYpZaMbpct0KzKsdhVk72kUvGltoveEoozIDQOLVIt3LW// XC+lOs8laV3N9W4HJ9ociiubZz5OL4bxdlzda/KWO1Z3N645HL1hWDB7to1T 19Lpa0qGrVhfOHOIyaWp41RDrJ1dlsoHFvae2GBX4bOxh63OP7YIPDSnouON SohNmaDIOphw8N7AR0tmHVfb1fIHeodf7GJadLHKeX4rpx6GAw6pFlars6Wz hGzpNAZAGD3uP8iXv5mo/X2at3D0fpGlfXZbTYlaWXcOGc/7+5ZCzQt1PzUQ OeCXf5SqEYvgbKVjSCfubevTOQcO6M43651fsEOIqfMvSnWIEFxoP6ox6UIS SDRJIyl0GjqOpBNLEkwySSpuxeP+SGz1J5lFDUfZ/ukYTc9MTYlPi0ztn2n5 h1gizQaiqrzj5xC9af2GDWx5lHXVlVGair5DVbN+aB+5KmmkxljZscFXnKtu D7zxLGfT1sXP2npuMxrPvfmwrO+kV8HHhvYvaOzpqrdi7vKnWm/r350Qwz0x HrWm9enG3q7rjF7dOjYtd9XKtiuW3Rrovk5VplU6a+vp0KFWU+e1cti8c+8h 8sZi7Y5LVyr2uEmj20yM++15/T0ffMbeWR3eXfvh7rD9p3J+KbplcdBzdsU5 oXxK8LD49auZHvdarqgZXNVmdu+Ux9H88IGPVJUGBj3fdEk9083kkeHSmgOt s2drDXn2YNC1mUZVBkfeMS9+yp24OHRT5zlv4iJaRexmHCuehxZGu92ZfK7p wNTKswc6j/UoymbMhWymjnFl6myGw10y6ow5/7Hg/818nMZnVyzsIxjV9UPF 7zc8AM/49RNWrS1OlQnu6qaYk3q4Ion5oxtWqs1dS8ZNt9xdf5nbQ43Q5KdN d534AzaLDuK38WrcpfdPMy6am8Yl+gzovOc3S/7QxbHXBrxbIlny6LdWDlv3 bldN7XP16uojpi0XznL3fzJl0rA+591vP77QaEeZfZhwI4dbXvMhbsvqYS/k PQvHt8nNs3bZFrRRcXD9qtOTD/rvsEmdX75Q0mHNOQvfEZb3LhvM3NZRXp4Z Z28adO9Op/jB4/KPL94V1W/95ZZ3Na+uqkmfK9FaOu2HDPad/51Vby+9uTGz dsijVzM3FJbZ9oXbqw4PP5F5bPWv+bW2ecdslhHBX8h/cih9l1+706EmGiFN TB939876SdFs4eCSwI7L8gZe9MnJEhw/TvV9kshHGW97M7FHw0OXmqVdqXBV T9HWiIm4MPgIIf8Dw7dbig0KZW5kc3RyZWFtDQplbmRvYmoNCjE0NCAwIG9i ag0KPDwvVHlwZS9YUmVmL1NpemUgMTQ0L1dbIDEgNCAyXSAvUm9vdCAxIDAg Ui9JbmZvIDMyIDAgUi9JRFs8NjU0MjQ0MkU2MTA0NUM0RDk2NTI2QUIyNjJE MDZBRjU+PDY1NDI0NDJFNjEwNDVDNEQ5NjUyNkFCMjYyRDA2QUY1Pl0gL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzI5Pj4NCnN0cmVhbQ0KeJw10jkz g3EQgPF/3BFXHLkPN3EnJK4kboK4j7jFbcZnUJrxEbRmFBqtglalMsOgUCoM OqOO1z5ssb/Znd1iZ1YpLRIJnZaNSv1yCHeC7lLI+Bb0Z0LmiWC4F4pomhog Cl+COSRYfHAhWGOCLQI3gv1FcCzAg+D8FFz78Cq448CC5wBO4UnwPgu+W8F/ rFSSdlGVisMGbMI6/I1saQuBo/9KB0mQDCmQCmmQDhmgh23IBANkQTa0QQ4U gBFyIQ/ywQImKIQiMIMT7GAFGzigFIrBBW4ogSqogDIoh0qogxqoBg/Ughca oR4aoAkC0AI+aAY/tEI7dEAn7EAQQhCGLuiGHuiFPuiHARiEIdiFCAzDCIxC FMZgHCZgEqZgGmZgFuZgHvYgBguwCEuwDCuwCmva0wbP5dnDS8LbtfC+Jnxc waNSP/5DRoINCmVuZHN0cmVhbQ0KZW5kb2JqDQp4cmVmDQowIDE0NQ0KMDAw MDAwMDAzMyA2NTUzNSBmDQowMDAwMDAwMDE3IDAwMDAwIG4NCjAwMDAwMDAx MjUgMDAwMDAgbg0KMDAwMDAwMDIwOCAwMDAwMCBuDQowMDAwMDAwNDM4IDAw MDAwIG4NCjAwMDAwMDIyOTMgMDAwMDAgbg0KMDAwMDAwMjQ2OCAwMDAwMCBu DQowMDAwMDAyNzEyIDAwMDAwIG4NCjAwMDAwMDMwMjcgMDAwMDAgbg0KMDAw MDAwNTU0MCAwMDAwMCBuDQowMDAwMDA1Njc4IDAwMDAwIG4NCjAwMDAwMDU3 MDggMDAwMDAgbg0KMDAwMDAwNTg3NSAwMDAwMCBuDQowMDAwMDA1OTQ5IDAw MDAwIG4NCjAwMDAwMDYxOTQgMDAwMDAgbg0KMDAwMDAwNjMxNyAwMDAwMCBu DQowMDAwMDA2NDg3IDAwMDAwIG4NCjAwMDAwMDY3MjggMDAwMDAgbg0KMDAw MDAwNjg1MiAwMDAwMCBuDQowMDAwMDA3MTMyIDAwMDAwIG4NCjAwMDAwMDcy NTYgMDAwMDAgbg0KMDAwMDAwNzM4MCAwMDAwMCBuDQowMDAwMDA3NjYwIDAw MDAwIG4NCjAwMDAwMDc3ODQgMDAwMDAgbg0KMDAwMDAwNzkwOCAwMDAwMCBu DQowMDAwMDA4MDMyIDAwMDAwIG4NCjAwMDAwMDgxNTYgMDAwMDAgbg0KMDAw MDAxMDYwMyAwMDAwMCBuDQowMDAwMDEwNjU3IDAwMDAwIG4NCjAwMDAwMTA3 MTEgMDAwMDAgbg0KMDAwMDAxMjc2MCAwMDAwMCBuDQowMDAwMDEzMDAyIDAw MDAwIG4NCjAwMDAwMTM3MDQgMDAwMDAgbg0KMDAwMDAwMDAzNCA2NTUzNSBm DQowMDAwMDAwMDM1IDY1NTM1IGYNCjAwMDAwMDAwMzYgNjU1MzUgZg0KMDAw MDAwMDAzNyA2NTUzNSBmDQowMDAwMDAwMDM4IDY1NTM1IGYNCjAwMDAwMDAw MzkgNjU1MzUgZg0KMDAwMDAwMDA0MCA2NTUzNSBmDQowMDAwMDAwMDQxIDY1 NTM1IGYNCjAwMDAwMDAwNDIgNjU1MzUgZg0KMDAwMDAwMDA0MyA2NTUzNSBm DQowMDAwMDAwMDQ0IDY1NTM1IGYNCjAwMDAwMDAwNDUgNjU1MzUgZg0KMDAw MDAwMDA0NiA2NTUzNSBmDQowMDAwMDAwMDQ3IDY1NTM1IGYNCjAwMDAwMDAw NDggNjU1MzUgZg0KMDAwMDAwMDA0OSA2NTUzNSBmDQowMDAwMDAwMDUwIDY1 NTM1IGYNCjAwMDAwMDAwNTEgNjU1MzUgZg0KMDAwMDAwMDA1MiA2NTUzNSBm DQowMDAwMDAwMDUzIDY1NTM1IGYNCjAwMDAwMDAwNTQgNjU1MzUgZg0KMDAw MDAwMDA1NSA2NTUzNSBmDQowMDAwMDAwMDU2IDY1NTM1IGYNCjAwMDAwMDAw NTcgNjU1MzUgZg0KMDAwMDAwMDA1OCA2NTUzNSBmDQowMDAwMDAwMDU5IDY1 NTM1IGYNCjAwMDAwMDAwNjAgNjU1MzUgZg0KMDAwMDAwMDA2MSA2NTUzNSBm DQowMDAwMDAwMDYyIDY1NTM1IGYNCjAwMDAwMDAwNjMgNjU1MzUgZg0KMDAw MDAwMDA2NCA2NTUzNSBmDQowMDAwMDAwMDY1IDY1NTM1IGYNCjAwMDAwMDAw NjYgNjU1MzUgZg0KMDAwMDAwMDA2NyA2NTUzNSBmDQowMDAwMDAwMDY4IDY1 NTM1IGYNCjAwMDAwMDAwNjkgNjU1MzUgZg0KMDAwMDAwMDA3MCA2NTUzNSBm DQowMDAwMDAwMDcxIDY1NTM1IGYNCjAwMDAwMDAwNzIgNjU1MzUgZg0KMDAw MDAwMDA3MyA2NTUzNSBmDQowMDAwMDAwMDc0IDY1NTM1IGYNCjAwMDAwMDAw NzUgNjU1MzUgZg0KMDAwMDAwMDA3NiA2NTUzNSBmDQowMDAwMDAwMDc3IDY1 NTM1IGYNCjAwMDAwMDAwNzggNjU1MzUgZg0KMDAwMDAwMDA3OSA2NTUzNSBm DQowMDAwMDAwMDgwIDY1NTM1IGYNCjAwMDAwMDAwODEgNjU1MzUgZg0KMDAw MDAwMDA4MiA2NTUzNSBmDQowMDAwMDAwMDgzIDY1NTM1IGYNCjAwMDAwMDAw ODQgNjU1MzUgZg0KMDAwMDAwMDA4NSA2NTUzNSBmDQowMDAwMDAwMDg2IDY1 NTM1IGYNCjAwMDAwMDAwODcgNjU1MzUgZg0KMDAwMDAwMDA4OCA2NTUzNSBm DQowMDAwMDAwMDg5IDY1NTM1IGYNCjAwMDAwMDAwOTAgNjU1MzUgZg0KMDAw MDAwMDA5MSA2NTUzNSBmDQowMDAwMDAwMDkyIDY1NTM1IGYNCjAwMDAwMDAw OTMgNjU1MzUgZg0KMDAwMDAwMDA5NCA2NTUzNSBmDQowMDAwMDAwMDk1IDY1 NTM1IGYNCjAwMDAwMDAwOTYgNjU1MzUgZg0KMDAwMDAwMDA5NyA2NTUzNSBm DQowMDAwMDAwMDk4IDY1NTM1IGYNCjAwMDAwMDAwOTkgNjU1MzUgZg0KMDAw MDAwMDEwMCA2NTUzNSBmDQowMDAwMDAwMTAxIDY1NTM1IGYNCjAwMDAwMDAx MDIgNjU1MzUgZg0KMDAwMDAwMDEwMyA2NTUzNSBmDQowMDAwMDAwMTA0IDY1 NTM1IGYNCjAwMDAwMDAxMDUgNjU1MzUgZg0KMDAwMDAwMDEwNiA2NTUzNSBm DQowMDAwMDAwMTA3IDY1NTM1IGYNCjAwMDAwMDAxMDggNjU1MzUgZg0KMDAw MDAwMDEwOSA2NTUzNSBmDQowMDAwMDAwMTEwIDY1NTM1IGYNCjAwMDAwMDAx MTEgNjU1MzUgZg0KMDAwMDAwMDExMiA2NTUzNSBmDQowMDAwMDAwMTEzIDY1 NTM1IGYNCjAwMDAwMDAxMTQgNjU1MzUgZg0KMDAwMDAwMDExNSA2NTUzNSBm DQowMDAwMDAwMTE2IDY1NTM1IGYNCjAwMDAwMDAxMTcgNjU1MzUgZg0KMDAw MDAwMDExOCA2NTUzNSBmDQowMDAwMDAwMTE5IDY1NTM1IGYNCjAwMDAwMDAx MjAgNjU1MzUgZg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAwMTIyIDY1 NTM1IGYNCjAwMDAwMDAxMjMgNjU1MzUgZg0KMDAwMDAwMDEyNCA2NTUzNSBm DQowMDAwMDAwMTI1IDY1NTM1IGYNCjAwMDAwMDAxMjYgNjU1MzUgZg0KMDAw MDAwMDEyNyA2NTUzNSBmDQowMDAwMDAwMTI4IDY1NTM1IGYNCjAwMDAwMDAx MjkgNjU1MzUgZg0KMDAwMDAwMDEzMCA2NTUzNSBmDQowMDAwMDAwMTMxIDY1 NTM1IGYNCjAwMDAwMDAxMzIgNjU1MzUgZg0KMDAwMDAwMDEzMyA2NTUzNSBm DQowMDAwMDAwMTM0IDY1NTM1IGYNCjAwMDAwMDAxMzUgNjU1MzUgZg0KMDAw MDAwMDEzNiA2NTUzNSBmDQowMDAwMDAwMTM3IDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAxNTUyOCAwMDAwMCBuDQowMDAwMDE1OTYyIDAw MDAwIG4NCjAwMDAwNTk1NzkgMDAwMDAgbg0KMDAwMDA1OTk5OCAwMDAwMCBu DQowMDAwMDYwMzQ2IDAwMDAwIG4NCjAwMDAwNjAzNzQgMDAwMDAgbg0KMDAw MDEzNzU1NyAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDE0NS9Sb290IDEg MCBSL0luZm8gMzIgMCBSL0lEWzw2NTQyNDQyRTYxMDQ1QzREOTY1MjZBQjI2 MkQwNkFGNT48NjU0MjQ0MkU2MTA0NUM0RDk2NTI2QUIyNjJEMDZBRjU+XSA+ Pg0Kc3RhcnR4cmVmDQoxMzgwODkNCiUlRU9GDQp4cmVmDQowIDANCnRyYWls ZXINCjw8L1NpemUgMTQ1L1Jvb3QgMSAwIFIvSW5mbyAzMiAwIFIvSURbPDY1 NDI0NDJFNjEwNDVDNEQ5NjUyNkFCMjYyRDA2QUY1Pjw2NTQyNDQyRTYxMDQ1 QzREOTY1MjZBQjI2MkQwNkFGNT5dIC9QcmV2IDEzODA4OS9YUmVmU3RtIDEz NzU1Nz4+DQpzdGFydHhyZWYNCjE0MTE0OQ0KJSVFT0Y= ---2005986409-377316027-1379102432=:61098-- From fielding@gbiv.com Fri Sep 13 13:26:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C5621E80AA for ; Fri, 13 Sep 2013 13:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=-3.954, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIMv6QDFN38T for ; Fri, 13 Sep 2013 13:26:32 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1F54211E80D5 for ; Fri, 13 Sep 2013 13:26:27 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id A99F44012242C; Fri, 13 Sep 2013 13:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=S9TqLXDE2XR9BU3uQghHB2Ecl8s=; b=UIwPbwk7pTGYKhTrj/s9q37SJHt2 aDMziHtxweDc+tO4iD++jEW0wZhOfbzGPxcNITaEdGOVHzoOufy7AhQ6COds7wlq xP41aetJIESgjDQl4aCXmz/busV8PESmnmoJU/dNA4y66NT+0gy8480kip5mdymo iItpBDagECUpZBY= Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 6F2CD4012241C; Fri, 13 Sep 2013 13:26:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> Date: Fri, 13 Sep 2013 13:26:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <826E49BC-8F03-43DA-9B19-62F5C999B5C1@gbiv.com> References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> To: Patrick Pelletier X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Fri, 13 Sep 2013 13:28:23 -0700 Cc: perpass@ietf.org, ietf-http-wg@w3.org, Stephen Farrell Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:26:37 -0000 One could argue a lot of things, but disabling the often-used and very useful User-Agent string (used by almost every site to avoid known bugs and incompatible implementation by both past and current browsers) is not going to happen. Among other things, it plays a role in CSRF security filters. Hiding the User-Agent field-value would not have any impact on browser fingerprinting. Common browsers do not send unique User-Agent strings (the TCP packeting is far more unique per user than the UA string); non-browser tools do, but they aren't a concern. Using an extremely uncommon browser will, of course, lead to more identifiable traces, but the same is true because of how it uniquely composes requests, how it buffers sends, and how it reacts to embedded subrequests. In any case, the primary source for fingerprinting information in browsers is the DOM interfaces, and I've seen very little to suggest that browser developers are willing to remove them. ....Roy On Sep 13, 2013, at 12:18 PM, Patrick Pelletier wrote: > Forwarding this idea along to httpbis as you (Stephen) suggested. = Although this could be retrofitted onto existing HTTP, not just httpbis, = since it's merely recommending practices which are already legal in = HTTP. >=20 > On Sep 13, 2013, at 5:17 AM, Stephen Farrell wrote: >=20 >> On 09/13/2013 04:12 AM, Patrick Pelletier wrote: >>> On 9/12/13 1:18 PM, Dave Crocker wrote: >>>=20 >>>> "privacy properties of IETF protocols and concrete ways in which >>>> those could be improved." >>>=20 >>> One obvious thing is the amount of (usually unnecessary) information >>> leaked by the User-Agent field in HTTP. >>>=20 >>> Should we downgrade the User-Agent field (section 14.43 of RFC 2616) >>> from a SHOULD to a MAY? >>=20 >> I think everyone finds those values problematic, and not only for >> privacy reasons. But yes, if you believe [1] then its probably the >> biggest contributor to browser fingerprinting that's in an IETF >> spec. (No idea if that site's evaluation is sound myself though.) >>=20 >> [1] https://panopticlick.eff.org/ >>=20 >>> Or, if that's too radical, should we standardize a small number of = fixed >>> strings to use in the User-Agent field? (For example, "Desktop/1.0" = for >>> desktop browsers, "Mobile/1.0" for mobile browsers, "Text/1.0" for = text >>> browsers like Lynx, "Batch/1.0" for non-interactive clients like = curl >>> which are performing a task more specific than crawling the web, and >>> "Robot/1.0" for clients which are crawling the web?) >>=20 >> Interesting. An IANA registry of those kinds of value might just end >> up like the UA string though, which also started out nice and simple. >=20 > I agree that things always start out simple and get messy. However, I = think there are some differences: >=20 > * The original User-Agent field was not designed with privacy in mind. = In fact, it was designed specifically to identify the product and = version the user is using. So, with a different goal (privacy first), = we will hopefully get different results. >=20 > * By specifying only a single product token, omitting comments, and = fixing the version number at 1.0, we've already eliminated a fair amount = of information. And then we further limit the information by making the = product name not the actual name of the software, but merely a generic = indication of the type of User-Agent; whatever is the minimal amount of = information necessary for any legitimate browser sniffing that needs to = occur. (Such as differentiating desktop and mobile clients.) >=20 > And, of course, using the simplified User-Agent strings was just one = of my two proposals. My other proposal, which was even simpler, though = perhaps more radical, was to downgrade the requirement on User-Agent = from SHOULD to MAY, and encourage browsers not to send User-Agent at = all. (We could even change it to a SHOULD NOT if we feel really = heavy-handed.) One could argue that by using other techniques such as = responsive layout, no browser sniffing should be necessary at all. >=20 >> Maybe ask this on httpbis if you don't get more feedback here? That's >> where you'd find folks who know if it could be done and who could do >> it. >=20 > --Patrick >=20 >=20 From dwm@xpasc.com Fri Sep 13 13:29:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306D011E8121 for ; Fri, 13 Sep 2013 13:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6T+EasMbAUl for ; Fri, 13 Sep 2013 13:29:07 -0700 (PDT) Received: from c2w3p-2.abacamail.com (c2w3p-2.abacamail.com [209.133.53.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDDD11E80D3 for ; Fri, 13 Sep 2013 13:29:07 -0700 (PDT) Received: from xpasc.com (h-68-164-244-188.snva.ca.megapath.net [68.164.244.188]) by c2w3p-2.abacamail.com (Postfix) with ESMTP id A3E6440573; Fri, 13 Sep 2013 20:29:00 +0000 (UTC) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id r8DKSvYj015791; Fri, 13 Sep 2013 13:28:59 -0700 Date: Fri, 13 Sep 2013 13:28:57 -0700 (PDT) From: David Morris To: Patrick Pelletier In-Reply-To: <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> Message-ID: References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> User-Agent: Alpine 2.01 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Milter-Version: master.87-g7939dec X-AV-Type: clean X-AV-Accuracy: exact X-Mailman-Approved-At: Fri, 13 Sep 2013 13:29:40 -0700 Cc: perpass@ietf.org, 'HTTP Working Group' , Stephen Farrell Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: 'HTTP Working Group' List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:29:12 -0000 I think you'll have a very hard time convincing web developers that they can solve the browser bug issues with this approach. The User-Agent string is an awful hack, but it has clasically allowed creativity on web sites which wouldn't be possible if the web sites were forced to conform to the LCD. In addition, I've noticed that some plug-ins add their version information to the UA String so that down stream processes will know about the specific features. Web developers need pretty specific knowledge about browsers and their enviornment. I would be hard to convince that any alternative mechanism which provided the platform target profile that web apps need wouldn't expose the user to the same or worse issues re. fingerprinting. On Fri, 13 Sep 2013, Patrick Pelletier wrote: > Forwarding this idea along to httpbis as you (Stephen) suggested. Although > this could be retrofitted onto existing HTTP, not just httpbis, since it's > merely recommending practices which are already legal in HTTP. > > On Sep 13, 2013, at 5:17 AM, Stephen Farrell wrote: > > > On 09/13/2013 04:12 AM, Patrick Pelletier wrote: > > > On 9/12/13 1:18 PM, Dave Crocker wrote: > > > > > > > "privacy properties of IETF protocols and concrete ways in which > > > > those could be improved." > > > > > > One obvious thing is the amount of (usually unnecessary) information > > > leaked by the User-Agent field in HTTP. > > > > > > Should we downgrade the User-Agent field (section 14.43 of RFC 2616) > > > from a SHOULD to a MAY? > > > > I think everyone finds those values problematic, and not only for > > privacy reasons. But yes, if you believe [1] then its probably the > > biggest contributor to browser fingerprinting that's in an IETF > > spec. (No idea if that site's evaluation is sound myself though.) > > > > [1] https://panopticlick.eff.org/ > > > > > Or, if that's too radical, should we standardize a small number of fixed > > > strings to use in the User-Agent field? (For example, "Desktop/1.0" for > > > desktop browsers, "Mobile/1.0" for mobile browsers, "Text/1.0" for text > > > browsers like Lynx, "Batch/1.0" for non-interactive clients like curl > > > which are performing a task more specific than crawling the web, and > > > "Robot/1.0" for clients which are crawling the web?) > > > > Interesting. An IANA registry of those kinds of value might just end > > up like the UA string though, which also started out nice and simple. > > I agree that things always start out simple and get messy. However, I think > there are some differences: > > * The original User-Agent field was not designed with privacy in mind. In > fact, it was designed specifically to identify the product and version the > user is using. So, with a different goal (privacy first), we will hopefully > get different results. > > * By specifying only a single product token, omitting comments, and fixing the > version number at 1.0, we've already eliminated a fair amount of information. > And then we further limit the information by making the product name not the > actual name of the software, but merely a generic indication of the type of > User-Agent; whatever is the minimal amount of information necessary for any > legitimate browser sniffing that needs to occur. (Such as differentiating > desktop and mobile clients.) > > And, of course, using the simplified User-Agent strings was just one of my two > proposals. My other proposal, which was even simpler, though perhaps more > radical, was to downgrade the requirement on User-Agent from SHOULD to MAY, > and encourage browsers not to send User-Agent at all. (We could even change > it to a SHOULD NOT if we feel really heavy-handed.) One could argue that by > using other techniques such as responsive layout, no browser sniffing should > be necessary at all. > > > Maybe ask this on httpbis if you don't get more feedback here? That's > > where you'd find folks who know if it could be done and who could do > > it. > > --Patrick > From malbrain@yahoo.com Fri Sep 13 13:40:28 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F276121E809C for ; Fri, 13 Sep 2013 13:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdNkDS5h6LgV for ; Fri, 13 Sep 2013 13:40:08 -0700 (PDT) Received: from nm8-vm0.bullet.mail.ne1.yahoo.com (nm8-vm0.bullet.mail.ne1.yahoo.com [98.138.91.23]) by ietfa.amsl.com (Postfix) with ESMTP id B16BC11E80D3 for ; Fri, 13 Sep 2013 13:40:07 -0700 (PDT) Received: from [98.138.90.48] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 20:40:05 -0000 Received: from [98.138.89.251] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 20:40:05 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 20:40:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 816779.16486.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 10261 invoked by uid 60001); 13 Sep 2013 20:40:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379104805; bh=awGWtpkx1le6kclCcCPrnZZTb5PN4TATlAuZB/MwDUg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=r+11mR/rzSvvQnhXDZYoLd6P4WqnPLucsUaagOXe6G+pNmnR8ibCXeIJ1cKS2djEBwUoOGQ7z0+kpRYdE5DqKLjoduOIQWbDyAPnjQwTnOhu7QgW4dSY4OBegxK2PpitcyLo3jwIepF6VIq95V6bfRZuekzhLp4HLidH2nL1dHg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pLbXmy04XB7qaju2HrtRVj+MLCRSFh482iDSV1JpGpvXwq+PLjSzfE4eF6XdPOqAC1Q1l7vGorQuFv3P9iTtU1R4YF2s9DskI5VGaokpit68Vmz9o3bqewc66Pg8z7owshJAqNGuxJ5B7MQvFbOhxhneCLWV2SsuBlMSQeEA7t0=; X-YMail-OSG: erpgQO8VM1muBsFn0Pe3rM.O9sb745ZK_FljdVTo3oaQge0 ajOpFgu2C9HFiuSh13hC.yHqYhLKKpmCz.aTsKJO1jeCFY3y..OGJ3Wa38Mj WRO8kvF6kW7QZ0epwAh3g2kCEp5rqyHGbqshIDIa_Hvz7YFFr8gXzLVZZHFI Y99RvSdNGKPTanUlHaPjXz3NM82zNCek7MsTBm2ckGhXvueUGfcvqYjNrKPO 2SuCgCSZXNsuriPMcquyN.bu2t7vP1ALivxc7dGQOMw_eW7mqKpvOcfdcuK6 _rccVzOLO39MwAhj1CE6QcKZKiwhOrdBoKRherHbXGl.tsev.s4ssT1a9SWX WXMHnkk3bZaD8fig2IIfee.XAWD.43_gTILh6t1yi_vi1EO99Zytz0Ni_7bG DsstiWSwL3pLaSXE2X8BQayCVIjfQls_mxJVo.XqWyr2S2MCywMxUlyLCK_M GOSG6LBPr1UnrWRbDGwIYQYzGrs_rQDTTJjfCeyBzPr476BL_Y.I3WuweS4f 8Phs2ohFngPHkgnbAVSGa5Tew_Ln64nOcDRbRxCe1OxdaraR1IxIvKZmPkS5 Y653ZVS25IqUiMDWt3_rDSF.pfM27Vg5bJw-- Received: from [206.169.92.130] by web125502.mail.ne1.yahoo.com via HTTP; Fri, 13 Sep 2013 13:40:04 PDT X-Rocket-MIMEInfo: 002.001, SSdtIG5vdCBmYW1pbGlhciB3aXRoIERBTkUuwqAgSXMgaXQgb3BlcmF0aW9uYWw_wqAgRG9lcyBpdCBpbmNsdWRlIGNoYW5nZXMgdG8gVExTIHRvIGFjY2VwdC9jb21wYXJlIHRoZSBzZXJ2ZXIncyBjZXJ0aWZpY2F0ZSBvYnRhaW5lZCBmcm9tIERBTkU_wqAgSWYgc28sIHRoZW4gdGhhdCBwYXJ0IG9mIHRoZSBwcm9wb3NhbCBjYW4gYmUgbW9vdGVkIGluIGZhdm9yIG9mIERBTkUuCsKgClllcywgaXQgd291bGQgYmUgc2ltcGxlciB0byBvZmZsb2FkIHRoZSBjZXJ0aWZpY2F0ZSBzb3VyY2luZyBtYW5hZ2VtZW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> Message-ID: <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 13:40:04 -0700 (PDT) From: Karl Malbrain To: Randy Bush In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1546730761-516841224-1379104804=:9549" Cc: Leif Johansson , "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:40:28 -0000 ---1546730761-516841224-1379104804=:9549 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm not familiar with DANE.=A0 Is it operational?=A0 Does it include change= s to TLS to accept/compare the server's certificate obtained from DANE?=A0 = If so, then that part of the proposal can be mooted in favor of DANE.=0A=A0= =0AYes, it would be simpler to offload the certificate sourcing management = to DNS.=A0 However, I'm proposing changes to be implemented entirely within= TLS, that are transparent on the client side.=A0 Only the server side woul= d require an additional interface to accept/reject client connections.=0A= =A0=0AKarl=0A =0A=0A________________________________=0A From: Randy Bush =0ATo: Karl Malbrain =0ACc: Leif Johansso= n =0ASent: Friday, September 13, 2013 1:24 PM=0ASubject: Re:= [perpass] proposed enhancement to TLS strong authentication protocol=0A = =0A=0A[ off lst ]=0A=0A> I've dropped the idea of including both client and= server public=0A> certificates in the directory in favor of a server certi= ficate only=0A> repository with=A0an additional TLS interface to authorize = access by=0A> clients.=0A=0Aso why is this a win over dane?=0A=0Arandy ---1546730761-516841224-1379104804=:9549 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not fa= miliar with DANE.  Is it operational?  Does it include changes to= TLS to accept/compare the server's certificate obtained from DANE?  I= f so, then that part of the proposal can be mooted in favor of DANE.=
 
Yes, it would be simpler to = offload the certificate sourcing management to DNS.  However, I'm prop= osing changes to be implemented entirely within TLS, that are transparent o= n the client side.  Only the server side would require an additional i= nterface to accept/reject client connections.
 
Karl

From: Randy Bush <randy@psg.com>
To: Karl Malbrain <malbrain@yahoo.com>
Cc: Leif Johansson <leifj@mnt= .se>
Sent: Friday,= September 13, 2013 1:24 PM
Subje= ct: Re: [perpass] proposed enhancement to TLS strong authenticat= ion protocol

=0A[ off= lst ]

> I've dropped the idea of including both client and serve= r public
> certificates in the directory in favor of a server certifi= cate only
> repository with an additional TLS interface to autho= rize access by
> clients.

so why is this a win over dane?
<= br>randy


---1546730761-516841224-1379104804=:9549-- From phk@phk.freebsd.dk Fri Sep 13 13:51:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C24111E80D7 for ; Fri, 13 Sep 2013 13:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.01 X-Spam-Level: * X-Spam-Status: No, score=1.01 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTk5PQLZ21-f for ; Fri, 13 Sep 2013 13:51:36 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD6911E80D5 for ; Fri, 13 Sep 2013 13:51:36 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4494C3EB62; Fri, 13 Sep 2013 20:51:33 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r8DKpUgl005908; Fri, 13 Sep 2013 20:51:30 GMT (envelope-from phk@phk.freebsd.dk) To: "Roy T. Fielding" In-reply-to: <826E49BC-8F03-43DA-9B19-62F5C999B5C1@gbiv.com> From: "Poul-Henning Kamp" References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> <826E49BC-8F03-43DA-9B19-62F5C999B5C1@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 13 Sep 2013 20:51:30 +0000 Message-ID: <5907.1379105490@critter.freebsd.dk> X-Mailman-Approved-At: Fri, 13 Sep 2013 13:56:09 -0700 Cc: perpass@ietf.org, Patrick Pelletier , ietf-http-wg@w3.org, Stephen Farrell Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:51:41 -0000 In message <826E49BC-8F03-43DA-9B19-62F5C999B5C1@gbiv.com>, "Roy T. Fielding" w rites: >One could argue a lot of things, but disabling the often-used >and very useful User-Agent string [...] How about making it intelligently usable instead ? Right now everybody wastes bandwidth claiming to be "Mozilla/5.0" with "Mozilla/4.0" being a distant second: root@phk:/usr/local/www/logs # grep -c Mozilla/4.0 thttpd.log 44445 root@phk:/usr/local/www/logs # grep -c Mozilla/5.0 thttpd.log 369977 root@phk:/usr/local/www/logs # wc -l thttpd.log 520850 thttpd.log with the result that those 12 bytes (incl the next SP) is just a total waste of bandwidth. HTTP/2.0 would be a great chance to stop this race to the bottom where everybody sticks everything they can think of into User-Agent in the hope that the dudes in the other end are incompetent enough to actually cater for broken browsers. If nothing else, putting a hard 32 byte limit on the string would be a BIG improvement, since that would force people to transmit only the necessary and useful information. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From martin.thomson@gmail.com Fri Sep 13 13:51:46 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFF121E8092 for ; Fri, 13 Sep 2013 13:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPBPn-Im2YCP for ; Fri, 13 Sep 2013 13:51:45 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5526811E80D7 for ; Fri, 13 Sep 2013 13:51:45 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id l18so1217454wgh.2 for ; Fri, 13 Sep 2013 13:51:44 -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; bh=bVoqO1m1TxThK+I8gzaEruqzAceKLf3G5V1s9UjrXkA=; b=aXtEr6WpGP0AZpC6qi4LAbp/4+IvoUvaTMW1JGs5jrGaGwTpFkWQxNy7z67VP8zgfD gmBZUO1NjS94TGnpDut2DeBb3ag6VeFry3tTB4OlWZ8WCgjgmF8WxC6bMzQ1OS3x7lZ7 XUc2RmDn3j8DA68dLQvnMCH4/g569X4+Fzc0Hlnqz39SpfpoaIJAbbLiV0yYpX6TF1LJ zUV65SWrM7qKp3hMJJZBJEFljNtqzRF112c1NtptpfhQnX+hyznOXJW603hCJn3O8J3U iqPmJgcGk6Cfapkta/1y5yP3GdcQhBQL2hSsU+tiIukKEmTVTtxyXFyZXn4pyjB/WOX0 YRcg== MIME-Version: 1.0 X-Received: by 10.180.82.164 with SMTP id j4mr3958006wiy.65.1379105504337; Fri, 13 Sep 2013 13:51:44 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Fri, 13 Sep 2013 13:51:44 -0700 (PDT) In-Reply-To: <826E49BC-8F03-43DA-9B19-62F5C999B5C1@gbiv.com> References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> <826E49BC-8F03-43DA-9B19-62F5C999B5C1@gbiv.com> Date: Fri, 13 Sep 2013 13:51:44 -0700 Message-ID: From: Martin Thomson To: "Roy T. Fielding" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 13 Sep 2013 13:56:09 -0700 Cc: perpass@ietf.org, Patrick Pelletier , HTTP Working Group , Stephen Farrell Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:51:46 -0000 On 13 September 2013 13:26, Roy T. Fielding wrote: > In any case, the primary source for fingerprinting information > in browsers is the DOM interfaces, and I've seen very little to > suggest that browser developers are willing to remove them. Speaking as someone actively involved in expanding the browser fingerprinting surface, the DOM is definitely where the worst fingerprinting problems exist. That's not to say that the right response is to throw our hands up and say "the Chinese are doing nothing about climate change, why should we suffer hardship?" Putting the fact that the premise is completely wrong aside for a moment, there are things that can be done. On the down side, we're not really the right group to do it. On the up side, the browsers - who are the right people - already are doing something. There aren't that many browsers in wide use. Most of those automatically update. The number of fingerprinting bits available from User-Agent if you use one of these browsers is actually very low. The value derived from those bits is simultaneously diminishing as more capability detection moves to the DOM. It may be that at some future point, the value of User-Agent diminishes to the point that browsers will cease sending it (or they will all send the same thing). At which point it contains zero bits of fingerprint entropy. For the moment, it's still very useful in some contexts, particularly mobile, so I suspect that it would very hard to go cold turkey. From karl@la-grange.net Fri Sep 13 13:50:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657B011E80D5 for ; Fri, 13 Sep 2013 13:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiR41mZ8MBEk for ; Fri, 13 Sep 2013 13:50:02 -0700 (PDT) Received: from nerval.la-grange.net (nerval.la-grange.net [128.30.54.58]) by ietfa.amsl.com (Postfix) with ESMTP id D4E2811E80D3 for ; Fri, 13 Sep 2013 13:50:01 -0700 (PDT) Received: from [127.0.0.1] (nerval.la-grange.net [128.30.54.58]) by nerval.la-grange.net (8.14.6/8.14.6) with ESMTP id r8DKkQ09081910; Fri, 13 Sep 2013 16:46:26 -0400 (EDT) (envelope-from karl@la-grange.net) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_676BC390-8560-480A-9E20-4A6AE74200E6"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Karl Dubost In-Reply-To: <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> Date: Fri, 13 Sep 2013 16:49:49 -0400 Message-Id: <93DFE1CD-38EB-488C-BFFA-15B2DD2EE821@la-grange.net> References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> To: Patrick Pelletier X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Fri, 13 Sep 2013 13:56:09 -0700 Cc: perpass@ietf.org, ietf-http-wg@w3.org, Stephen Farrell Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 20:51:48 -0000 --Apple-Mail=_676BC390-8560-480A-9E20-4A6AE74200E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Patrick Pelletier [2013-09-13T15:18]: > encourage browsers not to send User-Agent at all. It will not happen. This simple decision would break most of the Web. = (Unfortunately). My daily work is to fight against bad user agent = detection. It's so deep rooted in the Web infrastructure that even = simplifying it takes a lot of energy. Today I was going through the stats of a very high traffic web sites = that shared with me the list of all unique UA strings they collected on = 1 week.=20 cat access-ua-log-7days.txt | wc -l 386 844 Yes=85 each of these are different. Some of them are just the usual one, = such as=20 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 = Firefox/23.0" with million of occurences =46rom looking at the file I have, there are things which can be = improved though, some nasty things are done with some of the UA strings. = With two areas worse than others: * IE products such as 3rd party toolbars modifying the UA with a unique = ID per user. * some Mobile products with unique ID (most of the time put by = Operators) The spec could forbid it, but I guess it would be more a question of = legal matter. Operators are sometimes using these unique ID for = services. btw it's not only User-Agent, there are secondary things such as=20 X-Original-User-Agent X-Device-User-Agent Device-Stock-UA X-OperaMini-Phone-UA --=20 Karl Dubost http://www.la-grange.net/karl/ --Apple-Mail=_676BC390-8560-480A-9E20-4A6AE74200E6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSM3puAAoJEAmuD01odSZukdgH/j6VJAHJHJ2A441YUyj6fMLR PE9dlTaTc8TlaERvcsGIgmnWpuVoPYqsVWeOJvYxhOqVcLqoYSNIKpDvDURRsa2D mF0dgDMn5Nqg9ZNnB+i9KSRPhDQwD5mKIe2JBQx6/oMMuLt/1GjfNBfzH+AojVdv zjazayw3yCK4zx4CoAbLU6RqxwJ/zwYNQKkFMlhgr129coFFqeN/zKYczr+PQlOV TsQhfDV0y4Gf1oOh6ghcK1setrZniGZ+F9XTioJ7Mj519dGSH/XvwnO1vGcXBCHj I6WmSXlKndncNUNJjs/uJWEz7aS87IwOrjFWKIa3ybhp0qXTdyFEwmcp7qgAk9k= =ike+ -----END PGP SIGNATURE----- --Apple-Mail=_676BC390-8560-480A-9E20-4A6AE74200E6-- From leifj@mnt.se Fri Sep 13 14:06:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C339C11E8185 for ; Fri, 13 Sep 2013 14:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdHPENgu3bVX for ; Fri, 13 Sep 2013 14:06:05 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id A6BE721E8084 for ; Fri, 13 Sep 2013 14:05:58 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so2493322lbh.5 for ; Fri, 13 Sep 2013 14:05:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=gT/45XbSSZKwEpVcrFyhEBguB2QT0h7m+DN/R5rP+Rc=; b=V1JE9sVZUGF3mibbxuAJm+2HOmwo7g83Lxi0Z2rbk3Af82v14Y7JoGKpNmmg4yv5sk kVwZMAPYfSKifSQqgLf+TRvvuc+yBWqk+TzZmI8yJaZV/OZUDxy/WnVGvtSN/SxGos4H UtSgzDrwWEC6VFlxDZoUbAbf75eQZluzAs1Zow6UfW9VBMs61ZIBMagvcAsRfAKDkaIA A2eHBqpc76oK07AzuKlmwb78b2FfP9/8vWhMivWMvz2gycrx+BTNa/yC0Mv4AlMo0AR8 sWirxkfrRYZkCI5flnuWYGB6yq3FElCgF+RWhs/RfcpZm2rnlBm8DRgbNCdoYkKs/51r iV9g== X-Gm-Message-State: ALoCoQkRubtsgym5zM4MNw2HwYKyo3eQVjvFMTCvohb+C9TviG0ODtdhIGNKzJ3tzHXWesIpPJIf X-Received: by 10.152.36.98 with SMTP id p2mr12513441laj.14.1379106357412; Fri, 13 Sep 2013 14:05:57 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id b6sm5271783lae.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 14:05:56 -0700 (PDT) Message-ID: <52337E32.2050701@mnt.se> Date: Fri, 13 Sep 2013 23:05:54 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Karl Malbrain References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> In-Reply-To: <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> Content-Type: multipart/alternative; boundary="------------010402040902040800040509" Cc: Randy Bush , "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 21:06:12 -0000 This is a multi-part message in MIME format. --------------010402040902040800040509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/13/2013 10:40 PM, Karl Malbrain wrote: > I'm not familiar with DANE. Is it operational? Does it include > changes to TLS to accept/compare the server's certificate obtained > from DANE? If so, then that part of the proposal can be mooted in > favor of DANE. > The DNS is quite operational and nothing stops anyone from publishing TLSA records right this second. > Yes, it would be simpler to offload the certificate sourcing > management to DNS. However, I'm proposing changes to be implemented > entirely within TLS, that are transparent on the client side. Only > the server side would require an additional interface to accept/reject > client connections. There have been credible arguments from browser vendors against any scheme that involves an in-page-rendering lookup to an external service that takes more than a few milliseconds because of the adverse effect on usability. Granted, TLS is about much more than the web but its still a major use-case. I suspect that any scheme that will have any chance of success must involve pre-computing some form of proof on the server-side that can be stapled onto the TLS connection. Also you seem to focus on the client authenticating to the server which quite frankly could make the privacy story worse. > > Karl > > *From:* Randy Bush > *To:* Karl Malbrain > *Cc:* Leif Johansson > *Sent:* Friday, September 13, 2013 1:24 PM > *Subject:* Re: [perpass] proposed enhancement to TLS strong > authentication protocol > > [ off lst ] > > > I've dropped the idea of including both client and server public > > certificates in the directory in favor of a server certificate only > > repository with an additional TLS interface to authorize access by > > clients. > > so why is this a win over dane? > > randy > > --------------010402040902040800040509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/13/2013 10:40 PM, Karl Malbrain wrote:
I'm not familiar with DANE.  Is it operational?  Does it include changes to TLS to accept/compare the server's certificate obtained from DANE?  If so, then that part of the proposal can be mooted in favor of DANE.

The DNS is quite operational and nothing stops anyone from publishing TLSA records right this second.
Yes, it would be simpler to offload the certificate sourcing management to DNS.  However, I'm proposing changes to be implemented entirely within TLS, that are transparent on the client side.  Only the server side would require an additional interface to accept/reject client connections.
There have been credible arguments from browser vendors against any scheme that involves
an in-page-rendering lookup to an external service that takes more than a few milliseconds
because of the adverse effect on usability.

Granted, TLS is about much more than the web but its still a major use-case.

I suspect that any scheme that will have any chance of success must involve pre-computing
some form of proof on the server-side that can be stapled onto the TLS connection.

Also you seem to focus on the client authenticating to the server which quite frankly could make the
privacy story worse.
 
Karl

From: Randy Bush <randy@psg.com>
To: Karl Malbrain <malbrain@yahoo.com>
Cc: Leif Johansson <leifj@mnt.se>
Sent: Friday, September 13, 2013 1:24 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol

[ off lst ]

> I've dropped the idea of including both client and server public
> certificates in the directory in favor of a server certificate only
> repository with an additional TLS interface to authorize access by
> clients.

so why is this a win over dane?

randy



--------------010402040902040800040509-- From malbrain@yahoo.com Fri Sep 13 14:31:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F10B11E80AD for ; Fri, 13 Sep 2013 14:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50XfHXm6cMJD for ; Fri, 13 Sep 2013 14:31:00 -0700 (PDT) Received: from nm6-vm4.bullet.mail.ne1.yahoo.com (nm6-vm4.bullet.mail.ne1.yahoo.com [98.138.91.166]) by ietfa.amsl.com (Postfix) with ESMTP id AE0A321E80C5 for ; Fri, 13 Sep 2013 14:31:00 -0700 (PDT) Received: from [98.138.90.49] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 21:30:59 -0000 Received: from [98.138.86.157] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 21:30:59 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 21:30:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 200199.15015.bm@omp1015.mail.ne1.yahoo.com Received: (qmail 40569 invoked by uid 60001); 13 Sep 2013 21:30:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379107859; bh=LshwwsfeReYbnAXinwXRLMLpLMoWOHIMOjZxDlOqgkk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=p0YrbFoRZtOcSirqgbXPkYxCe842o1Scm6VhwO4nVxvF2lQnTR0tc5wtodBskcQU4fNrC8BwoP66nnGAUDB7eGA2kjeWdKZt24vRxwNUgTCF025MRoWmoPclBPImXZkXGjRHfZRsRx06WCjJd3VVD7kuAh/kYuq0UG2GcVGR4uo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=R8jju1h3iX81MLFr1dEQN/2qW015bgpSecITFl/+JmDgluKwVbPxjzqc8fNoBAlymAHXKboDcQDx85+GcbwE5D0xw9D1CLrM/6MVQoebhBUSLP9qZoD2pbunRRq9Zx1no2ucBkkZagH9FGjFc9archLHQXaZCjgi+cvSo3oKUvA=; X-YMail-OSG: CP891MgVM1nXtGVkvznppgE1M3DuppMM416VHg8d.c753PS B2iP2r5SEe2SJBbavMWDA6wp_A3WHh9FGm2EtHnoQIoh8fv9NX_wPds6jAq. 4l2yMyDoI9jG4ed4PyI1ceMuuQNdAqCw0FbusDzoCoPPWUvTxkO6Edj_A4ZJ OfAVGiWOpqpi.n4Y5LvjLx7JlW3G0TgmIj1DaHLbhUiTA1IfOCZ7SHdowpam ORpmPWMfly39_THJ4zM1.i4HWTCbXdBQxkY1V1NQWWBA8wjPbtrvh0BeD9EQ Zp4v0Fz.AD0oWaLqPSSZjY1Feq_eR2e4W69bIZ2OVyN4s46XM.N71kA4SOIO ueMp7PtHqtXu1BbL5oWJm5sqCHUt3qSmn97rn3QYpxwjlbpzhVOMUAHokTAP 3X8nBUMJf7uz5LhKg1xTNjKXlLr.XrGlQilutzORrCLFMqwSC0xQ8pDoNq1m iSxzvko4J625MPnVdfc1Il8R8CRNxfjSEE5uLwLWM1OjaOd53Qpp_.vx2R1i RGecv.P7011O3nbS3l2cPeDRpDl3k1NzBS3l7yvAPSrtG4yzYlVN3E7IwDn5 _EiRVzRu7JvZMACLiHi8YxfM4RqGgFVcPspuhYIQ- Received: from [206.169.92.130] by web125506.mail.ne1.yahoo.com via HTTP; Fri, 13 Sep 2013 14:30:59 PDT X-Rocket-MIMEInfo: 002.001, R3JlYXQgbmV3cy7CoCBUaGVuIGFsbCB0aGF0IGlzIG5lZWRlZCBpcyBhIHBvc3QgY29ubmVjdGlvbiBleGNoYW5nZSBjb21wYXJpc29uIGluIHRoZSBjbGllbnQgYmV0d2VlbiB0aGUgc2VydmVyIGNlcnRpZmljYXRlIHVzZWQgYnkgVExTIGFuZCB0aGUgb25lIG9idGFpbmVkIGZyb20gREFORS4KwqAKQXMgdG8gc2ltcGxlIEhUVFAgY29udGVudCBzZXJ2ZXJzLCB0aGUgdXNlIG9mIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gaW50ZXJmYWNlwqBpcyBvcHRpb25hbC7CoCBJZiB0aGVyZSBpcyBubyBpbnRlcmYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <52337E32.2050701@mnt.se> Message-ID: <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 14:30:59 -0700 (PDT) From: Karl Malbrain To: Leif Johansson In-Reply-To: <52337E32.2050701@mnt.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="264668936-1406299633-1379107859=:36612" Cc: "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 21:31:06 -0000 --264668936-1406299633-1379107859=:36612 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Great news.=A0 Then all that is needed is a post connection exchange compar= ison in the client between the server certificate used by TLS and the one o= btained from DANE.=0A=A0=0AAs to simple HTTP content servers, the use of th= e client authentication interface=A0is optional.=A0 If there is no interfac= e handler installed, the TLS package goes ahead and allows the connection.= =0A=A0=0ANote, for HTTP content servers that desire to authenticate client = connections as MITM free themselves, the in-page-rendering lookup is not to= an external source -- it's to the servers own account record where a secur= e hash of the client certificate is stored during account creation.=0A=A0= =0AHowever for servers that act as client agents over some domain, the serv= er will track whether the authenticated user certificate "owns" the account= or is an unrecognized user,=A0and preclude hacking the server by guessing = account names and passwords, etc.=0A=A0=0AYes, with DANE in place, this pro= posal is now entirely focused on authentication by the server of clients.= =0A=A0=0AKarl=0A=A0=0A=A0=0A =0A=0A________________________________=0A From= : Leif Johansson =0ATo: Karl Malbrain = =0ACc: Randy Bush ; "perpass@ietf.org" = =0ASent: Friday, September 13, 2013 2:05 PM=0ASubject: Re: [perpass] propos= ed enhancement to TLS strong authentication=09protocol=0A =0A=0A=0AOn 09/1= 3/2013 10:40 PM, Karl Malbrain wrote:=0A =0AI'm not familiar with DANE.=A0 = Is it operational?=A0 Does it include changes to TLS to accept/compare the = server's certificate obtained from DANE?=A0 If so, then that part of the pr= oposal can be mooted in favor of DANE. =0A> =0A> =0AThe DNS is quite opera= tional and nothing stops anyone from publishing TLSA records right this sec= ond.=0A=0AYes, it would be simpler to offload the certificate sourcing mana= gement to DNS.=A0 However, I'm proposing changes to be implemented entirely= within TLS, that are transparent on the client side.=A0 Only the server si= de would require an additional interface to accept/reject client connection= s. =0AThere have been credible arguments from browser vendors against any = scheme that involves=0Aan in-page-rendering lookup to an external service t= hat takes more=0A than a few milliseconds=0Abecause of the adverse effec= t on usability.=0A=0AGranted, TLS is about much more than the web but its s= till a major=0A use-case.=0A=0AI suspect that any scheme that will have = any chance of success must=0A involve pre-computing =0Asome form of proo= f on the server-side that can be stapled onto the=0A TLS connection. =0A= =0AAlso you seem to focus on the client authenticating to the server=0A = which quite frankly could make the=0Aprivacy story worse.=0A=0A=A0 =0A>Karl= =0A>=0A> =0A>From: Randy Bush mailto:randy@psg.com=0A>To: Karl Malbrain ma= ilto:malbrain@yahoo.com =0A>Cc: Leif Johansson mailto:leifj@mnt.se =0A>Sent= : Friday, September 13, 2013 1:24 PM=0A>Subject: Re: [perpass] proposed enh= ancement to TLS strong authentication protocol=0A> =0A>=0A>[ off lst ]=0A>= =0A>> I've dropped the idea of including both client and=0A se= rver public=0A>> certificates in the directory in favor of a server=0A = certificate only=0A>> repository with=A0an additional TLS interfac= e to=0A authorize access by=0A>> clients.=0A>=0A>so why is thi= s a win over dane?=0A>=0A>randy=0A>=0A>=0A> =0A =0A____________________= ___________________________=0Aperpass mailing list=0Aperpass@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/perpass --264668936-1406299633-1379107859=:36612 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Great news= .  Then all that is needed is a post connection exchange comparison in= the client between the server certificate used by TLS and the one obtained= from DANE.
 
As to simp= le HTTP content servers, the use of the client authentication interface&nbs= p;is optional.  If there is no interface handler installed, the TLS pa= ckage goes ahead and allows the connection.
&= nbsp;
Note, for HTTP content servers that desire to authent= icate client connections as MITM free themselves, the in-page-rendering loo= kup is not to an external source -- it's to the servers own account record = where a secure hash of the client certificate is stored during account crea= tion.
 
However for servers that act as client agents over some domain, the server will track = whether the authenticated user certificate "owns" the account or is an unre= cognized user, and preclude hacking the server by guessing account nam= es and passwords, etc.
 
Yes, with DANE in place, this proposal is now entirely focused on authenti= cation by the server of clients.
 
=
Karl
 
 

<= div style=3D"font-family: times new roman, new york, times, serif; font-siz= e: 12pt;">
From: Leif Johansson <leifj@mnt.se>
To: Karl Malbrain <malbrain@yahoo.com>
<= span style=3D"font-weight: bold;">Cc: Randy Bush <randy@psg.c= om>; "perpass@ietf.org" <perpass@ietf.org>
Sent: Friday, September 13, 2013 2:05 PM
= Subject: Re: [perpass] pr= oposed enhancement to TLS strong authentication=09protocol

=0A =0A=0A= =0A =0A
=0A
On 09= /13/2013 10:40 PM, Karl Malbrain=0A wrote:
=0A
=0A =0A
=0A
I'm not familiar with DANE.=   Is it operational?  Does=0A it include changes to TL= S to accept/compare the server's=0A certificate obtained from DA= NE?  If so, then that part of=0A the proposal can be mooted= in favor of DANE.
=0A

=0A =
=0A
=0A =0A The DNS is quite operation= al and nothing stops anyone from=0A publishing TLSA records right this s= econd.
=0A
=0A
=0A
Yes, i= t would be simpler to offload the certificate=0A sourcing manage= ment to DNS.  However, I'm proposing changes=0A to be imple= mented entirely within TLS, that are transparent=0A on the clien= t side.  Only the server side would require an=0A additiona= l interface to accept/reject client connections.
=0A =0A
=0A There have been credible arguments from browser= vendors against any=0A scheme that involves
=0A an in-page-render= ing lookup to an external service that takes more=0A than a few millisec= onds
=0A because of the adverse effect on usability.
=0A
= =0A Granted, TLS is about much more than the web but its still a major= =0A use-case.
=0A
=0A I suspect that any scheme that will h= ave any chance of success must=0A involve pre-computing
=0A some = form of proof on the server-side that can be stapled onto the=0A TLS con= nection.
=0A
=0A Also you seem to focus on the client authent= icating to the server=0A which quite frankly could make the
=0A pr= ivacy story worse.
=0A
=0A
=0A  
=0A
Karl
=0A =

=0A
=0A
=0A
= =0A
From: Randy=0A Bush = mail= to:randy@psg.com
=0A To: Karl=0A Malbrain mailto:malbrain@= yahoo.com
=0A = Cc: Leif=0A Johansson mailto:leifj@mnt.se
=0A= Sent:=0A = Friday, September 13, 2013 1:24 PM
=0A <= span style=3D"font-weight: bold;">Subject:=0A Re:= [perpass] proposed enhancement to TLS strong=0A authenticat= ion protocol
=0A
=0A

=0A [ off lst ]
=0A =
=0A > I've dropped the idea of including both = client and=0A server public
=0A > certifica= tes in the directory in favor of a server=0A certificate only<= br>=0A > repository with an additional TLS interface t= o=0A authorize access by
=0A > clients.
= =0A
=0A so why is this a win over dane?
= =0A
=0A randy
=0A
=0A =
=0A
=0A
=0A
=0A =
=0A =0A
=0A
=0A=0A

______= _________________________________________
perpass mailing list
perpass@i= etf.org
https://www.ietf.org/mailman/listinfo/perpass

--264668936-1406299633-1379107859=:36612-- From malbrain@yahoo.com Fri Sep 13 14:48:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92E21F9F01 for ; Fri, 13 Sep 2013 14:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiOvYRGbYLFs for ; Fri, 13 Sep 2013 14:48:35 -0700 (PDT) Received: from nm15-vm2.bullet.mail.ne1.yahoo.com (nm15-vm2.bullet.mail.ne1.yahoo.com [98.138.91.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB7A21F8E40 for ; Fri, 13 Sep 2013 14:48:35 -0700 (PDT) Received: from [98.138.90.57] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 21:48:33 -0000 Received: from [98.138.226.166] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 21:48:33 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 21:48:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 872915.90002.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 64044 invoked by uid 60001); 13 Sep 2013 21:48:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379108913; bh=UlPA8Rpc/oTGh9YY+5js6IMCDENDdEeYhp97XfPTPQ0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SdUFhDAUGM07QTgRjrz9fvA09HxOSZ0BsgWABWM79IbN5vrgPTaaQwkbC20QbyyxI0GunN9fLWXEiHOzVF99elBIyY6nkySeXEkT2tfitNDVRNRmbUYJBOyTIyMSpJFA7sebun6ptWIcaJYMOfht2gZeJg/DbUI9YZPzmlQUf7M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FXEat5yG1d/WxzVUjD9ddXYW0p97pPui8PLIb9kztUOUDzUGHsKA4BwXLBkLPYbzXLt6C2g9pzknilz0Q3/ZBqRUOal9XydlVJLnIc6p1ND045SFlMqOthl3dMYDq+NciUP5VOTJFQ9W+2lYLdA9S8O7ZkewAUH61YzZXcv0Y2U=; X-YMail-OSG: wsXRpO8VM1lRhye.efwk6RHH4P5YQZWGOH42OfRNbfa50.c f3sZ9faAHRFV1A4PcpD8n0TAOohanOHuf1X.5dBa5wJNyLAkWha6mKukgJSw sCLFKzCV6lzpA7gFVbzoumMIrHU8Eb1ol27uFRlnGBT5rw9SB9siocz0z_OP ODBoSbNLAAuplx8zlt5LVeneEC9rwPu4ONG7TYA6xrK.TklcmY8tN1XK8q2f TWHy_yCjhtlPXhuuj5nY7xKQF._b_HTyOz9tVtLGUiRLHesnfKXTbh2iQSYD H2P3AOykfLSQMLkYv9gXTbJ2oPUI6je5zoWuxZbBY1BIoH3zxnZGE5yiYkZn UizfSDVzvaXtOrEXmOhB2_3bQz.P_UdU9lnEKZhEgS4I6MkxdgslS.gl3xIB enNpRCXGUSnNK2oSeppaLMJBYFu7bDpsaBqG9StGTT8odnLlEGdpgmC8OmGX iHlCbB5NQvVEkAveZTQ9bZONMfwSqedo6QTD4PYHXS8oQyi_Z9QGFkIl3PCW Ryp_GjNka6mH_3U2p3ogna3m93U5Gou4Ryz0I1qh3uE58P3jGNJXCGmI.76U HOmNyj_0Le4RJ9.joV4TTxBdQ9ygEs44wEg-- Received: from [206.169.92.130] by web125506.mail.ne1.yahoo.com via HTTP; Fri, 13 Sep 2013 14:48:33 PDT X-Rocket-MIMEInfo: 002.001, U29ycnksIEkgbWlzLXJlYWQgeW91ciAiYnJvd3Nlci12ZW5kb3IiIGNvbmNlcm4gc2VjdGlvbiBhcyAic2VydmVyIiB2ZW5kb3IuCsKgClRoZSBicm93c2VywqBzaG91bGQgYmUgYWJsZSB0b8KgY2FjaGUgdGhlIFRMU0EgcmVjb3JkIG9uIHRoZSBsb2NhbCBtYWNoaW5lLgrCoApLYXJsCsKgCsKgCiAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBLYXJsIE1hbGJyYWluIDxtYWxicmFpbkB5YWhvby5jb20.ClRvOiBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAbW50LnNlPiAKQ2M6ICJwZXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <52337E32.2050701@mnt.se> <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> Message-ID: <1379108913.56984.YahooMailNeo@web125506.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 14:48:33 -0700 (PDT) From: Karl Malbrain To: Karl Malbrain , Leif Johansson In-Reply-To: <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="264668936-2104249680-1379108913=:56984" Cc: "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 21:48:41 -0000 --264668936-2104249680-1379108913=:56984 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, I mis-read your "browser-vendor" concern section as "server" vendor.= =0A=A0=0AThe browser=A0should be able to=A0cache the TLSA record on the loc= al machine.=0A=A0=0AKarl=0A=A0=0A=A0=0A =0A=0A_____________________________= ___=0A From: Karl Malbrain =0ATo: Leif Johansson =0ACc: "perpass@ietf.org" =0ASent: Friday, Sept= ember 13, 2013 2:30 PM=0ASubject: Re: [perpass] proposed enhancement to TLS= strong=09authentication=09protocol=0A =0A=0A=0AGreat news.=A0 Then all th= at is needed is a post connection exchange comparison in the client between= the server certificate used by TLS and the one obtained from DANE.=0A=A0= =0AAs to simple HTTP content servers, the use of the client authentication = interface=A0is optional.=A0 If there is no interface handler installed, the= TLS package goes ahead and allows the connection.=0A=A0=0ANote, for HTTP c= ontent servers that desire to authenticate client connections as MITM free = themselves, the in-page-rendering lookup is not to an external source -- it= 's to the servers own account record where a secure hash of the client cert= ificate is stored during account creation.=0A=A0=0AHowever for servers that= act as client agents over some domain, the server will track whether the a= uthenticated user certificate "owns" the account or is an unrecognized user= ,=A0and preclude hacking the server by guessing account names and passwords= , etc.=0A=A0=0AYes, with DANE in place, this proposal is now entirely focus= ed on authentication by the server of clients.=0A=A0=0AKarl=0A=A0=0A=A0=0A = =0A=0A________________________________=0A From: Leif Johansson =0ATo: Karl Malbrain =0ACc: Randy Bush ; "perpass@ietf.org" =0ASent: Friday, September 13, 20= 13 2:05 PM=0ASubject: Re: [perpass] proposed enhancement to TLS strong auth= entication=09protocol=0A =0A=0A=0AOn 09/13/2013 10:40 PM, Karl Malbrain wr= ote:=0A =0AI'm not familiar with DANE.=A0 Is it operational?=A0 Does it inc= lude changes to TLS to accept/compare the server's certificate obtained fro= m DANE?=A0 If so, then that part of the proposal can be mooted in favor of = DANE. =0A> =0A> =0AThe DNS is quite operational and nothing stops anyone f= rom publishing TLSA records right this second.=0A=0AYes, it would be simple= r to offload the certificate sourcing management to DNS.=A0 However, I'm pr= oposing changes to be implemented entirely within TLS, that are transparent= on the client side.=A0 Only the server side would require an additional in= terface to accept/reject client connections. =0AThere have been credible a= rguments from browser vendors against any scheme that involves=0Aan in-page= -rendering lookup to an external service that takes more=0A than a few m= illiseconds=0Abecause of the adverse effect on usability.=0A=0AGranted, TLS= is about much more than the web but its still a major=0A use-case.=0A= =0AI suspect that any scheme that will have any chance of success must=0A = involve pre-computing =0Asome form of proof on the server-side that can b= e stapled onto the=0A TLS connection. =0A=0AAlso you seem to focus on th= e client authenticating to the server=0A which quite frankly could make = the=0Aprivacy story worse.=0A=0A=A0 =0A>Karl =0A>=0A> =0A>From: Randy Bush = mailto:randy@psg.com=0A>To: Karl Malbrain mailto:malbrain@yahoo.com =0A>Cc:= Leif Johansson mailto:leifj@mnt.se =0A>Sent: Friday, September 13, 2013 1:= 24 PM=0A>Subject: Re: [perpass] proposed enhancement to TLS strong authenti= cation protocol=0A> =0A>=0A>[ off lst ]=0A>=0A>> I've dropped the idea of = including both client and=0A server public=0A>> certificates i= n the directory in favor of a server=0A certificate only=0A>> = repository with=A0an additional TLS interface to=0A authorize = access by=0A>> clients.=0A>=0A>so why is this a win over dane?=0A>=0A>randy= =0A>=0A>=0A> =0A =0A_______________________________________________=0Ap= erpass mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/perpass=0A=0A=0A =0A_______________________________________________= =0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/perpass --264668936-2104249680-1379108913=:56984 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry, I m= is-read your "browser-vendor" concern section as "server" vendor.
 
The browser should be able= to cache the TLSA record on the local machine.
 
Karl
 
 

<= div dir=3D"ltr">
From: K= arl Malbrain <malbrain@yahoo.com>
To: Leif Johansson <leifj@mnt.se>
Cc: "perpass@ietf.org" <perpass@ietf.org> Sent: Friday, September = 13, 2013 2:30 PM
Subject:<= /b> Re: [perpass] proposed enhancement to TLS strong=09authentication=09pro= tocol

Great news.  Then all that is needed is a post c= onnection exchange comparison in the client between the server certificate = used by TLS and the one obtained from DANE.
&= nbsp;
As to simple HTTP content servers, the use of the cli= ent authentication interface is optional.  If there is no interface = handler installed, the TLS package goes ahead and allows the connection.
 
Note, for HTTP content s= ervers that desire to authenticate client connections as MITM free themselv= es, the in-page-rendering lookup is not to an external source -- it's to th= e servers own account record where a secure hash of the client certificate = is stored during account creation.
 
However for=0A servers that act as client agents over some dom= ain, the server will track whether the authenticated user certificate "owns= " the account or is an unrecognized user, and preclude hacking the ser= ver by guessing account names and passwords, etc.
 
Yes, with DANE in place, this proposal is now e= ntirely focused on authentication by the server of clients.
 
Karl
 
&n= bsp;

<= /div> From: Lei= f Johansson <leifj@mnt.se>
= To: Karl Malbrain <malbrain@yahoo.com>
Cc: Randy Bush <randy@psg.com>; "p= erpass@ietf.org" <perpass@ietf.org>
Sent: Friday, September 13, 2013 2:05 PM
Subject: Re: [perpass] proposed enh= ancement to TLS strong authentication=09protocol

=0A =0A= =0A =0A =0A
=0A
On= 09/13/2013 10:40 PM, Karl Malbrain=0A wrote:
=0A
=0A <= blockquote type=3D"cite">=0A
=0A
I'm not familiar with DA= NE.  Is it operational?  Does=0A it include changes to= TLS to accept/compare the server's=0A certificate obtained from= DANE?  If so, then that part of=0A the proposal can be moo= ted in favor of DANE.
=0A

=0A =
=0A
=0A =0A The DNS is quite operat= ional and nothing stops anyone from=0A publishing TLSA records right thi= s second.
=0A
=0A
=0A
Yes= , it would be simpler to offload the certificate=0A sourcing man= agement to DNS.  However, I'm proposing changes=0A to be im= plemented entirely within TLS, that are transparent=0A on the cl= ient side.  Only the server side would require an=0A additi= onal interface to accept/reject client connections.
=0A =0A
=0A There have been credible arguments from brow= ser vendors against any=0A scheme that involves
=0A an in-page-ren= dering lookup to an external service that takes more=0A than a few milli= seconds
=0A because of the adverse effect on usability.
=0A =0A Granted, TLS is about much more than the web but its still a major= =0A use-case.
=0A
=0A I suspect that any scheme that will h= ave any chance of success must=0A involve pre-computing
=0A some = form of proof on the server-side that can be stapled onto the=0A TLS con= nection.
=0A
=0A Also you seem to focus on the client authent= icating to the server=0A which quite frankly could make the
=0A pr= ivacy story worse.
=0A
=0A
=0A  
=0A
Karl
=0A =

=0A
=0A
=0A
= =0A
From: Randy=0A Bush = mail= to:randy@psg.com
=0A To: Karl=0A Malbrain mailto:malbrain@= yahoo.com
=0A = Cc: Leif=0A Johansson mailto:leifj@mnt.se
=0A= Sent:=0A = Friday, September 13, 2013 1:24 PM
=0A <= span style=3D"font-weight: bold;">Subject:=0A Re:= [perpass] proposed enhancement to TLS strong=0A authenticat= ion protocol
=0A
=0A

=0A [ off lst ]
=0A =
=0A > I've dropped the idea of including both = client and=0A server public
=0A > certifica= tes in the directory in favor of a server=0A certificate only<= br>=0A > repository with an additional TLS interface t= o=0A authorize access by
=0A > clients.
= =0A
=0A so why is this a win over dane?
= =0A
=0A randy
=0A
=0A =
=0A
=0A
=0A
=0A =
=0A =0A
=0A
=0A=0A

______= _________________________________________
perpass mailing list
perpass@ietf.org
https:/= /www.ietf.org/mailman/listinfo/perpass


=

_______________________________________________
p= erpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/l= istinfo/perpass


--264668936-2104249680-1379108913=:56984-- From randy@psg.com Fri Sep 13 14:52:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAAB21E80D0 for ; Fri, 13 Sep 2013 14:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtBBDhjwB4lE for ; Fri, 13 Sep 2013 14:52:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE2F21E8099 for ; Fri, 13 Sep 2013 14:52:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKbHY-0002g5-Ft; Fri, 13 Sep 2013 21:52:04 +0000 Date: Fri, 13 Sep 2013 11:52:03 -1000 Message-ID: From: Randy Bush To: Karl Malbrain In-Reply-To: <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <52337E32.2050701@mnt.se> <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Leif Johansson , "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 21:52:11 -0000 > Great news.=A0 Then all that is needed is a post connection exchange > comparison in the client between the server certificate used by TLS > and the one obtained from DANE. yes, that is what dane clients do > Yes, with DANE in place, this proposal is now entirely focused on > authentication by the server of clients. though occasionally useful, it is not necessarily a good idea in the privacy context randy From gasser@net.in.tum.de Fri Sep 13 15:02:39 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF3211E80F9 for ; Fri, 13 Sep 2013 15:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7NQR6x4W54g for ; Fri, 13 Sep 2013 15:02:35 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (smtp1.informatik.tu-muenchen.de [131.159.0.99]) by ietfa.amsl.com (Postfix) with ESMTP id D814211E80AD for ; Fri, 13 Sep 2013 15:02:34 -0700 (PDT) Received: from [192.168.178.2] (109.125.92.225.dynamic.cablesurf.de [109.125.92.225]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 1F6221826053; Sat, 14 Sep 2013 00:02:27 +0200 (CEST) Message-ID: <52338B71.10505@net.in.tum.de> Date: Sat, 14 Sep 2013 00:02:25 +0200 From: Oliver Gasser User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8 MIME-Version: 1.0 To: Karl Malbrain References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <52337E32.2050701@mnt.se> <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> <1379108913.56984.YahooMailNeo@web125506.mail.ne1.yahoo.com> In-Reply-To: <1379108913.56984.YahooMailNeo@web125506.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Leif Johansson , "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 22:02:39 -0000 On 09/13/2013 11:48 PM, Karl Malbrain wrote: > Sorry, I mis-read your "browser-vendor" concern section as "server" vendor. > > The browser should be able to cache the TLSA record on the local machine. > > Karl > > > > *From:* Karl Malbrain > *To:* Leif Johansson > *Cc:* "perpass@ietf.org" > *Sent:* Friday, September 13, 2013 2:30 PM > *Subject:* Re: [perpass] proposed enhancement to TLS strong > authentication protocol > > Great news. Then all that is needed is a post connection exchange > comparison in the client between the server certificate used by TLS and > the one obtained from DANE. > > As to simple HTTP content servers, the use of the client authentication > interface is optional. If there is no interface handler installed, the > TLS package goes ahead and allows the connection. > > Note, for HTTP content servers that desire to authenticate client > connections as MITM free themselves, the in-page-rendering lookup is not > to an external source -- it's to the servers own account record where a > secure hash of the client certificate is stored during account creation. > > However for servers that act as client agents over some domain, the > server will track whether the authenticated user certificate "owns" the > account or is an unrecognized user, and preclude hacking the server by > guessing account names and passwords, etc. If I understand correctly, you want to dynamically create client certificates and then check the client certificate information in combination with a user's login name and password. What happens if a user accesses a site from different devices/clients? What about sites where users don't log in at all? > > Yes, with DANE in place, this proposal is now entirely focused on > authentication by the server of clients. > > Karl > > > > *From:* Leif Johansson > *To:* Karl Malbrain > *Cc:* Randy Bush ; "perpass@ietf.org" > *Sent:* Friday, September 13, 2013 2:05 PM > *Subject:* Re: [perpass] proposed enhancement to TLS strong > authentication protocol > > On 09/13/2013 10:40 PM, Karl Malbrain wrote: >> I'm not familiar with DANE. Is it operational? Does it include >> changes to TLS to accept/compare the server's certificate obtained >> from DANE? If so, then that part of the proposal can be mooted in >> favor of DANE. >> > The DNS is quite operational and nothing stops anyone from publishing > TLSA records right this second. >> Yes, it would be simpler to offload the certificate sourcing >> management to DNS. However, I'm proposing changes to be implemented >> entirely within TLS, that are transparent on the client side. Only >> the server side would require an additional interface to accept/reject >> client connections. > There have been credible arguments from browser vendors against any > scheme that involves > an in-page-rendering lookup to an external service that takes more than > a few milliseconds > because of the adverse effect on usability. > > Granted, TLS is about much more than the web but its still a major use-case. > > I suspect that any scheme that will have any chance of success must > involve pre-computing > some form of proof on the server-side that can be stapled onto the TLS > connection. > > Also you seem to focus on the client authenticating to the server which > quite frankly could make the > privacy story worse. >> >> Karl >> >> *From:* Randy Bush mailto:randy@psg.com >> *To:* Karl Malbrain mailto:malbrain@yahoo.com >> *Cc:* Leif Johansson mailto:leifj@mnt.se >> *Sent:* Friday, September 13, 2013 1:24 PM >> *Subject:* Re: [perpass] proposed enhancement to TLS strong >> authentication protocol >> >> [ off lst ] >> >> > I've dropped the idea of including both client and server public >> > certificates in the directory in favor of a server certificate only >> > repository with an additional TLS interface to authorize access by >> > clients. >> >> so why is this a win over dane? >> >> randy >> >> > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From warren@kumari.net Fri Sep 13 15:03:29 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA07A21F9AD5 for ; Fri, 13 Sep 2013 15:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoYAwpK9wYMS for ; Fri, 13 Sep 2013 15:03:25 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A99011E80AD for ; Fri, 13 Sep 2013 15:03:25 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id DA5E81B40115; Fri, 13 Sep 2013 18:03:24 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 18:03:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> To: Karl Malbrain X-Mailer: Apple Mail (2.1508) Cc: Randy Bush , Leif Johansson , "perpass@ietf.org" , Warren Kumari Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 22:03:29 -0000 On Sep 13, 2013, at 4:40 PM, Karl Malbrain wrote: > I'm not familiar with DANE. Is it operational? =20 Yes, it is just not widely (enough) deployed. There are some browser = extensions and a browser (Bloodhound) that has support built in. There = are good tools to generate the DANE (TLSA) records, and e.g registro.br = has a simple one click "generate and publish a TLSA record" record for = hosted DNS customers. It is gaining traction in mail / SMTP, with support in Postfix. At the moment one of the main deployment hurdles is browser support (and = more DNSSEC deployment!). Browsers (understandably) don't want to be waiting on TLSA records -- = latency is really important for browsers, and waiting for more DNS = lookups takes time. A few solutions have been discussed / suggested, such as only doing DANE = for self-signed certs, doing the TLSA lookup in parallel with the = regular lookup and making the normal connection, then aborting it (and = replacing the page with a notice) if DANE shows evidence of shennanigans = and / or caching TLSA records. W > Does it include changes to TLS to accept/compare the server's = certificate obtained from DANE? If so, then that part of the proposal = can be mooted in favor of DANE. > =20 > Yes, it would be simpler to offload the certificate sourcing = management to DNS. However, I'm proposing changes to be implemented = entirely within TLS, that are transparent on the client side. Only the = server side would require an additional interface to accept/reject = client connections. > =20 > Karl >=20 > From: Randy Bush > To: Karl Malbrain =20 > Cc: Leif Johansson =20 > Sent: Friday, September 13, 2013 1:24 PM > Subject: Re: [perpass] proposed enhancement to TLS strong = authentication protocol >=20 > [ off lst ] >=20 > > I've dropped the idea of including both client and server public > > certificates in the directory in favor of a server certificate only > > repository with an additional TLS interface to authorize access by > > clients. >=20 > so why is this a win over dane? >=20 > randy >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass -- Hope is not a strategy. -- Ben Treynor, Google From malbrain@yahoo.com Fri Sep 13 15:09:57 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADB411E810B for ; Fri, 13 Sep 2013 15:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2SM7SCD5aX4 for ; Fri, 13 Sep 2013 15:09:51 -0700 (PDT) Received: from nm1-vm2.bullet.mail.ne1.yahoo.com (nm1-vm2.bullet.mail.ne1.yahoo.com [98.138.91.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5396C11E8105 for ; Fri, 13 Sep 2013 15:09:51 -0700 (PDT) Received: from [98.138.90.50] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:09:50 -0000 Received: from [98.138.226.160] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:09:50 -0000 Received: from [127.0.0.1] by omp1061.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:09:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 486703.79513.bm@omp1061.mail.ne1.yahoo.com Received: (qmail 98985 invoked by uid 60001); 13 Sep 2013 22:09:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379110190; bh=pSzesWN/5b84Q9ZffCL5TngEvihszILlRKuBEbMj+e0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yQKI1Bm7jvhyPW/0gkHrO4RTBsLiyPXifnblEKY03fXjLnPdiBKV7jOhxgLSudfJ8/l0pFvI+rS/2wgIcQnjGyVNvknbpBj9ETVWfXmkM5B1h+V8CDMEKpm9h6+8poVf3R5dotUFWaAUtuCrlZVxDA//PDvaUqWLTSpkyzTZkEU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6X4b9qIDPyT29PnPEWiH5Wkac8Vrmt7IEZRFw60qFc2t6z5QuKkl8OwUWpwCbXI17syMV8gNbAWiCpvGkWRt5IlwO3P1mjIpOi1Mj54YR4Q0nwnu54e+GhiBFjccl9zXOjOXU8DDyTRC9cX4ovyUr8gaS+LVCSNS2qYl0TpsoTw=; X-YMail-OSG: F45q.owVM1lURKzj3YkBGlpXYrK7hKni9N4QbN37r5P3YSR F7xOTG.2BfQzu8LWm.QhjtZmRWdDGVu7BiDME29phoKgDHNA1F6q8.Ybs6sV Ukms7ceahKqstX3ziDLHeX_v4O5a9WwFjNUpnNhpAsNOHVeGVgAcs5Q6g3M5 nrJ911JVhiZL0TRT..fN2sBlQB7RTeZ1rBenGlRYcws3C53jc_wSSGKyYdL7 tdMy7lG7etGtgzo6qb7vJTMRKyumj9sAy1l3e0FDE9QG4MxO.pvm50dt0O7l _TeQusEtras.wlnsKb9lJtQqLOxAs0RTsaP7Zp8T7owmsqNiIEmIOZPdovEv uC9QW0i09DGziCge4V3WJh_FZVW3p3ZgBu5iv_41Lv9cJKMnQfVIpd181hVv ppLIBwy3pWXOYlPeRx6gnLa7k0YgHJgzIF2NZCNWMZEAgxe0JR_f1.IJpVdx cTeeoM4OeQ6o.u3uzCHSuOrEx5ZKoU.j56N6GfsLUy18chNEtxVNr7jCugrj zviInzlhobjhhLT4M9mCDxNqDfP4V1KRFsbzG6L.abVoFmQiyzV74_MjrIKE 69zG74hBl38RIokT9DAFGgNooj5vl7U9lH8apx7M- Received: from [206.169.92.130] by web125504.mail.ne1.yahoo.com via HTTP; Fri, 13 Sep 2013 15:09:50 PDT X-Rocket-MIMEInfo: 002.001, TW9zdCBodHRwcyBwcm90ZWN0ZWQgY2hhbm5lbHMgYXJlIHRvIHNlcnZlcnMgd2l0aCBzb21lIHNvcnQgb2YgYWdlbmN5IG9uIGJlaGFsZiBvZiB0aGUgY2xpZW50LsKgIE15IGJhbmsgYWNjb3VudCBjb25uZWN0aW9uIGZvciBleGFtcGxlIGFsbG93cyBhbnlvbmUgaW4gdGhlIHVuaXZlcnNlIHRvIHRyeSB0byBoYWNrIGludG8gbXkgYWNjb3VudCBieSBndWVzc2luZyB0aGUgYWNjb3VudCBuYW1lIGFuZCBwYXNzd29yZC7CoCBJZiB0aGlzIGNvbm5lY3Rpb24gd2VyZSBhdXRoZW50aWNhdGVkIHRocm91Z2ggbXkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <52337E32.2050701@mnt.se> <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> Message-ID: <1379110190.58129.YahooMailNeo@web125504.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 15:09:50 -0700 (PDT) From: Karl Malbrain To: Randy Bush In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="318864283-1039081714-1379110190=:58129" Cc: Leif Johansson , "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 22:09:57 -0000 --318864283-1039081714-1379110190=:58129 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Most https protected channels are to servers with some sort of agency on be= half of the client.=A0 My bank account connection for example allows anyone= in the universe to try to hack into my account by guessing the account nam= e and password.=A0 If this connection were authenticated through my public = certificate to my private key I, and the bank, wouldn't have to worry anywh= ere near as much as I do now due to the extra layer of security being offer= ed.=0A=A0=0APortability of the private key=A0to a new platform can be a con= cern to be addressed independently.=A0 In my case I only access my account = from a single=A0computer.=A0Theft of the computing device would be a threat= vector.=0A=A0=0AThere is also the question of due dilligence on behalf of = server operators that information being transmitted over the connection can= not be eavedropped by MITM style intrusion to third parties.=0A=A0=0AKarl= =0A=A0 =0A=0A________________________________=0A From: Randy Bush =0ATo: Karl Malbrain =0ACc: Leif Johansson ; "perpass@ietf.org" =0ASent: Friday, September= 13, 2013 2:52 PM=0ASubject: Re: [perpass] proposed enhancement to TLS stro= ng authentication protocol=0A =0A=0A> Great news.=A0 Then all that is need= ed is a post connection exchange=0A> comparison in the client between the s= erver certificate used by TLS=0A> and the one obtained from DANE.=0A=0Ayes,= that is what dane clients do=0A=0A> Yes, with DANE in place, this proposal= is now entirely focused on=0A> authentication by the server of clients.=0A= =0Athough occasionally useful, it is not necessarily a good idea in the=0Ap= rivacy context=0A=0Arandy=0A_______________________________________________= =0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/perpass --318864283-1039081714-1379110190=:58129 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Most https= protected channels are to servers with some sort of agency on behalf of th= e client.  My bank account connection for example allows anyone in the= universe to try to hack into my account by guessing the account name and p= assword.  If this connection were authenticated through my public cert= ificate to my private key I, and the bank, wouldn't have to worry anywhere = near as much as I do now due to the extra layer of security being offered.<= /span>
 
Portability of the pri= vate key to a new platform can be a concern to be addressed independen= tly.  In my case I only access my account from a single computer.=  Theft of the computing device would be a threat vector.
<= div> 
There is also the question of due dilligence on behalf of server operators that information being transm= itted over the connection cannot be eavedropped by MITM style intrusion to = third parties.
 
Karl
 
From: Randy Bush <randy@psg.com>
To: Karl Malbrain <malbrain@yahoo.= com>
Cc: Leif Johan= sson <leifj@mnt.se>; "perpass@ietf.org" <perpass@ietf.org>
= Sent: Friday, September 13, 2013 2= :52 PM
Subject: Re: [p= erpass] proposed enhancement to TLS strong authentication protocol

=0A> Great news.  The= n all that is needed is a post connection exchange
> comparison in th= e client between the server certificate used by TLS
> and the one obt= ained from DANE.

yes, that is what dane clients do

> Yes, = with DANE in place, this proposal is now entirely focused on
> authen= tication by the server of clients.

though occasionally useful, it is= not necessarily a good idea in the
privacy context

randy
____= ___________________________________________
perpass mailing list
perpass= @ietf.org
https://www.ietf.org/mailman/listinfo/perpass

=
--318864283-1039081714-1379110190=:58129-- From malbrain@yahoo.com Fri Sep 13 15:16:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CA121E808E for ; Fri, 13 Sep 2013 15:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAncltZXmNXs for ; Fri, 13 Sep 2013 15:16:08 -0700 (PDT) Received: from nm17-vm0.bullet.mail.ne1.yahoo.com (nm17-vm0.bullet.mail.ne1.yahoo.com [98.138.91.58]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF8C21E811A for ; Fri, 13 Sep 2013 15:16:08 -0700 (PDT) Received: from [98.138.226.178] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:16:06 -0000 Received: from [98.138.89.249] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:16:06 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:16:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 525209.88919.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 70743 invoked by uid 60001); 13 Sep 2013 22:16:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379110566; bh=O/lKFOHAH9EIHaX3jqtCfFCBAyr+KmNKPBPaVbNpQNg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IBZCQi9K3zR/NzBxQrP2MkFojS3S0AHZ047KXemhiRgB6NffM8ijWU0KLNr4GiAsSSeIORS3/WxnHjVDEV2fHCXJlk5ULejTaXIFkszfiwemQs7udNLXDtgjnMxflAMn1DPDnKShokBd93d3RVOMR+i3DgFo01duT5pNaE2y6NE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AVhp04BQ5Zsp5gfeVDpnmsrCG+59wssTmRwdf0Zj5TC2v/51+Q6PFe1bxdWHmmm9LliWR7UxM2RSELJpNkxG7I1d9+P9geU1eBDOtkSv7nwaR+2ld5SjUCVabHUj205q94xLXIiP0AG8R4dZjwexxnmUu4JLTp91ujWNGB9oRPM=; X-YMail-OSG: Ot3q..kVM1mgjIJwnB2qOT9073iIJRL8F78Pv1ZzwN0GMC8 QEK8TEndZfmW2xW_hZ9jiJ0cp1U9fSmgRlD_pbZLG5r4JTbiNccMY7LbgjVU I6MmHpjS3FdTr2uw7cVia.B5jI_.QcKuXR50BpwCvgkQj4jernGc1C3pn.Up OimoWPewSBZPYliNfOQi03AALe7gKFKKckeRv7dcrv89xJwRua6o2TqWwl4. 8OQU8J6cqZMcek7xmebY7SZQ6.U2FHvLiFjiX2_iJlanQWyI3G9ydyI8oKEj nSTJkAYsGNf_NjaRK3XRYTZJQ9UDAkwG17g8VAG6rLWz_3UObJ_JAXSl.fxh D0vap8Ex1Vg.Ag3GwpiYBlh66NpdTmNUHo8.D5kmFlg5DKUhjWxeL74Ph6xi VMaTABHk3O_wbld22FXV3TUIjUtGK2RUMKiP9VG0UD6Ew7MzTeBbzbyGUkzd Pi8To1j6iOuyafTXzilIHvEES9WdIiDkPoPyEG9kPfKI8YUP5tRRlNHzeTCG WI_Wi.1VLQAgmuUllgyYkyHhV9Fl85vI2NdA84fI14fWae23dwOE_CA.j4.c .ktmiHK1LqCjTujufNrIhEGDsYbcDgYQ5w1BBD9g- Received: from [206.169.92.130] by web125503.mail.ne1.yahoo.com via HTTP; Fri, 13 Sep 2013 15:16:06 PDT X-Rocket-MIMEInfo: 002.001, WWVzLCBJJ20gcHJvcG9zaW5nIHRoYXQgY2xpZW50cyBwcm90ZWN0IHRoZW1zZWx2ZXMgYnkgY3JlYXRpbmcgc2VsZi1zaWduZWQgc2VjdXJpdHkgY2VydGlmaWNhdGVzLCBhbmQgdGhhdCBzZXJ2ZXJzIGVuZ2FnZSBpbiBkdWUgZGlsbGVnZW5jZSB0byBlbnN1cmUgY29ubmVjdGlvbnMgYXJlIE1JVE0gZnJlZS4KwqAKV2lkZXNwcmVhZCBkZXBsb3ltZW50IG9mIERBTkUgcmVnaXN0cmllcyBvZiBzZXJ2ZXIgY2VydGlmaWNhdGVzIGlzIGFsc28gcmVxdWlyZWQuCsKgCklmIHRoZSBjbGllbnQgd2lzaGVzIHRvIG8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <52337E32.2050701@mnt.se> <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> <1379108913.56984.YahooMailNeo@web125506.mail.ne1.yahoo.com> <52338B71.10505@net.in.tum.de> Message-ID: <1379110566.62022.YahooMailNeo@web125503.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 15:16:06 -0700 (PDT) From: Karl Malbrain To: Oliver Gasser In-Reply-To: <52338B71.10505@net.in.tum.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2005986409-1918446523-1379110566=:62022" Cc: Leif Johansson , "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 22:16:14 -0000 ---2005986409-1918446523-1379110566=:62022 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I'm proposing that clients protect themselves by creating self-signed = security certificates, and that servers engage in due dillegence to ensure = connections are MITM free.=0A=A0=0AWidespread deployment of DANE registries= of server certificates is also required.=0A=A0=0AIf the client wishes to o= perate on multiple devices, they would need their public/private key pairs = installed on each device.=0A=A0=0AThe login to upstream applications is mos= tly independent of the TLS connection, except for a new interface where the= upstream application can participate in rejecting the TLS connection if th= ey have no record of the client certificate belonging to any acccounts in t= he server's control.=0A=A0=0AKarl=0A =0A=0A________________________________= =0A From: Oliver Gasser =0ATo: Karl Malbrain =0ACc: Leif Johansson ; "perpass@ietf.org" =0ASent: Friday, September 13, 2013 3:02 PM=0ASubject: Re: [p= erpass] proposed enhancement to TLS=09strong=09authentication=09protocol=0A= =0A=0A=0A=0AOn 09/13/2013 11:48 PM, Karl Malbrain wrote:=0A> Sorry, I mis= -read your "browser-vendor" concern section as "server" vendor.=0A>=A0 =0A>= The browser should be able to cache the TLSA record on the local machine.= =0A>=A0 =0A> Karl=0A>=A0 =0A>=A0 =0A> =0A> *From:* Karl Malbrain =0A> *To:* Leif Johansson =0A> *Cc:* "perpass@ietf.= org" =0A> *Sent:* Friday, September 13, 2013 2:30 PM=0A> = *Subject:* Re: [perpass] proposed enhancement to TLS strong=0A> authenticat= ion protocol=0A> =0A> Great news.=A0 Then all that is needed is a post conn= ection exchange=0A> comparison in the client between the server certificate= used by TLS and=0A> the one obtained from DANE.=0A>=A0 =0A> As to simple H= TTP content servers, the use of the client authentication=0A> interface is = optional.=A0 If there is no interface handler installed, the=0A> TLS packag= e goes ahead and allows the connection.=0A>=A0 =0A> Note, for HTTP content = servers that desire to authenticate client=0A> connections as MITM free the= mselves, the in-page-rendering lookup is not=0A> to an external source -- i= t's to the servers own account record where a=0A> secure hash of the client= certificate is stored during account creation.=0A>=A0 =0A> However for ser= vers that act as client agents over some domain, the=0A> server will track = whether the authenticated user certificate "owns" the=0A> account or is an = unrecognized user, and preclude hacking the server by=0A> guessing account = names and passwords, etc.=0A=0AIf I understand correctly, you want to dynam= ically create client=0Acertificates and then check the client certificate i= nformation in=0Acombination with a user's login name and password.=0AWhat h= appens if a user accesses a site from different devices/clients?=0AWhat abo= ut sites where users don't log in at all?=0A=0A>=A0 =0A> Yes, with DANE in = place, this proposal is now entirely focused on=0A> authentication by the s= erver of clients.=0A>=A0 =0A> Karl=0A>=A0 =0A>=A0 =0A> =0A> *From:* Leif Jo= hansson =0A> *To:* Karl Malbrain =0A> *Cc= :* Randy Bush ; "perpass@ietf.org" =0A> *S= ent:* Friday, September 13, 2013 2:05 PM=0A> *Subject:* Re: [perpass] propo= sed enhancement to TLS strong=0A> authentication protocol=0A> =0A> On 09/13= /2013 10:40 PM, Karl Malbrain wrote:=0A>> I'm not familiar with DANE.=A0 Is= it operational?=A0 Does it include=0A>> changes to TLS to accept/compare t= he server's certificate obtained=0A>> from DANE?=A0 If so, then that part o= f the proposal can be mooted in=0A>> favor of DANE.=0A>>=0A> The DNS is qui= te operational and nothing stops anyone from publishing=0A> TLSA records ri= ght this second.=0A>> Yes, it would be simpler to offload the certificate s= ourcing=0A>> management to DNS.=A0 However, I'm proposing changes to be imp= lemented=0A>> entirely within TLS, that are transparent on the client side.= =A0 Only=0A>> the server side would require an additional interface to acce= pt/reject=0A>> client connections.=0A> There have been credible arguments f= rom browser vendors against any=0A> scheme that involves=0A> an in-page-ren= dering lookup to an external service that takes more than=0A> a few millise= conds=0A> because of the adverse effect on usability.=0A> =0A> Granted, TLS= is about much more than the web but its still a major use-case.=0A> =0A> I= suspect that any scheme that will have any chance of success must=0A> invo= lve pre-computing=0A> some form of proof on the server-side that can be sta= pled onto the TLS=0A> connection.=0A> =0A> Also you seem to focus on the cl= ient authenticating to the server which=0A> quite frankly could make the=0A= > privacy story worse.=0A>>=A0 =0A>> Karl=0A>>=0A>> *From:* Randy Bush mail= to:randy@psg.com=0A>> *To:* Karl Malbrain mailto:malbrain@yahoo.com=0A>> *C= c:* Leif Johansson mailto:leifj@mnt.se=0A>> *Sent:* Friday, September 13, 2= 013 1:24 PM=0A>> *Subject:* Re: [perpass] proposed enhancement to TLS stron= g=0A>> authentication protocol=0A>>=0A>> [ off lst ]=0A>>=0A>> > I've dropp= ed the idea of including both client and server public=0A>> > certificates = in the directory in favor of a server certificate only=0A>> > repository wi= th an additional TLS interface to authorize access by=0A>> > clients.=0A>>= =0A>> so why is this a win over dane?=0A>>=0A>> randy=0A>>=0A>>=0A> =0A> = =0A> _______________________________________________=0A> perpass mailing li= st=0A> perpass@ietf.org =0A> https://www.ietf.org/= mailman/listinfo/perpass=0A> =0A> =0A> =0A> _______________________________= ________________=0A> perpass mailing list=0A> perpass@ietf.org =0A> https://www.ietf.org/mailman/listinfo/perpass=0A> =0A> = =0A> =0A> =0A> _______________________________________________=0A> perpass = mailing list=0A> perpass@ietf.org=0A> https://www.ietf.org/mailman/listinfo= /perpass=0A> =0A=0A_______________________________________________=0Aperpas= s mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/p= erpass ---2005986409-1918446523-1379110566=:62022 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, I'm p= roposing that clients protect themselves by creating self-signed security c= ertificates, and that servers engage in due dillegence to ensure connection= s are MITM free.
 
Wides= pread deployment of DANE registries of server certificates is also required= .
 
If the client wishes= to operate on multiple devices, they would need their public/private key p= airs installed on each device.
 
The login to upstream applications is mostly independent of the TL= S connection, except for a new interface where the upstream application can= participate in rejecting the TLS connection if they have no record of the = client certificate belonging to any acccounts in the server's control.
 
Karl<= /div>

From: Oliver Gasser <gasser@net= .in.tum.de>
To: Kar= l Malbrain <malbrain@yahoo.com>
Cc: Leif Johansson <leifj@mnt.se>; "perpass@ietf.org"= <perpass@ietf.org>
Sent:<= /span> Friday, September 13, 2013 3:02 PM
Subject: Re: [perpass] proposed enhancement to TLS=09str= ong=09authentication=09protocol



On 09/13/2013 11:48 PM, Karl Malbrain wrote:
> Sor= ry, I mis-read your "browser-vendor" concern section as "server" vendor.> 
> The browser should be able to cache the TLSA record on= the local machine.
> 
> Karl
> 
> = ;
>
> *From:* Karl Malbrain <malbrain@yahoo.com>> *To:* Leif Johansson <leifj@mnt.se>
> *Cc:* "perpass@ietf.org"= <perpass@ietf.org>
> *Sent:* Friday, September 13, 2013 2:30 = PM
> *Subject:* Re: [perpass] proposed enhancement to TLS strong
> authen= tication protocol
>
> Great news.  Then all that is neede= d is a post connection exchange
> comparison in the client between th= e server certificate used by TLS and
> the one obtained from DANE.> 
> As to simple HTTP content servers, the use of the clie= nt authentication
> interface is optional.  If there is no inter= face handler installed, the
> TLS package goes ahead and allows the c= onnection.
> 
> Note, for HTTP content servers that desir= e to authenticate client
> connections as MITM free themselves, the i= n-page-rendering lookup is not
> to an external source -- it's to the= servers own account record where a
> secure hash of the client certi= ficate is stored during account creation.
> 
> However fo= r servers that act as client agents over some domain, the
> server will track whether the authenticated user certificate "owns" the> account or is an unrecognized user, and preclude hacking the server b= y
> guessing account names and passwords, etc.

If I understand= correctly, you want to dynamically create client
certificates and then = check the client certificate information in
combination with a user's lo= gin name and password.
What happens if a user accesses a site from diffe= rent devices/clients?
What about sites where users don't log in at all?<= br>
> 
> Yes, with DANE in place, this proposal is now en= tirely focused on
> authentication by the server of clients.
>&= nbsp;
> Karl
> 
> 
>
> *From:* = Leif Johansson <leifj@mnt.se>
> *To:* Karl Malbrain <malbrain@yahoo.com>
> *= Cc:* Randy Bush <randy@psg.com>; "perpass@ietf.org" <perpass@ietf.org= >
> *Sent:* Friday, September 13, 2013 2:05 PM
> *Subject:* = Re: [perpass] proposed enhancement to TLS strong
> authentication pro= tocol
>
> On 09/13/2013 10:40 PM, Karl Malbrain wrote:
>= > I'm not familiar with DANE.  Is it operational?  Does it inc= lude
>> changes to TLS to accept/compare the server's certificate = obtained
>> from DANE?  If so, then that part of the proposal= can be mooted in
>> favor of DANE.
>>
> The DNS is= quite operational and nothing stops anyone from publishing
> TLSA re= cords right this second.
>> Yes, it would be simpler to offload the cer= tificate sourcing
>> management to DNS.  However, I'm proposi= ng changes to be implemented
>> entirely within TLS, that are tran= sparent on the client side.  Only
>> the server side would re= quire an additional interface to accept/reject
>> client connectio= ns.
> There have been credible arguments from browser vendors against= any
> scheme that involves
> an in-page-rendering lookup to an= external service that takes more than
> a few milliseconds
> b= ecause of the adverse effect on usability.
>
> Granted, TLS is= about much more than the web but its still a major use-case.
>
&= gt; I suspect that any scheme that will have any chance of success must
= > involve pre-computing
> some form of proof on the server-side th= at can be stapled onto the TLS
> connection.
>
> Also you seem to focus on the client authenticating to the server which> quite frankly could make the
> privacy story worse.
>>=  
>> Karl
>>
>> *From:* Randy Bush mailto:= randy@psg= .com
>> *To:* Karl Malbrain mailto:malbrain@yahoo.com
= >> *Cc:* Leif Johansson mailto:leifj@mnt.se
>> *Sent:* Friday, Sept= ember 13, 2013 1:24 PM
>> *Subject:* Re: [perpass] proposed enhanc= ement to TLS strong
>> authentication protocol
>>
>= > [ off lst ]
>>
>> > I've dropped the idea of incl= uding both client and server public
>> > certificates in the di= rectory in favor of a server certificate only
>> > repository w= ith an additional TLS interface to authorize access by
>> > client= s.
>>
>> so why is this a win over dane?
>>
&= gt;> randy
>>
>>
>
>
> ___________= ____________________________________
> perpass mailing list
> <= a href=3D"mailto:perpass@ietf.org" ymailto=3D"mailto:perpass@ietf.org">perp= ass@ietf.org <mailto:perpass@ietf.org>
> https://www.ietf= .org/mailman/listinfo/perpass
>
>
>
> ______= _________________________________________
> perpass mailing list
&= gt; perpass@ietf.org <mailto:perpass@ietf.org>
> h= ttps://www.ietf.org/mailman/listinfo/perpass
>
>
> =
>
> _______________________________________________
> p= erpass mailing list
> perpass@ietf.org
> https://www.ietf.org= /mailman/listinfo/perpass
>

_____________________________= __________________
perpass mailing list
perpass@ietf.org
https:= //www.ietf.org/mailman/listinfo/perpass


=
---2005986409-1918446523-1379110566=:62022-- From randy@psg.com Fri Sep 13 15:17:32 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8978921E8126 for ; Fri, 13 Sep 2013 15:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvRllaX-K6pA for ; Fri, 13 Sep 2013 15:17:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 223E421E811A for ; Fri, 13 Sep 2013 15:17:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VKbg4-0002kv-DR; Fri, 13 Sep 2013 22:17:25 +0000 Date: Fri, 13 Sep 2013 12:17:23 -1000 Message-ID: From: Randy Bush To: Karl Malbrain In-Reply-To: <1379110190.58129.YahooMailNeo@web125504.mail.ne1.yahoo.com> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <52337E32.2050701@mnt.se> <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> <1379110190.58129.YahooMailNeo@web125504.mail.ne1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 22:17:32 -0000 > Most https protected channels are to servers with some sort of agency > on behalf of the client. not today, and less and less in the future if the efforts here make progress randy From malbrain@yahoo.com Fri Sep 13 15:19:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9311E80E2 for ; Fri, 13 Sep 2013 15:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgvGLLzWf-9s for ; Fri, 13 Sep 2013 15:19:21 -0700 (PDT) Received: from nm20-vm5.bullet.mail.ne1.yahoo.com (nm20-vm5.bullet.mail.ne1.yahoo.com [98.138.91.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8E011E8101 for ; Fri, 13 Sep 2013 15:19:15 -0700 (PDT) Received: from [98.138.90.54] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:19:10 -0000 Received: from [98.138.101.162] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:19:10 -0000 Received: from [127.0.0.1] by omp1073.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:19:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 549425.79090.bm@omp1073.mail.ne1.yahoo.com Received: (qmail 99812 invoked by uid 60001); 13 Sep 2013 22:19:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379110750; bh=utdngED8nHUXtPIsiQG1iA4PkmMSFxFZiaDoFAtpehU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AYIZtTxzZ8BbNTKf4kSJUEOvxQx9rZMgUmm9bsF7MDgHbEvLcXY4QCW2GhSjihsYprbNJOko4Cv8Nq9kY4QF5hnBzzBUvYKwR0bmMgxspBnvCj9i4jTIymB+CxmmxkCa1RGedtcQJ0gqNR9/RTPkuuGaw8TDHmwbekAtoUbJmOI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4jHbwLAKQioQFnQtg1upYrNsGHZ3OG7qirRHJlOheo4sif0euomdwLhcmNkYTmJ4e3JDACHA+a28eYYhThaqJVrzQp1gJOx08y8xTrIn0ZvztpCMgWkqDqpyRkNz6na/7DEqV7I6zR73T99x3NHakfjbhxuSAoTRg1WmK+RYI50=; X-YMail-OSG: vduiVZQVM1naOxjzALlNFx9wh7u1b20qcDPT_z6yQhPMojB FyyeedV8tYUlaUv6tkIIepT1HP8R54rqhvZRZSipnIr3NtRD5B5YfZnLK.l9 4bdzGLFNYBMtOL254u1Sk58lXroaAzN.WlFyJD5IJLcY68aqXuV8QA_p5fir DKDuNRxeLSy8dtC93wwfFlea3gFEaWmk06GZ7TQF3U5WI3H67LXp0hLZZVpf cYQsGVmliY3a5nbpnny9gF_IUYeCu2UXIpnmfpWHE7vJhJQoRgw6T6T3Eujw qMEDO2r_vUv1CMa0Qgm_Y5OWYutqP59WgRDv0Bp0QMC5c7ztys3hZetkGEqG msiT9mgHsH49iQ4NhephBaENMEMx5ss45Tt4efptSBa_7VWmr7GYJlhTpN5X mAZ7EmBiRNw7aEfDE5x4f.gF9W8ayA1H9nczc1uuxXY3AfNEsW9wpIP7l5lF LULiWyoBk1.6Ic6YU.C3rmOjiil5s2vXWBelEzjHhLkJEaxGDoqsEbXOz8XM vzVI01alGa1xGiX29nVl0J0rN6BYTSg4p6vovVzJvb1hVbRICu64VQZCmW2S N1p90nHlm9mrF54b7t6nToTdK8Tylyyv9I7rpd5vfcJihmHJX0Q84vltN8O5 X5MLFikB78HBQy62HDr9BN_isG0lbPoTDsj0CVU4Lw59_OA-- Received: from [206.169.92.130] by web125505.mail.ne1.yahoo.com via HTTP; Fri, 13 Sep 2013 15:19:09 PDT X-Rocket-MIMEInfo: 002.001, RG9lc24ndCBEQU5FIHByb2R1Y2UgdGhlIHNlcnZlcidzIGNlcnRpZmljYXRlIGluIHRoZSBzYW1lIGNvbm5lY3Rpb24gdGhhdCBETlMgcHJvZHVjZXMgdGhlIHNlcnZlcnMgSVAgYWRkcmVzcz_CoCBJZiBub3QsIHRoYXQncyBhbiBvcHRpbWl6YXRpb24gdGhhdCdzIG5lZWRlZC4KwqAKwqAKS2FybAogCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogV2FycmVuIEt1bWFyaSA8d2FycmVuQGt1bWFyaS5uZXQ.ClRvOiBLYXJsIE1hbGJyYWluIDxtYWxicmFpbkB5YWhvby5jb20.IApDYzoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> Message-ID: <1379110749.99151.YahooMailNeo@web125505.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 15:19:09 -0700 (PDT) From: Karl Malbrain To: Warren Kumari In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-781490481-245566440-1379110749=:99151" Cc: Randy Bush , Leif Johansson , "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 22:19:26 -0000 ---781490481-245566440-1379110749=:99151 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Doesn't DANE produce the server's certificate in the same connection that D= NS produces the servers IP address?=A0 If not, that's an optimization that'= s needed.=0A=A0=0A=A0=0AKarl=0A =0A=0A________________________________=0A F= rom: Warren Kumari =0ATo: Karl Malbrain =0ACc: Randy Bush ; Leif Johansson ; "per= pass@ietf.org" ; Warren Kumari =0ASen= t: Friday, September 13, 2013 3:03 PM=0ASubject: Re: [perpass] proposed enh= ancement to TLS strong authentication=09protocol=0A =0A=0A=0AOn Sep 13, 20= 13, at 4:40 PM, Karl Malbrain wrote:=0A=0A> I'm not fa= miliar with DANE.=A0 Is it operational?=A0 =0A=0AYes, it is just not widely= (enough) deployed. There are some browser extensions and a browser (Bloodh= ound) that has support built in. There are good tools to generate the DANE = (TLSA) records, and e.g registro.br has a simple one click "generate and pu= blish a TLSA record" record for hosted DNS customers.=0A=0AIt is gaining tr= action in mail / SMTP, with support in Postfix.=0A=0AAt the moment one of t= he main deployment hurdles is browser support (and more DNSSEC deployment!)= .=0ABrowsers (understandably) don't want to be waiting on TLSA records -- l= atency is really important for browsers, and waiting for more DNS lookups t= akes time.=0A=0AA few solutions have been discussed / suggested, such as on= ly doing DANE for self-signed certs, doing the TLSA lookup in parallel with= the regular lookup and making the normal connection, then aborting it (and= replacing the page with a notice) if DANE shows evidence of shennanigans a= nd / or caching TLSA records.=0A=0AW=0A=0A> Does it include changes to TLS = to accept/compare the server's certificate obtained from DANE?=A0 If so, th= en that part of the proposal can be mooted in favor of DANE.=0A>=A0 =0A> Ye= s, it would be simpler to offload the certificate sourcing management to DN= S.=A0 However, I'm proposing changes to be implemented entirely within TLS,= that are transparent on the client side.=A0 Only the server side would req= uire an additional interface to accept/reject client connections.=0A>=A0 = =0A> Karl=0A> =0A> From: Randy Bush =0A> To: Karl Malbrain <= malbrain@yahoo.com> =0A> Cc: Leif Johansson =0A> Sent: Frida= y, September 13, 2013 1:24 PM=0A> Subject: Re: [perpass] proposed enhanceme= nt to TLS strong authentication protocol=0A> =0A> [ off lst ]=0A> =0A> > I'= ve dropped the idea of including both client and server public=0A> > certif= icates in the directory in favor of a server certificate only=0A> > reposit= ory with an additional TLS interface to authorize access by=0A> > clients.= =0A> =0A> so why is this a win over dane?=0A> =0A> randy=0A> =0A> =0A> ____= ___________________________________________=0A> perpass mailing list=0A> pe= rpass@ietf.org=0A> https://www.ietf.org/mailman/listinfo/perpass=0A=0A--=0A= Hope is not a strategy.=0A=A0 =A0 =A0 --=A0 Ben Treynor, Google=0A=0A=0A___= ____________________________________________=0Aperpass mailing list=0Aperpa= ss@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/perpass ---781490481-245566440-1379110749=:99151 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Doesn't DA= NE produce the server's certificate in the same connection that DNS produce= s the servers IP address?  If not, that's an optimization that's neede= d.
 
 
=
Karl
From: Warren Kumari <warren@kum= ari.net>
To: Karl M= albrain <malbrain@yahoo.com>
Cc: Randy Bush <randy@psg.com>; Leif Johansson <leifj@mnt.se= >; "perpass@ietf.org" <perpass@ietf.org>; Warren Kumari <warren= @kumari.net>
Sent:= Friday, September 13, 2013 3:03 PM
Subject: Re: [perpass] proposed enhancement to TLS strong aut= hentication=09protocol

On Sep 13, 2013, at 4:40 PM, Karl Malbrain <malbrain@yahoo.com> wrote:

> I'm not familiar with DANE.  Is it operationa= l? 

Yes, it is just not widely (enough) deployed. There are so= me browser extensions and a browser (Bloodhound) that has support built in.= There are good tools to generate the DANE (TLSA) records, and e.g registro= .br has a simple one click "generate and publish a TLSA record" record for hosted = DNS customers.

It is gaining traction in mail / SMTP, with support i= n Postfix.

At the moment one of the main deployment hurdles is brows= er support (and more DNSSEC deployment!).
Browsers (understandably) don'= t want to be waiting on TLSA records -- latency is really important for bro= wsers, and waiting for more DNS lookups takes time.

A few solutions = have been discussed / suggested, such as only doing DANE for self-signed ce= rts, doing the TLSA lookup in parallel with the regular lookup and making t= he normal connection, then aborting it (and replacing the page with a notic= e) if DANE shows evidence of shennanigans and / or caching TLSA records.
W

> Does it include changes to TLS to accept/compare the ser= ver's certificate obtained from DANE?  If so, then that part of the pr= oposal can be mooted in favor of DANE.
> 
> Yes, it would be simpler to offload the certificate sourcing management to DNS.=   However, I'm proposing changes to be implemented entirely within TLS= , that are transparent on the client side.  Only the server side would= require an additional interface to accept/reject client connections.
&g= t; 
> Karl
>
> From: Randy Bush <randy@psg.com>> To: Karl Malbrain <malbrain@yahoo.com>
> Cc: Leif= Johansson <leifj@mnt.se>
> Sent: Friday, September 13, 2013 1:24 PM<= br>> Subject: Re: [perpass] proposed enhancement to TLS strong authentic= ation protocol
>
> [ off lst ]
>
> > I've drop= ped the idea of including both client and server public
> > certif= icates in the directory in favor of a server certificate only
> > reposi= tory with an additional TLS interface to authorize access by
> > c= lients.
>
> so why is this a win over dane?
>
> r= andy
>
>
> ____________________________________________= ___
> perpass mailing list
> perpass@ietf.org
> https:= //www.ietf.org/mailman/listinfo/perpass

--
Hope is not a stra= tegy.
      --  Ben Treynor, Google


_____= __________________________________________
perpass mailing list
perpass@= ietf.org
https://www.ietf.org/mailman/listinfo/perpass

<= br>
---781490481-245566440-1379110749=:99151-- From malbrain@yahoo.com Fri Sep 13 15:25:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198A121E80B3 for ; Fri, 13 Sep 2013 15:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMvtKhOkNLwY for ; Fri, 13 Sep 2013 15:25:06 -0700 (PDT) Received: from nm19-vm4.bullet.mail.ne1.yahoo.com (nm19-vm4.bullet.mail.ne1.yahoo.com [98.138.91.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13221E8096 for ; Fri, 13 Sep 2013 15:25:01 -0700 (PDT) Received: from [98.138.101.128] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:25:00 -0000 Received: from [98.138.87.8] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:25:00 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 22:25:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 633977.8274.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 94672 invoked by uid 60001); 13 Sep 2013 22:25:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379111100; bh=AqbNwRw2OrJTbAgoxJmqjhSlPRPuNLpZzH0qRsTsfUU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=4NjfQFzRNPnN0prfwzsXJW99FdiCIAHRzIiqKV6Te+YCovTqceccAgsxYcuzMBvefKJTF5hprRZCzYIihuoezJDGAryRbHlmw10G23jf2yYPSWgpwWjrLnWwFJIwViygrxeGvU3dVDRVBC6URVzPQNZkSzvVoN3s9yZvljVe9nU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tdcmshEHDnbf3Px2hxP0w3XMjK4nQ7D1mwW9xBTEjzOspFGVyR9cA8itCwl1z7kB4r+yu9Cv/Rfq2j0JVxquD7h3DcA2ETmLKhnntG5uKueymW+LYvBSs+jTFj+HusfxINCH0gEskjt6y0pLzNPV2seTuaj956cdnwr//HqaGdg=; X-YMail-OSG: K.D3hg8VM1nF3VUeoOKKBQbfLKsn8XGSaYBoiryhbmlv2TJ 0_owBe2rNWxgL7HX4XvUvM34HBBLIHg6xzcwsV6E7Kn_bm7u6Uclh_64aHIz kYmxVIgcTjVYWahjndOdD.enCfjiHDBy7lVzdLIzD2rQhnIK0MYugr6tmYRi 4gbSaLqKFLwE1O8YvXCIXCvjgk1WuZK4atQsWOXGqO6P5mxm8s268UBZG6LA QM_YEd0PF5UPzQ.7Tr_mQQnX1NeYnrGoks1alwgc11Of7JM9D3ad4tpbmoUg 3wvNUGi7zXKRuJGaPhJPcGJEbSLg88.5ubnepHzREGk1o00DHclG7UEFFVT3 vwzxX2kpjzXzZ7CgY14Lm1u6SzA3kjwsUpcO7sVYqDq.mTmc5kQlWuLP4wXd JdmBQJaXAvkFrHtKQs0YQ9M_qqqYascNpQY1Bmo4G4fqe7pUXCvRzEg9BIb9 U0Q0nI9wFD4GyPOGQeTXVjoJd_ssUj2SQAAq8Pgho6hXnVGzyrps4N9.S7pX EkFD68rBJ0QHQggZ1zOIj8o1E9yf_4L1tqTsEscA0m9j5qJH37gvd66TwNKM yXetE.yBSzPPkkADYYKdxqZS4vkUWjL5lHQ-- Received: from [206.169.92.130] by web125502.mail.ne1.yahoo.com via HTTP; Fri, 13 Sep 2013 15:25:00 PDT X-Rocket-MIMEInfo: 002.001, V2VsbCwgdGhlIGludGVyZmFjZSBpbXBsZW1lbnRhdGlvbiB0byBhdXRob3JpemUgYXV0aGVudGljYXRlZCBjbGllbnRzIGlzIG9wdGlvbmFsLsKgIFN0YXRpYyBodHRwIGNvbnRlbnQgc2VydmVycyBkb24ndCBuZWNlc3NhcmlseSBoYXZlIHRvIGtlZXAgdHJhY2sgb2YgdGhlaXIgY2xpZW50cyB5ZXQgd2FudCBhIHNlY3VyZSBjaGFubmVsIHRvIHRyYW5zbWl0IGNvbnRlbnQgY2hvaWNlc8KgcHJpdmF0ZWx5LgrCoApJJ20gcHJpbWFyaWx5IGFkZHJlc3NpbmcgYXBwbGljYXRpb24gc2VydmVycyBsaWtlIGdvb2cBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <52337E32.2050701@mnt.se> <1379107859.36612.YahooMailNeo@web125506.mail.ne1.yahoo.com> <1379110190.58129.YahooMailNeo@web125504.mail.ne1.yahoo.com> Message-ID: <1379111100.93991.YahooMailNeo@web125502.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 15:25:00 -0700 (PDT) From: Karl Malbrain To: Randy Bush In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1546730761-1622493429-1379111100=:93991" Cc: perpass Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 22:25:12 -0000 ---1546730761-1622493429-1379111100=:93991 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Well, the interface implementation to authorize authenticated clients is op= tional.=A0 Static http content servers don't necessarily have to keep track= of their clients yet want a secure channel to transmit content choices=A0p= rivately.=0A=A0=0AI'm primarily addressing application servers like google = mail, your bank, etc.=A0 The ones who need authentication.=0A=A0=0AKarl=0A = =0A=0A________________________________=0A From: Randy Bush = =0ATo: Karl Malbrain =0ACc: perpass = =0ASent: Friday, September 13, 2013 3:17 PM=0ASubject: Re: [perpass] propo= sed enhancement to TLS strong authentication=09protocol=0A =0A=0A> Most ht= tps protected channels are to servers with some sort of agency=0A> on behal= f of the client.=0A=0Anot today, and less and less in the future if the eff= orts here make=0Aprogress=0A=0Arandy=0A____________________________________= ___________=0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.or= g/mailman/listinfo/perpass ---1546730761-1622493429-1379111100=:93991 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Well, the = interface implementation to authorize authenticated clients is optional.&nb= sp; Static http content servers don't necessarily have to keep track of the= ir clients yet want a secure channel to transmit content choices priva= tely.
 
I'm primarily ad= dressing application servers like google mail, your bank, etc.  The on= es who need authentication.
 
= Karl

From: Randy Bu= sh <randy@psg.com>
To: Karl Malbrain <malbrain@yahoo.com>
Cc: perpass <perpass@ietf.org>
Sent: Friday, September 13, 2013 = 3:17 PM
Subject: Re: [= perpass] proposed enhancement to TLS strong authentication=09protocol
<= /font>

> Most https protected = channels are to servers with some sort of agency
> on behalf of the c= lient.

not today, and less and less in the future if the efforts her= e make
progress

randy
________________________________________= _______
perpass mailing list
perpass@ietf.org
https://www.i= etf.org/mailman/listinfo/perpass


---1546730761-1622493429-1379111100=:93991-- From warren@kumari.net Fri Sep 13 16:03:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7857E21F9360 for ; Fri, 13 Sep 2013 16:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulfI49TJyy0E for ; Fri, 13 Sep 2013 16:03:52 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396A921F92E7 for ; Fri, 13 Sep 2013 16:03:52 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id C2D5E1B401AB; Fri, 13 Sep 2013 19:03:51 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: <1379110749.99151.YahooMailNeo@web125505.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 19:03:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2E98A5F0-247F-48C2-ABF2-EA279CBD0D4C@kumari.net> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <1379110749.99151.YahooMailNeo@web125505.mail.ne1.yahoo.com> To: Karl Malbrain X-Mailer: Apple Mail (2.1508) Cc: Randy Bush , Leif Johansson , "perpass@ietf.org" , Warren Kumari Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 23:03:56 -0000 On Sep 13, 2013, at 6:19 PM, Karl Malbrain wrote: > Doesn't DANE produce the server's certificate in the same connection = that DNS produces the servers IP address? Nope.=20 > If not, that's an optimization that's needed. Would be nice, but, unfortunately DNS doesn't really allow you to return = answers to questions that the client didn't ask=85 There are all sorts of sexy (and dangerous :-)) things that you could do = if it did... E.g. - if a client asks for the A record for www.example.com they are = presumably trying to reach my webserver and render a page -- which = contains images from images.example.com and some ads from = www.punchthemonkey.com, so I would like to be able to return: www.example.com 600 IN A 192.0.2.2 images.example.com 600 IN A 192.0.2.3 www.punchthemonkey.com 600 A 192.0.2.100. Or, even just returning MX responses in addition to A and AAA=85=20 W > =20 > =20 > Karl > From: Warren Kumari > To: Karl Malbrain =20 > Cc: Randy Bush ; Leif Johansson ; = "perpass@ietf.org" ; Warren Kumari =20= > Sent: Friday, September 13, 2013 3:03 PM > Subject: Re: [perpass] proposed enhancement to TLS strong = authentication protocol >=20 >=20 > On Sep 13, 2013, at 4:40 PM, Karl Malbrain wrote: >=20 > > I'm not familiar with DANE. Is it operational? =20 >=20 > Yes, it is just not widely (enough) deployed. There are some browser = extensions and a browser (Bloodhound) that has support built in. There = are good tools to generate the DANE (TLSA) records, and e.g registro.br = has a simple one click "generate and publish a TLSA record" record for = hosted DNS customers. >=20 > It is gaining traction in mail / SMTP, with support in Postfix. >=20 > At the moment one of the main deployment hurdles is browser support = (and more DNSSEC deployment!). > Browsers (understandably) don't want to be waiting on TLSA records -- = latency is really important for browsers, and waiting for more DNS = lookups takes time. >=20 > A few solutions have been discussed / suggested, such as only doing = DANE for self-signed certs, doing the TLSA lookup in parallel with the = regular lookup and making the normal connection, then aborting it (and = replacing the page with a notice) if DANE shows evidence of shennanigans = and / or caching TLSA records. >=20 > W >=20 > > Does it include changes to TLS to accept/compare the server's = certificate obtained from DANE? If so, then that part of the proposal = can be mooted in favor of DANE. > > =20 > > Yes, it would be simpler to offload the certificate sourcing = management to DNS. However, I'm proposing changes to be implemented = entirely within TLS, that are transparent on the client side. Only the = server side would require an additional interface to accept/reject = client connections. > > =20 > > Karl > >=20 > > From: Randy Bush > > To: Karl Malbrain =20 > > Cc: Leif Johansson =20 > > Sent: Friday, September 13, 2013 1:24 PM > > Subject: Re: [perpass] proposed enhancement to TLS strong = authentication protocol > >=20 > > [ off lst ] > >=20 > > > I've dropped the idea of including both client and server public > > > certificates in the directory in favor of a server certificate = only > > > repository with an additional TLS interface to authorize access by > > > clients. > >=20 > > so why is this a win over dane? > >=20 > > randy > >=20 > >=20 > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass >=20 > -- > Hope is not a strategy. > -- Ben Treynor, Google >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --=20 With Feudalism, it's your Count that votes. From malbrain@yahoo.com Fri Sep 13 16:35:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF54511E81A7 for ; Fri, 13 Sep 2013 16:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sijlm+4OkmS for ; Fri, 13 Sep 2013 16:35:21 -0700 (PDT) Received: from nm27-vm2.bullet.mail.ne1.yahoo.com (nm27-vm2.bullet.mail.ne1.yahoo.com [98.138.91.215]) by ietfa.amsl.com (Postfix) with ESMTP id 80DFA11E8149 for ; Fri, 13 Sep 2013 16:35:21 -0700 (PDT) Received: from [98.138.90.56] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 23:35:20 -0000 Received: from [98.138.226.166] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 23:35:20 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 13 Sep 2013 23:35:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 615072.20757.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 84478 invoked by uid 60001); 13 Sep 2013 23:35:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379115320; bh=Sd/tK8qj42JoXKjG8wzFSD/AUiCmI4zkjNWzHoG/r8o=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QX70nyFHwVc0PvV8V+rgRz2sZSMZhO6u8HrOqODwjJ/6X6+4PwgMh1NQlptqFvzj507LxWGx9R5vqjrCpCkq2PWmUr8k2ld2je72pWvCWCyZ3WWuC+LO4XlTodktON2xTlUE02aHps3XLFGk7Itz0PZZIfn6GNJBwDt1zo6TTMI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EVe0X1Z3p8NH5oSCdo/gS0FmJWIhFgO1KJXz7kEDjLVJsQFXYBqSseiVcMuRU2QuRcG3L88lGbNYtglRXH1vzCmxGSearBosuiZ5Y2V5UzH8eZSjgANqyp7AWrRpQTp0gjVTHop1df1MIFzZ1rvHjgLKMGMrqGZXnwJgSHvUrcg=; X-YMail-OSG: U3jckyAVM1npARcWR_578G9RRmnMzmAir0Tuj.C8.rNwdE3 jAg2nAtYZbUjDh_L82_0pVwbW8Y83.D87BQlIRuBmdG9sQoXEGtBWqpl96Xu Mr70htdXrOpLc7XpISoAvXZhcgy9RD6mLIlGVPIs1AfQGkyB7lxaxXVy_Qm. Aclx07TTQvGtsrQsO3LFN5a0VeD98lI56tQKVJVAy71Ztsn5HoibiOEmOjGV qlkLQzPwZMIP4YQfax0_AXk1ZrgeVjeZhjBdMWo.SfydgQLCLjdDv9c_q0Dc aVwgUpepAVvqFgb.4hR6hMMsnoGyasKm7FKj3R10lHztz0yZlF1vUKaEbpOd ANzgbnqcHvwt07Arp9H.BDRs7AVHwHx_IIrCVauUDIAn8NtR2VcZ2SDB8P7f nSHzbnUusWKekpjxKSSzzQL7KdxuArGYBHkIKGVOtwih656GF9ebghvTV3te 7x0gev2E98.1qBLSJiP1ojEePiRyodH5Vo663.ttVU1oghq8FlmUUZ4qq1dY 3PfNS5gb_czrTPU.Ye46A5xLAtTAPs_8WEP1iqE7_MiOVDDfMX58eS.D8BzH M.Di0sk8nsG3z9XEuYooEXPiqzeWh5.7fbbj.G8x_ztcXLDBUsRamVpyCpHv WaoAJR0PBZ5Vc4XFNmcKWKZQXpBwcepgoogU9T9IRAa5A1aXwrKGbEYtlDtb gAWeWmddEJfDBdl0MmGpGCVM2qumNZKxNlLbrFuFthdLmS.wksPcYTqvOoDV .s2v9_NJE0164oFfKTBY4SrxXamXWzaDA Received: from [206.169.92.130] by web125505.mail.ne1.yahoo.com via HTTP; Fri, 13 Sep 2013 16:35:20 PDT X-Rocket-MIMEInfo: 002.001, V2FycmVuLArCoApTaW5jZSBteSBwcm9wb3NhbCBpcyBub3cgaG9va2VkIHRvIHRoZSB3aWRlc3ByZWFkIGRlbG95bWVudMKgb2YgREFORSwgYW5kIGlmIERBTkUgaXMgYmVpbmcgaGluZGVyZWQgYnkgYW4gYW5jaWVudCBETlMgcHJvdG9jb2wgdGhhdCByZXF1aXJlcyBtdWx0aXBsZSBjb25uZWN0aW9ucyB0b8Kgc2VjdXJlIGHCoCBzZXJ2ZXIncyBjZXJ0aWZpY2F0ZSBhbmQgSVAgYWRkcmVzcywgSSdsbCBoYXZlIHRvIGluY2x1ZGUgYW4gaXRlbSBmb3IgRE5TIDIuMCB0aGF0IGFsbG93cyBmb3IgbXVsdGlwbGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <1379110749.99151.YahooMailNeo@web125505.mail.ne1.yahoo.com> <2E98A5F0-247F-48C2-ABF2-EA279CBD0D4C@kumari.net> Message-ID: <1379115320.83794.YahooMailNeo@web125505.mail.ne1.yahoo.com> Date: Fri, 13 Sep 2013 16:35:20 -0700 (PDT) From: Karl Malbrain To: Warren Kumari In-Reply-To: <2E98A5F0-247F-48C2-ABF2-EA279CBD0D4C@kumari.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-781490481-414940940-1379115320=:83794" Cc: Leif Johansson , "perpass@ietf.org" Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 23:35:26 -0000 ---781490481-414940940-1379115320=:83794 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Warren,=0A=C2=A0=0ASince my proposal is now hooked to the widespread deloym= ent=C2=A0of DANE, and if DANE is being hindered by an ancient DNS protocol = that requires multiple connections to=C2=A0secure a=C2=A0 server's certific= ate and IP address, I'll have to include an item for DNS 2.0 that allows fo= r multiple commands and multiple reponses in a simple cpio like data stream= .=0A=C2=A0=0AThanks for your help!!=0AKarl Malbrain=0A =0A=0A______________= __________________=0A From: Warren Kumari =0ATo: Karl Ma= lbrain =0ACc: Randy Bush ; Leif Johanss= on ; "perpass@ietf.org" ; Warren Kumari =0ASent: Friday, September 13, 2013 4:03 PM=0ASubject: Re:= [perpass] proposed enhancement to TLS strong=09authentication=09protocol= =0A =0A=0A=0AOn Sep 13, 2013, at 6:19 PM, Karl Malbrain wrote:=0A=0A> Doesn't DANE produce the server's certificate in the same = connection that DNS produces the servers IP address?=0A=0ANope. =0A=0A>=C2= =A0 If not, that's an optimization that's needed.=0A=0AWould be nice, but, = unfortunately DNS doesn't really allow you to return answers to questions t= hat the client didn't ask=E2=80=A6=0A=0AThere are all sorts of sexy (and da= ngerous :-)) things that you could do if it did...=0AE.g. - if a client ask= s for the A record for www.example.com they are presumably trying to reach = my webserver and render a page --=C2=A0 which contains images from images.e= xample.com and some ads from www.punchthemonkey.com, so I would like to be = able to return:=0A=0Awww.example.com=C2=A0 600 IN A 192.0.2.2=0Aimages.exa= mple.com 600 IN A 192.0.2.3=0Awww.punchthemonkey.com 600 A 192.0.2.100.=0A= =0AOr, even just returning MX responses in addition to A and AAA=E2=80=A6 = =0A=0AW=0A=0A=0A=0A>=C2=A0 =0A>=C2=A0 =0A> Karl=0A> From: Warren Kumari =0A> To: Karl Malbrain =0A> Cc: Randy = Bush ; Leif Johansson ; "perpass@ietf.org" ; Warren Kumari =0A> Sent: Friday, Septe= mber 13, 2013 3:03 PM=0A> Subject: Re: [perpass] proposed enhancement to TL= S strong authentication=C2=A0=C2=A0=C2=A0 protocol=0A> =0A> =0A> On Sep 13,= 2013, at 4:40 PM, Karl Malbrain wrote:=0A> =0A> > I'm= not familiar with DANE.=C2=A0 Is it operational?=C2=A0 =0A> =0A> Yes, it i= s just not widely (enough) deployed. There are some browser extensions and = a browser (Bloodhound) that has support built in. There are good tools to g= enerate the DANE (TLSA) records, and e.g registro.br has a simple one click= "generate and publish a TLSA record" record for hosted DNS customers.=0A> = =0A> It is gaining traction in mail / SMTP, with support in Postfix.=0A> = =0A> At the moment one of the main deployment hurdles is browser support (a= nd more DNSSEC deployment!).=0A> Browsers (understandably) don't want to be= waiting on TLSA records -- latency is really important for browsers, and w= aiting for more DNS lookups takes time.=0A> =0A> A few solutions have been = discussed / suggested, such as only doing DANE for self-signed certs, doing= the TLSA lookup in parallel with the regular lookup and making the normal = connection, then aborting it (and replacing the page with a notice) if DANE= shows evidence of shennanigans and / or caching TLSA records.=0A> =0A> W= =0A> =0A> > Does it include changes to TLS to accept/compare the server's c= ertificate obtained from DANE?=C2=A0 If so, then that part of the proposal = can be mooted in favor of DANE.=0A> >=C2=A0 =0A> > Yes, it would be simpler= to offload the certificate sourcing management to DNS.=C2=A0 However, I'm = proposing changes to be implemented entirely within TLS, that are transpare= nt on the client side.=C2=A0 Only the server side would require an addition= al interface to accept/reject client connections.=0A> >=C2=A0 =0A> > Karl= =0A> > =0A> > From: Randy Bush =0A> > To: Karl Malbrain =0A> > Cc: Leif Johansson =0A> > Sent: Frid= ay, September 13, 2013 1:24 PM=0A> > Subject: Re: [perpass] proposed enhanc= ement to TLS strong authentication protocol=0A> > =0A> > [ off lst ]=0A> > = =0A> > > I've dropped the idea of including both client and server public= =0A> > > certificates in the directory in favor of a server certificate onl= y=0A> > > repository with an additional TLS interface to authorize access b= y=0A> > > clients.=0A> > =0A> > so why is this a win over dane?=0A> > =0A> = > randy=0A> > =0A> > =0A> > _______________________________________________= =0A> > perpass mailing list=0A> > perpass@ietf.org=0A> > https://www.ietf.o= rg/mailman/listinfo/perpass=0A> =0A> --=0A> Hope is not a strategy.=0A>=C2= =A0 =C2=A0 =C2=A0 --=C2=A0 Ben Treynor, Google=0A> =0A> =0A> _____________= __________________________________=0A> perpass mailing list=0A> perpass@iet= f.org=0A> https://www.ietf.org/mailman/listinfo/perpass=0A> =0A> =0A> _____= __________________________________________=0A> perpass mailing list=0A> per= pass@ietf.org=0A> https://www.ietf.org/mailman/listinfo/perpass=0A=0A-- =0A= With Feudalism, it's your Count that votes.=0A=0A=0A_______________________= ________________________=0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps:= //www.ietf.org/mailman/listinfo/perpass ---781490481-414940940-1379115320=:83794 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Warren,
 
Since my proposal is now= hooked to the widespread deloyment of DANE, and if DANE is being hind= ered by an ancient DNS protocol that requires multiple connections to = secure a  server's certificate and IP address, I'll have to include an= item for DNS 2.0 that allows for multiple commands and multiple reponses i= n a simple cpio like data stream.
 
Thanks for your help!!
Karl Malbrain
From: Warren Kumari <warren@kumari.n= et>
To: Karl Malbra= in <malbrain@yahoo.com>
Cc:= Randy Bush <randy@psg.com>; Leif Johansson <leifj@mnt.= se>; "perpass@ietf.org" <perpass@ietf.org>; Warren Kumari <warr= en@kumari.net>
Sent: Friday, September 13, 2013 4:03 PM
Subject: Re: [perpass] proposed enhancement to TLS strong= =09authentication=09protocol


On Sep 13, 2013, at 6:19 PM, Karl Malbrain <malbrain@yahoo.= com> wrote:

> Doesn't DANE produce the server's certificate in the sa= me connection that DNS produces the servers IP address?

Nope.
>  If not, that's an optimization that's needed.

Would be = nice, but, unfortunately DNS doesn't really allow you to return answers to = questions that the client didn't ask=E2=80=A6

There are all sorts of= sexy (and dangerous :-)) things that you could do if it did...
E.g. - i= f a client asks for the A record for www.example.com they are presumably tr= ying to reach my webserver and render a page --  which contains images= from images.example.com and some ads from www.punchthemonkey.com, so I wou= ld like to be able to return:

www.example.com  600 IN A 192.0.= 2.2
images.example.com 600 IN A 192.0.2.3
www.punchthemonkey.com 600 = A 192.0.2.100.

Or, even just returning MX responses in addition to A= and AAA=E2=80=A6

W



> 
> 
&g= t; Karl
> From: Warren Kumari <warren@kumari.net>
> To: = Karl Malbrain <malbrain@yahoo.com>
> Cc: Randy Bush <<= a href=3D"mailto:randy@psg.com" ymailto=3D"mailto:randy@psg.com">randy@psg.= com>; Leif Johansson <leifj@mnt.se>; "perpass@ietf.org" <perpass@ie= tf.org>; Warren Kumari <warren@kumari.net>
> Sent: F= riday, September 13, 2013 3:03 PM
> Subject: Re: [perpass] proposed e= nhancement to TLS strong authentication    protocol
> =
>
> On Sep 13, 2013, at 4:40 PM, Karl Malbrain <malbrain@yahoo.com> wr= ote:
>
> > I'm not familiar with DANE.  Is it operatio= nal? 
>
> Yes, it is just not widely (enough) deployed. = There are some browser extensions and a browser (Bloodhound) that has suppo= rt built in. There are good tools to generate the DANE (TLSA) records, and = e.g registro.br has a simple one click "generate and publish a TLSA record"= record for hosted DNS customers.
>
> It is gaining traction i= n mail / SMTP, with support in Postfix.
>
> At the moment one = of the main deployment hurdles is browser support (and more DNSSEC deployme= nt!).
> Browsers (understandably) don't want to be waiting on TLSA re= cords -- latency is really important for browsers, and waiting for more DNS= lookups takes time.
>
> A few solutions have been discussed / suggested, such as only doing DANE for self-signed certs, doin= g the TLSA lookup in parallel with the regular lookup and making the normal= connection, then aborting it (and replacing the page with a notice) if DAN= E shows evidence of shennanigans and / or caching TLSA records.
> > W
>
> > Does it include changes to TLS to accept/comp= are the server's certificate obtained from DANE?  If so, then that par= t of the proposal can be mooted in favor of DANE.
> > 
&g= t; > Yes, it would be simpler to offload the certificate sourcing manage= ment to DNS.  However, I'm proposing changes to be implemented entirel= y within TLS, that are transparent on the client side.  Only the serve= r side would require an additional interface to accept/reject client connec= tions.
> > 
> > Karl
> >
> > Fro= m: Randy Bush <randy@psg.com>
> > To: Ka= rl Malbrain <malbrain@yahoo.com>
> > Cc: Leif Johansso= n <leifj= @mnt.se>
> > Sent: Friday, September 13, 2013 1:24 PM
&= gt; > Subject: Re: [perpass] proposed enhancement to TLS strong authenti= cation protocol
> >
> > [ off lst ]
> >
>= ; > > I've dropped the idea of including both client and server publi= c
> > > certificates in the directory in favor of a server cert= ificate only
> > > repository with an additional TLS interface = to authorize access by
> > > clients.
> >
> >= ; so why is this a win over dane?
> >
> > randy
> = >
> >
> > _______________________________________________
> > perpass maili= ng list
> > perpass@ietf.org
> > https://www.ietf.org/m= ailman/listinfo/perpass
>
> --
> Hope is not a strat= egy.
>      --  Ben Treynor, Google
>
= >
> _______________________________________________
> perpa= ss mailing list
> perpass@ietf.org
> https://www.ietf.org/mai= lman/listinfo/perpass
>
>
> _______________________= ________________________
> perpass mailing list
> perpass@ietf.org=
> https://www.ietf.org/mailman/listinfo/perpass

--
With Feud= alism, it's your Count that votes.


_____________________________= __________________
perpass mailing list
perpass@ietf.org
https:= //www.ietf.org/mailman/listinfo/perpass

---781490481-414940940-1379115320=:83794-- From ynir@checkpoint.com Fri Sep 13 21:10:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53F11E815E for ; Fri, 13 Sep 2013 21:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.995 X-Spam-Level: X-Spam-Status: No, score=-9.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnjMYhXrUOoJ for ; Fri, 13 Sep 2013 21:10:32 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C49D511E80ED for ; Fri, 13 Sep 2013 21:10:31 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8E4ASvO018862; Sat, 14 Sep 2013 07:10:28 +0300 X-CheckPoint: {5233E1B4-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sat, 14 Sep 2013 07:10:28 +0300 From: Yoav Nir To: Karl Malbrain Thread-Topic: [perpass] proposed enhancement to TLS strong authentication protocol Thread-Index: AQHOsNn5s+tBQLm/M0+CU/xB7Icf/5nEbLOA Date: Sat, 14 Sep 2013 04:10:27 +0000 Message-ID: References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <1379110749.99151.YahooMailNeo@web125505.mail.ne1.yahoo.com> <2E98A5F0-247F-48C2-ABF2-EA279CBD0D4C@kumari.net> <1379115320.83794.YahooMailNeo@web125505.mail.ne1.yahoo.com> In-Reply-To: <1379115320.83794.YahooMailNeo@web125505.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.208] x-kse-antivirus-interceptor-info: protection disabled Content-Type: multipart/alternative; boundary="_000_B85F574814DA42C3AE0B537FA1C68F7Fcheckpointcom_" MIME-Version: 1.0 Cc: Leif Johansson , "perpass@ietf.org" , Warren Kumari Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 04:10:37 -0000 --_000_B85F574814DA42C3AE0B537FA1C68F7Fcheckpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi I don't think that's necessary. DNS queries are usually done over UDP, so t= here's no "connection", just an extra round-trip. And for the most part, th= e DNS server is very close to the client, so those are not very expensive r= ound-trips. And you can make multiple requests in the same message. What Wa= rren is suggesting is that the DNS gratuitously return records you might wa= nt soon, which would require the DNS to know a lot about the website, so I = don't think it's a worthwhile optimization. Yoav On Sep 14, 2013, at 2:35 AM, Karl Malbrain > wrote: Warren, Since my proposal is now hooked to the widespread deloyment of DANE, and if= DANE is being hindered by an ancient DNS protocol that requires multiple c= onnections to secure a server's certificate and IP address, I'll have to i= nclude an item for DNS 2.0 that allows for multiple commands and multiple r= eponses in a simple cpio like data stream. Thanks for your help!! Karl Malbrain From: Warren Kumari > To: Karl Malbrain > Cc: Randy Bush >; Leif Johansson >; "perpass@ietf.org" = >; Warren Kumari > Sent: Friday, September 13, 2013 4:03 PM Subject: Re: [perpass] proposed enhancement to TLS strong authentication pr= otocol On Sep 13, 2013, at 6:19 PM, Karl Malbrain > wrote: > Doesn't DANE produce the server's certificate in the same connection that= DNS produces the servers IP address? Nope. > If not, that's an optimization that's needed. Would be nice, but, unfortunately DNS doesn't really allow you to return an= swers to questions that the client didn't ask=85 There are all sorts of sexy (and dangerous :-)) things that you could do if= it did... E.g. - if a client asks for the A record for www.example.com they are presumably trying to reach my webserver and render a pag= e -- which contains images from images.example.com and some ads from www.punchthemonkey.com= , so I would like to be able to return: www.example.com 600 IN A 192.0.2.2 images.example.com 600 IN A 192.0.2.3 www.punchthemonkey.com 600 A 192.0.2.100. Or, even just returning MX responses in addition to A and AAA=85 W > > > Karl > From: Warren Kumari > > To: Karl Malbrain > > Cc: Randy Bush >; Leif Johansson >; "perpass@ietf.org= " >; Warren Kumari > > Sent: Friday, September 13, 2013 3:03 PM > Subject: Re: [perpass] proposed enhancement to TLS strong authentication = protocol > > > On Sep 13, 2013, at 4:40 PM, Karl Malbrain > wrote: > > > I'm not familiar with DANE. Is it operational? > > Yes, it is just not widely (enough) deployed. There are some browser exte= nsions and a browser (Bloodhound) that has support built in. There are good= tools to generate the DANE (TLSA) records, and e.g registro.br has a simple one click "generate and publish a TLSA record" record= for hosted DNS customers. > > It is gaining traction in mail / SMTP, with support in Postfix. > > At the moment one of the main deployment hurdles is browser support (and = more DNSSEC deployment!). > Browsers (understandably) don't want to be waiting on TLSA records -- lat= ency is really important for browsers, and waiting for more DNS lookups tak= es time. > > A few solutions have been discussed / suggested, such as only doing DANE = for self-signed certs, doing the TLSA lookup in parallel with the regular l= ookup and making the normal connection, then aborting it (and replacing the= page with a notice) if DANE shows evidence of shennanigans and / or cachin= g TLSA records. > > W > > > Does it include changes to TLS to accept/compare the server's certifica= te obtained from DANE? If so, then that part of the proposal can be mooted= in favor of DANE. > > > > Yes, it would be simpler to offload the certificate sourcing management= to DNS. However, I'm proposing changes to be implemented entirely within = TLS, that are transparent on the client side. Only the server side would r= equire an additional interface to accept/reject client connections. > > > > Karl > > > > From: Randy Bush > > > To: Karl Malbrain > > > Cc: Leif Johansson > > > Sent: Friday, September 13, 2013 1:24 PM > > Subject: Re: [perpass] proposed enhancement to TLS strong authenticatio= n protocol > > > > [ off lst ] > > > > > I've dropped the idea of including both client and server public > > > certificates in the directory in favor of a server certificate only > > > repository with an additional TLS interface to authorize access by > > > clients. > > > > so why is this a win over dane? > > > > randy > > > > > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass > > -- > Hope is not a strategy. > -- Ben Treynor, Google > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass -- With Feudalism, it's your Count that votes. _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass --_000_B85F574814DA42C3AE0B537FA1C68F7Fcheckpointcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <57F9211BEAC01C44856638767AE111F8@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi

I don't think that's necessary. DNS queries are usually done over UDP,= so there's no "connection", just an extra round-trip. And for th= e most part, the DNS server is very close to the client, so those are not v= ery expensive round-trips. And you can make multiple requests in the same message. What Warren is suggesting is that t= he DNS gratuitously return records you might want soon, which would require= the DNS to know a lot about the website, so I don't think it's a worthwhil= e optimization.

Yoav

On Sep 14, 2013, at 2:35 AM, Karl Malbrain <malbrain@yahoo.com> wrote:

Warren,
 
Since my proposal is now hooked to the widespread deloyment = ;of DANE, and if DANE is being hindered by an ancient DNS protocol that req= uires multiple connections to secure a  server's certificate and = IP address, I'll have to include an item for DNS 2.0 that allows for multiple commands and multiple reponses in a simple cp= io like data stream.
 
Thanks for your help!!
Karl Malbrain


On Sep 13, 2013, at 6:19 PM, Karl Malbrain <malbrain@yahoo.com> = wrote:

> Doesn't DANE produce the server's certificate in the same connection t= hat DNS produces the servers IP address?

Nope.

>  If not, that's an optimization that's needed.

Would be nice, but, unfortunately DNS doesn't really allow you to return an= swers to questions that the client didn't ask=85

There are all sorts of sexy (and dangerous :-)) things that you could do if= it did...
E.g. - if a client asks for the A record for www.example.com they are presumably trying to reach my webserver a= nd render a page --  which contains images from images.example.com and some ads f= rom www.punchthemonkey.com, so I would like to be able to return:

www.example.com  600 IN A 192.0= .2.2
images.example.com 600 IN A 192.0= .2.3
www.punchthemonkey.com 600 A = 192.0.2.100.

Or, even just returning MX responses in addition to A and AAA=85

W



> 
> 
> Karl
> From: Warren Kumari <warren@kumari.net>
> To: Karl Malbrain <malbrain@yahoo.com>
> Cc: Randy Bush <randy@psg.com>; Leif Johansson <leifj@mnt.se>; "<= a href=3D"mailto:perpass@ietf.org" ymailto=3D"mailto:perpass@ietf.org">perp= ass@ietf.org" <perpass@ietf.org>; Warren Kumari <warren@kumari.net>
> Sent: Friday, September 13, 2013 3:03 PM
> Subject: Re: [perpass] proposed enhancement to TLS strong authenticati= on    protocol
>
>
> On Sep 13, 2013, at 4:40 PM, Karl Malbrain <malbrain@yahoo.com= > wrote:
>
> > I'm not familiar with DANE.  Is it operational? 
>
> Yes, it is just not widely (enough) deployed. There are some browser e= xtensions and a browser (Bloodhound) that has support built in. There are g= ood tools to generate the DANE (TLSA) records, and e.g registro.br has a simple one click "= ;generate and publish a TLSA record" record for hosted DNS customers.<= br> >
> It is gaining traction in mail / SMTP, with support in Postfix.
>
> At the moment one of the main deployment hurdles is browser support (a= nd more DNSSEC deployment!).
> Browsers (understandably) don't want to be waiting on TLSA records -- = latency is really important for browsers, and waiting for more DNS lookups = takes time.
>
> A few solutions have been discussed / suggested, such as only doing DA= NE for self-signed certs, doing the TLSA lookup in parallel with the regula= r lookup and making the normal connection, then aborting it (and replacing = the page with a notice) if DANE shows evidence of shennanigans and / or caching TLSA records.
>
> W
>
> > Does it include changes to TLS to accept/compare the server's cer= tificate obtained from DANE?  If so, then that part of the proposal ca= n be mooted in favor of DANE.
> > 
> > Yes, it would be simpler to offload the certificate sourcing mana= gement to DNS.  However, I'm proposing changes to be implemented entir= ely within TLS, that are transparent on the client side.  Only the ser= ver side would require an additional interface to accept/reject client connections.
> > 
> > Karl
> >
> > From: Randy Bush <randy@psg.com>
> > To: Karl Malbrain <malbrain@yahoo.com>
> > Cc: Leif Johansson <leifj@mnt.se>
> > Sent: Friday, September 13, 2013 1:24 PM
> > Subject: Re: [perpass] proposed enhancement to TLS strong authent= ication protocol
> >
> > [ off lst ]
> >
> > > I've dropped the idea of including both client and server pu= blic
> > > certificates in the directory in favor of a server certifica= te only
> > > repository with an additional TLS interface to authorize acc= ess by
> > > clients.
> >
> > so why is this a win over dane?
> >
> > randy
> >
> >
> > _______________________________________________
> > perpass mailing list
> > perpass@ietf.org
> > https://www.ietf.org/mailman/listinfo/perpass
>
> --
> Hope is not a strategy.
>      --  Ben Treynor, Google
>
>
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
>
>
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass

--
With Feudalism, it's your Count that votes.


_______________________________________________
perpass mailing list
per= pass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

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

--_000_B85F574814DA42C3AE0B537FA1C68F7Fcheckpointcom_-- From bmanning@isi.edu Fri Sep 13 21:13:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2413711E8131 for ; Fri, 13 Sep 2013 21:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lRURd6nBDCo for ; Fri, 13 Sep 2013 21:13:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 779F211E80ED for ; Fri, 13 Sep 2013 21:13:20 -0700 (PDT) Received: from [192.168.0.3] (cpe-24-24-228-167.socal.res.rr.com [24.24.228.167]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r8E4Cb3J014574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Sep 2013 21:12:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: manning bill In-Reply-To: <52329A7A.7060103@headstrong.de> Date: Fri, 13 Sep 2013 21:12:37 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <52329A7A.7060103@headstrong.de> To: Moritz Bartl X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: perpass@ietf.org Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 04:13:25 -0000 is there a good reason to remove support for address literals? are you _really_ forcing a critical dependence on the DNS? /bill On 12September2013Thursday, at 21:54, Moritz Bartl wrote: > Hi, > > I would very much like to see servers having a minimal logging policy by > default, especially and at least when it comes to IP addresses. I wonder > if RFC 6302 is the right document to look at or extend for this. > > It is easy to flip a switch to enable IP logging. The default should be > no IP logs, which is true for most XMPP servers, for example, but not > for web or mail servers. > > On a side node, can we do anything to get rid of sender IP addresses in > (the first) Received headers of mail? > > -- Moritz > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From bmanning@isi.edu Fri Sep 13 21:15:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393F611E80F3 for ; Fri, 13 Sep 2013 21:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMNesi3+gZUj for ; Fri, 13 Sep 2013 21:14:58 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CF4CD11E80ED for ; Fri, 13 Sep 2013 21:14:58 -0700 (PDT) Received: from [192.168.0.3] (cpe-24-24-228-167.socal.res.rr.com [24.24.228.167]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r8E4ETII026170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Sep 2013 21:14:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: <52330712.8060104@cs.tcd.ie> Date: Fri, 13 Sep 2013 21:14:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E696900-9C24-42BA-ABC6-E6F652D40A7D@isi.edu> References: <52329A7A.7060103@headstrong.de> <52330712.8060104@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: perpass@ietf.org, Moritz Bartl Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 04:15:03 -0000 sure, i'm sure this will be complex and difficult=85 /bill On 13September2013Friday, at 5:37, Stephen Farrell wrote: >=20 >=20 > On 09/13/2013 05:54 AM, Moritz Bartl wrote: >> Hi, >>=20 >> I would very much like to see servers having a minimal logging policy = by >> default, especially and at least when it comes to IP addresses. I = wonder >> if RFC 6302 is the right document to look at or extend for this. >=20 > Or obsolete it. >=20 >>=20 >> It is easy to flip a switch to enable IP logging. The default should = be >> no IP logs, which is true for most XMPP servers, for example, but not >> for web or mail servers. >=20 > The wonderfully ironically named PRISM [1] project was an EU funded > project that did some work on obfuscating IP addresses in logs. >=20 > I'd love to see an RFC that described such techniques and recommended > when to use what, so we could point people at that. >=20 > Any takers for a -00 to get that going? >=20 > S. >=20 > [1] http://www.fp7-prism.eu/ >=20 >>=20 >> On a side node, can we do anything to get rid of sender IP addresses = in >> (the first) Received headers of mail? >>=20 >> -- Moritz >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >>=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From bclaise@cisco.com Sat Sep 14 04:02:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1422B11E8159 for ; Sat, 14 Sep 2013 04:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6e3wz2onblFm for ; Sat, 14 Sep 2013 04:02:05 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 68F6C11E8156 for ; Sat, 14 Sep 2013 04:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1361; q=dns/txt; s=iport; t=1379156525; x=1380366125; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gBfxoaqoh9gUDPcE+zTmXZA04sTAbs0TMUw8LAZp+Es=; b=CCLf6HDxHlS70D4z7clVrJoJBGPsoH4nT0Zvf/TwFv0G0oQ8UbxsGmr5 w1wUrX2cwl5tPWCjPQI5sJS6iMC8+cj2APJS39DWd9zpDRGyYC7WQZEmT A4Ubk9PKmIcwhD271UmJ/mQkrdMwl6McL4DI5xrgU1F7TnwOJiJCF+DL5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFALhBNFKQ/khR/2dsb2JhbABbgwc4wU2BHBZ0giUBAQEEAQEBNTYKARALGAkWDwkDAgECARUwBg0BBQIBAYd/DLoijjqBOQeEHgOXe4Ywi0SDJjqBNQ X-IronPort-AV: E=Sophos;i="4.90,903,1371081600"; d="scan'208";a="18009329" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 14 Sep 2013 11:02:04 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8EB22YX003882; Sat, 14 Sep 2013 11:02:02 GMT Message-ID: <5234422A.3010003@cisco.com> Date: Sat, 14 Sep 2013 13:02:02 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <52329A7A.7060103@headstrong.de> <52330712.8060104@cs.tcd.ie> In-Reply-To: <52330712.8060104@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Moritz Bartl Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 11:02:10 -0000 On 13/09/2013 14:37, Stephen Farrell wrote: > > On 09/13/2013 05:54 AM, Moritz Bartl wrote: >> Hi, >> >> I would very much like to see servers having a minimal logging policy by >> default, especially and at least when it comes to IP addresses. I wonder >> if RFC 6302 is the right document to look at or extend for this. > Or obsolete it. > >> It is easy to flip a switch to enable IP logging. The default should be >> no IP logs, which is true for most XMPP servers, for example, but not >> for web or mail servers. > The wonderfully ironically named PRISM [1] project was an EU funded > project that did some work on obfuscating IP addresses in logs. rfc6235 Regards, Benoit > > I'd love to see an RFC that described such techniques and recommended > when to use what, so we could point people at that. > > Any takers for a -00 to get that going? > > S. > > [1] http://www.fp7-prism.eu/ > >> On a side node, can we do anything to get rid of sender IP addresses in >> (the first) Received headers of mail? >> >> -- Moritz >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > . > From bmanning@isi.edu Sat Sep 14 05:35:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381C311E8173 for ; Sat, 14 Sep 2013 05:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.099 X-Spam-Level: X-Spam-Status: No, score=-93.099 tagged_above=-999 required=5 tests=[AWL=-10.500, BAYES_00=-2.599, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxDT8oM68L2b for ; Sat, 14 Sep 2013 05:35:20 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id DCD0011E8174 for ; Sat, 14 Sep 2013 05:35:19 -0700 (PDT) Received: from [192.168.0.3] (cpe-24-24-228-167.socal.res.rr.com [24.24.228.167]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r8ECYZoW002385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Sep 2013 05:34:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: Date: Sat, 14 Sep 2013 05:34:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24D28BB6-725F-4E78-8786-C1F749782F98@isi.edu> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <1379110749.99151.YahooMailNeo@web125505.mail.ne1.yahoo.com> <2E98A5F0-247F-48C2-ABF2-EA279CBD0D4C@kumari.net> <1379115320.83794.YahooMailNeo@web125505.mail.ne1.yahoo.com> To: Yoav Nir X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: Leif Johansson , "perpass@ietf.org" , Warren Kumari , Karl Malbrain Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 12:35:24 -0000 its not at all clear that the DNS service is "close" to the client - the = last two studies indicate that DNS service is usually tied to a business = relationship or a trust relationship. this will only increase with the lack of DNSSEC validation in the end = system. as for prefetching, one -could- prefetch, I guess, but that = would still be the normal query/response unless one were to redesign the DNS protocol=85 =20 /bill On 13September2013Friday, at 21:10, Yoav Nir wrote: > Hi >=20 > I don't think that's necessary. DNS queries are usually done over UDP, = so there's no "connection", just an extra round-trip. And for the most = part, the DNS server is very close to the client, so those are not very = expensive round-trips. And you can make multiple requests in the same = message. What Warren is suggesting is that the DNS gratuitously return = records you might want soon, which would require the DNS to know a lot = about the website, so I don't think it's a worthwhile optimization. >=20 > Yoav >=20 > On Sep 14, 2013, at 2:35 AM, Karl Malbrain wrote: >=20 >> Warren, >> =20 >> Since my proposal is now hooked to the widespread deloyment of DANE, = and if DANE is being hindered by an ancient DNS protocol that requires = multiple connections to secure a server's certificate and IP address, = I'll have to include an item for DNS 2.0 that allows for multiple = commands and multiple reponses in a simple cpio like data stream. >> =20 >> Thanks for your help!! >> Karl Malbrain >> From: Warren Kumari >> To: Karl Malbrain =20 >> Cc: Randy Bush ; Leif Johansson ; = "perpass@ietf.org" ; Warren Kumari =20= >> Sent: Friday, September 13, 2013 4:03 PM >> Subject: Re: [perpass] proposed enhancement to TLS strong = authentication protocol >>=20 >>=20 >> On Sep 13, 2013, at 6:19 PM, Karl Malbrain = wrote: >>=20 >> > Doesn't DANE produce the server's certificate in the same = connection that DNS produces the servers IP address? >>=20 >> Nope.=20 >>=20 >> > If not, that's an optimization that's needed. >>=20 >> Would be nice, but, unfortunately DNS doesn't really allow you to = return answers to questions that the client didn't ask=85 >>=20 >> There are all sorts of sexy (and dangerous :-)) things that you could = do if it did... >> E.g. - if a client asks for the A record for www.example.com they are = presumably trying to reach my webserver and render a page -- which = contains images from images.example.com and some ads from = www.punchthemonkey.com, so I would like to be able to return: >>=20 >> www.example.com 600 IN A 192.0.2.2 >> images.example.com 600 IN A 192.0.2.3 >> www.punchthemonkey.com 600 A 192.0.2.100. >>=20 >> Or, even just returning MX responses in addition to A and AAA=85=20 >>=20 >> W >>=20 >>=20 >>=20 >> > =20 >> > =20 >> > Karl >> > From: Warren Kumari >> > To: Karl Malbrain =20 >> > Cc: Randy Bush ; Leif Johansson ; = "perpass@ietf.org" ; Warren Kumari =20= >> > Sent: Friday, September 13, 2013 3:03 PM >> > Subject: Re: [perpass] proposed enhancement to TLS strong = authentication protocol >> >=20 >> >=20 >> > On Sep 13, 2013, at 4:40 PM, Karl Malbrain = wrote: >> >=20 >> > > I'm not familiar with DANE. Is it operational? =20 >> >=20 >> > Yes, it is just not widely (enough) deployed. There are some = browser extensions and a browser (Bloodhound) that has support built in. = There are good tools to generate the DANE (TLSA) records, and e.g = registro.br has a simple one click "generate and publish a TLSA record" = record for hosted DNS customers. >> >=20 >> > It is gaining traction in mail / SMTP, with support in Postfix. >> >=20 >> > At the moment one of the main deployment hurdles is browser support = (and more DNSSEC deployment!). >> > Browsers (understandably) don't want to be waiting on TLSA records = -- latency is really important for browsers, and waiting for more DNS = lookups takes time. >> >=20 >> > A few solutions have been discussed / suggested, such as only doing = DANE for self-signed certs, doing the TLSA lookup in parallel with the = regular lookup and making the normal connection, then aborting it (and = replacing the page with a notice) if DANE shows evidence of shennanigans = and / or caching TLSA records. >> >=20 >> > W >> >=20 >> > > Does it include changes to TLS to accept/compare the server's = certificate obtained from DANE? If so, then that part of the proposal = can be mooted in favor of DANE. >> > > =20 >> > > Yes, it would be simpler to offload the certificate sourcing = management to DNS. However, I'm proposing changes to be implemented = entirely within TLS, that are transparent on the client side. Only the = server side would require an additional interface to accept/reject = client connections. >> > > =20 >> > > Karl >> > >=20 >> > > From: Randy Bush >> > > To: Karl Malbrain =20 >> > > Cc: Leif Johansson =20 >> > > Sent: Friday, September 13, 2013 1:24 PM >> > > Subject: Re: [perpass] proposed enhancement to TLS strong = authentication protocol >> > >=20 >> > > [ off lst ] >> > >=20 >> > > > I've dropped the idea of including both client and server = public >> > > > certificates in the directory in favor of a server certificate = only >> > > > repository with an additional TLS interface to authorize access = by >> > > > clients. >> > >=20 >> > > so why is this a win over dane? >> > >=20 >> > > randy >> > >=20 >> > >=20 >> > > _______________________________________________ >> > > perpass mailing list >> > > perpass@ietf.org >> > > https://www.ietf.org/mailman/listinfo/perpass >> >=20 >> > -- >> > Hope is not a strategy. >> > -- Ben Treynor, Google >> >=20 >> >=20 >> > _______________________________________________ >> > perpass mailing list >> > perpass@ietf.org >> > https://www.ietf.org/mailman/listinfo/perpass >> >=20 >> >=20 >> > _______________________________________________ >> > perpass mailing list >> > perpass@ietf.org >> > https://www.ietf.org/mailman/listinfo/perpass >>=20 >> --=20 >> With Feudalism, it's your Count that votes. >>=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From sm@resistor.net Sat Sep 14 07:38:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A1F11E80EA for ; Sat, 14 Sep 2013 07:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNRR5T+Mb33a for ; Sat, 14 Sep 2013 07:38:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3549E11E8195 for ; Sat, 14 Sep 2013 07:38:16 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8EEcBCh026201; Sat, 14 Sep 2013 07:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379169495; bh=+ebVQMmp1/hzEgIoG9IOZD5/utKeNAmVibUfo8tqxwA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hN+MnIU6IJwXhj7WdltdxDpMY5iAPwSGetgQzDdivZLzNl7K7CzT3mRp0FtCYfZfZ eGZ0ud7lvWvCopPzE8cv6SCNr+5KHqIKYuWdH1u1d+uDwd4S0qLzBzIwFLSyTrBB2f p3faGxgr1UdVDhT470ob8PDLmEN59leYBFFcaGxc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1379169495; i=@resistor.net; bh=+ebVQMmp1/hzEgIoG9IOZD5/utKeNAmVibUfo8tqxwA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rK9B6+Gg/kBy9J9tlgN1a8/3Ka+z4Lc47fpNb650co7XFm0vKT+m//eLsymz1wm0t TvSGFp/zJegZRnZUxBpGDK1HigZikx+9NXxhYRU4JUnK1f/aWCVBkbA8C5zt2w3Byt 44G25pUlwr1H0oF4dyFxC3lQl788lskFROVWpSQM= Message-Id: <6.2.5.6.2.20130914054829.0b2a32d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Sep 2013 06:55:40 -0700 To: Dean Willis From: SM In-Reply-To: <7DA623C5-E8C4-437F-BFC9-0CDD350853A8@softarmor.com> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <7DA623C5-E8C4-437F-BFC9-0CDD350853A8@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 14:38:18 -0000 Hi Dean, At 10:12 13-09-2013, Dean Willis wrote: >So unless we have widespread review, from people likely to be in the >influence of multiple and conflicting actors, we really haven't had >a review. How widespread? I'm not exactly sure -- but it means more >than one review, from more than one company, from more than one >sector, and from more than one nation-state at a minimum. Trust is >really hard; our best substitute is a very widespread consensus. > >Arguably, the mode that we've operated in for many years has given >us a rather bad current situation. Perhaps we should reassess "good enough". The IETF has been operating in "good enough" mode since a long time. Some proposals do not get widespread review. There are variations of RFC 6302 in the IETF RFCs. When I raised a "privacy issue" some time back the only person who supported the argument was Stephen Farrell. The amount of effort to raise a "privacy issue" is discouraging. It's difficult to ensure review from more than one nation-state when the majority is from one nation-state. It is not always clear what the company or sector ties are. There is a report of a Tor exit node being compromised. It's unlikely that the problem could have been avoided with better encryption. The architectural aspect of the problem was mentioned in 2005. Regards, -sm From sm@resistor.net Sat Sep 14 07:38:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786F621E811D for ; Sat, 14 Sep 2013 07:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhJe46jM2ffl for ; Sat, 14 Sep 2013 07:38:26 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F6E21E8121 for ; Sat, 14 Sep 2013 07:38:26 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8EEcBCj026201; Sat, 14 Sep 2013 07:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379169499; bh=qAcB+jNx2ONklBipB/llLKpEPurusQNsZPKfAB8uDPI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zcbiPxsvahhsBTu8kesnpzyZ+qqcaHanzoCzon8feHUkrAvR+LJXX6FnjA2tOF+kj 6W8Ml7IpTFMcn+Pz15B35l4mPU9VZuoFzNxtDrq5I7zj+aCBWze4o5SIsf99B7nNc8 bc5Yo5VoEMcqFu8SpsXPY9MuYcQ9FisSH+3fa+QQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1379169499; i=@resistor.net; bh=qAcB+jNx2ONklBipB/llLKpEPurusQNsZPKfAB8uDPI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=m50dgcSc49A+Jb9NHg1T02hFimPc/Cb2zEYDhCW49jGtXPcoM/0lILIq4+pNOhda9 pAnewzcNqZcWyu6QvCvaMCrLgJ6uHLUsLmmFREuwdz7a2cBNxdZiKUUVErKt4OxFr0 xImsSMX+FafD1UyhGOMO3sKJn9R1IMxjd+Eh+koM= Message-Id: <6.2.5.6.2.20130914065822.0b287268@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Sep 2013 07:31:12 -0700 To: Moritz Bartl From: SM In-Reply-To: <52329A7A.7060103@headstrong.de> References: <52329A7A.7060103@headstrong.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 14:38:26 -0000 Hi Moritz, At 21:54 12-09-2013, Moritz Bartl wrote: >On a side node, can we do anything to get rid of sender IP addresses in >(the first) Received headers of mail? Yes. Someone can write an Internet-Draft which recommends that such information should not be included. Regards, -sm From jacob@appelbaum.net Sat Sep 14 10:58:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E18111E81B7 for ; Sat, 14 Sep 2013 10:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+5WcKMGwBdM for ; Sat, 14 Sep 2013 10:58:08 -0700 (PDT) Received: from mail-ye0-f173.google.com (mail-ye0-f173.google.com [209.85.213.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8F711E8172 for ; Sat, 14 Sep 2013 10:58:08 -0700 (PDT) Received: by mail-ye0-f173.google.com with SMTP id m3so971942yen.4 for ; Sat, 14 Sep 2013 10:58:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=i+txK/bNfSOojBCh4Y8PuJjy2D+3BcO9FcXynw+2z3E=; b=iRDCzDu9zRGOL4NAitQKD5vY5NwPmSjGBZ0v9HR6JaNICl71TwDzpTaq5Ft9CiyQZG WyQqO1WkQPHxwzs3XTF2MI083VQIxRhBZsF+SrBcHMt2iYLG1r23r7QZrusUZyyivH+L jnzBPC9N0GvG3UMJ8L6my/s3uDMYXQIvQCyvqHzVX8ZBwRF/1pccAbgd1sLVN5Spr5yv ULMIQBYD66ipcuw8tZnV7CexZX5jNdyv0lGiosk2smc58y9DfxhxHi5DoMrrWDqovf1+ kp7C4Db5WGuzPfBERaLJ3Vr/4B4JVUCD3w5Mz8jaACUlYTQni8x8puKyHuTjKfzRNuVi HaqQ== X-Gm-Message-State: ALoCoQnqoCdBkQqu294f5JMjH94cgoIUMVi9DCrGenI5TXBM/u94+3DdZiWCjIqiOfaAl7kKcJuI X-Received: by 10.236.85.237 with SMTP id u73mr72777yhe.67.1379181487723; Sat, 14 Sep 2013 10:58:07 -0700 (PDT) Received: from 127.0.0.1 (wannabe.torservers.net. [96.47.226.22]) by mx.google.com with ESMTPSA id d26sm21495844yhk.21.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 10:58:07 -0700 (PDT) Message-ID: <5234A2E3.2050604@appelbaum.net> Date: Sat, 14 Sep 2013 17:54:43 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: perpass@ietf.org References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <7DA623C5-E8C4-437F-BFC9-0CDD350853A8@softarmor.com> <6.2.5.6.2.20130914054829.0b2a32d8@resistor.net> In-Reply-To: <6.2.5.6.2.20130914054829.0b2a32d8@resistor.net> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 17:58:14 -0000 SM: > Hi Dean, > At 10:12 13-09-2013, Dean Willis wrote: >> So unless we have widespread review, from people likely to be in the >> influence of multiple and conflicting actors, we really haven't had a >> review. How widespread? I'm not exactly sure -- but it means more than >> one review, from more than one company, from more than one sector, and >> from more than one nation-state at a minimum. Trust is really hard; >> our best substitute is a very widespread consensus. >> >> Arguably, the mode that we've operated in for many years has given us >> a rather bad current situation. Perhaps we should reassess "good enough". > > The IETF has been operating in "good enough" mode since a long time. > Some proposals do not get widespread review. There are variations of > RFC 6302 in the IETF RFCs. When I raised a "privacy issue" some time > back the only person who supported the argument was Stephen Farrell. > The amount of effort to raise a "privacy issue" is discouraging. > Seems like that isn't a problem now, right? Water under the bridge, perhaps? I have also seen a lot of IETF privacy and security weirdness but it is clear that things are improving now. > It's difficult to ensure review from more than one nation-state when the > majority is from one nation-state. It is not always clear what the > company or sector ties are. I don't think that this is a problem at all. I see people from a dozen countries on this list. > > There is a report of a Tor exit node being compromised. It's unlikely > that the problem could have been avoided with better encryption. The > architectural aspect of the problem was mentioned in 2005. > (Tor Developer here...) What are you referring to with regard to a Tor exit node being compromised? All the best, Jacob From nb@bollow.ch Sat Sep 14 12:07:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038C911E8181 for ; Sat, 14 Sep 2013 12:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RDQgCqdkXWl for ; Sat, 14 Sep 2013 12:06:58 -0700 (PDT) Received: from beta.bollow.ch (beta.bollow.ch [193.37.152.11]) by ietfa.amsl.com (Postfix) with ESMTP id 91EB011E818E for ; Sat, 14 Sep 2013 12:06:56 -0700 (PDT) Received: from quill (170-70.78-83.cust.bluewin.ch [83.78.70.170]) by beta.bollow.ch (Postfix) with ESMTPSA id C7C8F1404BD; Sat, 14 Sep 2013 21:11:15 +0200 (CEST) Date: Sat, 14 Sep 2013 21:06:55 +0200 From: Norbert Bollow To: perpass@ietf.org Message-ID: <20130914210655.067c9a68@quill> In-Reply-To: <5234A2E3.2050604@appelbaum.net> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <7DA623C5-E8C4-437F-BFC9-0CDD350853A8@softarmor.com> <6.2.5.6.2.20130914054829.0b2a32d8@resistor.net> <5234A2E3.2050604@appelbaum.net> Organization: GoalTree Empowerment X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 19:07:04 -0000 Jacob Appelbaum wrote: > SM: > > The IETF has been operating in "good enough" mode since a long > > time. Some proposals do not get widespread review. There are > > variations of RFC 6302 in the IETF RFCs. When I raised a "privacy > > issue" some time back the only person who supported the argument > > was Stephen Farrell. The amount of effort to raise a "privacy > > issue" is discouraging. > > > > Seems like that isn't a problem now, right? Water under the bridge, > perhaps? I have also seen a lot of IETF privacy and security weirdness > but it is clear that things are improving now. At some point in the future it will be good to do some kind of post mortem analysis to figure out how it happened that things went so badly off track in regard to privacy protection. But I agree, the Snowden disclosures definitely mark a turning point. Privacy concerns are going to get taken serious now. Greetings, Norbert From sm@resistor.net Sat Sep 14 12:57:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5152211E8227 for ; Sat, 14 Sep 2013 12:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk2YYmb3wRM5 for ; Sat, 14 Sep 2013 12:57:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7A111E8224 for ; Sat, 14 Sep 2013 12:57:39 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8EJvOru029347; Sat, 14 Sep 2013 12:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379188650; bh=MXSBBbruUP2flLZe7lGkFMA7am2bFUxqOyU5GDB+1hw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2DdT0M5QAZzr+ORsiVFMCmOyYKRuT1cnL0YgUmoxDzabaiwSEmVMaE7XYM2gKe0/e SY02LFUYAmguBrJMkFk/ZOZMBY3wXG32ax1AZVP+xmAEk7Siyu+l5qxWsvSfBqW0Ja qw1638mtMy6pc1/r2uiJK9ulWuRnsOzhMG8wq0kw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1379188650; i=@resistor.net; bh=MXSBBbruUP2flLZe7lGkFMA7am2bFUxqOyU5GDB+1hw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UvH0A3aTv5jjSWRR4fnzWdn13+HzG2FbLE+50oW3auAtqSziJ1dI9TgMA4u92NSS4 AVAFn1jcOgOn+dVB6LTidXs2APDSNzAV4OjfU8SvEATsvslf55ikIsViqf8yegBwCG TD46iXCrSjDvIuBGkbfBYpsamnRUPhhYCfyFvClQ= Message-Id: <6.2.5.6.2.20130914120157.0b38b130@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Sep 2013 12:36:11 -0700 To: Jacob Appelbaum From: SM In-Reply-To: <5234A2E3.2050604@appelbaum.net> References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <7DA623C5-E8C4-437F-BFC9-0CDD350853A8@softarmor.com> <6.2.5.6.2.20130914054829.0b2a32d8@resistor.net> <5234A2E3.2050604@appelbaum.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 19:57:41 -0000 Hi Jacob, At 10:54 14-09-2013, Jacob Appelbaum wrote: >Seems like that isn't a problem now, right? Water under the bridge, >perhaps? I have also seen a lot of IETF privacy and security weirdness >but it is clear that things are improving now. I already commented about the problem on the relevant list. There was an interesting message from Yoav Nir ( http://www.ietf.org/mail-archive/web/ietf/current/msg82383.html ). I don't know whether things are improving. >I don't think that this is a problem at all. I see people from a dozen >countries on this list. I commented on two drafts this week (see http://www.ietf.org/mail-archive/web/ietf/current/msg82438.html and http://www.ietf.org/mail-archive/web/ietf/current/msg82466.html ). I posted the following last year http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00230.html >What are you referring to with regard to a Tor exit node being compromised? I'll comment off-list. Regards, -sm From willchan@google.com Fri Sep 13 14:22:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB4921E809C for ; Fri, 13 Sep 2013 14:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQjVz1x13pZz for ; Fri, 13 Sep 2013 14:22:24 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 654AA11E80AD for ; Fri, 13 Sep 2013 14:22:24 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so3727502iej.38 for ; Fri, 13 Sep 2013 14:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3ikHsbbSUrpOXGG1TYyIuSojx+A9ypaaujPIMimoW9E=; b=W1jGDKd8FPkMdPU/cnIQ7VqhSfFD+mOQlLheMIIqcq8yfcKMqnII/ERfRQbvxRMSgR LvI+ghDDjXC4UpssDz5OL/mbjXuKjCIOUgcHM4P9I6kxKE6LlO7ef4iHaAF22RTdZjkH Rpd8xaii15nHrFuARNu+Sc3USy+tDskY2+PFi+MjjsvUfvOYlfv4eaHIPGDXPumfH6l7 iSsTT84qX/4ZpOZLnY/m6HvPy9zRSmal/Gmn8AZqnRhO8RJkVoCquxP0z61FTIQfa1qp Y8xN56QZVeGf/Q6qvU2I/WG8BfFeXvRk4e6cuPAezXsbFwrlIqu30mcBqJ8y2PLW09Rh 8hCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3ikHsbbSUrpOXGG1TYyIuSojx+A9ypaaujPIMimoW9E=; b=dUTJkpq+5aFWrqKPEd9Jc5ySSKmxOpPna1xaGDtZ4c69dyYInntBgFeuvBDTY8c6GD oL96ixrxbFxtWAyxPQfrQp1vehLs30DmboLQGvaxdGEe4pItAK1WmeMbaSeQblGY7l5n 6kI3rFOLl6dzNK8Bjkbt87G18OzGkB+3dwEkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3ikHsbbSUrpOXGG1TYyIuSojx+A9ypaaujPIMimoW9E=; b=ZCEhjL94Q7J5/Rslugoed86KXFT5JLgiZj2jwF2wiYiq6HXcdJ46D1AcUXi1TL/xg7 HYChn1XYNQd0tdBsOISBewOQvp2hzsdkW85S8Dtwm5/4cltsyiKKjyuqNeAsuCPIQVoA mso4xNYvshFCwu20Qxlp/OQL+893p5/7r0fmsiqMmc/RG5AnlY4G8G7Kj+uCrPjnfEqq mkJqA7UvgIJgR1Ifshe5c5LrUfMnJSQitPQe+w6Qd7flzYjXcfUyHiS/oK2wi8bXOFFs 6YnOZ4311WniV6KGYxEYkO9MJZN5T5aevKw660ARrczC2s1N7PqqwLviK7Blx4cENbHW 5YjA== X-Gm-Message-State: ALoCoQnBmoSYvAGq4RpsBuYSQTqc0u+0k2qZKTXmXjprwaZ+jatxmrcxpTH8Qoi8E1NE6/NAT5JF/HuK2NWDonlkb50veQ9CjEdHSyya6AJNdbDWo0VZPj0N8K80MLdBCGCsvcBmavXBjjvLqsGn9v1BFgX/Q9NyE5L1cTR8lz5GJanpQdnxD1eiCLMYUVTOynAz1gc1OJp6 MIME-Version: 1.0 X-Received: by 10.50.164.165 with SMTP id yr5mr1751022igb.38.1379107342573; Fri, 13 Sep 2013 14:22:22 -0700 (PDT) Sender: willchan@google.com Received: by 10.64.225.75 with HTTP; Fri, 13 Sep 2013 14:22:22 -0700 (PDT) In-Reply-To: <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> Date: Fri, 13 Sep 2013 14:22:22 -0700 X-Google-Sender-Auth: chQQR6tVT273jDBPf1G-zuOMDhg Message-ID: From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= To: Patrick Pelletier Content-Type: multipart/alternative; boundary=089e01229ed4430b7404e64a731d X-Mailman-Approved-At: Sat, 14 Sep 2013 16:55:36 -0700 Cc: perpass@ietf.org, HTTP Working Group , Stephen Farrell Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 21:22:25 -0000 --089e01229ed4430b7404e64a731d Content-Type: text/plain; charset=ISO-8859-1 Speaking as a browser vendor, we do try to limit the info we send in the UA string. It's sadly difficult. Please refer to http://webaim.org/blog/user-agent-string-history/. Changing the UA string breaks web compat, and when the end user's favorite site foo.com fails to render in browser X, the end user switches to browser Y. For a fairly recent discussion of this on the Chromium developer's mailing list, feel free to refer to https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/N78vBMOZlF8/tQ-xnJV1lVsJ . On Fri, Sep 13, 2013 at 12:18 PM, Patrick Pelletier < code@funwithsoftware.org> wrote: > Forwarding this idea along to httpbis as you (Stephen) suggested. > Although this could be retrofitted onto existing HTTP, not just httpbis, > since it's merely recommending practices which are already legal in HTTP. > > On Sep 13, 2013, at 5:17 AM, Stephen Farrell wrote: > > On 09/13/2013 04:12 AM, Patrick Pelletier wrote: >> >>> On 9/12/13 1:18 PM, Dave Crocker wrote: >>> >>> "privacy properties of IETF protocols and concrete ways in which >>>> those could be improved." >>>> >>> >>> One obvious thing is the amount of (usually unnecessary) information >>> leaked by the User-Agent field in HTTP. >>> >>> Should we downgrade the User-Agent field (section 14.43 of RFC 2616) >>> from a SHOULD to a MAY? >>> >> >> I think everyone finds those values problematic, and not only for >> privacy reasons. But yes, if you believe [1] then its probably the >> biggest contributor to browser fingerprinting that's in an IETF >> spec. (No idea if that site's evaluation is sound myself though.) >> >> [1] https://panopticlick.eff.org/ >> >> Or, if that's too radical, should we standardize a small number of fixed >>> strings to use in the User-Agent field? (For example, "Desktop/1.0" for >>> desktop browsers, "Mobile/1.0" for mobile browsers, "Text/1.0" for text >>> browsers like Lynx, "Batch/1.0" for non-interactive clients like curl >>> which are performing a task more specific than crawling the web, and >>> "Robot/1.0" for clients which are crawling the web?) >>> >> >> Interesting. An IANA registry of those kinds of value might just end >> up like the UA string though, which also started out nice and simple. >> > > I agree that things always start out simple and get messy. However, I > think there are some differences: > > * The original User-Agent field was not designed with privacy in mind. In > fact, it was designed specifically to identify the product and version the > user is using. So, with a different goal (privacy first), we will > hopefully get different results. > > * By specifying only a single product token, omitting comments, and fixing > the version number at 1.0, we've already eliminated a fair amount of > information. And then we further limit the information by making the > product name not the actual name of the software, but merely a generic > indication of the type of User-Agent; whatever is the minimal amount of > information necessary for any legitimate browser sniffing that needs to > occur. (Such as differentiating desktop and mobile clients.) > > And, of course, using the simplified User-Agent strings was just one of my > two proposals. My other proposal, which was even simpler, though perhaps > more radical, was to downgrade the requirement on User-Agent from SHOULD to > MAY, and encourage browsers not to send User-Agent at all. (We could even > change it to a SHOULD NOT if we feel really heavy-handed.) One could argue > that by using other techniques such as responsive layout, no browser > sniffing should be necessary at all. > > Maybe ask this on httpbis if you don't get more feedback here? That's >> where you'd find folks who know if it could be done and who could do >> it. >> > > --Patrick > > > --089e01229ed4430b7404e64a731d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --318864283-622548779-1379310326=:66432-- From yaronf.ietf@gmail.com Mon Sep 16 00:26:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CFD11E81CA for ; Mon, 16 Sep 2013 00:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQDwMu--l7jG for ; Mon, 16 Sep 2013 00:26:43 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 40A8A11E80E3 for ; Mon, 16 Sep 2013 00:26:42 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so3232917wes.36 for ; Mon, 16 Sep 2013 00:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bKngfzS2cdsJg/jl3AmIOnP4yz2lrjUDjwF6iQQ7kG4=; b=cWvjQEO9EsATImkbvbhwM42ucIzZXe8bOLmZ2cF5nLCI15oBmztCt6ttaPazNBDPFg kos6f0Y0V5bb2zIznosU7QAu127WUfeeh4XeN9rQ3nuxa3l3NfkvFDu46qjw7mn3QFag +PgU5lg0SpD0KxdCHgVxKdYVqbylwi2D1ezu7iLT9h6aCjNow4jYp0VbH6xeVFYN7dhk M90rKzY8fIDTbUe6dZuc5kFbE0zjn1wG67ROO9Ng3kFNGodDOAQBHmmau56r5ntPgxZ4 Maft8T1Dzf+gwz2DhHqK6Bqbu0zSnhEMopJ5bRMdzHFYsh5glGfaNGTT/zTlds0XdcaF Q4fA== X-Received: by 10.194.250.6 with SMTP id yy6mr21158761wjc.13.1379316402120; Mon, 16 Sep 2013 00:26:42 -0700 (PDT) Received: from [10.0.0.142] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id i8sm21326631wiy.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Sep 2013 00:26:41 -0700 (PDT) Message-ID: <5236B2B0.50803@gmail.com> Date: Mon, 16 Sep 2013 10:26:40 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Karl Malbrain References: <522B2C86.7020300@gmail.com> <522B3F92.1090702@cs.tcd.ie> <522B6709.4070009@gmail.com> <5235F788.8040501@gmail.com> <1379310326.66432.YahooMailNeo@web125504.mail.ne1.yahoo.com> In-Reply-To: <1379310326.66432.YahooMailNeo@web125504.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "perpass@ietf.org" , James Cloos , Stephen Farrell Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 07:26:44 -0000 Hi Karl, I don't understand how this relates to TLS. S/MIME traffic is self-protected and does not need to be transported over TLS. S/MIME is also independent of SMTP. But yes, if you can store a self-signed *CA* certificate in your DNS zone, then you should be able to pull it off. Thanks, Yaron On 09/16/2013 08:45 AM, Karl Malbrain wrote: > Yaron, > From what I've learned about DANE, domain owners can publish their own > self-signed server certificate through the DNS system. By using TLS > strong authentication, the S/MIME client doesn't need to have the > server's certificate checked against a CA. Rather the S/MIME layer > needs to match the DANE delivered certificate with the certificate sent > by the server during the TLS negotiation. This is a very small change to > the S/MIME to TLS protocol layer interface to query from TLS the server > certificate presented, and a similar change to the SMTP to S/MIME > interface to pass along the DANE delivered certificate along with the > server IP address. > Unfortunately, I'm not a TLS nor an S/MIME expert so I can't specify the > exact interface changes needed to utilize strong authentication in the > TLS interface to S/MIME, or the SMTP interface to S/MIME. Perhaps > someone who knows what they are talking about in this area can help. > Karl Malbrain > > *From:* Yaron Sheffer > *To:* James Cloos > *Cc:* perpass@ietf.org; Stephen Farrell > *Sent:* Sunday, September 15, 2013 11:08 AM > *Subject:* Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world > > Hi Jim, > > I agree that storing users' public keys in DNS is weird. > > But I also wonder about your proposal: it sounds like you're putting the > entire organization's list of employees on a public Web server. > > Wouldn't the following be simpler and more natural than both proposals: > > - The organization maintains its own CA, maybe just for S/MIME client certs. > - The CA cert is kept as a DNS record, signed by DANE. > - The CA cert is usage-limited, so it can be used for S/MIME only, and > only for addresses at this particular domain. [I suppose this is the > hard part. Is it allowed by X.509?] > > Advantages: > > - This would leave S/MIME unchanged. > - The cert validation code remains a combination of normal trust chain > processing plus DANE. > - No privacy issues: certificates are not published anywhere. > - Users are managed within the organization, with widely available tools. > > Thanks, > Yaron > > On 09/15/2013 07:58 PM, James Cloos wrote: > >>>>>> "YS" == Yaron Sheffer > writes: > > > > YS> S/MIME with DANE would alleviate this problem if organizations were > > YS> allowed to generate their own certificates, including email certs, > > YS> and have them chained to the DNS root of trust. I don't know if DANE > > YS> supports this usage scenario by default. > > > > draft-ietf-dane-smime-02.txt exists. > > > > Webfinger may be a better choice, though. It is defined in > > draft-ietf-appsawg-webfinger-18.txt. > > > > Details on how to store public keys in webfinger are not yet specified > > in any draft, afaics. > > > > Dane tlsa records of course can be used to secure the the webfinger uri. > > > > If one does that, the steps to find or verify an smime or pgp public key > > include: > > > > Convert the email address to a webfinger uri > > > > Do the a/aaaa and tlsa lookups on the hostname in that uri > > > > If those dnssec-verify, retrieve the uri > > > > Find the public key (or a link to the public key) in the json reply > > > > The trust path, then, is rooted with the DS record for the dns root, > > follows the dnssec path to the rrsigs for the a/aaaa and tlsa records > > for the webfinger uri and trusts the content of the data retrieved from > > the uri on the basis that it trusts the location of the uri. > > > > That seems a bit brittle, but not any worse than trusting a path from > > some random ca of which one has never heard. Or a path through a WoT > > involving names/identifiers with which one is not familiar. > > > > And http serves large blobs better than dns does. > > > > -JimC > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From paul@cypherpunks.ca Mon Sep 16 07:51:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5557411E8286 for ; Mon, 16 Sep 2013 07:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKAce02xzNNX for ; Mon, 16 Sep 2013 07:51:04 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEAD11E827A for ; Mon, 16 Sep 2013 07:51:02 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cdr415kCdz4K8; Mon, 16 Sep 2013 10:50:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oY8IvREWfHFI; Mon, 16 Sep 2013 10:50:56 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 16 Sep 2013 10:50:54 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 6A4058001C; Mon, 16 Sep 2013 10:50:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5FBE580019; Mon, 16 Sep 2013 10:50:54 -0400 (EDT) Date: Mon, 16 Sep 2013 10:50:54 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yaron Sheffer In-Reply-To: <5235F788.8040501@gmail.com> Message-ID: References: <522B2C86.7020300@gmail.com> <522B3F92.1090702@cs.tcd.ie> <522B6709.4070009@gmail.com> <5235F788.8040501@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: perpass@ietf.org, James Cloos , Stephen Farrell Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:51:10 -0000 On Sun, 15 Sep 2013, Yaron Sheffer wrote: > Wouldn't the following be simpler and more natural than both proposals: > > - The organization maintains its own CA, maybe just for S/MIME client certs. > - The CA cert is kept as a DNS record, signed by DANE. > - The CA cert is usage-limited, so it can be used for S/MIME only, and only > for addresses at this particular domain. [I suppose this is the hard part. Is > it allowed by X.509?] I guess that works although that does not solve things for large user domains like hotmail.com or gmail.com. Ideally, we would find something that works there too, without giving the DNS owners the power to change these. Although I have no idea if that can be done. Something DLV or CT like comes to mind. Paul From carl@redhoundsoftware.com Mon Sep 16 08:03:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B89B11E8114 for ; Mon, 16 Sep 2013 08:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwCxbrvzlGhw for ; Mon, 16 Sep 2013 08:03:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 181AA11E8110 for ; Mon, 16 Sep 2013 08:03:47 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hu8so446262vcb.3 for ; Mon, 16 Sep 2013 08:03:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=zUEIWr3XsbGxteE2TOZA1HZjl+uBLqC3GYQgnP7UPDA=; b=ZyzlrJCWG54qsYKETsXKfFQLR1JIv9F/ZmMopa4f3sLRsEtTVeCnUDa1t5VCJVGcQk Hoq3ZYXWA7r/SVtluplrxP52NTNJPHOfrPC6obC92WsQ6WcRGy+zuFPOgv3GkeIpQweS LnnW1vmpjMhNcUWrL8/Zioz0JgO/jA1X5Mnw+ka1D7MXKvlkyYVY7JSraUPnJrkHhSZW 726QGeVHJuxJ6ANO3OH3EoVMR597sVet8uR4E5xgMQCSJ6SgyP1ANL7ec+Z6NIh9JmsQ TM8b6HxAJPu6k+JSy9Horu2nkmKMOBZEfTgCLhuzVfvH80b5zGqn7cVPcPcq2g5lhK+L TDhg== X-Gm-Message-State: ALoCoQmUj5+q5I+mJOnuWI6p5STK4kDxfuo+39Z6nXw5m8G32tskvtPJrkdvDrOwb4Zsc6YNVfNL X-Received: by 10.220.164.70 with SMTP id d6mr6037442vcy.19.1379343827234; Mon, 16 Sep 2013 08:03:47 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-121-77.washdc.fios.verizon.net. [173.79.121.77]) by mx.google.com with ESMTPSA id eu2sm13673854vdc.2.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 16 Sep 2013 08:03:46 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Mon, 16 Sep 2013 11:03:43 -0400 From: Carl Wallace To: Yaron Sheffer , James Cloos Message-ID: Thread-Topic: [perpass] Why Yaron can't encrypt: S/MIME in the real world In-Reply-To: <5235F788.8040501@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: perpass@ietf.org, Stephen Farrell Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 15:03:54 -0000 On 9/15/13 2:08 PM, "Yaron Sheffer" wrote: >Hi Jim, > >Wouldn't the following be simpler and more natural than both proposals: > >- The organization maintains its own CA, maybe just for S/MIME client >certs. >- The CA cert is kept as a DNS record, signed by DANE. >- The CA cert is usage-limited, so it can be used for S/MIME only, and >only for addresses at this particular domain. [I suppose this is the >hard part. Is it allowed by X.509?] You'd need to write something to limit CA certificates in this manner. This may just be a matter of writing up processing rules to codify the recent CAB Forum changes to EKU usage. From warren@kumari.net Mon Sep 16 08:11:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D255211E825B for ; Mon, 16 Sep 2013 08:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHcHDAzUgBvP for ; Mon, 16 Sep 2013 08:11:33 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398AF11E8298 for ; Mon, 16 Sep 2013 08:11:29 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id 710A21B4037C; Mon, 16 Sep 2013 11:11:24 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Warren Kumari In-Reply-To: Date: Mon, 16 Sep 2013 11:11:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <482BD289-9821-4CC4-8D36-45C7353EEAA6@kumari.net> References: <65EEC6E375AA474A847D510D5B7E83742502A555@mail2010> <20130911183856.GA13397@thunk.org> <65EEC6E375AA474A847D510D5B7E83742502A5C7@mail2010> <260675CB-F53A-48A2-831E-6E6D7266EEA4@icloud.com> <65EEC6E375AA474A847D510D5B7E83742502A6C0@mail2010> <5231EFFF.2020606@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6DE@mail2010> <5231F859.2040002@cs.tcd.ie> <65EEC6E375AA474A847D510D5B7E83742502A6FD@mail2010> <5232045B.4040904@mnt.se> <1379011022.86026.YahooMailNeo@web125506.mail.ne1.yahoo.com> <5232B258.1070104@mnt.se> <1379102432.61098.YahooMailNeo@web125503.mail.ne1.yahoo.com> <1379104804.9549.YahooMailNeo@web125502.mail.ne1.yahoo.com> <1379110749.99151.YahooMailNeo@web125505.mail.ne1.yahoo.com> <2E98A5F0-247F-48C2-ABF2-EA279CBD0D4C@kumari.net> <1379115320.83794.YahooMailNeo@web125505.mail.ne1.yahoo.com> To: Yoav Nir X-Mailer: Apple Mail (2.1508) Cc: Leif Johansson , "perpass@ietf.org" , Warren Kumari , Karl Malbrain Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 15:11:38 -0000 On Sep 14, 2013, at 12:10 AM, Yoav Nir wrote: > Hi >=20 > I don't think that's necessary. DNS queries are usually done over UDP, = so there's no "connection", just an extra round-trip. And for the most = part, the DNS server is very close to the client, so those are not very = expensive round-trips. And you can make multiple requests in the same = message. What Warren is suggesting is that the DNS gratuitously return = records you might want soon, which would require the DNS to know a lot = about the website, so I don't think it's a worthwhile optimization. Whoa there=85 I wasn't really suggesting that the DNS do that -- just that if it *did* = there would be a bunch of other things / optimizations that it would = enable (including in the example I included, poisoning :-))=20 As to if it *should* -- well, maybe=85 but there would need to be a = bunch of additional protection -- such as being in bailiwick, signed, = preferably at the same level, etc. Oh yes, there is also the whole legacy issue, larger responses (so = better amplification, etc).=20 Don't hold your breath on a draft.. W >=20 > Yoav >=20 > On Sep 14, 2013, at 2:35 AM, Karl Malbrain wrote: >=20 >> Warren, >> =20 >> Since my proposal is now hooked to the widespread deloyment of DANE, = and if DANE is being hindered by an ancient DNS protocol that requires = multiple connections to secure a server's certificate and IP address, = I'll have to include an item for DNS 2.0 that allows for multiple = commands and multiple reponses in a simple cpio like data stream. >> =20 >> Thanks for your help!! >> Karl Malbrain >> From: Warren Kumari >> To: Karl Malbrain =20 >> Cc: Randy Bush ; Leif Johansson ; = "perpass@ietf.org" ; Warren Kumari =20= >> Sent: Friday, September 13, 2013 4:03 PM >> Subject: Re: [perpass] proposed enhancement to TLS strong = authentication protocol >>=20 >>=20 >> On Sep 13, 2013, at 6:19 PM, Karl Malbrain = wrote: >>=20 >> > Doesn't DANE produce the server's certificate in the same = connection that DNS produces the servers IP address? >>=20 >> Nope.=20 >>=20 >> > If not, that's an optimization that's needed. >>=20 >> Would be nice, but, unfortunately DNS doesn't really allow you to = return answers to questions that the client didn't ask=85 >>=20 >> There are all sorts of sexy (and dangerous :-)) things that you could = do if it did... >> E.g. - if a client asks for the A record for www.example.com they are = presumably trying to reach my webserver and render a page -- which = contains images from images.example.com and some ads from = www.punchthemonkey.com, so I would like to be able to return: >>=20 >> www.example.com 600 IN A 192.0.2.2 >> images.example.com 600 IN A 192.0.2.3 >> www.punchthemonkey.com 600 A 192.0.2.100. >>=20 >> Or, even just returning MX responses in addition to A and AAA=85=20 >>=20 >> W >>=20 >>=20 >>=20 >> > =20 >> > =20 >> > Karl >> > From: Warren Kumari >> > To: Karl Malbrain =20 >> > Cc: Randy Bush ; Leif Johansson ; = "perpass@ietf.org" ; Warren Kumari =20= >> > Sent: Friday, September 13, 2013 3:03 PM >> > Subject: Re: [perpass] proposed enhancement to TLS strong = authentication protocol >> >=20 >> >=20 >> > On Sep 13, 2013, at 4:40 PM, Karl Malbrain = wrote: >> >=20 >> > > I'm not familiar with DANE. Is it operational? =20 >> >=20 >> > Yes, it is just not widely (enough) deployed. There are some = browser extensions and a browser (Bloodhound) that has support built in. = There are good tools to generate the DANE (TLSA) records, and e.g = registro.br has a simple one click "generate and publish a TLSA record" = record for hosted DNS customers. >> >=20 >> > It is gaining traction in mail / SMTP, with support in Postfix. >> >=20 >> > At the moment one of the main deployment hurdles is browser support = (and more DNSSEC deployment!). >> > Browsers (understandably) don't want to be waiting on TLSA records = -- latency is really important for browsers, and waiting for more DNS = lookups takes time. >> >=20 >> > A few solutions have been discussed / suggested, such as only doing = DANE for self-signed certs, doing the TLSA lookup in parallel with the = regular lookup and making the normal connection, then aborting it (and = replacing the page with a notice) if DANE shows evidence of shennanigans = and / or caching TLSA records. >> >=20 >> > W >> >=20 >> > > Does it include changes to TLS to accept/compare the server's = certificate obtained from DANE? If so, then that part of the proposal = can be mooted in favor of DANE. >> > > =20 >> > > Yes, it would be simpler to offload the certificate sourcing = management to DNS. However, I'm proposing changes to be implemented = entirely within TLS, that are transparent on the client side. Only the = server side would require an additional interface to accept/reject = client connections. >> > > =20 >> > > Karl >> > >=20 >> > > From: Randy Bush >> > > To: Karl Malbrain =20 >> > > Cc: Leif Johansson =20 >> > > Sent: Friday, September 13, 2013 1:24 PM >> > > Subject: Re: [perpass] proposed enhancement to TLS strong = authentication protocol >> > >=20 >> > > [ off lst ] >> > >=20 >> > > > I've dropped the idea of including both client and server = public >> > > > certificates in the directory in favor of a server certificate = only >> > > > repository with an additional TLS interface to authorize access = by >> > > > clients. >> > >=20 >> > > so why is this a win over dane? >> > >=20 >> > > randy >> > >=20 >> > >=20 >> > > _______________________________________________ >> > > perpass mailing list >> > > perpass@ietf.org >> > > https://www.ietf.org/mailman/listinfo/perpass >> >=20 >> > -- >> > Hope is not a strategy. >> > -- Ben Treynor, Google >> >=20 >> >=20 >> > _______________________________________________ >> > perpass mailing list >> > perpass@ietf.org >> > https://www.ietf.org/mailman/listinfo/perpass >> >=20 >> >=20 >> > _______________________________________________ >> > perpass mailing list >> > perpass@ietf.org >> > https://www.ietf.org/mailman/listinfo/perpass >>=20 >> --=20 >> With Feudalism, it's your Count that votes. >>=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass -- The above email is neither interesting or relevant, but at least it = provided no new information. From cloos@jhcloos.com Mon Sep 16 11:30:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4109611E814B for ; Mon, 16 Sep 2013 11:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPzK3OG59tt0 for ; Mon, 16 Sep 2013 11:30:22 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01611E8140 for ; Mon, 16 Sep 2013 11:30:22 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 1AF151DFBF; Mon, 16 Sep 2013 18:30:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1379356219; bh=gqvgRj+xSwURxPKBFhIGiNfOUJwP/jFTb8kZlI+Tnhk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jCN/kHV5w/+1eYXaQpgX7noafmVEMuMyLKdY681lObO0uBrEQuIbMHrbQqJdxOH9k KnhSbOGzDKJI5E+foWVw9BTmiBBslMZO52JhqsDFywnnHGU+Ck5rAMvwL+aNRuxehM xogS3p8kBZat8TwbGoyV3tGQl3E8zWNU2A+DOBVZ7Rw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 86ED36001E; Mon, 16 Sep 2013 18:26:52 +0000 (UTC) From: James Cloos To: Yaron Sheffer In-Reply-To: <5235F788.8040501@gmail.com> (Yaron Sheffer's message of "Sun, 15 Sep 2013 21:08:08 +0300") References: <522B2C86.7020300@gmail.com> <522B3F92.1090702@cs.tcd.ie> <522B6709.4070009@gmail.com> <5235F788.8040501@gmail.com> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 16 Sep 2013 14:26:52 -0400 Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130916:yaronf.ietf@gmail.com::MRZa4a/KTUrC7w5j:000000000000000000000000000000000000000D14Uc X-Hashcash: 1:28:130916:perpass@ietf.org::+JhIA81lnoJk/wpC:Q7XpO X-Hashcash: 1:28:130916:stephen.farrell@cs.tcd.ie::kaxJobDYE9p9Ug4k:000000000000000000000000000000000003OjkG Cc: perpass@ietf.org, Stephen Farrell Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:30:23 -0000 >>>>> "YS" == Yaron Sheffer writes: YS> I agree that storing users' public keys in DNS is weird. YS> But I also wonder about your proposal: it sounds like you're putting YS> the entire organization's list of employees on a public Web server. It wasn't my proposal; just another which was posted on the dane list. YS> Wouldn't the following be simpler and more natural than both proposals: YS> - The organization maintains its own CA, maybe just for S/MIME client certs. YS> - The CA cert is kept as a DNS record, signed by DANE. YS> - The CA cert is usage-limited, so it can be used for S/MIME only, and YS> only for addresses at this particular domain. [I suppose this is the YS> hard part. Is it allowed by X.509?] For orgs which can manage a local CA, doing so is a good idea. And I'd suggest they use it for everything which is dane-compatible. Not just s/mime. But it doesn't address the question of how correspondents can find a given address' cert or the org's ca cert. They'll need the former to send encrypted mail to the org's users, and the latter to verify sigs. Well know mappings from an email address to either a dns lookup or to the web can provide that. The dane smime draft (like rfc 2538) tries to the the former. Webfinger is an example of the latter. YS> Advantages: YS> - This would leave S/MIME unchanged. YS> - The cert validation code remains a combination of normal trust chain YS> processing plus DANE. YS> - No privacy issues: certificates are not published anywhere. YS> - Users are managed within the organization, with widely available tools. Not publishing certs means that they are unavailable for encrypting incoming mail or verifying outgoing sigs w/o some prior out of band exchange. That is reasonable for some usages, but precludes other reasonable ones. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From karl@la-grange.net Mon Sep 16 11:43:47 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0853611E82EF for ; Mon, 16 Sep 2013 11:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.939 X-Spam-Level: X-Spam-Status: No, score=-4.939 tagged_above=-999 required=5 tests=[AWL=-2.340, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clqb9CrI1tf8 for ; Mon, 16 Sep 2013 11:43:42 -0700 (PDT) Received: from nerval.la-grange.net (nerval.la-grange.net [128.30.54.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7D18911E8141 for ; Mon, 16 Sep 2013 11:43:42 -0700 (PDT) Received: from [127.0.0.1] (nerval.la-grange.net [128.30.54.58]) by nerval.la-grange.net (8.14.6/8.14.6) with ESMTP id r8GIcYO1033181; Mon, 16 Sep 2013 14:38:35 -0400 (EDT) (envelope-from karl@la-grange.net) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_6CA9E043-684C-422D-98EE-0857150E3933"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Karl Dubost X-Priority: 3 (Normal) In-Reply-To: <331db5651e98469af660607459b2c2dd.squirrel@arekh.dyndns.org> Date: Mon, 16 Sep 2013 14:42:07 -0400 Message-Id: References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> <331db5651e98469af660607459b2c2dd.squirrel@arekh.dyndns.org> To: Nicolas Mailhot X-Mailer: Apple Mail (2.1283) Cc: perpass@ietf.org, Patrick Pelletier , ietf-http-wg@w3.org, Stephen Farrell Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:43:47 -0000 --Apple-Mail=_6CA9E043-684C-422D-98EE-0857150E3933 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Nicolas Mailhot [2013-09-16T12:34]: > User-Agent is invaluable for filtering out pathologic web clients in a = network without bothering legitimate users. * At which level do you need to filter out? (proxy, server, =85) * Which type of clients? (bot, browser, etc?) * Why do you need to filter out? * What are you looking for in the UA string? /me is interested to know. I'm kind of collecting how the UA string is = used out in the wild in good and bad ways. --=20 Karl Dubost http://www.la-grange.net/karl/ --Apple-Mail=_6CA9E043-684C-422D-98EE-0857150E3933 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSN1D/AAoJEAmuD01odSZuon4H/1QS9Pt7RPmRqHefx21tlwQJ pf6TTONp1SzJCrj+bcSQ0JPal0ocj2OmJQWHgJX4w3HPoY48qXaSIvwL0NEdEBaI 0cdXcxTyEXYnpCVqdJ87vCEsnN4lHYnHs3+XeYsNxUxg8wUQfXQzkT/m9dYYuzSG UbMBkSIKd348zeThe39Dt6XxPoZ1gqhXzOYVfbcZfq3PRXOapdT6f9qWivWmGJba /YysnvoPmD2mPQxRFSQ1dO3TTkLB7MD4/D8R00ojKCxpq2tV3vFY3x8DEhI018if zJUYLb/eKrLhuy0u4YH1Mo4USsLfglSya9FFocFKyIAOVJYY1RGE1jUnzR8y+CY= =0alp -----END PGP SIGNATURE----- --Apple-Mail=_6CA9E043-684C-422D-98EE-0857150E3933-- From watsonbladd@gmail.com Mon Sep 16 12:34:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A90C11E81A1 for ; Mon, 16 Sep 2013 12:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo8Iol1YMPPN for ; Mon, 16 Sep 2013 12:34:44 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 80B6411E8165 for ; Mon, 16 Sep 2013 12:34:44 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cb5so4031940wib.1 for ; Mon, 16 Sep 2013 12:34:43 -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=NFFRFUWn4KG4C7Vtt059Nl2aWSkI182nL3T+iB4rZIw=; b=eFvp0t5jw6zuZW+mKISplizUsPxwn1Bxoe2Zd2AT3iX7MUOhrhLzndg0OK4W8ccmbb WotZzIczkuyPwiVuN09EoMVkDn854EziamKVczz65fqBcz0BHpxhvkmLP1LJVkZIBtEz 07ODl3OBC0A+8awCq+l4+YhkgMNDWXKAEzO4m3V8odVDF7ner/4W7gSI1fpcv+/3cI8i AfmosxYxmuso7MtXzgt9FLfEoI0vzHrHSmYPTPyNwmDC8byVF/Z6ePsXjd/rV7nvZvNe Zz7H5HJa4eI60UeFNsTl6IXqSIt++GrKidmB70K+O3Zs1ci/Ylf93L1Qc9z8296Ko3Yc EPFA== MIME-Version: 1.0 X-Received: by 10.194.222.2 with SMTP id qi2mr24157258wjc.14.1379360083737; Mon, 16 Sep 2013 12:34:43 -0700 (PDT) Received: by 10.194.174.38 with HTTP; Mon, 16 Sep 2013 12:34:43 -0700 (PDT) Date: Mon, 16 Sep 2013 12:34:43 -0700 Message-ID: From: Watson Ladd To: perpass@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [perpass] The scope of the problem X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 19:34:45 -0000 I would like to explain the extent to which a pervasive passive adversary is able to find things out. Naturally a few hours with wireshark is sufficient to see that a lot of data passes over the wire unencrypted. But what exactly can we learn? First off, web browsing. We see what sites are accessed and when from DNS queries, which are not encrypted. From HTTP accesses we learn what plugins, fonts, and languages are suggested or installed, which can uniquely identify a computer. Email is worse: even if the connection to the mail provider is encrypted, the mail will go out on port 25 for transport. STARTLS is nice, but isn't everywhere, and it is a pain to deploy. Even S/MIME and PGP offer limited protection: quite a lot has been written on how PGP doesn't protect what you think it does, more than just headers. (For instance a signature doesn't actually identify the intended recipient, leading to fun and games). The world of many email providers making clients on your machine second-class citizens makes key management tough. IRC is regrettably mostly cleartext. Given that it is a public forum, it is hard to imagine this being a major problem, but deploying it securely is tough. NFS I do not believe can be encrypted by means short of deploying IPsec. UDP based protocols require hackery, and so every standard has its own system, not ideal for security. VoIP leaks information from the compression. Custom applications do not routinely check TLS certificates, or properly deal with the attacks that are possible. Do we know that all autodownloaders properly check signatures? What can we do to solve this problem? First, we can make standards that have encryption that is easy to deploy in a wide range of organizational scenarios, and provides the abstractions that people expect of secure channels, immune to all attacks and manipulations other than possible replay. (Replay is fine in email: humans are likely to recognize it. But it is not okay in TLS!) We need to make this bulletproof. Secondly, we can make these new standards have advantages that lead to them being widely deployed. SSH replaced Telnet because of port forwarding, not security. It also eliminated the need for typing in passwords with ssh-agent. Web-agent could do the same. Thirdly, all cryptography should provide easy to understand abstractions like secure channels, and be implemented cleanly. OpenSSL needs to be refactored. It should be easy to deploy cryptography, and easy for developers to use securely. We should have one, or maybe 2 standards, rather than a menagerie of ad-hoc, poorly specified, unanalysable hacks. Doing these three things will lead to cryptography being easy to deploy, having benefits when deployed beyond security, and make it easy to deploy *correctly*. These issues extend beyond the scope of standards, but can in part be addressed by them. If we have standards that are "plug and play" then committees will use them, rather than some ad-hoc mess. TLS has done a good job, but more is required, particularly for UDP. Sincerely, Watson Ladd From nicolas.mailhot@laposte.net Mon Sep 16 09:35:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B1321F9DC6 for ; Mon, 16 Sep 2013 09:35:13 -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_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGsyspO6QLuP for ; Mon, 16 Sep 2013 09:35:07 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 75AA221F9EE9 for ; Mon, 16 Sep 2013 09:35:06 -0700 (PDT) Received: from arekh.dyndns.org ([88.174.226.208]) by mwinf8510-out with ME id Rsay1m00E4WQcrc03sayxG; Mon, 16 Sep 2013 18:35:05 +0200 Received: from localhost (localhost [127.0.0.1]) by arekh.dyndns.org (Postfix) with ESMTP id 5B0FD2E1062; Mon, 16 Sep 2013 18:34:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at arekh.dyndns.org Received: from arekh.dyndns.org ([127.0.0.1]) by localhost (arekh.okg [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiOjwAecVDAf; Mon, 16 Sep 2013 18:34:57 +0200 (CEST) Received: from arekh.dyndns.org (localhost [127.0.0.1]) by arekh.dyndns.org (Postfix) with ESMTP; Mon, 16 Sep 2013 18:34:57 +0200 (CEST) Received: from 192.168.0.4 (SquirrelMail authenticated user nim) by arekh.dyndns.org with HTTP; Mon, 16 Sep 2013 18:34:57 +0200 Message-ID: <331db5651e98469af660607459b2c2dd.squirrel@arekh.dyndns.org> In-Reply-To: <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> Date: Mon, 16 Sep 2013 18:34:57 +0200 From: "Nicolas Mailhot" To: "Patrick Pelletier" User-Agent: SquirrelMail/1.4.22-13.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 16 Sep 2013 13:19:08 -0700 Cc: perpass@ietf.org, ietf-http-wg@w3.org, Stephen Farrell Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 16:56:35 -0000 Le Ven 13 septembre 2013 21:18, Patrick Pelletier a écrit : > And, of course, using the simplified User-Agent strings was just one > of my two proposals. My other proposal, which was even simpler, > though perhaps more radical, was to downgrade the requirement on User- > Agent from SHOULD to MAY, and encourage browsers not to send User- > Agent at all. (We could even change it to a SHOULD NOT if we feel > really heavy-handed.) Please don't. If any change it from SHOULD to MUST User-Agent is invaluable for filtering out pathologic web clients in a network without bothering legitimate users. And in fact 9 web clients out of ten that do not declare user-agent are broken one way or another protocol-wise (and they're a PITA because you can't filter them out without breaking the few correctly implemented clients that take advantage of the SHOULD) In fact no-user-agent should be "I swear on the penalty of [insert cruel and deserved punishment] to never take liberties with the HTTP protocol and never add a bug to my software". Right now no-user-agent-is "I don't want to understand HTTP but it gets me through the firewall, simulate a real web client and only implement the parts I need most of the time with no error handling except for retrying in a loop with no sleeps" -- Nicolas Mailhot From nicolas.mailhot@laposte.net Mon Sep 16 13:01:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81EB11E8310 for ; Mon, 16 Sep 2013 13:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkOmy9LuaKQC for ; Mon, 16 Sep 2013 13:00:36 -0700 (PDT) Received: from smtpout.laposte.net (smtpout6.laposte.net [193.253.67.231]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5F11E8305 for ; Mon, 16 Sep 2013 13:00:20 -0700 (PDT) Received: from arekh.dyndns.org ([88.174.226.208]) by mwinf8511-out with ME id Rw021m0074WQcrc03w05A7; Mon, 16 Sep 2013 22:00:09 +0200 Received: from localhost (localhost [127.0.0.1]) by arekh.dyndns.org (Postfix) with ESMTP id 4BB1C2E1062; Mon, 16 Sep 2013 22:00:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at arekh.dyndns.org Received: from arekh.dyndns.org ([127.0.0.1]) by localhost (arekh.okg [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lmc-ZJW6y29b; Mon, 16 Sep 2013 21:59:59 +0200 (CEST) Received: from arekh.dyndns.org (localhost [127.0.0.1]) by arekh.dyndns.org (Postfix) with ESMTP; Mon, 16 Sep 2013 21:59:59 +0200 (CEST) Received: from 192.168.0.4 (SquirrelMail authenticated user nim) by arekh.dyndns.org with HTTP; Mon, 16 Sep 2013 21:59:59 +0200 Message-ID: In-Reply-To: References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> <331db5651e98469af660607459b2c2dd.squirrel@arekh.dyndns.org> Date: Mon, 16 Sep 2013 21:59:59 +0200 From: "Nicolas Mailhot" To: "Karl Dubost" User-Agent: SquirrelMail/1.4.22-13.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 16 Sep 2013 13:19:08 -0700 Cc: Stephen Farrell , perpass@ietf.org, Patrick Pelletier , ietf-http-wg@w3.org, Nicolas Mailhot Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 20:01:00 -0000 Le Lun 16 septembre 2013 20:42, Karl Dubost a écrit : > Nicolas Mailhot [2013-09-16T12:34]: >> User-Agent is invaluable for filtering out pathologic web clients in a >> network without bothering legitimate users. > > * At which level do you need to filter out? (proxy, server, …) proxy > * Which type of clients? (bot, browser, etc?) pretty much everything that tries to access the web in http(s) > * Why do you need to filter out? because the internet got so fast web client authors do pretty idiotic things at the http level and it's lost in the youtube noise. OTOH those idiotic things tend to clutter my logs with errors that make investigating actual problems difficult, so it's easier to just blacklist miscreants Major browsers almost never cause problems, but pretty much anything else that does http is likely to make shortcuts > * What are you looking for in the UA string? Anything likely to identify the problem client and nothing else. For example: 1. corp policy is that windows stations must go through corp wsus → blacklist windows update UA ; 2. something is hammering the proxy with corrupted connects (control chars before CONNECT) → it says it is "Google Mail" → go away Google Mail, 3. someone deployed a widget that wants to go to the internet every 5 minutes to display a clock no one will look at → kill clock (not ntp, we have perfectly fine ntp servers) Actually, I don't care about the volume as long as it's not pathological real-time updates, what I do care is the flood of errors that makes our job more difficult than it should be. > > /me is interested to know. I'm kind of collecting how the UA string is > used out in the wild in good and bad ways. > -- Nicolas Mailhot From bclaise@cisco.com Mon Sep 16 14:04:31 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C8711E8323 for ; Mon, 16 Sep 2013 14:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+x58WCYFK8k for ; Mon, 16 Sep 2013 14:04:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2323011E8333 for ; Mon, 16 Sep 2013 14:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13374; q=dns/txt; s=iport; t=1379365384; x=1380574984; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=mkVO+QT5ixPgxL+dTQmZszmp3u8arNalsd1jrQ13+XA=; b=lIQwayLP6XVRGzYQGN0TNxHzCuL+C7SaP6ZZmqdr3Oy5o57BlSjooyjP FnAaAvZ82/EW4LdaXrVT5iw9FJ3/DHGhiIcNU9Fhxp9xeR0rP3G0B8iK6 N1ZbaUDpbE98Y5r5l5YHwNc2PdCrlxy7QCCWnCV0oa2NGLt59he7PBQ4x g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKhwN1KQ/khL/2dsb2JhbABagwc4iVm3MkqBIhZ0giUBAQEEAQEBFVYKARALGAkWDwkDAgECARUwBg0BBQIBAYd/DLpGjjqBOQcJhBUDl3uBL4UBi0SDJjqBNQ X-IronPort-AV: E=Sophos;i="4.90,918,1371081600"; d="scan'208,217";a="86703452" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 16 Sep 2013 21:02:55 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8GL2rmP001069; Mon, 16 Sep 2013 21:02:54 GMT Message-ID: <523771FD.3000801@cisco.com> Date: Mon, 16 Sep 2013 23:02:53 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <52329A7A.7060103@headstrong.de> <52330712.8060104@cs.tcd.ie> <5234422A.3010003@cisco.com> <5235F203.5090609@cs.tcd.ie> <4538CD25-68D8-407E-8B72-F0D5B76A7B9D@tik.ee.ethz.ch> <523613B8.2010308@cs.tcd.ie> In-Reply-To: <523613B8.2010308@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------030506000708070408090005" Cc: perpass@ietf.org, Brian Trammell Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 21:04:32 -0000 This is a multi-part message in MIME format. --------------030506000708070408090005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 15/09/2013 22:08, Stephen Farrell wrote: > Hi Brian, > > On 09/15/2013 08:42 PM, Brian Trammell wrote: >> hi Stephen, Benoit, all, >> >> The survey of anonymization techniques in 6235 was intended primarily >> to be a complete accounting of methods one _could_ use to anonymize >> fields (Information Elements) in a record, as opposed to a survey of >> methods we knew to be implemented. Here the idea was to allow a >> complete specification of a metadata format for specifying how >> records were anonymized, as input to future analysis tasks to be done >> on the data (since the anonymization method affects the set of >> analyses for which the data can be used). >> >> So we were really trying to solve a different problem: applying >> anonymization (to mask irrelevant and potentially privacy-sensitive >> information) while still maintaining the usefulness of the data for >> specific analytical tasks. Here we'd like to get rid of absolutely >> _everything_ that might be useful for analysis, just keeping around >> the minimum necessary for the operation and management of the >> protocol. >> >> Which gets me back to thinking it would be very useful to have a >> survey of the information radiated by protocols in common usage, then >> a systematic exercise to make sure each of those bits of information >> which may be identifiable serves a purpose that couldn't be done in >> an anonymous or pseudonymous way. > A fine research proposal. (Really, I'd try get dosh for that:-) > > But in an IETF context, maybe that'd be a thing that the lmap > wg [1] could look at? Anyone on this list active there? > > The lmap charter says: "The LMAP WG will consider privacy as a core > requirement and will ensure that by default measurement and collection > mechanisms and protocols standardized operate in a privacy-sensitive > manner, for example, ensuring that measurements are not personally > identifying except where permission for such has been granted by > identified subjects. Note that this does not mean that all uses of LMAP > need to turn on all privacy features but it does mean that privacy > features do need to be at least well-defined." > > (However, if I recall correctly I got that sentence shoe-horned into > their charter, so its not clear to me if the active participants are > actually keen on it or if it'll turn out to be RFC6919 fodder;-) The issue is that it depends on the use case. In the use case of the ISP monitoring my access device & link, the ISP has got anyway some personally identifiable information (PII) for his monitoring. And this is what I'm expecting as a customer .... when I call them, complaining about _my _link quality. However, in the regulator use case, monitoring my access link, I don't want to share any PII. Regards, Benoit > > S. > > [1] http://datatracker.ietf.org/wg/lmap/charter/ > >> Cheers, >> >> Brian >> >> On Sep 15, 2013, at 7:44 PM, Stephen Farrell >> wrote: >> >>> Hi Benoit, >>> >>> On 09/14/2013 12:02 PM, Benoit Claise wrote: >>>> On 13/09/2013 14:37, Stephen Farrell wrote: >>>>> On 09/13/2013 05:54 AM, Moritz Bartl wrote: >>>>>> Hi, >>>>>> >>>>>> I would very much like to see servers having a minimal >>>>>> logging policy by default, especially and at least when it >>>>>> comes to IP addresses. I wonder if RFC 6302 is the right >>>>>> document to look at or extend for this. >>>>> Or obsolete it. >>>>> >>>>>> It is easy to flip a switch to enable IP logging. The default >>>>>> should be no IP logs, which is true for most XMPP servers, >>>>>> for example, but not for web or mail servers. >>>>> The wonderfully ironically named PRISM [1] project was an EU >>>>> funded project that did some work on obfuscating IP addresses >>>>> in logs. >>>> rfc6235 >>> Yep, sections 4 & 5 of that are generic and not really ipfix >>> specific. >>> >>> Do you know of implementations of that for ipfix? Or libraries that >>> do the various functions? >>> >>> I wonder if separating those sections out into a separate RFC would >>> result in more people writing code that supports those kinds of >>> transformations. Not sure to be honest. >>> >>> But that is a useful reference, regardless, Thanks, S. >>> >>>> Regards, Benoit >>>>> I'd love to see an RFC that described such techniques and >>>>> recommended when to use what, so we could point people at >>>>> that. >>>>> >>>>> Any takers for a -00 to get that going? >>>>> >>>>> S. >>>>> >>>>> [1] http://www.fp7-prism.eu/ >>>>> >>>>>> On a side node, can we do anything to get rid of sender IP >>>>>> addresses in (the first) Received headers of mail? >>>>>> >>>>>> -- Moritz _______________________________________________ >>>>>> perpass mailing list perpass@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/perpass >>>>>> >>>>> _______________________________________________ perpass mailing >>>>> list perpass@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/perpass . >>>>> >>>> >>> _______________________________________________ perpass mailing >>> list perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >> >> >> _______________________________________________ perpass mailing list >> perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass >> > . > --------------030506000708070408090005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 15/09/2013 22:08, Stephen Farrell wrote:
Hi Brian,

On 09/15/2013 08:42 PM, Brian Trammell wrote:

hi Stephen, Benoit, all,

The survey of anonymization techniques in 6235 was intended primarily
to be a complete accounting of methods one _could_ use to anonymize
fields (Information Elements) in a record, as opposed to a survey of
methods we knew to be implemented. Here the idea was to allow a
complete specification of a metadata format for specifying how
records were anonymized, as input to future analysis tasks to be done
on the data (since the anonymization method affects the set of
analyses for which the data can be used).

So we were really trying to solve a different problem: applying
anonymization (to mask irrelevant and potentially privacy-sensitive
information) while still maintaining the usefulness of the data for
specific analytical tasks. Here we'd like to get rid of absolutely
_everything_ that might be useful for analysis, just keeping around
the minimum necessary for the operation and management of the
protocol.

Which gets me back to thinking it would be very useful to have a
survey of the information radiated by protocols in common usage, then
a systematic exercise to make sure each of those bits of information
which may be identifiable serves a purpose that couldn't be done in
an anonymous or pseudonymous way.

A fine research proposal. (Really, I'd try get dosh for that:-)

But in an IETF context, maybe that'd be a thing that the lmap
wg [1] could look at? Anyone on this list active there?

The lmap charter says: "The LMAP WG will consider privacy as a core
requirement and will ensure that by default measurement and collection
mechanisms and protocols standardized operate in a privacy-sensitive
manner, for example, ensuring that measurements are not personally
identifying except where permission for such has been granted by
identified subjects. Note that this does not mean that all uses of LMAP
need to turn on all privacy features but it does mean that privacy
features do need to be at least well-defined."

(However, if I recall correctly I got that sentence shoe-horned into
their charter, so its not clear to me if the active participants are
actually keen on it or if it'll turn out to be RFC6919 fodder;-)
The issue is that it depends on the use case.
In the use case of the ISP monitoring my access device & link, the ISP has got anyway some personally identifiable information (PII) for his monitoring. And this is what I'm expecting as a customer .... when I call them, complaining about my link quality.
However, in the regulator use case, monitoring my access link, I don't want to share any PII.

Regards, Benoit

S.

[1] http://datatracker.ietf.org/wg/lmap/charter/


Cheers,

Brian

On Sep 15, 2013, at 7:44 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:


Hi Benoit,

On 09/14/2013 12:02 PM, Benoit Claise wrote:

On 13/09/2013 14:37, Stephen Farrell wrote:

On 09/13/2013 05:54 AM, Moritz Bartl wrote:

Hi,

I would very much like to see servers having a minimal
logging policy by default, especially and at least when it
comes to IP addresses. I wonder if RFC 6302 is the right
document to look at or extend for this.

Or obsolete it.


It is easy to flip a switch to enable IP logging. The default
should be no IP logs, which is true for most XMPP servers,
for example, but not for web or mail servers.

The wonderfully ironically named PRISM [1] project was an EU
funded project that did some work on obfuscating IP addresses
in logs.

rfc6235

Yep, sections 4 & 5 of that are generic and not really ipfix 
specific.

Do you know of implementations of that for ipfix? Or libraries that
do the various functions?

I wonder if separating those sections out into a separate RFC would
result in more people writing code that supports those kinds of
transformations. Not sure to be honest.

But that is a useful reference, regardless, Thanks, S.


Regards, Benoit

I'd love to see an RFC that described such techniques and
recommended when to use what, so we could point people at
that.

Any takers for a -00 to get that going?

S.

[1] http://www.fp7-prism.eu/


On a side node, can we do anything to get rid of sender IP
addresses in (the first) Received headers of mail?

-- Moritz _______________________________________________ 
perpass mailing list perpass@ietf.org 
https://www.ietf.org/mailman/listinfo/perpass


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




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



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


.

--------------030506000708070408090005-- From stephen.farrell@cs.tcd.ie Mon Sep 16 14:09:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F03921F9EB8 for ; Mon, 16 Sep 2013 14:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5O4PjLPUgo4 for ; Mon, 16 Sep 2013 14:09:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 215BC21F9E99 for ; Mon, 16 Sep 2013 14:09:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 80EA6BE56; Mon, 16 Sep 2013 22:09:00 +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 mM3oUpPLYWtT; Mon, 16 Sep 2013 22:08:59 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.19.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 96A73BE6F; Mon, 16 Sep 2013 22:08:59 +0100 (IST) Message-ID: <5237736B.40005@cs.tcd.ie> Date: Mon, 16 Sep 2013 22:08:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Benoit Claise References: <52329A7A.7060103@headstrong.de> <52330712.8060104@cs.tcd.ie> <5234422A.3010003@cisco.com> <5235F203.5090609@cs.tcd.ie> <4538CD25-68D8-407E-8B72-F0D5B76A7B9D@tik.ee.ethz.ch> <523613B8.2010308@cs.tcd.ie> <523771FD.3000801@cisco.com> In-Reply-To: <523771FD.3000801@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Brian Trammell Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 21:09:07 -0000 On 09/16/2013 10:02 PM, Benoit Claise wrote: > > In the use case of the ISP monitoring my access device & link, the ISP > has got anyway some personally identifiable information (PII) for his > monitoring. And this is what I'm expecting as a customer .... when I > call them, complaining about _my _link quality. Fair enough. OTOH, large organisations do tend to leak out information once enough people need access (cf. NSA and Snowden:-) so one might argue that having a well defined way to keep that PII private as you send it to and then have it stored/processed in the ISP may well be worthwhile. (And granting special access to some customer support applications.) > However, in the regulator use case, monitoring my access link, I don't > want to share any PII. More promising:-) So, I guess there ought be an argument for applying some of the Good-PRISM/RFC6325 techniques in lmap? If so that's good to hear. (If not, or probably not, be interested in that too.) Cheers, S. From bclaise@cisco.com Mon Sep 16 14:23:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E080311E81CE for ; Mon, 16 Sep 2013 14:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL-5lpvcOTW1 for ; Mon, 16 Sep 2013 14:23:21 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE4E11E825E for ; Mon, 16 Sep 2013 14:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1124; q=dns/txt; s=iport; t=1379366601; x=1380576201; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=brVvmk5a3uIhVLqBNuGgl3X7QJfhPbEycjUC7hiWEEQ=; b=DFjXfq7gupX8Lh/9dAJ7BCqd0gwmKiG4a+6SbZS3hYSPFfDd689GIJ2y DQ8Rnl77XWJBVQLQUidlFWR1aRTTWHvUerWwk8hsOzthmK0WbCB5DMFM/ spH+qeRT3pM8YCwDbA87RY1QN5UpW7HXQ/wVI61XXn2g75gXGQtCNXTZC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANR1N1KQ/khL/2dsb2JhbABagwe/EoJ7gSIWdIIlAQEBAwE4QAEQCxgJFg8JAwIBAgFFBg0BBwEBh3kGul6PcweEHgOXe4Ywi0SDJjo X-IronPort-AV: E=Sophos;i="4.90,872,1371081600"; d="scan'208";a="17578689" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 16 Sep 2013 21:23:20 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8GLNI2K004619; Mon, 16 Sep 2013 21:23:18 GMT Message-ID: <523776C5.2060302@cisco.com> Date: Mon, 16 Sep 2013 23:23:17 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <52329A7A.7060103@headstrong.de> <52330712.8060104@cs.tcd.ie> <5234422A.3010003@cisco.com> <5235F203.5090609@cs.tcd.ie> <4538CD25-68D8-407E-8B72-F0D5B76A7B9D@tik.ee.ethz.ch> <523613B8.2010308@cs.tcd.ie> <523771FD.3000801@cisco.com> <5237736B.40005@cs.tcd.ie> In-Reply-To: <5237736B.40005@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Brian Trammell Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 21:23:27 -0000 On 16/09/2013 23:08, Stephen Farrell wrote: > > On 09/16/2013 10:02 PM, Benoit Claise wrote: >> In the use case of the ISP monitoring my access device & link, the ISP >> has got anyway some personally identifiable information (PII) for his >> monitoring. And this is what I'm expecting as a customer .... when I >> call them, complaining about _my _link quality. > Fair enough. OTOH, large organisations do tend to leak out information > once enough people need access (cf. NSA and Snowden:-) so one might > argue that having a well defined way to keep that PII private as you > send it to and then have it stored/processed in the ISP may well be > worthwhile. (And granting special access to some customer support > applications.) > >> However, in the regulator use case, monitoring my access link, I don't >> want to share any PII. > More promising:-) So, I guess there ought be an argument for applying > some of the Good-PRISM/RFC6325 techniques in lmap? For sure. Regards, Benoit > If so that's good > to hear. (If not, or probably not, be interested in that too.) > > Cheers, > S. > . > From scott.brim@gmail.com Mon Sep 16 14:43:05 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BB021F9E77 for ; Mon, 16 Sep 2013 14:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m2lxrj2Pc8X for ; Mon, 16 Sep 2013 14:43:04 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D0C5421F9E36 for ; Mon, 16 Sep 2013 14:43:04 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wp4so4526608obc.14 for ; Mon, 16 Sep 2013 14:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AKPX9GR+Dk02uO7kPXmJ8mbVRT3D/XZllin5p8cCPhs=; b=m36DPsTuHNPbJ4tHPjFzpQpB4n02tBqb9QsoZO5IIhVHBLr1ilsequ/wDSuRN0wiWL AcbVQ0r89YcIw4/dphEgJodsy85KwWZvbRJssP++W2eelAbHt09LAUf6VurxM3/TE7VW BuzbbEAN1MInY0JphTreTyfECiE0d+wwcjYwU4kpKw5hnpW1mANlI2C/6uSRq6aj9Z74 hh1kEMIepoiQit3X8NQU4rPpX1ekRrWSBha2IGs9XfEnF6bNq8ilahlvU7SeBMS+L/pX WuXdrcVClyqf6y5+zJDkLpyvtaJEPIBY1AqODW3miG3bOmezCu9JsMTfW+nij1ytd1Hh 7Lng== X-Received: by 10.182.49.166 with SMTP id v6mr26917186obn.13.1379367784431; Mon, 16 Sep 2013 14:43:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.134 with HTTP; Mon, 16 Sep 2013 14:42:44 -0700 (PDT) In-Reply-To: <5237736B.40005@cs.tcd.ie> References: <52329A7A.7060103@headstrong.de> <52330712.8060104@cs.tcd.ie> <5234422A.3010003@cisco.com> <5235F203.5090609@cs.tcd.ie> <4538CD25-68D8-407E-8B72-F0D5B76A7B9D@tik.ee.ethz.ch> <523613B8.2010308@cs.tcd.ie> <523771FD.3000801@cisco.com> <5237736B.40005@cs.tcd.ie> From: Scott Brim Date: Mon, 16 Sep 2013 17:42:44 -0400 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b5d2ea4ce4d8f04e68716d4 Cc: Benoit Claise , perpass , Brian Trammell Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 21:43:05 -0000 --047d7b5d2ea4ce4d8f04e68716d4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 16, 2013 at 5:08 PM, Stephen Farrell wrote: > More promising:-) So, I guess there ought be an argument for applying > some of the Good-PRISM/RFC6325 techniques in lmap? If so that's good > to hear. (If not, or probably not, be interested in that too.) > The PII your ISP needs for access management is rather different from what IMAP needs :-) but yes that would be good in IMAP. Scott --047d7b5d2ea4ce4d8f04e68716d4 Content-Type: text/html; charset=ISO-8859-1
On Mon, Sep 16, 2013 at 5:08 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
More promising:-) So, I guess there ought be an argument for applying
some of the Good-PRISM/RFC6325 techniques in lmap? If so that's good
to hear. (If not, or probably not, be interested in that too.)

The PII your ISP needs for access management is rather different from what IMAP needs :-) but yes that would be good in IMAP.

Scott
--047d7b5d2ea4ce4d8f04e68716d4-- From stpeter@stpeter.im Mon Sep 16 14:47:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1BC11E81C8 for ; Mon, 16 Sep 2013 14:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dbfK+sdjBX4 for ; Mon, 16 Sep 2013 14:47:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8631C11E81B4 for ; Mon, 16 Sep 2013 14:47:13 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BB16B4163F; Mon, 16 Sep 2013 15:51:57 -0600 (MDT) Message-ID: <52377C5E.6060903@stpeter.im> Date: Mon, 16 Sep 2013 15:47:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hannes Tschofenig References: <5232C047.1040607@gmx.net> In-Reply-To: <5232C047.1040607@gmx.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] draft-saintandre-xmpp-tls-01 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 21:47:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/13/13 1:35 AM, Hannes Tschofenig wrote: > Hi Peter, > > I am wondering whether it would be possible to link the > recommendations between draft-saintandre-xmpp-tls-01 and > draft-sheffer-tls-bcp-00 with respect to what it says about TLS. Sure. > I believe that the TLS recommendations should be generic for the > crypto (no RC4, key length, etc.) and don't depend on the specific > application that is being protected. In general, yes. There might be some differences depending on the application protocol that uses TLS. > Of course you could argue that it makes sense to replicate the text > for simpler readability. One thing I'm trying to do with draft-saintandre-xmpp-tls is educate and engage the XMPP community in the task of upgrading the security profile of the XMPP network (a conversation that predates the recent incidents). > One other remark about session resumption. There are two versions > of session resumption, namely one that is part of the base TLS spec > and another one that provides session resumption without server > side state. From your text it seems that focus on the latter, which > is OK. > > RFC 5077 already says that you have to encrypt and authenticate > the ticket. What can be said in the XMPP context is to implement > the recommended format of the ticket to avoid problems with not > encrypting the information or not authenticating it. The info is > found in Section 4 of RFC 5077. Of course, we could double-check > the recommended algorithms for that as well. About session resumption, I need to look more closely at RFC 5077 and the version that is in the base spec. I am not yet fully sure that citing RFC 5077 is the right thing for XMPP. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSN3xeAAoJEOoGpJErxa2p/PMP/0Adzg6321ojzvCNgBMLMNIC z3+WR/xbG1uJBmCiZ5cLU08HuINn+x1LTLeraZHDGxrHw5Uv1nRK3FAGZqKSLktK duX9lNBhQCYDms62vKFO8femJaGBi4fLlS4a1fqDqJnNgDk8IbtOghHq4CDYJuhm MLZrTJpogo3TxaUpDacBzzqrTEQPuSS04lbcZGtrRibe99DdxY9TrmVSeoZajXD1 /AWpp4tuyRQU08j4yg1K2VdQvXYfy6xKsgrkvXEqCa7S8h4/2l3AjghyoQ21p5iw ZnQuUK5xA+w737/FtmsClZo057Cd6O5gQht523MtLXe8a/mqtXScPq4Uc4aNh5LK bKqG0NL+tg8Jk+tnnHjhy3/WJU4GCPW+JB8JNuGLAARhYHPK6vup6ybxFmEiU9nC D6fzhjB9+YTY/Jsb4RU5LEqduDG961wf5oXHVj0dN/Zokh5vZEZGSLH5rPmqKtG1 LFu3t/8ocXiZ2ojEadZ53L+U8h1BWozVQJVJenFhZ1Okvewo10Q5n1K4chnt+qZx 3BYR8SPcEPvklVrIA5KjiGCiX8hLpTcUn3k6RlqEhzyyiYGPCoDWv9JXgk/AssAF 72tmLznjgGBTk+ueauragAdojSVOuQdbKoQEGNNR6VCaHy/hDXxV7XTpRaw2OZPH 46SP98PVUxQQRIQdh7oC =wsJy -----END PGP SIGNATURE----- From davieseb@scss.tcd.ie Mon Sep 16 15:11:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163E711E819C for ; Mon, 16 Sep 2013 15:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8O0XhAlcbHw for ; Mon, 16 Sep 2013 15:11:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4E89E11E815C for ; Mon, 16 Sep 2013 15:11:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 88270BEA1; Mon, 16 Sep 2013 23:11:33 +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 239NtfxfryFH; Mon, 16 Sep 2013 23:11:32 +0100 (IST) Received: from [10.1.4.180] (unknown [31.216.238.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 599CDBE70; Mon, 16 Sep 2013 23:11:31 +0100 (IST) Date: Mon, 16 Sep 2013 23:11:28 +0100 Message-ID: From: Elwyn Davies To: Karl Dubost MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: Stephen Farrell , perpass@ietf.org, Patrick Pelletier , ietf-http-wg@w3.org, Nicolas Mailhot Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 22:11:41 -0000 CgpJIGRvbid0IHRoaW5rIHRoaXMgaGFzIGJlZW4gbWVudGlvbmVkLi4uCgpTb21lIHNlcnZlcnMg d2lsbCBub3Qgc2VydmUgcGVyZmVjdGx5IGdvb2QgcmVxdWVzdHMgd2l0aCBjZXJ0YWluIFVBIHN0 cmluZ3MgKGUuZy4sIFdpa2lwZWRpYSBhY2Nlc3NlZCBmcm9tIGEgc3BlY2lhbCBwdXJwb3NlIGNs aWVudCBidWlsdCB1c2luZyBQeXRob24gbGlicmFyaWVzIHRoYXQgaGF2ZSBhIGJ1aWx0IGluIGRl ZmF1bHQgVUEgc3RyaW5nLCBhbHNvIHNvbWUgc2VydmVycyB3aXRoICd3Z2V0JykuICBPZiBjb3Vy c2UgdGhlIFB5dGhvbiBjbGllbnQgY2FuICdsaWUnIHdpdGggdHJpdmlhbCBlZmZvcnQgYW5kIHVz ZSAgdGhlIHNhbWUgVUEgc3RyaW5nIHRoYXQgYW4gJ2FwcHJvdmVkJyBicm93c2VyIHdvdWxkIHVz ZS4uLiB0aGVuIHRoZSByZXN1bHRzIGZsb3cgYmFjayBqdXN0IGFzIGlmIHRoZSBnZW51aW5lIGJy b3dzZXIgaGFkIGFza2VkLgoKSSBjYW4ndCByZW1lbWJlciBpZiAgV2lraXBlZGlhIHJlZnVzZWQg YW55dGhpbmcgdGhhdCB3YXNuJ3QgYXBwYXJlbnRseSBmcm9tIGEgd2VsbC1rbm93biBicm93c2Vy IG9yIHdhcyBzZW5zaXRpdmUgc3BlY2lmaWNhbGx5IHRvIHRoZSBQeXRob24gY2FzZS4KClJlZ2Fy ZHMsCkVsd3luCgoKU2VudCBmcm9tIG15IEFTVVMgUGFkCgpLYXJsIER1Ym9zdCA8a2FybEBsYS1n cmFuZ2UubmV0PiB3cm90ZToKCj5OaWNvbGFzIE1haWxob3QgWzIwMTMtMDktMTZUMTI6MzRdOgo+ PiBVc2VyLUFnZW50IGlzIGludmFsdWFibGUgZm9yIGZpbHRlcmluZyBvdXQgcGF0aG9sb2dpYyB3 ZWIgY2xpZW50cyBpbiBhIG5ldHdvcmsgd2l0aG91dCBib3RoZXJpbmcgbGVnaXRpbWF0ZSB1c2Vy cy4KPgo+KiBBdCB3aGljaCBsZXZlbCBkbyB5b3UgbmVlZCB0byBmaWx0ZXIgb3V0PyAocHJveHks IHNlcnZlciwg4oCmKQo+KiBXaGljaCB0eXBlIG9mIGNsaWVudHM/IChib3QsIGJyb3dzZXIsIGV0 Yz8pCj4qIFdoeSBkbyB5b3UgbmVlZCB0byBmaWx0ZXIgb3V0Pwo+KiBXaGF0IGFyZSB5b3UgbG9v a2luZyBmb3IgaW4gdGhlIFVBIHN0cmluZz8KPgo+L21lIGlzIGludGVyZXN0ZWQgdG8ga25vdy4g SSdtIGtpbmQgb2YgY29sbGVjdGluZyBob3cgdGhlIFVBIHN0cmluZyBpcyB1c2VkIG91dCBpbiB0 aGUgd2lsZCBpbiBnb29kIGFuZCBiYWQgd2F5cy4KPgo+LS0gCj5LYXJsIER1Ym9zdAo+aHR0cDov L3d3dy5sYS1ncmFuZ2UubmV0L2thcmwvCj4KPgo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo+cGVycGFzcyBtYWlsaW5nIGxpc3QKPnBlcnBhc3NAaWV0 Zi5vcmcKPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGVycGFzcwo= From stephen.farrell@cs.tcd.ie Mon Sep 16 16:59:48 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D3211E815F for ; Mon, 16 Sep 2013 16:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEs-Lu2-QCp1 for ; Mon, 16 Sep 2013 16:59:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C20DB11E80D5 for ; Mon, 16 Sep 2013 16:59:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52901BE83 for ; Tue, 17 Sep 2013 00:59: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 rrbhch+cEpYJ for ; Tue, 17 Sep 2013 00:59:34 +0100 (IST) Received: from [10.87.48.3] (unknown [86.44.72.81]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F28DBE76 for ; Tue, 17 Sep 2013 00:59:34 +0100 (IST) Message-ID: <52379B65.8060100@cs.tcd.ie> Date: Tue, 17 Sep 2013 00:59:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 23:59:48 -0000 Hiya, I've gone through the perpass archive to try make a list of the things that seem to be more doable/stable. This is just to make it more manageable for me, the list has no official status whatsoever. I've not included things where I'm not clear what might be the outcome. Even if I include something I may well be wrong that there'll be a clear outcome. Let me know if I've missed stuff (probably) or if you've any other comments. On or off list, whichever's better. I do know that some other folks are discussing some other relevant activities that are not yet published or weren't mentioned on this list. When/if you want those added here, just give me the info. and I'll add it. (If your thing hasn't been discussed on an IETF list or published in an I-D, I'd rather see that happen first if you don't mind, for all the normal tedious IPR/Note-well reasons.) I'll sporadically maintain this between now and Vancouver at [1] (you may prefer to read it at [2], since [1] will get you browser warnings about my self-signed cert. (*) Cheers, S. [1] https://down.dsg.cs.tcd.ie/misc/perpass.txt [2] http://down.dsg.cs.tcd.ie/misc/perpass.txt (*) Nothing to do with the topic really but I just noticed I'd not updated the key pair in 5 years so I made a new one a few minutes ago since now's a good time before this year's batch of students arrive. (How they complain about that tells me a bit about 'em:-) From hallam@gmail.com Mon Sep 16 18:07:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D274111E8173 for ; Mon, 16 Sep 2013 18:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Z3K7YKqejCs for ; Mon, 16 Sep 2013 18:06:53 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 962CC21F8468 for ; Mon, 16 Sep 2013 18:06:50 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id u14so4760615lbd.40 for ; Mon, 16 Sep 2013 18:06:46 -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; bh=eDl/tOoy4DElvnNCG5aeQzcyX8OLi3ZOako9XzBgGuM=; b=FqW7jUsdLrSopOX5+3TJx1KAo0zJHHwkQuyMeVZTyz6K19d9Bx+AZiQ2a1ZhoxU2Yi hwn8Xi3UqSWvzGfl+NDHcTrsVirtM27A+pr+0nc4laEn+jFEP4BVJv0hZDcNVP2yhafB 3NIRAg5NUL6AAbARAGpEDpXGVlo9rE3AJFpZth+5xcS6aCJtl6A8ZTIp1kWi2c2Oe4wV UVAcUN1g4Ls90FKjfIxkYuBD9SWsSKcOYrChojgIIwif7g/q6qs0r8qAmkmPeltV7ews rVoYMhCt5b0q+RNohXO7diE6QunsAToFyBAoMx6b3QGKoK42Q2g4Mq8ZEXZQaX3OMsH5 MqcA== MIME-Version: 1.0 X-Received: by 10.112.168.170 with SMTP id zx10mr27377317lbb.0.1379380006527; Mon, 16 Sep 2013 18:06:46 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Mon, 16 Sep 2013 18:06:46 -0700 (PDT) In-Reply-To: <52379B65.8060100@cs.tcd.ie> References: <52379B65.8060100@cs.tcd.ie> Date: Mon, 16 Sep 2013 21:06:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c23c884ca98e04e689efd2 Cc: perpass Subject: Re: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 01:07:07 -0000 --001a11c23c884ca98e04e689efd2 Content-Type: text/plain; charset=ISO-8859-1 I wrote a draft that attempts to set out criteria for 'PRISM-PROOF' security. Actually it is more general than that looking at any bulk surveillance scheme. It is a summary of material from this and other lists. The main reason I wrote it was to capture conversation from other lists that kept going round in circles and to provide a basis for evaluating my other design. On Mon, Sep 16, 2013 at 7:59 PM, Stephen Farrell wrote: > > Hiya, > > I've gone through the perpass archive to try make a > list of the things that seem to be more doable/stable. > > This is just to make it more manageable for me, the > list has no official status whatsoever. I've not included > things where I'm not clear what might be the outcome. > Even if I include something I may well be wrong that > there'll be a clear outcome. > > Let me know if I've missed stuff (probably) or if you've > any other comments. On or off list, whichever's better. > > I do know that some other folks are discussing some > other relevant activities that are not yet published or > weren't mentioned on this list. When/if you want those > added here, just give me the info. and I'll add it. (If > your thing hasn't been discussed on an IETF list or > published in an I-D, I'd rather see that happen first if > you don't mind, for all the normal tedious IPR/Note-well > reasons.) > > I'll sporadically maintain this between now and Vancouver > at [1] (you may prefer to read it at [2], since [1] will > get you browser warnings about my self-signed cert. (*) > > Cheers, > S. > > [1] https://down.dsg.cs.tcd.ie/misc/perpass.txt > [2] http://down.dsg.cs.tcd.ie/misc/perpass.txt > > (*) Nothing to do with the topic really but I just noticed > I'd not updated the key pair in 5 years so I made a new one > a few minutes ago since now's a good time before this year's > batch of students arrive. (How they complain about that > tells me a bit about 'em:-) > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > -- Website: http://hallambaker.com/ --001a11c23c884ca98e04e689efd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I wrote a draft that attempts to set out criteria for '= ;PRISM-PROOF' security. Actually it is more general than that looking a= t any bulk surveillance scheme. It is a summary of material from this and o= ther lists.

The main reason I wrote it was to capture conversation from = other lists that kept going round in circles and to provide a basis for eva= luating my other design.


On Mon, Sep 16, 2013 at 7:59 PM, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:

Hiya,

I've gone through the perpass archive to try make a
list of the things that seem to be more doable/stable.

This is just to make it more manageable for me, the
list has no official status whatsoever. I've not included
things where I'm not clear what might be the outcome.
Even if I include something I may well be wrong that
there'll be a clear outcome.

Let me know if I've missed stuff (probably) or if you've
any other comments. On or off list, whichever's better.

I do know that some other folks are discussing some
other relevant activities that are not yet published or
weren't mentioned on this list. When/if you want those
added here, just give me the info. and I'll add it. (If
your thing hasn't been discussed on an IETF list or
published in an I-D, I'd rather see that happen first if
you don't mind, for all the normal tedious IPR/Note-well
reasons.)

I'll sporadically maintain this between now and Vancouver
at [1] (you may prefer to read it at [2], since [1] will
get you browser warnings about my self-signed cert. (*)

Cheers,
S.

[1] https://down.dsg.cs.tcd.ie/misc/perpass.txt
[2] http://down.dsg.cs.tcd.ie/misc/perpass.txt

(*) Nothing to do with the topic really but I just noticed
I'd not updated the key pair in 5 years so I made a new one
a few minutes ago since now's a good time before this year's
batch of students arrive. (How they complain about that
tells me a bit about 'em:-)


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



--
Website: http://hallambaker.com/
Speaking as a browser vendor, we do try to limit the info = we send in the UA string. It's sadly difficult. Please refer to=A0http://webaim.org/= blog/user-agent-string-history/. Changing the UA string breaks web comp= at, and when the end user's favorite site fo= o.com fails to render in browser X, the end user switches to browser Y.=

For a fairly recent discussion of this on the Chromium devel= oper's mailing list, feel free to refer to=A0

On Fri,= Sep 13, 2013 at 12:18 PM, Patrick Pelletier <code@funwithsoftware= .org> wrote:
Forwarding this idea along to httpbis as you= (Stephen) suggested. =A0Although this could be retrofitted onto existing H= TTP, not just httpbis, since it's merely recommending practices which a= re already legal in HTTP.

On Sep 13, 2013, at 5:17 AM, Stephen Farrell wrote:

On 09/13/2013 04:12 AM, Patrick Pelletier wrote:
On 9/12/13 1:18 PM, Dave Crocker wrote:

=A0 =A0"privacy properties of IETF protocols and concrete ways in whic= h
=A0 =A0 those could be improved."

One obvious thing is the amount of (usually unnecessary) information
leaked by the User-Agent field in HTTP.

Should we downgrade the User-Agent field (section 14.43 of RFC 2616)
from a SHOULD to a MAY?

I think everyone finds those values problematic, and not only for
privacy reasons. But yes, if you believe [1] then its probably the
biggest contributor to browser fingerprinting that's in an IETF
spec. (No idea if that site's evaluation is sound myself though.)

=A0 [1] https:/= /panopticlick.eff.org/

Or, if that's too radical, should we standardize a small number of fixe= d
strings to use in the User-Agent field? =A0(For example, "Desktop/1.0&= quot; for
desktop browsers, "Mobile/1.0" for mobile browsers, "Text/1.= 0" for text
browsers like Lynx, "Batch/1.0" for non-interactive clients like = curl
which are performing a task more specific than crawling the web, and
"Robot/1.0" for clients which are crawling the web?)

Interesting. An IANA registry of those kinds of value might just end
up like the UA string though, which also started out nice and simple.

I agree that things always start out simple and get messy. =A0However, I th= ink there are some differences:

* The original User-Agent field was not designed with privacy in mind. =A0I= n fact, it was designed specifically to identify the product and version th= e user is using. =A0So, with a different goal (privacy first), we will hope= fully get different results.

* By specifying only a single product token, omitting comments, and fixing = the version number at 1.0, we've already eliminated a fair amount of in= formation. =A0And then we further limit the information by making the produ= ct name not the actual name of the software, but merely a generic indicatio= n of the type of User-Agent; whatever is the minimal amount of information = necessary for any legitimate browser sniffing that needs to occur. =A0(Such= as differentiating desktop and mobile clients.)

And, of course, using the simplified User-Agent strings was just one of my = two proposals. =A0My other proposal, which was even simpler, though perhaps= more radical, was to downgrade the requirement on User-Agent from SHOULD t= o MAY, and encourage browsers not to send User-Agent at all. =A0(We could e= ven change it to a SHOULD NOT if we feel really heavy-handed.) =A0One could= argue that by using other techniques such as responsive layout, no browser= sniffing should be necessary at all.

Maybe ask this on httpbis if you don't get more feedback here? That'= ;s
where you'd find folks who know if it could be done and who could do it.

--Patrick



--089e01229ed4430b7404e64a731d-- From moritz@headstrong.de Sat Sep 14 18:11:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD9711E8101 for ; Sat, 14 Sep 2013 18:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCJONiaeK5ED for ; Sat, 14 Sep 2013 18:11:40 -0700 (PDT) Received: from mail.headstrong.de (mail.headstrong.de [IPv6:2a02:180:a:25:2::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3A611E8100 for ; Sat, 14 Sep 2013 18:11:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.headstrong.de (Postfix) with ESMTP id 7885F1C00501 for ; Sun, 15 Sep 2013 03:11:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=headstrong.de; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:mime-version:user-agent :from:from:date:date:message-id:received; s=mail; t=1379207497; x=1381021898; bh=UvRRzwkaYMmMgP9/z37R99A4YkP+8HolJaGwar3cgfM=; b= kQcvckfyH1T+SoQEkQDZy6v0ujLxE236Z6KK3/DCSGymCLjOcwRib3DdiKZn/LfW aL9Cya/Z06NFMnXeN6AUO0gHzHrwJOU1bRURUVgzzIZLHZGy5IpUZxDq/RBX0hHq YO1ttj3MuDvNg3N8BQA+Em7JpGh7U1MjyGejSWkR/3U= X-Virus-Scanned: Debian amavisd-new at mail.headstrong.de Received: from mail.headstrong.de ([127.0.0.1]) by localhost (mail.headstrong.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AZhFWF50v4-4 for ; Sun, 15 Sep 2013 03:11:37 +0200 (CEST) Message-ID: <5235093A.20704@headstrong.de> Date: Sun, 15 Sep 2013 03:11:22 +0200 From: Moritz Bartl User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130827 Icedove/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <52329A7A.7060103@headstrong.de> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 01:11:40 -0000 On 09/14/2013 06:12 AM, manning bill wrote: >> On a side node, can we do anything to get rid of sender IP addresses in >> (the first) Received headers of mail? > is there a good reason to remove support for address literals? > are you _really_ forcing a critical dependence on the DNS? Sorry. What I meant to say was "get rid of sender addresses", as in client addresses. Both hostname and IP. Today, where most people use SMTP relays, the relay should not include sender address from authenticated senders in mail headers. They can keep a local mapping, say of Message-ID to sender, as long as necessary, but I don't see any reason to include that data as "world readable" in the mail headers. Gmail doesn't do it, for example, and rightly so. As a counter-example, Postfix makes it artificially hard, and it should be its default. --Mo From randy@psg.com Sat Sep 14 18:59:51 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E9211E80DC for ; Sat, 14 Sep 2013 18:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHiKYDylRe4F for ; Sat, 14 Sep 2013 18:59:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 423FB11E80A2 for ; Sat, 14 Sep 2013 18:59:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VL1co-00050l-6N; Sun, 15 Sep 2013 01:59:47 +0000 Date: Sat, 14 Sep 2013 15:59:44 -1000 Message-ID: From: Randy Bush To: William Chan (=?ISO-2022-JP-2?B?GyRBM0IbJEJDUj47GyhC?=) In-Reply-To: References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 01:59:51 -0000 < a fair bit off topic > forgetting ww2, isn't this the wrong way around? the browser should speak of which of a well-known feature set it supports, not what it's 'name' happens to be. randy From ynir@checkpoint.com Sat Sep 14 22:18:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD4821E8096 for ; Sat, 14 Sep 2013 22:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.045 X-Spam-Level: X-Spam-Status: No, score=-10.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnQnxMid8bka for ; Sat, 14 Sep 2013 22:18:05 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8797D21E8090 for ; Sat, 14 Sep 2013 22:18:04 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8F5HvUZ023851; Sun, 15 Sep 2013 08:17:57 +0300 X-CheckPoint: {52354305-5-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sun, 15 Sep 2013 08:17:57 +0300 From: Yoav Nir To: Randy Bush Thread-Topic: [perpass] HTTP user-agent fingerprinting Thread-Index: AQHOsC8g6O/zvNoRJU68/w5mTqx6HZnDY9OAgAB1lQCAACKaAIAB39MAgAA3YQA= Date: Sun, 15 Sep 2013 05:17:57 +0000 Message-ID: References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.33] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <00AEE6DFE0C1A444A8C7E329CAE1108B@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass , William Chan Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 05:18:10 -0000 It's not just a set of features. Sure, it all started with Netscape support= ing frames whereas Mosaic did not. So it would be nice if it just advertise= d "Supports: frames". But then IE also supported frames, but if the graphic= s designer made a web page so that it was nice and pretty and aligned perfe= ctly in Netscape, it looked all screwy in IE, because of differences in spa= cing within and between frames. So it helped to be able to serve different = pages to different browsers. And then came active content, with Java applet= s and ActiveX and embedded video and javascript/vbscript, and things got wo= rse. It's been getting better in the last few years, but not that much bett= er than you can make a single version of your website. On Sep 15, 2013, at 4:59 AM, Randy Bush wrote: > < a fair bit off topic > >=20 > forgetting ww2, isn't this the wrong way around? the browser should > speak of which of a well-known feature set it supports, not what it's > 'name' happens to be. >=20 > randy From ggm@algebras.org Sat Sep 14 23:57:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17821F9C9A for ; Sat, 14 Sep 2013 23:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qIWNAL-0j2J for ; Sat, 14 Sep 2013 23:56:59 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0238021F9ED4 for ; Sat, 14 Sep 2013 23:56:53 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so4140551pad.4 for ; Sat, 14 Sep 2013 23:56:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bfk8kTW412VuvoA2uwylTnWhV13EZIbzutIlt7kvq1I=; b=FD3la9ng81XyMqtQugC6on7dakL9vRSjhAqyOsJxkTHBreNxlAHozjnCeGTaoG552c OwvpNqT8ifw4SL9YhNcdS7jzg2W6U2Xh61MVDIQyDE+LfPJ7OWGoBx2/aiDC8nOL1dQy GKYD6KXbudofsniCH307f/LrihS3XVtMn2KIknE13T02CXQqehk3Rqbddcq66DUyRZ5x SzKPXJqOUYMmYU+CHQuhrmEg2JpsZFvA+8OSE+GcOd+uEdU8Q3vh3zjWjgGCII35Iz0M EFlYxQy7XVZIJ1f0MPrREyNYNZ/a7BGhIB1uhhTgK4+JDliALemKJst6t0qCRNW+wH5f QHsw== X-Gm-Message-State: ALoCoQlDTguTuBv9thr4cWhnnNXMObIxU43UuEM3F2z2RAeIZOwMYf5A7eR9Qk7IuCM3qkSUrfRi MIME-Version: 1.0 X-Received: by 10.66.162.195 with SMTP id yc3mr24309480pab.64.1379228211669; Sat, 14 Sep 2013 23:56:51 -0700 (PDT) Received: by 10.70.19.98 with HTTP; Sat, 14 Sep 2013 23:56:51 -0700 (PDT) X-Originating-IP: [2001:44b8:2136:8e00:c0a9:9b10:efb3:cb62] In-Reply-To: References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> Date: Sun, 15 Sep 2013 16:56:51 +1000 Message-ID: From: George Michaelson To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7b6dc1a89f01d504e66697d1 Cc: Randy Bush , perpass , William Chan Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 06:57:06 -0000 --047d7b6dc1a89f01d504e66697d1 Content-Type: text/plain; charset=ISO-8859-1 please don't laugh if I mention TELNET options negotiation or SMTP capabilites exchange.. (I find browser strings fascinating. the sheer volume of 'I may behave like ' statements adds up to a mighty mishmash of things none of which directly relate to what I think web code developers wanted, although 'works in IE5' may indeed be "it") -G On Sun, Sep 15, 2013 at 3:17 PM, Yoav Nir wrote: > It's not just a set of features. Sure, it all started with Netscape > supporting frames whereas Mosaic did not. So it would be nice if it just > advertised "Supports: frames". But then IE also supported frames, but if > the graphics designer made a web page so that it was nice and pretty and > aligned perfectly in Netscape, it looked all screwy in IE, because of > differences in spacing within and between frames. So it helped to be able > to serve different pages to different browsers. And then came active > content, with Java applets and ActiveX and embedded video and > javascript/vbscript, and things got worse. It's been getting better in the > last few years, but not that much better than you can make a single version > of your website. > > On Sep 15, 2013, at 4:59 AM, Randy Bush > wrote: > > > < a fair bit off topic > > > > > forgetting ww2, isn't this the wrong way around? the browser should > > speak of which of a well-known feature set it supports, not what it's > > 'name' happens to be. > > > > randy > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --047d7b6dc1a89f01d504e66697d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
please don't laugh if I mention TELNET options negotia= tion or SMTP capabilites exchange..

(I find browser stri= ngs fascinating. the sheer volume of 'I may behave like <x>' = statements adds up to a mighty mishmash of things none of which directly re= late to what I think web code developers wanted, although 'works in IE5= ' may indeed be "it")

-G


=
On Sun, Sep 15, 2013 at 3:17 PM, Yoav Nir <yn= ir@checkpoint.com> wrote:
It's not just a set of features. Sure, i= t all started with Netscape supporting frames whereas Mosaic did not. So it= would be nice if it just advertised "Supports: frames". But then= IE also supported frames, but if the graphics designer made a web page so = that it was nice and pretty and aligned perfectly in Netscape, it looked al= l screwy in IE, because of differences in spacing within and between frames= . So it helped to be able to serve different pages to different browsers. A= nd then came active content, with Java applets and ActiveX and embedded vid= eo and javascript/vbscript, and things got worse. It's been getting bet= ter in the last few years, but not that much better than you can make a sin= gle version of your website.

On Sep 15, 2013, at 4:59 AM, Randy Bush <randy@psg.com>
=A0wrote:

> < a fair bit off topic >
>
> forgetting ww2, isn't this the wrong way around? =A0the browser sh= ould
> speak of which of a well-known feature set it supports, not what it= 9;s
> 'name' happens to be.
>
> randy


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

--047d7b6dc1a89f01d504e66697d1-- From ynir@checkpoint.com Sun Sep 15 00:17:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F1121E809C for ; Sun, 15 Sep 2013 00:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fQdzGIYdHbM for ; Sun, 15 Sep 2013 00:17:07 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6B11E80E6 for ; Sun, 15 Sep 2013 00:16:53 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8F7GgUh019106; Sun, 15 Sep 2013 10:16:42 +0300 X-CheckPoint: {52355ED9-11-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sun, 15 Sep 2013 10:16:42 +0300 From: Yoav Nir To: George Michaelson Thread-Topic: [perpass] HTTP user-agent fingerprinting Thread-Index: AQHOsC8g6O/zvNoRJU68/w5mTqx6HZnDY9OAgAB1lQCAACKaAIAB39MAgAA3YQCAABujgIAANrcg Date: Sun, 15 Sep 2013 07:16:41 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772121A3773A@DAG-EX10.ad.checkpoint.com> References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.27] x-kse-antivirus-interceptor-info: protection disabled Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC302772121A3773ADAGEX10adcheckp_" MIME-Version: 1.0 Cc: Randy Bush , perpass , William Chan Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 07:17:13 -0000 --_000_4613980CFC78314ABFD7F85CC302772121A3773ADAGEX10adcheckp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the foo browser says "works like IE5" but then your page looks bad there= , users of the foo browser are going to complain both to you. So "works lik= e IE5" is an OK first step, but as a web developer you really want to know = what browser this really is, because you can't trust browser vendors to rea= lly exactly be like IE5. I guess that's why Adobe Flash had so much success. It really provided a ve= ry consistent experience across platforms provided everyone had the plug-in= . From: George Michaelson [mailto:ggm@algebras.org] Sent: Sunday, September 15, 2013 9:57 AM To: Yoav Nir Cc: Randy Bush; perpass; William Chan Subject: Re: [perpass] HTTP user-agent fingerprinting please don't laugh if I mention TELNET options negotiation or SMTP capabili= tes exchange.. (I find browser strings fascinating. the sheer volume of 'I may behave like= ' statements adds up to a mighty mishmash of things none of which direc= tly relate to what I think web code developers wanted, although 'works in I= E5' may indeed be "it") -G On Sun, Sep 15, 2013 at 3:17 PM, Yoav Nir > wrote: It's not just a set of features. Sure, it all started with Netscape support= ing frames whereas Mosaic did not. So it would be nice if it just advertise= d "Supports: frames". But then IE also supported frames, but if the graphic= s designer made a web page so that it was nice and pretty and aligned perfe= ctly in Netscape, it looked all screwy in IE, because of differences in spa= cing within and between frames. So it helped to be able to serve different = pages to different browsers. And then came active content, with Java applet= s and ActiveX and embedded video and javascript/vbscript, and things got wo= rse. It's been getting better in the last few years, but not that much bett= er than you can make a single version of your website. On Sep 15, 2013, at 4:59 AM, Randy Bush > wrote: > < a fair bit off topic > > > forgetting ww2, isn't this the wrong way around? the browser should > speak of which of a well-known feature set it supports, not what it's > 'name' happens to be. > > randy _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass Email secured by Check Point --_000_4613980CFC78314ABFD7F85CC302772121A3773ADAGEX10adcheckp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If the foo browser says &= #8220;works like IE5” but then your page looks bad there, users of th= e foo browser are going to complain both to you. So “works like IE5&#= 8221; is an OK first step, but as a web developer you really want to know what b= rowser this really is, because you can’t trust browser vendors to rea= lly exactly be like IE5.

 <= /p>

I guess that’s why = Adobe Flash had so much success. It really provided a very consistent exper= ience across platforms provided everyone had the plug-in.=

 <= /p>

From: George M= ichaelson [mailto:ggm@algebras.org]
Sent: Sunday, September 15, 2013 9:57 AM
To: Yoav Nir
Cc: Randy Bush; perpass; William Chan
Subject: Re: [perpass] HTTP user-agent fingerprinting

 

please don't laugh if I mention TELNET options negot= iation or SMTP capabilites exchange..

 

(I find browser strings fascinating. the sheer volum= e of 'I may behave like <x>' statements adds up to a mighty mishmash = of things none of which directly relate to what I think web code developers= wanted, although 'works in IE5' may indeed be "it")

 

-G

 

On Sun, Sep 15, 2013 at 3:17 PM, Yoav Nir <ynir@checkpoint.com&= gt; wrote:

It's not just a set of features. Sure, it all starte= d with Netscape supporting frames whereas Mosaic did not. So it would be ni= ce if it just advertised "Supports: frames". But then IE also sup= ported frames, but if the graphics designer made a web page so that it was nice and pretty and aligned perfectly in Ne= tscape, it looked all screwy in IE, because of differences in spacing withi= n and between frames. So it helped to be able to serve different pages to d= ifferent browsers. And then came active content, with Java applets and ActiveX and embedded video and javas= cript/vbscript, and things got worse. It's been getting better in the last = few years, but not that much better than you can make a single version of y= our website.

On Sep 15, 2013, at 4:59 AM, Randy Bush <randy@psg.com>

 wrote:

> < a fair bit off topic >
>
> forgetting ww2, isn't this the wrong way around?  the browser sho= uld
> speak of which of a well-known feature set it supports, not what it's<= br> > 'name' happens to be.
>
> randy


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

 



Email secured by Check Point

--_000_4613980CFC78314ABFD7F85CC302772121A3773ADAGEX10adcheckp_-- From randy@psg.com Sun Sep 15 02:39:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DA721F9CFB for ; Sun, 15 Sep 2013 02:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9O2jO2rKBgh for ; Sun, 15 Sep 2013 02:39:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 09C6A21F9CF3 for ; Sun, 15 Sep 2013 02:39:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VL8o5-0005UR-5X; Sun, 15 Sep 2013 09:39:53 +0000 Date: Sat, 14 Sep 2013 23:39:51 -1000 Message-ID: From: Randy Bush To: Yoav Nir In-Reply-To: References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: PerPass Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 09:39:55 -0000 >> forgetting ww2, isn't this the wrong way around? again, forget the past, even though you are deeply entangled in the results of a design error, or lack of design. my point was for next time we design something, which is why i warned this is somewhat off topic. we have analogous lessons in many places. when receiving an ebgp announcement, color it indicating from what kind of peer it was received, not what exit it should take, let the exit decide. there are also analogs in programming. i could go on, but i'll be kind. randy From cloos@jhcloos.com Sun Sep 15 10:00:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C7411E8113 for ; Sun, 15 Sep 2013 10:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bR5OvmImCxUf for ; Sun, 15 Sep 2013 10:00:28 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id DCAAE21F9FCF for ; Sun, 15 Sep 2013 10:00:27 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 2B3A51E761; Sun, 15 Sep 2013 17:00:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1379264419; bh=32ROs/tBVyx6/yiddi0TeYCCy0K+PTwG4igDWv1GIjs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MCCX377/dTCmZTspa2ikmAJZ9IulUiS9dCiYJ4sX9xwkWiXOBOc+74jpFuc+SJ92w ZEjn7Z/HaKyyfMgj9AEVPiX6ojp5tA/sC/c67w95lijwbAvEggiJsKRjsMObxyYX2N v8OpDtaqbFJhzpQzvFPjHzJbK9kfypj55+qcyPtodOg== Received: by carbon.jhcloos.org (Postfix, from userid 500) id DB3156001E; Sun, 15 Sep 2013 16:58:29 +0000 (UTC) From: James Cloos To: Yaron Sheffer In-Reply-To: <522B6709.4070009@gmail.com> (Yaron Sheffer's message of "Sat, 07 Sep 2013 20:48:57 +0300") References: <522B2C86.7020300@gmail.com> <522B3F92.1090702@cs.tcd.ie> <522B6709.4070009@gmail.com> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 15 Sep 2013 12:58:29 -0400 Message-ID: Lines: 43 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130915:yaronf.ietf@gmail.com::o6MIvw51mKHpcLk8:00000000000000000000000000000000000000071gNC X-Hashcash: 1:28:130915:stephen.farrell@cs.tcd.ie::+7asIGZA60EGAP8F:000000000000000000000000000000000002+LYr X-Hashcash: 1:28:130915:perpass@ietf.org::CGwvShe/fbXbq6ZY:8hu8h Cc: perpass@ietf.org, Stephen Farrell Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 17:00:30 -0000 >>>>> "YS" == Yaron Sheffer writes: YS> S/MIME with DANE would alleviate this problem if organizations were YS> allowed to generate their own certificates, including email certs, YS> and have them chained to the DNS root of trust. I don't know if DANE YS> supports this usage scenario by default. draft-ietf-dane-smime-02.txt exists. Webfinger may be a better choice, though. It is defined in draft-ietf-appsawg-webfinger-18.txt. Details on how to store public keys in webfinger are not yet specified in any draft, afaics. Dane tlsa records of course can be used to secure the the webfinger uri. If one does that, the steps to find or verify an smime or pgp public key include: Convert the email address to a webfinger uri Do the a/aaaa and tlsa lookups on the hostname in that uri If those dnssec-verify, retrieve the uri Find the public key (or a link to the public key) in the json reply The trust path, then, is rooted with the DS record for the dns root, follows the dnssec path to the rrsigs for the a/aaaa and tlsa records for the webfinger uri and trusts the content of the data retrieved from the uri on the basis that it trusts the location of the uri. That seems a bit brittle, but not any worse than trusting a path from some random ca of which one has never heard. Or a path through a WoT involving names/identifiers with which one is not familiar. And http serves large blobs better than dns does. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From stephen.farrell@cs.tcd.ie Sun Sep 15 10:44:53 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3611E8137 for ; Sun, 15 Sep 2013 10:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2B3ekZoszeW for ; Sun, 15 Sep 2013 10:44:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4680C21F9DB4 for ; Sun, 15 Sep 2013 10:44:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 36926BE76; Sun, 15 Sep 2013 18:44:47 +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 jgGmesoey9+Y; Sun, 15 Sep 2013 18:44:45 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.59.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AB319BE4C; Sun, 15 Sep 2013 18:44:45 +0100 (IST) Message-ID: <5235F203.5090609@cs.tcd.ie> Date: Sun, 15 Sep 2013 18:44:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Benoit Claise References: <52329A7A.7060103@headstrong.de> <52330712.8060104@cs.tcd.ie> <5234422A.3010003@cisco.com> In-Reply-To: <5234422A.3010003@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 17:44:54 -0000 Hi Benoit, On 09/14/2013 12:02 PM, Benoit Claise wrote: > On 13/09/2013 14:37, Stephen Farrell wrote: >> >> On 09/13/2013 05:54 AM, Moritz Bartl wrote: >>> Hi, >>> >>> I would very much like to see servers having a minimal logging policy by >>> default, especially and at least when it comes to IP addresses. I wonder >>> if RFC 6302 is the right document to look at or extend for this. >> Or obsolete it. >> >>> It is easy to flip a switch to enable IP logging. The default should be >>> no IP logs, which is true for most XMPP servers, for example, but not >>> for web or mail servers. >> The wonderfully ironically named PRISM [1] project was an EU funded >> project that did some work on obfuscating IP addresses in logs. > rfc6235 Yep, sections 4 & 5 of that are generic and not really ipfix specific. Do you know of implementations of that for ipfix? Or libraries that do the various functions? I wonder if separating those sections out into a separate RFC would result in more people writing code that supports those kinds of transformations. Not sure to be honest. But that is a useful reference, regardless, Thanks, S. > > Regards, Benoit >> >> I'd love to see an RFC that described such techniques and recommended >> when to use what, so we could point people at that. >> >> Any takers for a -00 to get that going? >> >> S. >> >> [1] http://www.fp7-prism.eu/ >> >>> On a side node, can we do anything to get rid of sender IP addresses in >>> (the first) Received headers of mail? >>> >>> -- Moritz >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> . >> > > From yaronf.ietf@gmail.com Sun Sep 15 11:08:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D421A11E813A for ; Sun, 15 Sep 2013 11:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX9hzy2Eejy3 for ; Sun, 15 Sep 2013 11:08:14 -0700 (PDT) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 77F6411E8146 for ; Sun, 15 Sep 2013 11:08:12 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id d49so1565790eek.6 for ; Sun, 15 Sep 2013 11:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rgAlOpdHS32idYYMaTTswwViScfPo8IrXgPtq901gDs=; b=W/7Oq9x/XNldxQwX0Txk5zAUO1/UcJVXUx8kWJXrQqGIEfSKtJN5U6BKlhqIKQMO+r rpfzsOReC3xSLRMwQXhdRwkc4jFUH7dXaBJ+Hb6dVnubHaEW8p8H/qklKLzGItMyv/rn IMrP31z9EeaakzhbCsOssurN5VEJ3ROXbKhghyiwKprbRPkcvRc1KR0IvYqFhIWSzKB+ MrAzzlLT0fX735kIT3rmEH2A1CEFX+iLtLXqlQo4dh62XvfjEZBIo91XheMGm5u6HpVp cwzGMcCJQBTCGox0NSEh1SAriRwM6uyP3H/qdrLR7rKNpSnrKK73Ebnu4c/nf4RVHmxq tpSQ== X-Received: by 10.15.36.9 with SMTP id h9mr37233386eev.30.1379268490403; Sun, 15 Sep 2013 11:08:10 -0700 (PDT) Received: from [10.0.0.8] (bzq-79-181-201-37.red.bezeqint.net. [79.181.201.37]) by mx.google.com with ESMTPSA id d8sm34925269eeh.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 11:08:09 -0700 (PDT) Message-ID: <5235F788.8040501@gmail.com> Date: Sun, 15 Sep 2013 21:08:08 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: James Cloos References: <522B2C86.7020300@gmail.com> <522B3F92.1090702@cs.tcd.ie> <522B6709.4070009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Stephen Farrell Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 18:08:14 -0000 Hi Jim, I agree that storing users' public keys in DNS is weird. But I also wonder about your proposal: it sounds like you're putting the entire organization's list of employees on a public Web server. Wouldn't the following be simpler and more natural than both proposals: - The organization maintains its own CA, maybe just for S/MIME client certs. - The CA cert is kept as a DNS record, signed by DANE. - The CA cert is usage-limited, so it can be used for S/MIME only, and only for addresses at this particular domain. [I suppose this is the hard part. Is it allowed by X.509?] Advantages: - This would leave S/MIME unchanged. - The cert validation code remains a combination of normal trust chain processing plus DANE. - No privacy issues: certificates are not published anywhere. - Users are managed within the organization, with widely available tools. Thanks, Yaron On 09/15/2013 07:58 PM, James Cloos wrote: >>>>>> "YS" == Yaron Sheffer writes: > > YS> S/MIME with DANE would alleviate this problem if organizations were > YS> allowed to generate their own certificates, including email certs, > YS> and have them chained to the DNS root of trust. I don't know if DANE > YS> supports this usage scenario by default. > > draft-ietf-dane-smime-02.txt exists. > > Webfinger may be a better choice, though. It is defined in > draft-ietf-appsawg-webfinger-18.txt. > > Details on how to store public keys in webfinger are not yet specified > in any draft, afaics. > > Dane tlsa records of course can be used to secure the the webfinger uri. > > If one does that, the steps to find or verify an smime or pgp public key > include: > > Convert the email address to a webfinger uri > > Do the a/aaaa and tlsa lookups on the hostname in that uri > > If those dnssec-verify, retrieve the uri > > Find the public key (or a link to the public key) in the json reply > > The trust path, then, is rooted with the DS record for the dns root, > follows the dnssec path to the rrsigs for the a/aaaa and tlsa records > for the webfinger uri and trusts the content of the data retrieved from > the uri on the basis that it trusts the location of the uri. > > That seems a bit brittle, but not any worse than trusting a path from > some random ca of which one has never heard. Or a path through a WoT > involving names/identifiers with which one is not familiar. > > And http serves large blobs better than dns does. > > -JimC > From trammell@tik.ee.ethz.ch Sun Sep 15 12:42:28 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08D11E818E for ; Sun, 15 Sep 2013 12:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH-YsG7CvyT2 for ; Sun, 15 Sep 2013 12:42:23 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6E52E11E8194 for ; Sun, 15 Sep 2013 12:42:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 4EDBAD9305; Sun, 15 Sep 2013 21:42:10 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id J4yexcYEOU2s; Sun, 15 Sep 2013 21:42:10 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id F1480D9304; Sun, 15 Sep 2013 21:42:09 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_B5AAD210-CA55-42E8-BC39-0667CBAE8A78"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <5235F203.5090609@cs.tcd.ie> Date: Sun, 15 Sep 2013 21:42:08 +0200 Message-Id: <4538CD25-68D8-407E-8B72-F0D5B76A7B9D@tik.ee.ethz.ch> References: <52329A7A.7060103@headstrong.de> <52330712.8060104@cs.tcd.ie> <5234422A.3010003@cisco.com> <5235F203.5090609@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: Benoit Claise , perpass@ietf.org Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 19:42:28 -0000 --Apple-Mail=_B5AAD210-CA55-42E8-BC39-0667CBAE8A78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Stephen, Benoit, all, The survey of anonymization techniques in 6235 was intended primarily to = be a complete accounting of methods one _could_ use to anonymize fields = (Information Elements) in a record, as opposed to a survey of methods we = knew to be implemented. Here the idea was to allow a complete = specification of a metadata format for specifying how records were = anonymized, as input to future analysis tasks to be done on the data = (since the anonymization method affects the set of analyses for which = the data can be used).=20 So we were really trying to solve a different problem: applying = anonymization (to mask irrelevant and potentially privacy-sensitive = information) while still maintaining the usefulness of the data for = specific analytical tasks. Here we'd like to get rid of absolutely = _everything_ that might be useful for analysis, just keeping around the = minimum necessary for the operation and management of the protocol. Which gets me back to thinking it would be very useful to have a survey = of the information radiated by protocols in common usage, then a = systematic exercise to make sure each of those bits of information which = may be identifiable serves a purpose that couldn't be done in an = anonymous or pseudonymous way. Cheers, Brian On Sep 15, 2013, at 7:44 PM, Stephen Farrell = wrote: >=20 > Hi Benoit, >=20 > On 09/14/2013 12:02 PM, Benoit Claise wrote: >> On 13/09/2013 14:37, Stephen Farrell wrote: >>>=20 >>> On 09/13/2013 05:54 AM, Moritz Bartl wrote: >>>> Hi, >>>>=20 >>>> I would very much like to see servers having a minimal logging = policy by >>>> default, especially and at least when it comes to IP addresses. I = wonder >>>> if RFC 6302 is the right document to look at or extend for this. >>> Or obsolete it. >>>=20 >>>> It is easy to flip a switch to enable IP logging. The default = should be >>>> no IP logs, which is true for most XMPP servers, for example, but = not >>>> for web or mail servers. >>> The wonderfully ironically named PRISM [1] project was an EU funded >>> project that did some work on obfuscating IP addresses in logs. >> rfc6235 >=20 > Yep, sections 4 & 5 of that are generic and not really ipfix > specific. >=20 > Do you know of implementations of that for ipfix? Or libraries > that do the various functions? >=20 > I wonder if separating those sections out into a separate RFC > would result in more people writing code that supports those > kinds of transformations. Not sure to be honest. >=20 > But that is a useful reference, regardless, > Thanks, > S. >=20 >>=20 >> Regards, Benoit >>>=20 >>> I'd love to see an RFC that described such techniques and = recommended >>> when to use what, so we could point people at that. >>>=20 >>> Any takers for a -00 to get that going? >>>=20 >>> S. >>>=20 >>> [1] http://www.fp7-prism.eu/ >>>=20 >>>> On a side node, can we do anything to get rid of sender IP = addresses in >>>> (the first) Received headers of mail? >>>>=20 >>>> -- Moritz >>>> _______________________________________________ >>>> perpass mailing list >>>> perpass@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perpass >>>>=20 >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>> . >>>=20 >>=20 >>=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_B5AAD210-CA55-42E8-BC39-0667CBAE8A78 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSNg2QAAoJENt3nsOmbNJczGsH/3KXmE4ZvocbonOEiaa4ULzN ETvxhGdfWq/MjBTNndGjD9yFQqvzbboGVUWxSavm0uexhn6q27VO/qzhMwYexeX4 /Sx1SlUrtfKpcaKAu4yu/lYUZ/tHjgo2S80NKjpqXy59Ne0ETa8FgPfR+XKB1MPs kt4yh5pAItT6BZhjR3P3HpOK4MTxeXmz0Ov0FM9KJEdlIG1UqolBf7w0MaXjqWNB fCKqJRCCOarpogWRosHA7TObaE1kkjGnnEzxDMAVnPNRYP7mzfE/MbLwdjvjhjvw THeMJTwycnbyz2INB75FKmeSb0+hO7KLYvlAHI2LbJMkPhz9thFVmgLZGru+cHc= =I7ZK -----END PGP SIGNATURE----- --Apple-Mail=_B5AAD210-CA55-42E8-BC39-0667CBAE8A78-- From sm@resistor.net Sun Sep 15 12:45:53 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAC111E81AC for ; Sun, 15 Sep 2013 12:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dS3vRsMItnn for ; Sun, 15 Sep 2013 12:45:52 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FB211E818E for ; Sun, 15 Sep 2013 12:45:52 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8FJjcxF019993; Sun, 15 Sep 2013 12:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379274342; bh=Shyo2ks7+fULyZLSBTTcVjmKQ0JkfB3JtIV6924K3dM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Zq1xx+ZMVKJfpYXdWu+VkzldfgvBkGZEq2zLX3IhXWyCaj9z6usZoDxM0MXlwOmR7 P6KUoPkiIM5HVHRijT8DFIc1dFqQqh+Es4+OgIBAqIQAT7Wl1XfVnfJ/fA0hsd7Hql LblQ3YueKfWbMKloRPCxHUYAp2q2+mclIIJWiYEQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1379274342; i=@resistor.net; bh=Shyo2ks7+fULyZLSBTTcVjmKQ0JkfB3JtIV6924K3dM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EfF3PV89Piglkfu+kmPoUPVHO4GJtSyWrJDmnwB9dVTlRkGmLyBLyntsllMaSyPc4 jTUZyhH2K6hL/SeKGtYyDHo9YkdDYaeBHEc1g9DpizTAlmFe2BEBJ5E2RNM1NH9o+8 yWZTB/5ENKLhMaNCjC6jK7xrcgfBmEhELlXGKdY8= Message-Id: <6.2.5.6.2.20130915124238.0ccc86f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 15 Sep 2013 12:45:06 -0700 To: Phillip Hallam-Baker From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] PRISM-Proof Criteria X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 19:45:53 -0000 Hi Phillip, At 13:27 11-09-2013, Phillip Hallam-Baker wrote: >If you have been following the cryptography list you will have >noticed that it is rather high volume of late. I produced some notes >in an attempt to summarize the discussion and have just converted >them into an Internet draft which might be helpful to people who >don't have time to go through the whole discussion. I read the draft. Do you have any pointers to reports based on Section 4.2.3? Regards, -sm From stephen.farrell@cs.tcd.ie Sun Sep 15 13:08:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8911E81B7 for ; Sun, 15 Sep 2013 13:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqAFk3DHzrDs for ; Sun, 15 Sep 2013 13:08:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBED21F84F9 for ; Sun, 15 Sep 2013 13:08:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD8DEBE6E; Sun, 15 Sep 2013 21:08:26 +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 9o7-NjRIh2iN; Sun, 15 Sep 2013 21:08:25 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.59.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C178BE61; Sun, 15 Sep 2013 21:08:25 +0100 (IST) Message-ID: <523613B8.2010308@cs.tcd.ie> Date: Sun, 15 Sep 2013 21:08:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Trammell References: <52329A7A.7060103@headstrong.de> <52330712.8060104@cs.tcd.ie> <5234422A.3010003@cisco.com> <5235F203.5090609@cs.tcd.ie> <4538CD25-68D8-407E-8B72-F0D5B76A7B9D@tik.ee.ethz.ch> In-Reply-To: <4538CD25-68D8-407E-8B72-F0D5B76A7B9D@tik.ee.ethz.ch> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Benoit Claise , perpass@ietf.org Subject: Re: [perpass] RFC 6302 Logging Recommendations for Internet-Facing Servers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 20:08:45 -0000 Hi Brian, On 09/15/2013 08:42 PM, Brian Trammell wrote: > hi Stephen, Benoit, all, > > The survey of anonymization techniques in 6235 was intended primarily > to be a complete accounting of methods one _could_ use to anonymize > fields (Information Elements) in a record, as opposed to a survey of > methods we knew to be implemented. Here the idea was to allow a > complete specification of a metadata format for specifying how > records were anonymized, as input to future analysis tasks to be done > on the data (since the anonymization method affects the set of > analyses for which the data can be used). > > So we were really trying to solve a different problem: applying > anonymization (to mask irrelevant and potentially privacy-sensitive > information) while still maintaining the usefulness of the data for > specific analytical tasks. Here we'd like to get rid of absolutely > _everything_ that might be useful for analysis, just keeping around > the minimum necessary for the operation and management of the > protocol. > > Which gets me back to thinking it would be very useful to have a > survey of the information radiated by protocols in common usage, then > a systematic exercise to make sure each of those bits of information > which may be identifiable serves a purpose that couldn't be done in > an anonymous or pseudonymous way. A fine research proposal. (Really, I'd try get dosh for that:-) But in an IETF context, maybe that'd be a thing that the lmap wg [1] could look at? Anyone on this list active there? The lmap charter says: "The LMAP WG will consider privacy as a core requirement and will ensure that by default measurement and collection mechanisms and protocols standardized operate in a privacy-sensitive manner, for example, ensuring that measurements are not personally identifying except where permission for such has been granted by identified subjects. Note that this does not mean that all uses of LMAP need to turn on all privacy features but it does mean that privacy features do need to be at least well-defined." (However, if I recall correctly I got that sentence shoe-horned into their charter, so its not clear to me if the active participants are actually keen on it or if it'll turn out to be RFC6919 fodder;-) S. [1] http://datatracker.ietf.org/wg/lmap/charter/ > > Cheers, > > Brian > > On Sep 15, 2013, at 7:44 PM, Stephen Farrell > wrote: > >> >> Hi Benoit, >> >> On 09/14/2013 12:02 PM, Benoit Claise wrote: >>> On 13/09/2013 14:37, Stephen Farrell wrote: >>>> >>>> On 09/13/2013 05:54 AM, Moritz Bartl wrote: >>>>> Hi, >>>>> >>>>> I would very much like to see servers having a minimal >>>>> logging policy by default, especially and at least when it >>>>> comes to IP addresses. I wonder if RFC 6302 is the right >>>>> document to look at or extend for this. >>>> Or obsolete it. >>>> >>>>> It is easy to flip a switch to enable IP logging. The default >>>>> should be no IP logs, which is true for most XMPP servers, >>>>> for example, but not for web or mail servers. >>>> The wonderfully ironically named PRISM [1] project was an EU >>>> funded project that did some work on obfuscating IP addresses >>>> in logs. >>> rfc6235 >> >> Yep, sections 4 & 5 of that are generic and not really ipfix >> specific. >> >> Do you know of implementations of that for ipfix? Or libraries that >> do the various functions? >> >> I wonder if separating those sections out into a separate RFC would >> result in more people writing code that supports those kinds of >> transformations. Not sure to be honest. >> >> But that is a useful reference, regardless, Thanks, S. >> >>> >>> Regards, Benoit >>>> >>>> I'd love to see an RFC that described such techniques and >>>> recommended when to use what, so we could point people at >>>> that. >>>> >>>> Any takers for a -00 to get that going? >>>> >>>> S. >>>> >>>> [1] http://www.fp7-prism.eu/ >>>> >>>>> On a side node, can we do anything to get rid of sender IP >>>>> addresses in (the first) Received headers of mail? >>>>> >>>>> -- Moritz _______________________________________________ >>>>> perpass mailing list perpass@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/perpass >>>>> >>>> _______________________________________________ perpass mailing >>>> list perpass@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perpass . >>>> >>> >>> >> _______________________________________________ perpass mailing >> list perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > > > _______________________________________________ perpass mailing list > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > From kaduk@mit.edu Sun Sep 15 21:30:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A9A11E80F1 for ; Sun, 15 Sep 2013 21:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIhc8e6K8R9L for ; Sun, 15 Sep 2013 21:30:21 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id F224F11E81B5 for ; Sun, 15 Sep 2013 21:30:20 -0700 (PDT) X-AuditID: 1209190f-b7fa58e000000953-5c-5236895bac1a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A6.EB.02387.B5986325; Mon, 16 Sep 2013 00:30:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r8G4UJjL012035 for ; Mon, 16 Sep 2013 00:30:19 -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 r8G4UHnC006101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Sep 2013 00:30:19 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r8G4UHEM027288; Mon, 16 Sep 2013 00:30:17 -0400 (EDT) Date: Mon, 16 Sep 2013 00:30:17 -0400 (EDT) From: Benjamin Kaduk To: perpass@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUixCmqrRvTaRZkcGYyi8XdSx0sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKaPg6halgP1/FrY6v7A2MJ7i7GDk5JARMJHb2tTFD2GISF+6t Z+ti5OIQEtjHKHH96m4o5wSjxIt5V6Ccm0wSO7dPZwdpERJoYJSY/x7MZhHQlri98h8biM0m oCIx881GMFtEQERi0apnrF2MHBzCAuYSzY98QMK8Ao4SDb/fMYHYogI6Eqv3T2GBiAtKnJz5 BMxmFrCU+Lf2F+sERr5ZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtN Kd3ECA4mSf4djN8OKh1iFOBgVOLh7dA2CxJiTSwrrsw9xCjJwaQkyru3DSjEl5SfUpmRWJwR X1Sak1p8iFGCg1lJhDfaDyjHm5JYWZValA+TkuZgURLnXe+kHyQkkJ5YkpqdmlqQWgSTleHg UJLgVe8AahQsSk1PrUjLzClBSDNxcIIM5wEaPrEdZHhxQWJucWY6RP4Uo6KUOK8bSLMASCKj NA+uFxbtrxjFgV4R5vUCqeIBJgq47ldAg5mABm/ebQQyuCQRISXVwDi1u/MUQ1rI8i+spXH+ i4vVU33fVXzKDuMrfXVq8vMPLP3suRlGfaJbJXxPPvy26n5M5sd3Qk4swsv2e9dKaErIaT4r m8UbennzVtVvjvsPcMmm7W298/7Ejnu/O+O0fhkeOP5iBcvFjNXmf75ZhTltUf5YH2qtFjL3 jWt42eKOy8H8P7vLC5RYijMSDbWYi4oTAVyMyivRAgAA Subject: [perpass] forward secrecy for symmetric crypto consumers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 04:30:30 -0000 So far, we've had a lot of talk about TLS and email (which is great!), but I wonder if we want to broaden our horizons a bit and consider what else we should be talking about. Many symmetric key cryptosystems (such as Kerberos) do not really include provisions for forward secrecy. A pervasive passive attacker, then, who can record all traffic involving certain participants over a long timescale (years?), can then go back and decrypt all the old traffic, if a key is ever revealed. Now, a responsible deployment will of course have a schedule for changing long-term keys (note: most deployments I interact with are not responsible in this regard), but it is common for the old long-term key to be used to secure the exchange setting the new long-term key. If that exchange is captured by the adversary, then leaking the old key will also leak the new key! In Kerberos, we have session keys and key derivation to avoid producing much ciphertext in a given long-term key to give to an attacker, but it seems unlikely that an attacker in this scenario will be using only cryptanalitic techniques. The KDC presents a very juicy target, for one, but other long-term keys can be compromised in other ways (and from less sensitive targets). We have some ideas for how to improve the situation in Kerberos, adding forward secrecy for kadmin exchanges and AP-REQ/AP-REP exchanges, to prevent leaking old keys from exposing new keys, and to give extra protection to application traffic. There is probably more that can be done for Kerberos as well; we haven't had too much time to think about it, yet. The question I pose to this list is: what other symmetric-key systems should we be thinking about? (Even without the qualification, what other systems should we be thinking about?) -Ben Kaduk From malbrain@yahoo.com Sun Sep 15 22:48:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731DB21F85E8 for ; Sun, 15 Sep 2013 22:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6CV4ykeWJdq for ; Sun, 15 Sep 2013 22:48:22 -0700 (PDT) Received: from nm41.bullet.mail.ne1.yahoo.com (nm41.bullet.mail.ne1.yahoo.com [98.138.120.48]) by ietfa.amsl.com (Postfix) with ESMTP id 230ED11E8200 for ; Sun, 15 Sep 2013 22:48:21 -0700 (PDT) Received: from [127.0.0.1] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 16 Sep 2013 05:48:19 -0000 Received: from [98.138.226.179] by nm41.bullet.mail.ne1.yahoo.com with NNFMP; 16 Sep 2013 05:45:26 -0000 Received: from [98.138.101.177] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 16 Sep 2013 05:45:26 -0000 Received: from [127.0.0.1] by omp1088.mail.ne1.yahoo.com with NNFMP; 16 Sep 2013 05:45:26 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 434738.98853.bm@omp1088.mail.ne1.yahoo.com Received: (qmail 70151 invoked by uid 60001); 16 Sep 2013 05:45:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379310326; bh=yGxOKe/jqZEMb6JnUmZv+QJjG1Ou2C4LyezcaNxaOBs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6AT/Xfh4mDbJ7GlKBdaH8m250Uy3WWh9RhGjvFWiySp7skILw0AriBtYCebweTcxFt89I2EU+DC5uznXbXo8QnO5WTFeDMeoBrwkBAO7Quwxm2IdmIPs9BCTEwjL7hbSEg0xZBXFxnJDt1pVtg5fy4eY5ixiesY5OmoCzt6Uhcg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=L19A2PSHR11XAJGB4eM1T35Zg8RnxVv0At+xnEMxDbwNjhIs58mfEMe13rv/cOxCLAIw+pV0IYNWe+Vzte1FKIBFzEgK/8IcCvwUsWqyxJ4Mwxe73lB048psoZndAV0sxOKnbOT6x52HHFPDtCNZzhdJ9E+kH248zauVGTjt+Lk=; X-YMail-OSG: rdR5cb4VM1lElJwj_HrZER5egKYWtwSsMlhWd7C9dGjd_le q2dJDkL1FvoglynKUli8SNJ7ktJxfNxNnVE8YyyOdma8gnBYXzdG9PXek04x gJCThiciib2gEOB1YXNfVirsXjqxN6iIyXNcq7Sm6HUI8NeeoCejiYFkMcMk eeumzc9tX64QAT01nw2Qp5Xk16Hu_vnXM6RszZe8NaA1.3hz7EwB8Duh_X.T 42UAyDAA4dSug9qyVqv.XbZkgU0G5rTEpPCsjTesXyN7EbrKI9_NahjU8Snl CtNSNcDeQNkftsMD7Be6Ygl8rMlUJu5uY3mOJvC2_SkphWGjOkmXdifrhu3X GV9ui55H0ZYtbv6LIXgRtBvg8dpbKVxfnBuiVYbo1FJSES7d5eup874kRP8y .UXEpPplV6NtCS_cGmVK0OQMeIBf0a6V81QOy2FrjKgfvNg8rMvxF6nQTxAR 43JazJNHKDI5R5dX.3_qAmzbZmSK3ETxJ1IePnJZEipPXxPdaqqC7IcS6ZJG bXEfO60BHP7KqJmN.4e1Nfs_CN6oiJqe.4nzmzBPkdXs_tZmSdm.Bm1epG4g lyvANnEiDQZbSqHjF05qw0hKrI0JjVsLI9H5UQCemNnIeEQGXLQ-- Received: from [50.201.233.2] by web125504.mail.ne1.yahoo.com via HTTP; Sun, 15 Sep 2013 22:45:26 PDT X-Rocket-MIMEInfo: 002.001, WWFyb24sCsKgCkZyb20gd2hhdCBJJ3ZlIGxlYXJuZWQgYWJvdXQgREFORSwgZG9tYWluIG93bmVycyBjYW4gcHVibGlzaCB0aGVpciBvd24gc2VsZi1zaWduZWQgc2VydmVyIGNlcnRpZmljYXRlIHRocm91Z2ggdGhlIEROUyBzeXN0ZW0uwqAgQnkgdXNpbmcgVExTIHN0cm9uZyBhdXRoZW50aWNhdGlvbiwgdGhlIFMvTUlNRSBjbGllbnQgZG9lc24ndCBuZWVkIHRvIGhhdmXCoHRoZSBzZXJ2ZXIncyBjZXJ0aWZpY2F0ZSBjaGVja2VkIGFnYWluc3QgYSBDQS7CoFJhdGhlciB0aGUgUy9NSU1FwqAgbGF5ZXIgbmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <522B2C86.7020300@gmail.com> <522B3F92.1090702@cs.tcd.ie> <522B6709.4070009@gmail.com> <5235F788.8040501@gmail.com> Message-ID: <1379310326.66432.YahooMailNeo@web125504.mail.ne1.yahoo.com> Date: Sun, 15 Sep 2013 22:45:26 -0700 (PDT) From: Karl Malbrain To: Yaron Sheffer , James Cloos In-Reply-To: <5235F788.8040501@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="318864283-622548779-1379310326=:66432" Cc: "perpass@ietf.org" , Stephen Farrell Subject: Re: [perpass] Why Yaron can't encrypt: S/MIME in the real world X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 05:48:35 -0000 --318864283-622548779-1379310326=:66432 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yaron,=0A=A0=0AFrom what I've learned about DANE, domain owners can publish= their own self-signed server certificate through the DNS system.=A0 By usi= ng TLS strong authentication, the S/MIME client doesn't need to have=A0the = server's certificate checked against a CA.=A0Rather the S/MIME=A0 layer nee= ds to match the DANE delivered certificate with the certificate=A0sent by t= he server during the TLS negotiation.=A0This is a very small change to the = S/MIME to TLS protocol layer interface to query from TLS the server certifi= cate presented, and a similar change to the SMTP to S/MIME interface to pas= s along the DANE delivered certificate along with the server IP address.=0A= =A0=0AUnfortunately, I'm not=A0a TLS nor an S/MIME expert so I can't specif= y the exact interface changes needed to utilize strong authentication in th= e TLS interface to S/MIME, or the SMTP interface to S/MIME. Perhaps someone= who knows what they are talking about in this area can help.=0A=A0=0AKarl = Malbrain=0A =0A=0A________________________________=0A From: Yaron Sheffer <= yaronf.ietf@gmail.com>=0ATo: James Cloos =0ACc: perpass= @ietf.org; Stephen Farrell =0ASent: Sunday, Sep= tember 15, 2013 11:08 AM=0ASubject: Re: [perpass] Why Yaron can't encrypt: = S/MIME in the real world=0A =0A=0AHi Jim,=0A=0AI agree that storing users'= public keys in DNS is weird.=0A=0ABut I also wonder about your proposal: i= t sounds like you're putting the =0Aentire organization's list of employees= on a public Web server.=0A=0AWouldn't the following be simpler and more na= tural than both proposals:=0A=0A- The organization maintains its own CA, ma= ybe just for S/MIME client certs.=0A- The CA cert is kept as a DNS record, = signed by DANE.=0A- The CA cert is usage-limited, so it can be used for S/M= IME only, and =0Aonly for addresses at this particular domain. [I suppose t= his is the =0Ahard part. Is it allowed by X.509?]=0A=0AAdvantages:=0A=0A- T= his would leave S/MIME unchanged.=0A- The cert validation code remains a co= mbination of normal trust chain =0Aprocessing plus DANE.=0A- No privacy iss= ues: certificates are not published anywhere.=0A- Users are managed within = the organization, with widely available tools.=0A=0AThanks,=0A=A0=A0=A0 Yar= on=0A=0AOn 09/15/2013 07:58 PM, James Cloos wrote:=0A>>>>>> "YS" =3D=3D Yar= on Sheffer writes:=0A>=0A> YS> S/MIME with DANE wou= ld alleviate this problem if organizations were=0A> YS> allowed to generate= their own certificates, including email certs,=0A> YS> and have them chain= ed to the DNS root of trust. I don't know if DANE=0A> YS> supports this usa= ge scenario by default.=0A>=0A> draft-ietf-dane-smime-02.txt exists.=0A>=0A= > Webfinger may be a better choice, though.=A0 It is defined in=0A> draft-i= etf-appsawg-webfinger-18.txt.=0A>=0A> Details on how to store public keys i= n webfinger are not yet specified=0A> in any draft, afaics.=0A>=0A> Dane tl= sa records of course can be used to secure the the webfinger uri.=0A>=0A> I= f one does that, the steps to find or verify an smime or pgp public key=0A>= include:=0A>=0A>=A0 =A0 Convert the email address to a webfinger uri=0A>= =0A>=A0 =A0 Do the a/aaaa and tlsa lookups on the hostname in that uri=0A>= =0A>=A0 =A0 If those dnssec-verify, retrieve the uri=0A>=0A>=A0 =A0 Find th= e public key (or a link to the public key) in the json reply=0A>=0A> The tr= ust path, then, is rooted with the DS record for the dns root,=0A> follows = the dnssec path to the rrsigs for the a/aaaa and tlsa records=0A> for the w= ebfinger uri and trusts the content of the data retrieved from=0A> the uri = on the basis that it trusts the location of the uri.=0A>=0A> That seems a b= it brittle, but not any worse than trusting a path from=0A> some random ca = of which one has never heard.=A0 Or a path through a WoT=0A> involving name= s/identifiers with which one is not familiar.=0A>=0A> And http serves large= blobs better than dns does.=0A>=0A> -JimC=0A>=0A__________________________= _____________________=0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps://w= ww.ietf.org/mailman/listinfo/perpass --318864283-622548779-1379310326=:66432 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yaron,
 
From what I've learned ab= out DANE, domain owners can publish their own self-signed server certificat= e through the DNS system.  By using TLS strong authentication, the S/M= IME client doesn't need to have the server's certificate checked again= st a CA. Rather the S/MIME  layer needs to match the DANE deliver= ed certificate with the certificate sent by the server during the TLS = negotiation. This is a very small change to the S/MIME to TLS protocol= layer interface to query from TLS the server certificate presented, and a = similar change to the SMTP to S/MIME interface to pass along the DANE deliv= ered certificate along with the server IP address.
<= span> 
Unfortunately, I'm not a TLS nor an S/MIME expert so I can't specify the exact interface= changes needed to utilize strong authentication in the TLS interface to S/= MIME, or the SMTP interface to S/MIME. Perhaps someone who knows what they = are talking about in this area can help.
&nbs= p;
Karl Malbrain

<= div style=3D"font-family: times new roman, new york, times, serif; font-siz= e: 12pt;">
From:<= /span> Yaron Sheffer <yaronf.ietf@gmail.com>
To: James Cloos <cloos@jhcloos.com>= ;
Cc: perpass@ietf.org; Stephen Farr= ell <stephen.farrell@cs.tcd.ie>
Sent: Sunday, September 15, 2013 11:08 AM
Subject: Re: [perpass] Why Yaron can't= encrypt: S/MIME in the real world

Hi Jim,

I agree that storing users' public keys in DNS= is weird.

But I also wonder about your proposal: it sounds like you= 're putting the
entire organization's list of employees on a public Web= server.

Wouldn't the following be simpler and more natural than bot= h proposals:

- The organization maintains its own CA, maybe just for= S/MIME client certs.
- The CA cert is kept as a DNS record, signed by D= ANE.
- The CA cert is usage-limited, so it can be used for S/MIME only, = and
only for addresses at this particular domain. [I suppose this is th= e
hard part. Is it allowed by X.509?]

Advantages:

- This w= ould leave S/MIME unchanged.
- The cert validation code remains a combin= ation of normal trust chain
processing plus DANE.
- No privacy issue= s: certificates are not published anywhere.
- Users are managed within t= he organization, with widely available tools.

Thanks,
  = ;  Yaron

On 09/15/2013 07:58 PM, James Cloos wrote:
>>= >>>> "YS" =3D=3D Yaron Sheffer <yaronf.ietf@gmail.com= > writes:
>
> YS> S/MIME with DANE would alleviate th= is problem if organizations were
> YS> allowed to generate their o= wn certificates, including email certs,
> YS> and have them chaine= d to the DNS root of trust. I don't know if DANE
> YS> supports th= is usage scenario by default.
>
> draft-ietf-dane-smime-02.txt exists.
>
> Webfinger may be a better choice, though.  It= is defined in
> draft-ietf-appsawg-webfinger-18.txt.
>
>= Details on how to store public keys in webfinger are not yet specified
= > in any draft, afaics.
>
> Dane tlsa records of course can = be used to secure the the webfinger uri.
>
> If one does that, = the steps to find or verify an smime or pgp public key
> include:
= >
>    Convert the email address to a webfinger uri
&= gt;
>    Do the a/aaaa and tlsa lookups on the hostname in = that uri
>
>    If those dnssec-verify, retrieve the = uri
>
>    Find the public key (or a link to the publ= ic key) in the json reply
>
> The trust path, then, is rooted w= ith the DS record for the dns root,
> follows the dnssec path to the = rrsigs for the a/aaaa and tlsa records
> for the webfinger uri and trusts the content of the data retrieved from
> the uri on the b= asis that it trusts the location of the uri.
>
> That seems a b= it brittle, but not any worse than trusting a path from
> some random= ca of which one has never heard.  Or a path through a WoT
> inv= olving names/identifiers with which one is not familiar.
>
> An= d http serves large blobs better than dns does.
>
> -JimC
&g= t;
_______________________________________________
perpass mailing li= st
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass


--001a11c23c884ca98e04e689efd2-- From Jeff.Hodges@KingsMountain.com Mon Sep 16 18:46:20 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2511E82BF for ; Mon, 16 Sep 2013 18:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.851 X-Spam-Level: X-Spam-Status: No, score=-99.851 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JX4++7QfxjQi for ; Mon, 16 Sep 2013 18:46:15 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 9999411E8187 for ; Mon, 16 Sep 2013 18:46:14 -0700 (PDT) Received: (qmail 16369 invoked by uid 0); 17 Sep 2013 01:45:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.mail.unifiedlayer.com with SMTP; 17 Sep 2013 01:45:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=J6SbFHJj0vrI8qu1Deggv0rEyfDygftKzXFW5PTPA0s=; b=lk6fLP6kYXLHm0IZsCKnPAWCmcYTuhNLPgcBldbIWrnCyeOHfNjV7x9X8B1BL4dtIi167AKDSIiIF+RAoPFvtfKWjP9FoVJSm8NQ0OGddI5SQClH9tQuXL5SkMBeRqJr; Received: from [24.4.122.173] (port=55483 helo=[192.168.11.14]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VLkMQ-000648-52 for perpass@ietf.org; Mon, 16 Sep 2013 19:45:50 -0600 Message-ID: <5237B44C.7000405@KingsMountain.com> Date: Mon, 16 Sep 2013 18:45:48 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: perpass Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 01:46:20 -0000 Here's some items not as yet on the "rough list of concrete stuff" AFAICT, which perhaps should be, at least from a completeness perspective (YMMV)... Background/Requirements/Opportunities.. Adam Langley, 2009, W2SP. "Opportunistic Encryption Everywhere". W2SP. http://w2spconf.com/2009/papers/s1p2.pdf Andrea Bittau, et al. (2010-08-13). "The case for ubiquitous transport-level encryption". 19th USENIX Security Symposium. http://www.usenix.org/events/sec10/tech/full_papers/Bittau.pdf Opportunistic encryption (has list of various applicable projects) http://en.wikipedia.org/wiki/Opportunistic_encryption Linux FreeS/WAN Project - Opportunistic Encryption Henry Spencer, D. Hugh Redelmeier. http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec examples.. tcpcrypt http://en.wikipedia.org/wiki/Tcpcrypt https://tools.ietf.org/html/draft-bittau-tcp-crypt-03 Obfuscated TCP http://en.wikipedia.org/wiki/Obfuscated_TCP [tcpm] Faster application handshakes with SYN/ACK payloads http://www.ietf.org/mail-archive/web/tcpm/current/msg03829.html http://tools.ietf.org/html/draft-agl-tcpm-sadata-01 IETF rejects Obfuscated TCP (email thread on tcpm@) http://comments.gmane.org/gmane.network.peer-to-peer.p2p-hackers/2099 freeS/WAN, Openswan, Libreswan et al. http://en.wikipedia.org/wiki/FreeS/WAN HTH, =JeffH From stephen.farrell@cs.tcd.ie Tue Sep 17 01:03:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB04311E839E for ; Tue, 17 Sep 2013 01:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmwKnxoTXKXl for ; Tue, 17 Sep 2013 01:03:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD8311E8391 for ; Tue, 17 Sep 2013 01:03:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B9955BE61; Tue, 17 Sep 2013 09:03:37 +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 0aTZu5TE4DZa; Tue, 17 Sep 2013 09:03:33 +0100 (IST) Received: from [10.37.59.247] (unknown [95.83.250.110]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 15514BE70; Tue, 17 Sep 2013 09:03:33 +0100 (IST) References: <52379B65.8060100@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-99174658-EB12-438A-9496-30672C9EC958 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: Stephen Farrell Date: Tue, 17 Sep 2013 09:03:20 +0100 To: Phillip Hallam-Baker Cc: perpass Subject: Re: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 08:03:45 -0000 --Apple-Mail-99174658-EB12-438A-9496-30672C9EC958 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Phill, Yep I had a read, seems like good stuff, and getting attention which can als= o be good.=20 It just wasn't clear to me what specific outcome might arise. And since you s= aid you'd another draft on the boil I figured I'd wait for that, Cheers. S On 17 Sep 2013, at 02:06, Phillip Hallam-Baker wrote: > I wrote a draft that attempts to set out criteria for 'PRISM-PROOF' securi= ty. Actually it is more general than that looking at any bulk surveillance s= cheme. It is a summary of material from this and other lists. >=20 > The main reason I wrote it was to capture conversation from other lists th= at kept going round in circles and to provide a basis for evaluating my othe= r design. >=20 >=20 > On Mon, Sep 16, 2013 at 7:59 PM, Stephen Farrell wrote: >>=20 >> Hiya, >>=20 >> I've gone through the perpass archive to try make a >> list of the things that seem to be more doable/stable. >>=20 >> This is just to make it more manageable for me, the >> list has no official status whatsoever. I've not included >> things where I'm not clear what might be the outcome. >> Even if I include something I may well be wrong that >> there'll be a clear outcome. >>=20 >> Let me know if I've missed stuff (probably) or if you've >> any other comments. On or off list, whichever's better. >>=20 >> I do know that some other folks are discussing some >> other relevant activities that are not yet published or >> weren't mentioned on this list. When/if you want those >> added here, just give me the info. and I'll add it. (If >> your thing hasn't been discussed on an IETF list or >> published in an I-D, I'd rather see that happen first if >> you don't mind, for all the normal tedious IPR/Note-well >> reasons.) >>=20 >> I'll sporadically maintain this between now and Vancouver >> at [1] (you may prefer to read it at [2], since [1] will >> get you browser warnings about my self-signed cert. (*) >>=20 >> Cheers, >> S. >>=20 >> [1] https://down.dsg.cs.tcd.ie/misc/perpass.txt >> [2] http://down.dsg.cs.tcd.ie/misc/perpass.txt >>=20 >> (*) Nothing to do with the topic really but I just noticed >> I'd not updated the key pair in 5 years so I made a new one >> a few minutes ago since now's a good time before this year's >> batch of students arrive. (How they complain about that >> tells me a bit about 'em:-) >>=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail-99174658-EB12-438A-9496-30672C9EC958 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Phill,

Yep I had a read, seems like good stuff, and getting attention which can also be good. 

It just wasn't clear to me what specific outcome might arise. And since you said you'd another draft on the boil I figured I'd wait for that,

Cheers.
S

On 17 Sep 2013, at 02:06, Phillip Hallam-Baker <hallam@gmail.com> wrote:

I wrote a draft that attempts to set out criteria for 'PRISM-PROOF' security. Actually it is more general than that looking at any bulk surveillance scheme. It is a summary of material from this and other lists.

The main reason I wrote it was to capture conversation from other lists that kept going round in circles and to provide a basis for evaluating my other design.


On Mon, Sep 16, 2013 at 7:59 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

I've gone through the perpass archive to try make a
list of the things that seem to be more doable/stable.

This is just to make it more manageable for me, the
list has no official status whatsoever. I've not included
things where I'm not clear what might be the outcome.
Even if I include something I may well be wrong that
there'll be a clear outcome.

Let me know if I've missed stuff (probably) or if you've
any other comments. On or off list, whichever's better.

I do know that some other folks are discussing some
other relevant activities that are not yet published or
weren't mentioned on this list. When/if you want those
added here, just give me the info. and I'll add it. (If
your thing hasn't been discussed on an IETF list or
published in an I-D, I'd rather see that happen first if
you don't mind, for all the normal tedious IPR/Note-well
reasons.)

I'll sporadically maintain this between now and Vancouver
at [1] (you may prefer to read it at [2], since [1] will
get you browser warnings about my self-signed cert. (*)

Cheers,
S.

[1] https://down.dsg.cs.tcd.ie/misc/perpass.txt
[2] http://down.dsg.cs.tcd.ie/misc/perpass.txt

(*) Nothing to do with the topic really but I just noticed
I'd not updated the key pair in 5 years so I made a new one
a few minutes ago since now's a good time before this year's
batch of students arrive. (How they complain about that
tells me a bit about 'em:-)


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



--
Website: http://hallambaker.com/
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
--Apple-Mail-99174658-EB12-438A-9496-30672C9EC958-- From stephen.farrell@cs.tcd.ie Tue Sep 17 02:10:22 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE84011E83C5 for ; Tue, 17 Sep 2013 02:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IMvw9IjIGnF for ; Tue, 17 Sep 2013 02:10:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4047811E83BD for ; Tue, 17 Sep 2013 02:10:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 56FB4BE25; Tue, 17 Sep 2013 10:10:15 +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 Xhp5mLMJXaqg; Tue, 17 Sep 2013 10:10:15 +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 33EF2BDF9; Tue, 17 Sep 2013 10:10:15 +0100 (IST) Message-ID: <52381C78.8090504@cs.tcd.ie> Date: Tue, 17 Sep 2013 10:10:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: =JeffH References: <5237B44C.7000405@KingsMountain.com> In-Reply-To: <5237B44C.7000405@KingsMountain.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 09:10:23 -0000 Hi Jeff, On 09/17/2013 02:45 AM, =JeffH wrote: > Here's some items not as yet on the "rough list of concrete stuff" > AFAICT, which perhaps should be, at least from a completeness > perspective (YMMV)... Maybe I need to clarify: I put stuff on that list where I felt happy that I understood how the end result in the IETF might look. Its not meant to be a complete list of relevant stuff, nor most important stuff, just the stuff that's already concrete enough that if it did end up in an RFC, I reckon I understand more-or-less what'd be in that and how we might get it done. But those links do certainly look relevant and it'd be good to see some discussion of them (in new threads please). I'll start one thread in a minute on tcpcrypt. Cheers, S. > > Background/Requirements/Opportunities.. > > Adam Langley, 2009, W2SP. "Opportunistic Encryption Everywhere". W2SP. > http://w2spconf.com/2009/papers/s1p2.pdf > > Andrea Bittau, et al. (2010-08-13). "The case for ubiquitous > transport-level encryption". 19th USENIX Security Symposium. > http://www.usenix.org/events/sec10/tech/full_papers/Bittau.pdf > > Opportunistic encryption (has list of various applicable projects) > http://en.wikipedia.org/wiki/Opportunistic_encryption > > Linux FreeS/WAN Project - Opportunistic Encryption > Henry Spencer, D. Hugh Redelmeier. > http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec > > > > examples.. > > tcpcrypt > http://en.wikipedia.org/wiki/Tcpcrypt > https://tools.ietf.org/html/draft-bittau-tcp-crypt-03 > > > Obfuscated TCP > http://en.wikipedia.org/wiki/Obfuscated_TCP > > [tcpm] Faster application handshakes with SYN/ACK payloads > http://www.ietf.org/mail-archive/web/tcpm/current/msg03829.html > http://tools.ietf.org/html/draft-agl-tcpm-sadata-01 > > IETF rejects Obfuscated TCP (email thread on tcpm@) > http://comments.gmane.org/gmane.network.peer-to-peer.p2p-hackers/2099 > > > freeS/WAN, Openswan, Libreswan et al. > http://en.wikipedia.org/wiki/FreeS/WAN > > > > > HTH, > > =JeffH > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Tue Sep 17 02:13:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0BC11E83CC for ; Tue, 17 Sep 2013 02:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZOZeD3jdFLT for ; Tue, 17 Sep 2013 02:12:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 33EEC11E83C5 for ; Tue, 17 Sep 2013 02:12:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 62565BE4C for ; Tue, 17 Sep 2013 10:12:50 +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 KjvOtmW8phrs for ; Tue, 17 Sep 2013 10:12:50 +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 2AEB2BE47 for ; Tue, 17 Sep 2013 10:12:50 +0100 (IST) Message-ID: <52381D13.2010604@cs.tcd.ie> Date: Tue, 17 Sep 2013 10:12:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 09:13:01 -0000 Hi, Jeff raised tcpcrypt [1] in his earlier email. When this proposal came up a few IETFs ago, I was against it on the basis that we already have IPsec and TLS so why would we want yet another way to protect TCP sessions? Esp. since it didn't seem to allow the flexibility of IPsec or TLS in terms of key mgmt, nor have a DTLS variant etc etc. Maybe I was wrong. I'm not sure I was, but I do think its at least worth looking at again. I guess that tcpcrypt does do opportunistic encryption of TCP sessions, which now seems more attractive. A bit more heterogeneity in the infrastructure might also be useful and maybe some of the MITM attacks on TLS that have been done wouldn't be nearly as easy on this. (The ones where a CA has been subverted.) And now that MPTCP is going to attempt to be moved to the standards track, that will need better security than the experimental MPTCP RFC has, and this could do that. On the negative side, I'm not sure if this is still a live proposal, nor if it'd really get traction. I just don't know if using the data portion of segments works for key exchange. tcpcrypt doesn't currently seem to support PFS if public keys are re-used either. I guess there're also a bunch of other bits and pieces in there that'd need work as well. This might also be over-the-top for MPTCP's needs. And maybe we'd be better off putting effort into opportunistic encryption at the IP layer and in TLS. I'd be interested in knowing what folks think about that. Personally, I'm not sure, but if there were a groundswell of support for progressing tcpcrypt then I at least would be more interested than I was a year ago. Thanks, S. [1] https://tools.ietf.org/html/draft-bittau-tcp-crypt From m.handley@cs.ucl.ac.uk Tue Sep 17 04:06:22 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E5311E83F6 for ; Tue, 17 Sep 2013 04:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGO8Ospi-tTQ for ; Tue, 17 Sep 2013 04:06:17 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2F17B11E83F3 for ; Tue, 17 Sep 2013 04:06:16 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5828920B19; Tue, 17 Sep 2013 07:06:07 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute4.internal (MEProxy); Tue, 17 Sep 2013 07:06:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=UROlsrDjfWEQiOg3R6KnBilPA6s=; b=t4m EB7E5hOCHlyGWrLEZ3g8tjOhRJ+MFf+dgC+QZoXp3fWW347ytFi1CjXmmBMfV/fM HgtV4CrwbAt1+7gJUwz1OkZ/MqAEz70l9bU4Tk1Q+x2X8OoFWqdxbyen4UZ8YZeN MJLP5/KVEdt99uIhMv3F7HdQ5WGxKjp/jSpLeHpU= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 11D401085FC; Tue, 17 Sep 2013 07:06:07 -0400 (EDT) Message-Id: <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> X-Sasl-Enc: jCqV92uMSQtOhDh8yrybZUgNTDtx6ytrz8RGHY9Mmp+0 1379415967 From: Mark Handley To: Stephen Farrell MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-d310b333 In-Reply-To: <52381DB6.1030200@cs.tcd.ie> References: <52381D13.2010604@cs.tcd.ie> <52381DB6.1030200@cs.tcd.ie> Date: Tue, 17 Sep 2013 04:06:07 -0700 X-Mailman-Approved-At: Tue, 17 Sep 2013 04:10:15 -0700 Cc: perpass@ietf.org Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 11:06:22 -0000 tcpcrypt has been mostly dormant for the last couple of years, as we didn't really gain traction in the IETF last time round. I (and I believe my co-authors) still believe that tcpcrypt (or something similar) is a key part of moving forward on improving general Internet security, and especially on large-scale passive eavesdropping. We're happy and ready to put in energy if there's interest now. The key reason for an approach at this layer in the stack is that it gets you the most bang for the buck. By leveraging the TCP handshake, you can get sessions encypted very easily with minimal infrastructure deployment, and only a single change to the stack. It's much harder to do that at the IP layer because there's no handshake, and it's hard to roll out _everywhere_ above TCP (it shouldn't really be so hard, but all the evidence of the last couple of decades is that it is). So our philosophy is: - Separate encryption from authentication. - Encryption is easy, and application-independent. Enable encryption by default, using ephemeral public keys for key exchange. - Authentication is hard and application-dependent (which also makes it dependent on the TCP port - different TCP ports need different authentication). Provide the hooks in tcpcrypt to support a wide range of authentication in applications running over the top of tcpcrypt. - Provide a hook in tcpcrypt so each end knows if the other end's application is capable of negotiating the next layer. We also showed how to do key exchange fast in servers, so there should be little cost of enabling it. In the long run we'd hope all TCP sessions would be encrypted, but wouldn't expect all to the authenticated. An interesting benefit is you cannot tell from eavesdropping whether or not an encrypted session will also be authenticated. This makes mounting a MITM attack risky if you want to go unobserved. As for PFS - tcpcrypt allows key resuse, but discourages doing too much reuse. It's up to the implementation how frequently to generate new key pairs, but it would be easy to do this in the background when idle. Whether you get PFS or not depends on how often the keys are reused (you can choose to never reuse, at some cost), but keys are never kept around for long. There's certainly no CA to subvert as far as encryption is concerned. Cheers, Mark > Hi, > > Jeff raised tcpcrypt [1] in his earlier email. > > When this proposal came up a few IETFs ago, I was against > it on the basis that we already have IPsec and TLS so why > would we want yet another way to protect TCP sessions? Esp. > since it didn't seem to allow the flexibility of IPsec or > TLS in terms of key mgmt, nor have a DTLS variant etc etc. > > Maybe I was wrong. > > I'm not sure I was, but I do think its at least worth > looking at again. > > I guess that tcpcrypt does do opportunistic encryption of > TCP sessions, which now seems more attractive. A bit more > heterogeneity in the infrastructure might also be useful > and maybe some of the MITM attacks on TLS that have been > done wouldn't be nearly as easy on this. (The ones where > a CA has been subverted.) And now that MPTCP is going to > attempt to be moved to the standards track, that will > need better security than the experimental MPTCP RFC has, > and this could do that. > > On the negative side, I'm not sure if this is still a > live proposal, nor if it'd really get traction. I just > don't know if using the data portion of segments works > for key exchange. tcpcrypt doesn't currently seem to > support PFS if public keys are re-used either. I guess > there're also a bunch of other bits and pieces in there > that'd need work as well. This might also be over-the-top > for MPTCP's needs. And maybe we'd be better off putting > effort into opportunistic encryption at the IP layer and > in TLS. > > I'd be interested in knowing what folks think about that. > > Personally, I'm not sure, but if there were a groundswell > of support for progressing tcpcrypt then I at least would > be more interested than I was a year ago. > > Thanks, > S. > > [1] https://tools.ietf.org/html/draft-bittau-tcp-crypt > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > > > From mark@handley.org.uk Tue Sep 17 04:13:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89811E83F3 for ; Tue, 17 Sep 2013 04:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwcg327NQuhl for ; Tue, 17 Sep 2013 04:13:40 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4C08911E83F2 for ; Tue, 17 Sep 2013 04:13:40 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B1D5C20F4D for ; Tue, 17 Sep 2013 07:13:39 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute1.internal (MEProxy); Tue, 17 Sep 2013 07:13:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:list-id:subject:date :list-post; s=smtpout; bh=bSMV2XAu3chucnDZ/nBWkWK1tRM=; b=YqmPr0 vs6+6OXUfjxS0f41W9n+UTe0MdHnmie/qZZRNnEtiVFQtxXtwZ1SLpjDEgJY5BpM 65ZmLUUzF/FFNY7aojl9JyVV5DRQ3df29fZjT549SETgmOpfbuqP3RJ/vA4JBEyG pnw1slTagrs9ALiDcYslrZ/j2HJQfi65kN/O4= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 9007610869C; Tue, 17 Sep 2013 07:13:39 -0400 (EDT) Message-Id: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> X-Sasl-Enc: OMNrSdl+OJAVjEXhRCDOiQJ59/lNv8DPDhnY5I4pGlR6 1379416419 From: Mark Handley To: perpass@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-d310b333 Received: ARRAY(0x7f204aefd680) Date: Tue, 17 Sep 2013 04:13:39 -0700 X-Delivered-To: mark@handley.org.uk Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 11:13:52 -0000 tcpcrypt has been mostly dormant for the last couple of years, as we didn't really gain traction in the IETF last time round. I (and I believe my co-authors) still believe that tcpcrypt (or something similar) is a key part of moving forward on improving general Internet security, and especially on large-scale passive eavesdropping. We're happy and ready to put in energy if there's interest now. The key reason for an approach at this layer in the stack is that it gets you the most bang for the buck. By leveraging the TCP handshake, you can get sessions encypted very easily with minimal infrastructure deployment, and only a single change to the stack. It's much harder to do that at the IP layer because there's no handshake, and it's hard to roll out _everywhere_ above TCP (it shouldn't really be so hard, but all the evidence of the last couple of decades is that it is). So our philosophy is: - Separate encryption from authentication. - Encryption is easy, and application-independent. Enable encryption by default, using ephemeral public keys for key exchange. - Authentication is hard and application-dependent (which also makes it dependent on the TCP port - different TCP ports need different authentication). Provide the hooks in tcpcrypt to support a wide range of authentication in applications running over the top of tcpcrypt. - Provide a hook in tcpcrypt so each end knows if the other end's application is capable of negotiating the next layer. We also showed how to do key exchange fast in servers, so there should be little cost of enabling it. In the long run we'd hope all TCP sessions would be encrypted, but wouldn't expect all to the authenticated. An interesting benefit is you cannot tell from eavesdropping whether or not an encrypted session will also be authenticated. This makes mounting a MITM attack risky if you want to go unobserved. As for PFS - tcpcrypt allows key resuse, but discourages doing too much reuse. It's up to the implementation how frequently to generate new key pairs, but it would be easy to do this in the background when idle. Whether you get PFS or not depends on how often the keys are reused (you can choose to never reuse, at some cost), but keys are never kept around for long. There's certainly no CA to subvert as far as encryption is concerned. Cheers, Mark > Hi, > > Jeff raised tcpcrypt [1] in his earlier email. > > When this proposal came up a few IETFs ago, I was against > it on the basis that we already have IPsec and TLS so why > would we want yet another way to protect TCP sessions? Esp. > since it didn't seem to allow the flexibility of IPsec or > TLS in terms of key mgmt, nor have a DTLS variant etc etc. > > Maybe I was wrong. > > I'm not sure I was, but I do think its at least worth > looking at again. > > I guess that tcpcrypt does do opportunistic encryption of > TCP sessions, which now seems more attractive. A bit more > heterogeneity in the infrastructure might also be useful > and maybe some of the MITM attacks on TLS that have been > done wouldn't be nearly as easy on this. (The ones where > a CA has been subverted.) And now that MPTCP is going to > attempt to be moved to the standards track, that will > need better security than the experimental MPTCP RFC has, > and this could do that. > > On the negative side, I'm not sure if this is still a > live proposal, nor if it'd really get traction. I just > don't know if using the data portion of segments works > for key exchange. tcpcrypt doesn't currently seem to > support PFS if public keys are re-used either. I guess > there're also a bunch of other bits and pieces in there > that'd need work as well. This might also be over-the-top > for MPTCP's needs. And maybe we'd be better off putting > effort into opportunistic encryption at the IP layer and > in TLS. > > I'd be interested in knowing what folks think about that. > > Personally, I'm not sure, but if there were a groundswell > of support for progressing tcpcrypt then I at least would > be more interested than I was a year ago. > > Thanks, > S. > > [1] https://tools.ietf.org/html/draft-bittau-tcp-crypt > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > > > _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass -- Mark From mark@handley.org.uk Tue Sep 17 04:23:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB4811E8137 for ; Tue, 17 Sep 2013 04:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV-bKZ3wkI8p for ; Tue, 17 Sep 2013 04:23:44 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1895811E80FE for ; Tue, 17 Sep 2013 04:23:43 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 583FB20BA0 for ; Tue, 17 Sep 2013 07:23:41 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 17 Sep 2013 07:23:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=mq8NssP4uMKK+W9SPohoehWPzes=; b=WEs 7oFKZpn6oxJQE8E7kHqbiIt0LAWR8/3LiuHYS/KshUMcfkbZNQzO+ZPxLRlDIbNS hsaDv8L/YvSPCScrNEe0lFVBEBOy+3V/Un3IdunoC/zpEsqGTRhFAjJFI1MmwuwG undEWrL2FCcGQDgM6mNff4WoSW0SLo5Pk2d3DGjM= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 37F9C1087D0; Tue, 17 Sep 2013 07:23:41 -0400 (EDT) Message-Id: <1379417021.19162.22985529.0E77A3C8@webmail.messagingengine.com> X-Sasl-Enc: NaYGYzA7l+g+W+WrMBRgvytD+EeCNlTlUUJH4VW4nXFT 1379417021 From: Mark Handley To: perpass@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-d310b333 In-Reply-To: <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> References: <52381D13.2010604@cs.tcd.ie> <52381DB6.1030200@cs.tcd.ie> <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> Date: Tue, 17 Sep 2013 04:23:41 -0700 Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 11:23:49 -0000 By the way, if you want an intro to tcpcrypt, it's probably best to start with the Usenix Security paper: http://tcpcrypt.org/tcpcrypt.pdf It does a better job of explaining what we're trying to achieve than the internet draft. Or as a quick intro, the video of the Usenix Security session by Andrea Bittau: http://tcpcrypt.org/talk.php Cheers, Mark On Tue, Sep 17, 2013, at 04:06 AM, Mark Handley wrote: > > tcpcrypt has been mostly dormant for the last couple of years, as we > didn't really gain traction in the IETF last time round. I (and I > believe my co-authors) still believe that tcpcrypt (or something > similar) is a key part of moving forward on improving general Internet > security, and especially on large-scale passive eavesdropping. We're > happy and ready to put in energy if there's interest now. > > The key reason for an approach at this layer in the stack is that it > gets you the most bang for the buck. By leveraging the TCP handshake, > you can get sessions encypted very easily with minimal infrastructure > deployment, and only a single change to the stack. It's much harder to > do that at the IP layer because there's no handshake, and it's hard to > roll out _everywhere_ above TCP (it shouldn't really be so hard, but all > the evidence of the last couple of decades is that it is). > > So our philosophy is: > > - Separate encryption from authentication. > > - Encryption is easy, and application-independent. Enable encryption > by default, using ephemeral public keys for key exchange. > > - Authentication is hard and application-dependent (which also makes it > dependent on the TCP port - different TCP ports need different > authentication). Provide the hooks in tcpcrypt to support a wide range > of authentication in applications running over the top of tcpcrypt. > > - Provide a hook in tcpcrypt so each end knows if the other end's > application is capable of negotiating the next layer. > > We also showed how to do key exchange fast in servers, so there should > be little cost of enabling it. > > In the long run we'd hope all TCP sessions would be encrypted, but > wouldn't expect all to the authenticated. An interesting benefit is you > cannot tell from eavesdropping whether or not an encrypted session will > also be authenticated. This makes mounting a MITM attack risky if you > want to go unobserved. > > As for PFS - tcpcrypt allows key resuse, but discourages doing too much > reuse. It's up to the implementation how frequently to generate new key > pairs, but it would be easy to do this in the background when idle. > Whether you get PFS or not depends on how often the keys are reused (you > can choose to never reuse, at some cost), but keys are never kept around > for long. There's certainly no CA to subvert as far as encryption is > concerned. > > Cheers, > Mark > > > Hi, > > > > Jeff raised tcpcrypt [1] in his earlier email. > > > > When this proposal came up a few IETFs ago, I was against > > it on the basis that we already have IPsec and TLS so why > > would we want yet another way to protect TCP sessions? Esp. > > since it didn't seem to allow the flexibility of IPsec or > > TLS in terms of key mgmt, nor have a DTLS variant etc etc. > > > > Maybe I was wrong. > > > > I'm not sure I was, but I do think its at least worth > > looking at again. > > > > I guess that tcpcrypt does do opportunistic encryption of > > TCP sessions, which now seems more attractive. A bit more > > heterogeneity in the infrastructure might also be useful > > and maybe some of the MITM attacks on TLS that have been > > done wouldn't be nearly as easy on this. (The ones where > > a CA has been subverted.) And now that MPTCP is going to > > attempt to be moved to the standards track, that will > > need better security than the experimental MPTCP RFC has, > > and this could do that. > > > > On the negative side, I'm not sure if this is still a > > live proposal, nor if it'd really get traction. I just > > don't know if using the data portion of segments works > > for key exchange. tcpcrypt doesn't currently seem to > > support PFS if public keys are re-used either. I guess > > there're also a bunch of other bits and pieces in there > > that'd need work as well. This might also be over-the-top > > for MPTCP's needs. And maybe we'd be better off putting > > effort into opportunistic encryption at the IP layer and > > in TLS. > > > > I'd be interested in knowing what folks think about that. > > > > Personally, I'm not sure, but if there were a groundswell > > of support for progressing tcpcrypt then I at least would > > be more interested than I was a year ago. > > > > Thanks, > > S. > > > > [1] https://tools.ietf.org/html/draft-bittau-tcp-crypt > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass > > > > > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From stephen.farrell@cs.tcd.ie Tue Sep 17 04:28:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A7111E8413 for ; Tue, 17 Sep 2013 04:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYgaWF83g-oH for ; Tue, 17 Sep 2013 04:28:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8108811E83FE for ; Tue, 17 Sep 2013 04:27:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E60EFBE55; Tue, 17 Sep 2013 12:27: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 KtwWwFxmWX0D; Tue, 17 Sep 2013 12:27:41 +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 B8921BE54; Tue, 17 Sep 2013 12:27:41 +0100 (IST) Message-ID: <52383CAE.10105@cs.tcd.ie> Date: Tue, 17 Sep 2013 12:27:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Handley References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> In-Reply-To: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 11:28:23 -0000 Hi Mark, On 09/17/2013 12:13 PM, Mark Handley wrote: > > tcpcrypt has been mostly dormant for the last couple of years, as we > didn't really gain traction in the IETF last time round. I (and I > believe my co-authors) still believe that tcpcrypt (or something > similar) is a key part of moving forward on improving general Internet > security, and especially on large-scale passive eavesdropping. We're > happy and ready to put in energy if there's interest now. Great. So anyone else here think that's a good plan and might get traction? I'd also be keen to know if you've any thoughts on the mptcp question - do you think tcpcrypt could be a real option for mptcp security? Cheers, S. > > The key reason for an approach at this layer in the stack is that it > gets you the most bang for the buck. By leveraging the TCP handshake, > you can get sessions encypted very easily with minimal infrastructure > deployment, and only a single change to the stack. It's much harder to > do that at the IP layer because there's no handshake, and it's hard to > roll out _everywhere_ above TCP (it shouldn't really be so hard, but all > the evidence of the last couple of decades is that it is). > > So our philosophy is: > > - Separate encryption from authentication. > > - Encryption is easy, and application-independent. Enable encryption > by default, using ephemeral public keys for key exchange. > > - Authentication is hard and application-dependent (which also makes it > dependent on the TCP port - different TCP ports need different > authentication). Provide the hooks in tcpcrypt to support a wide range > of authentication in applications running over the top of tcpcrypt. > > - Provide a hook in tcpcrypt so each end knows if the other end's > application is capable of negotiating the next layer. > > We also showed how to do key exchange fast in servers, so there should > be little cost of enabling it. > > In the long run we'd hope all TCP sessions would be encrypted, but > wouldn't expect all to the authenticated. An interesting benefit is you > cannot tell from eavesdropping whether or not an encrypted session will > also be authenticated. This makes mounting a MITM attack risky if you > want to go unobserved. > > As for PFS - tcpcrypt allows key resuse, but discourages doing too much > reuse. It's up to the implementation how frequently to generate new key > pairs, but it would be easy to do this in the background when idle. > Whether you get PFS or not depends on how often the keys are reused (you > can choose to never reuse, at some cost), but keys are never kept around > for long. There's certainly no CA to subvert as far as encryption is > concerned. > > Cheers, > Mark > >> Hi, >> >> Jeff raised tcpcrypt [1] in his earlier email. >> >> When this proposal came up a few IETFs ago, I was against >> it on the basis that we already have IPsec and TLS so why >> would we want yet another way to protect TCP sessions? Esp. >> since it didn't seem to allow the flexibility of IPsec or >> TLS in terms of key mgmt, nor have a DTLS variant etc etc. >> >> Maybe I was wrong. >> >> I'm not sure I was, but I do think its at least worth >> looking at again. >> >> I guess that tcpcrypt does do opportunistic encryption of >> TCP sessions, which now seems more attractive. A bit more >> heterogeneity in the infrastructure might also be useful >> and maybe some of the MITM attacks on TLS that have been >> done wouldn't be nearly as easy on this. (The ones where >> a CA has been subverted.) And now that MPTCP is going to >> attempt to be moved to the standards track, that will >> need better security than the experimental MPTCP RFC has, >> and this could do that. >> >> On the negative side, I'm not sure if this is still a >> live proposal, nor if it'd really get traction. I just >> don't know if using the data portion of segments works >> for key exchange. tcpcrypt doesn't currently seem to >> support PFS if public keys are re-used either. I guess >> there're also a bunch of other bits and pieces in there >> that'd need work as well. This might also be over-the-top >> for MPTCP's needs. And maybe we'd be better off putting >> effort into opportunistic encryption at the IP layer and >> in TLS. >> >> I'd be interested in knowing what folks think about that. >> >> Personally, I'm not sure, but if there were a groundswell >> of support for progressing tcpcrypt then I at least would >> be more interested than I was a year ago. >> >> Thanks, >> S. >> >> [1] https://tools.ietf.org/html/draft-bittau-tcp-crypt >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> >> >> >> > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From scott.brim@gmail.com Tue Sep 17 04:40:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD75B11E83F6 for ; Tue, 17 Sep 2013 04:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VdWjXzYMagh for ; Tue, 17 Sep 2013 04:40:15 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9B43911E83FF for ; Tue, 17 Sep 2013 04:40:04 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id wm4so5173279obc.16 for ; Tue, 17 Sep 2013 04:40:02 -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; bh=F49XgfAPvuk5MSSXxr3TJWm+D9Swq4f5HVJ/Wb5r2AI=; b=PyFDKprDNpPQ6BO+L2MuImCDCFDK2QznyM2DJ/DImnjg4MMPhn0h79Y2riO9KpHKS0 Eg74FHeiqXwSALB+lpn3waUs4V0sTzHJT1f06VQPKCrfxUVTacfJgkmfIxD2fUfat4nj AdNRmLzkQYBMGthAkBGtwtabHtx6OOM9VZZGYayHFUgxX4BKk/hHJ0VHQSGXXbh/J5I4 4RAF/YMZlQnzLySaaflEqBLtmdY43KG0ddo314Wy5Jo8iDHzFmGbYjOGpDqBDeXBSgia 9uv4iJYmJSnsadWKynMxIJaaes582aMF98lJQW7aDjazKWTLYQwAcWkam5qA7s3pXSpR JvBw== MIME-Version: 1.0 X-Received: by 10.182.49.166 with SMTP id v6mr29479998obn.13.1379418002630; Tue, 17 Sep 2013 04:40:02 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Tue, 17 Sep 2013 04:40:02 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Tue, 17 Sep 2013 04:40:02 -0700 (PDT) In-Reply-To: <52383CAE.10105@cs.tcd.ie> References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> <52383CAE.10105@cs.tcd.ie> Date: Tue, 17 Sep 2013 07:40:02 -0400 Message-ID: From: Scott Brim To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b5d2ea40b7f0b04e692c8a8 Cc: Mark Handley , perpass Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 11:40:16 -0000 --047d7b5d2ea40b7f0b04e692c8a8 Content-Type: text/plain; charset=ISO-8859-1 With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly so interesting. --047d7b5d2ea40b7f0b04e692c8a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

With the entire web moving To UDP and QUIC, tcpcrypt isn'= ;t nearly=A0 so interesting.

--047d7b5d2ea40b7f0b04e692c8a8-- From scott.brim@gmail.com Tue Sep 17 05:08:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0514D11E81E8 for ; Tue, 17 Sep 2013 05:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhnLY9bW5qHX for ; Tue, 17 Sep 2013 05:08:34 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 444B411E8118 for ; Tue, 17 Sep 2013 05:08:07 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id uz6so5238066obc.33 for ; Tue, 17 Sep 2013 05:07:57 -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; bh=HQcWp9Qi9Yt+5+otwOOZIMgRvXYdbVCBWo1VszbLIcw=; b=z2CPq6rcN3VGm49Ls9b9QcPRJcHCRuFGg0l1065Qkut14DBF1UdzXOqp7oOa5TXrER 7H/4/jPZ2AEBC1WVDhSegh7t3vcivToM6ELcxtyYhYFaqYOyHxEn8E8EkST12C6BbTnl bAn1Gyh4tnnYaVkU49rrDs+lCdHAqbYPbCDXACwXd8VzP3Xs35C2U/pDIq9nT0ZFKAXv aS6RdYBCv6C8S0BbjKRgsB5FARyGx6u/ckzWughlux7CJDHeWtxDRzATUwhLoDIz/CGr 7ZA2OkjKfKHtiRiKlXKjcNMG1LgoDaT5kwjYI2py34y6jNJ97mBeu7lsxlez3/DUnfpC ST3Q== MIME-Version: 1.0 X-Received: by 10.182.44.134 with SMTP id e6mr30171596obm.14.1379419677800; Tue, 17 Sep 2013 05:07:57 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Tue, 17 Sep 2013 05:07:57 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Tue, 17 Sep 2013 05:07:57 -0700 (PDT) In-Reply-To: <331db5651e98469af660607459b2c2dd.squirrel@arekh.dyndns.org> References: <5232218A.9010704@dcrocker.net> <52328288.6070806@funwithsoftware.org> <52330265.9020709@cs.tcd.ie> <6DCCF5ED-0AD3-42B4-83A7-7FE42DAA27D2@funwithsoftware.org> <331db5651e98469af660607459b2c2dd.squirrel@arekh.dyndns.org> Date: Tue, 17 Sep 2013 08:07:57 -0400 Message-ID: From: Scott Brim To: Nicolas Mailhot Content-Type: multipart/alternative; boundary=001a11c3235ae4b5e904e6932b62 Cc: perpass , Patrick Pelletier , ietf-http-wg@w3.org, Stephen Farrell Subject: Re: [perpass] HTTP user-agent fingerprinting X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:08:35 -0000 --001a11c3235ae4b5e904e6932b62 Content-Type: text/plain; charset=ISO-8859-1 On Sep 16, 2013 4:19 PM, "Nicolas Mailhot" wrote: > Right now no-user-agent-is "I don't want to understand HTTP but it gets me > through the firewall, simulate a real web client and only implement the > parts I need most of the time with no error handling except for retrying > in a loop with no sleeps" Granted user-agent is a pretty good ad hoc filter but I hope you're working on dealing with this in the long term by some architecturally cleaner way. :-) Scott --001a11c3235ae4b5e904e6932b62 Content-Type: text/html; charset=ISO-8859-1


On Sep 16, 2013 4:19 PM, "Nicolas Mailhot" <nicolas.mailhot@laposte.net> wrote:
> Right now no-user-agent-is "I don't want to understand HTTP but it gets me
> through the firewall, simulate a real web client and only implement the
> parts I need most of the time with no error handling except for retrying
> in a loop with no sleeps"

Granted user-agent is a pretty good ad hoc filter but I hope you're working on dealing with this in the long term by some architecturally cleaner way. :-)

Scott

--001a11c3235ae4b5e904e6932b62-- From mark@handley.org.uk Tue Sep 17 05:19:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F6B11E840A for ; Tue, 17 Sep 2013 05:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQX6F-uUGBRK for ; Tue, 17 Sep 2013 05:18:56 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id F061E11E8410 for ; Tue, 17 Sep 2013 05:17:59 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E5AAF22335; Tue, 17 Sep 2013 08:17:57 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute4.internal (MEProxy); Tue, 17 Sep 2013 08:17:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=lEvD3vkUKcctKxNeI0MTPxkOQgQ=; b=ocs7g XBp+mnXEmS7eAbGiEoTJElcp0GN79AD6H8r6w8JD1PHdgWPgU6zXjXdo9F+bu3J1 Xcoe2cfvr6l9Bw9hlZxMGb92Vz6d8yB1HhklNHj9aNI8RhZkz8KwJZKY8e2MERSS NQCsUNCAsBSBeDi3WOenOTQ7w2Qb+2UJmgU9ZQ= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id B9E251090C8; Tue, 17 Sep 2013 08:17:57 -0400 (EDT) Message-Id: <1379420277.11365.23001593.66645932@webmail.messagingengine.com> X-Sasl-Enc: wUEmBszKlrlQCCcrS8CmUPsLG801W0BL6tR/9tXlgKoJ 1379420277 From: Mark Handley To: Scott Brim MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1379420277113650"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-d310b333 Date: Tue, 17 Sep 2013 05:17:57 -0700 In-Reply-To: References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> <52383CAE.10105@cs.tcd.ie> Cc: perpass Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:19:02 -0000 This is a multi-part message in MIME format. --_----------=_1379420277113650 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Tue, Sep 17, 2013, at 04:40 AM, Scott Brim wrote: With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly so interesting. QUIC is pretty interesting as a protocol and does a lot of things that TCP should have evolved to do. From a security point of view, if I understand the design documents correctly, it's really a drop-in replacement for TLS/TCP. Thus it seems to suffer from the same issues TLS does - not enabled sufficiently frequently (you can argue about why, but we've been doing that for a very long time), and dependence on the CA infrastructure. Thus it seems likely to be mostly deployed in places that already do TLS. QUIC could, of course, take the same approach as tcpcrypt. Do encryption by default using ephemeral public keys, even with no configuration, but provide the hooks to enable various forms of authentication. From what I've read, it doesn't seem to do that. Please correct me if I misunderstood though. Cheers, Mark --_----------=_1379420277113650 Content-Transfer-Encoding: 7bit Content-Type: text/html
 
On Tue, Sep 17, 2013, at 04:40 AM, Scott Brim wrote:

With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly  so interesting.

QUIC is pretty interesting as a protocol and does a lot of things that TCP should have evolved to do.  From a security point of view, if I understand the design documents correctly, it's really a drop-in replacement for TLS/TCP.  Thus it seems to suffer from the same issues TLS does - not enabled sufficiently frequently (you can argue about why, but we've been doing that for a very long time), and dependence on the CA infrastructure.  Thus it seems likely to be mostly deployed in places that already do TLS.
 
QUIC could, of course, take the same approach as tcpcrypt.  Do encryption by default using ephemeral public keys, even with no configuration, but provide the hooks to enable various forms of authentication.  From what I've read, it doesn't seem to do that.  Please correct me if I misunderstood though.
 
Cheers,
Mark
--_----------=_1379420277113650-- From jari.arkko@piuha.net Tue Sep 17 05:26:20 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D35A11E8400 for ; Tue, 17 Sep 2013 05:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBjb2Fzxks8y for ; Tue, 17 Sep 2013 05:26:05 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 19D1C11E821B for ; Tue, 17 Sep 2013 05:26:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 60CFF2CC6F; Tue, 17 Sep 2013 15:26:03 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEHpidoEq5PR; Tue, 17 Sep 2013 15:25:59 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 232C92CC48; Tue, 17 Sep 2013 15:25:59 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jari Arkko In-Reply-To: <52381C78.8090504@cs.tcd.ie> Date: Tue, 17 Sep 2013 15:25:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: perpass Subject: Re: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:26:20 -0000 Thanks for the list, Stephen. I also made a short list yesterday for = other purposes. The items not on your list yet were: HTTP 2.0 security becoming somehow more widely turned on than we have on = current HTTP. Curent spec says it is required to implement, see = http://tools.ietf.org/html/draft-ietf-httpbis-http2-06#section-9.2 and = the topic is also discussed in here: = http://tools.ietf.org/agenda/87/slides/slides-87-httpbis-3.pdf I think I saw a discussion about reducing fingerprinting possibilities = for web traffic somewhere. Did we have a discussion of PFS in TLS somewhere? And there is a category of actions we could take, but are not technical = improvements themselves. For instance, we could more aggressively = deprecate algorithms known to have issues. Or we could launch a review = of various security mechanisms or even other protocols to find areas = that need improvement.=20 Jari From hannes.tschofenig@gmx.net Tue Sep 17 05:34:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C411E8237 for ; Tue, 17 Sep 2013 05:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.948 X-Spam-Level: X-Spam-Status: No, score=-101.948 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bR1Ylde3hlBW for ; Tue, 17 Sep 2013 05:34:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4131411E81C4 for ; Tue, 17 Sep 2013 05:34:13 -0700 (PDT) Received: from [10.255.130.17] ([194.251.119.201]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LZz01-1Vldzq15m1-00liYR for ; Tue, 17 Sep 2013 14:34:11 +0200 Message-ID: <52384C38.4020301@gmx.net> Date: Tue, 17 Sep 2013 15:34:00 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jari Arkko References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:lGhLB4K0UEwEDnHDvU5BlW/6clpQEUkTYF8kCtyiZByJQra7/lt e8QYwEo+qTkWGjI0idRcI6ekFtzY83bXlsEXcCvta+DRzYSJhPup1stEdQFW2//wyoRgouM ev2LJLZiEhzRJN4URogKsq98bl6XVaSHqRqxt5HPba/G0uFx7PEsKc1mrnXfqcxBMMRoMwn FoWApWBO6E02mpBfJp9pw== Cc: perpass , hannes.tschofenig@gmx.net, Stephen Farrell Subject: Re: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:34:19 -0000 On 17.09.2013 15:25, Jari Arkko wrote: > Did we have a discussion of PFS in TLS somewhere? That's part of Yaron's draft. From stephen.farrell@cs.tcd.ie Tue Sep 17 05:34:53 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F4811E8432 for ; Tue, 17 Sep 2013 05:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sI7VLa+WLcJ for ; Tue, 17 Sep 2013 05:34:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5267A11E81C4 for ; Tue, 17 Sep 2013 05:34:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 42261BE50; Tue, 17 Sep 2013 13:34:45 +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 KRr4y4J2KLyO; Tue, 17 Sep 2013 13:34:45 +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 1F2F2BE24; Tue, 17 Sep 2013 13:34:45 +0100 (IST) Message-ID: <52384C66.9000308@cs.tcd.ie> Date: Tue, 17 Sep 2013 13:34:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jari Arkko References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:34:53 -0000 Hiya, On 09/17/2013 01:25 PM, Jari Arkko wrote: > Thanks for the list, Stephen. I also made a short list yesterday for > other purposes. The items not on your list yet were: > > HTTP 2.0 security becoming somehow more widely turned on than we have > on current HTTP. Curent spec says it is required to implement, see > http://tools.ietf.org/html/draft-ietf-httpbis-http2-06#section-9.2 > and the topic is also discussed in here: > http://tools.ietf.org/agenda/87/slides/slides-87-httpbis-3.pdf Right. I think there may be a draft popping out on that soonish so I was gonna wait for that. But yes, that's a major topic of interest so I hope to add an item to the list for that once it gets a little more concrete. > I think I saw a discussion about reducing fingerprinting > possibilities for web traffic somewhere. The UA string discussion won't result in changes I think. That's a pity but a) its probably too ingrained in web sites to change and b) its probably only a minor fingerprinting technique so on balance we might have to put this one down as nice to have but not practically changeable. The gmt time in TLS discussion is similar, but seems much more like its a change that can be easily done. > Did we have a discussion of PFS in TLS somewhere? Yep, that'll be more explicit in Yaron's -01 draft I hope but is implicitly there now. > And there is a category of actions we could take, but are not > technical improvements themselves. For instance, we could more > aggressively deprecate algorithms known to have issues. Or we could > launch a review of various security mechanisms or even other > protocols to find areas that need improvement. Sure. Different list though. S. > > Jari > > _______________________________________________ perpass mailing list > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > > From stpeter@stpeter.im Tue Sep 17 05:43:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2559911E8425 for ; Tue, 17 Sep 2013 05:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WgbGCDgAa99 for ; Tue, 17 Sep 2013 05:43:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 37E5411E841A for ; Tue, 17 Sep 2013 05:43:29 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 40B0F41689; Tue, 17 Sep 2013 06:48:16 -0600 (MDT) Message-ID: <52384E70.7060402@stpeter.im> Date: Tue, 17 Sep 2013 06:43:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Brim References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> <52383CAE.10105@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mark Handley , perpass , Stephen Farrell Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:43:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/17/13 5:40 AM, Scott Brim wrote: > With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly > so interesting. Is there an equivalent to tcpcrypt for UDP? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOE5wAAoJEOoGpJErxa2pZkoP/2f9CjwvIpFuIrenInyJkbdF IZ4RNpEDBu1aaOtGh++aHrem+6UQbHJRKL94zplucli2JfTyeDhts8AHI4C4ddsD ifX6GSRbSbNWyGKR3SDBXbOwyL2otFCo4370H8dsbuHrQV7kdyPEU+QKjMd9ITgp rp234ZzXqBz14e2hd8wp+/R6Nr/bwTcjW/pPg94LkwyBph+ll3JJf59Lvv5yC0Jo aNvjCwBaIwFKYxntg6HrzXEucaUk5hTN299hb2zLGk80wbWTioA+AzzSvcNoRq3f X6KtFRZvESYO0RVdcqkn9u0xgiEQHjcoY15ON8wI2HCE++H1L9lISbGptpGFtTvV j8Ls97dAbs53gdQ18UzB4nYhXQdnwTttZDrJoQImdIN8FgmRWbyaXDUKdaA/YLXX PLeAKRmgJk7hWeUFr1xoPmM09zGrlHydDe7oFhtqZlP/2i0PEw0gOkgZrf2uwKD0 foYyLiLVrXUPg5U6PAA8ttvW7fhcarWXny14S8UsgLDYICgj8YBY3Z1+az+jQqFf aXFbK28kgazq3j+6GFT93UXCwsZVfIMP+iPU6xHDedScFVa09kU31EJSmWWVwl26 zBSaJy8Ys2sRXLpsF9mGdH6Jv7wJ8z63aiJCHTyo7TV4PtmKa7Kqk4P+vrVpB8ge O+S4AYBKaxyEDptk7Ev4 =hFJl -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Tue Sep 17 05:49:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BD711E843F for ; Tue, 17 Sep 2013 05:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OR2a9VVnnYD8 for ; Tue, 17 Sep 2013 05:49:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id B814E11E843D for ; Tue, 17 Sep 2013 05:49:13 -0700 (PDT) Received: from [10.255.130.17] ([194.251.119.201]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lxgt9-1VyFCV04vT-017D05 for ; Tue, 17 Sep 2013 14:49:12 +0200 Message-ID: <52384FBB.9020606@gmx.net> Date: Tue, 17 Sep 2013 15:48:59 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> <52383CAE.10105@cs.tcd.ie> <52384E70.7060402@stpeter.im> In-Reply-To: <52384E70.7060402@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:pUvWlppOmvAzn4tW2LEYreNVBYSDSy6JE2AbkGtGfDxiltItoF3 WVyUVAwUlv2KzmRoAAtpOwU4gnQwXnatAJM43k7VUu34Eqb3YzqA1XUsLyXWkV6XQ+Cy7e2 yuRIRyhsuVSSxU3E9mYYPYZVhYjp5D1YJobMYe0Tsk19NzXW4t6zG8P0WNAW8R1ZuXApjIS no6G+ycopknm7rsbw4fnA== Cc: Mark Handley , perpass , hannes.tschofenig@gmx.net, Scott Brim , Stephen Farrell Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:49:37 -0000 > Is there an equivalent to tcpcrypt for UDP? In some sense you could just use DTLS (for UDP) and TLS (for TCP) without server-side authentication and you are done with it. The real challenge is to get the deployment out there. Ciao Hannes From scott.brim@gmail.com Tue Sep 17 07:05:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C591E11E824B for ; Tue, 17 Sep 2013 07:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn8fZtwrg8i6 for ; Tue, 17 Sep 2013 07:05:12 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4311E823D for ; Tue, 17 Sep 2013 07:05:12 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id va2so5512639obc.29 for ; Tue, 17 Sep 2013 07:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KDz+P1W9Dg9IMecQ7lhaN1tSP82gFVMm/+DBmT7Lwzc=; b=kFuf9ZYA2Ow4UfK3ssTDXkCeQJiZMdu/ZjMPylL0gnP63sy3MTF/plxQKQ3V938qeO aCqnEhfMlPRd1TTgIGTpUnqzdlp1OxoITJHRy6pz/2bzwT0I3EltegtufpS8A4fdii5B Akk6sImanMY1slCX3/dfw+4XSnpD/byi36w9Hy1EycGPS8NYANg/Yq/nDu6d6AbEAf3f sQaFgoXs3atgaOOigKcCei8G6RuM1iv9U6MkxNsup8ApOcxwHCdlmARggy8OwSS2ZlsF Oasa5wn4jypjK6wd0dIONvg7ouZrwEoQSityct2YdyoxmRXbwc8r+1+Hqvr7bRQSX73w ivDQ== X-Received: by 10.182.45.195 with SMTP id p3mr3875obm.29.1379426711681; Tue, 17 Sep 2013 07:05:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.2.134 with HTTP; Tue, 17 Sep 2013 07:04:51 -0700 (PDT) In-Reply-To: <52384FBB.9020606@gmx.net> References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> <52383CAE.10105@cs.tcd.ie> <52384E70.7060402@stpeter.im> <52384FBB.9020606@gmx.net> From: Scott Brim Date: Tue, 17 Sep 2013 10:04:51 -0400 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e01537e422526a104e694cf82 Cc: Mark Handley , perpass , Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 14:05:13 -0000 --089e01537e422526a104e694cf82 Content-Type: text/plain; charset=ISO-8859-1 Now that I'm out of bed and at a device with a real keyboard, I can elaborate. I hope Mark will forgive me, but I've envisioned the birth of tcpcrypt as something like: Student: "Mark, you know that conversation we had two weeks ago about research projects related to MPTCP? I figured out how to do low overhead encryption for TCP." Mark: "That's great. We can bundle it with MPTCP and take it to the IETF. Maybe we can find a way to make it generally useful." :-) There is a trend toward putting capabilities in what I'm going to call the session layer (if you don't like that I'm glad to call it something else - that's not the main point), of which QUIC is an example. Partly this is because the behavior of the transport layer isn't very consistent anymore. The great thing going on in HTTPbis, RTCWeb, etc. is they might get a good level of behavioral consistency. And if they do, they will attract even more feature building. This leads me to believe that that level/layer is a really good place to put consistent security capabilities. Scott --089e01537e422526a104e694cf82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Now that I'm out of bed and at a device with a real ke= yboard, I can elaborate.

I hope Mark will forgive me, bu= t I've envisioned the birth of tcpcrypt as something like: Student: &qu= ot;Mark, you know that conversation we had two weeks ago about research pro= jects related to MPTCP? =A0I figured out how to do low overhead encryption = for TCP." =A0Mark: "That's great. =A0We can bundle it with MP= TCP and take it to the IETF. Maybe we can find a way to make it generally u= seful." =A0:-)

There is a trend toward putting capabilities in what I&= #39;m going to call the session layer (if you don't like that I'm g= lad to call it something else - that's not the main point), of which QU= IC is an example. =A0Partly this is because the behavior of the transport l= ayer isn't very consistent anymore. =A0The great thing going on in HTTP= bis, RTCWeb, etc. is they might get a good level of behavioral consistency.= =A0And if they do, they will attract even more feature building. =A0

This leads me to believe that that level/layer is= a really good place to put consistent security capabilities.
Scott
--089e01537e422526a104e694cf82-- From nb@bollow.ch Tue Sep 17 07:13:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BC911E8278 for ; Tue, 17 Sep 2013 07:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz7AM2s78iCi for ; Tue, 17 Sep 2013 07:13:31 -0700 (PDT) Received: from beta.bollow.ch (beta.bollow.ch [193.37.152.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7C411E8121 for ; Tue, 17 Sep 2013 07:13:30 -0700 (PDT) Received: from quill (177-243.62-81.cust.bluewin.ch [81.62.243.177]) by beta.bollow.ch (Postfix) with ESMTPSA id 84B3B1404BC; Tue, 17 Sep 2013 16:17:58 +0200 (CEST) Date: Tue, 17 Sep 2013 16:13:31 +0200 From: Norbert Bollow To: perpass@ietf.org Message-ID: <20130917161331.47daed82@quill> In-Reply-To: <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> References: <52381D13.2010604@cs.tcd.ie> <52381DB6.1030200@cs.tcd.ie> <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> Organization: GoalTree Empowerment X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 14:13:37 -0000 Mark Handley wrote: > The key reason for an approach at this layer in the stack is that it > gets you the most bang for the buck. By leveraging the TCP handshake, > you can get sessions encypted very easily with minimal infrastructure > deployment, and only a single change to the stack. I've tried to find (in the draft or in the paper) information on the server's entropy consumption, and the practical consequences. Can entropy generation become performance-limiting on servers that receive a lot of connection requests? What kind of source of randomness did you use in the experiments? Greetings, Norbert From llynch@civil-tongue.net Tue Sep 17 07:21:28 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1B811E8278 for ; Tue, 17 Sep 2013 07:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgQOBkj5UXc6 for ; Tue, 17 Sep 2013 07:21:16 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id 0384311E8246 for ; Tue, 17 Sep 2013 07:21:12 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id r8HEKeh5096348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Sep 2013 07:20:40 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id r8HEKekd096345; Tue, 17 Sep 2013 07:20:40 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Tue, 17 Sep 2013 07:20:40 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: Stephen Farrell In-Reply-To: <52379B65.8060100@cs.tcd.ie> Message-ID: References: <52379B65.8060100@cs.tcd.ie> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: perpass Subject: Re: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 14:21:28 -0000 On Tue, 17 Sep 2013, Stephen Farrell wrote: > > Hiya, > > I've gone through the perpass archive to try make a > list of the things that seem to be more doable/stable. > > This is just to make it more manageable for me, the > list has no official status whatsoever. I've not included > things where I'm not clear what might be the outcome. > Even if I include something I may well be wrong that > there'll be a clear outcome. > > Let me know if I've missed stuff (probably) or if you've > any other comments. On or off list, whichever's better. I haven't seen Martin Thompson among the posters and I think there may be some interesting lessons in the geopriv location obfuscation work that was included in his 2011 lying draft - https://tools.ietf.org/html/draft-thomson-geopriv-lying-00 some of which is now embedded here: https://tools.ietf.org/html/draft-thomson-geopriv-uncertainty-08 not sure how this relates to the other proposals but it should be on the list. I remember a slide set as well from one of the meetings but can't find it in the archive. - Lucy > I do know that some other folks are discussing some > other relevant activities that are not yet published or > weren't mentioned on this list. When/if you want those > added here, just give me the info. and I'll add it. (If > your thing hasn't been discussed on an IETF list or > published in an I-D, I'd rather see that happen first if > you don't mind, for all the normal tedious IPR/Note-well > reasons.) > > I'll sporadically maintain this between now and Vancouver > at [1] (you may prefer to read it at [2], since [1] will > get you browser warnings about my self-signed cert. (*) > > Cheers, > S. > > [1] https://down.dsg.cs.tcd.ie/misc/perpass.txt > [2] http://down.dsg.cs.tcd.ie/misc/perpass.txt > > (*) Nothing to do with the topic really but I just noticed > I'd not updated the key pair in 5 years so I made a new one > a few minutes ago since now's a good time before this year's > batch of students arrive. (How they complain about that > tells me a bit about 'em:-) > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From lars@netapp.com Tue Sep 17 09:00:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CFE21F9C13 for ; Tue, 17 Sep 2013 09:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.809 X-Spam-Level: X-Spam-Status: No, score=-4.809 tagged_above=-999 required=5 tests=[AWL=-2.210, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4oZ+GkjjDbf for ; Tue, 17 Sep 2013 09:00:28 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2E80511E8297 for ; Tue, 17 Sep 2013 09:00:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,924,1371106800"; d="asc'?scan'208";a="50572092" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx11-out.netapp.com with ESMTP; 17 Sep 2013 09:00:26 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.46]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 17 Sep 2013 09:00:25 -0700 From: "Eggert, Lars" To: Hannes Tschofenig Thread-Topic: [perpass] BoFing in Vancouver Thread-Index: AQHOrXiKO6mTnXn69EeJ3I3RfXj+rJm+ENEAgAGpkoCAAAjLgIAAA3YAgArRzQA= Date: Tue, 17 Sep 2013 16:00:25 +0000 Message-ID: References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F6637.2080700@dcrocker.net> <522F691E.3010101@gmx.net> In-Reply-To: <522F691E.3010101@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_585CC653-AC9C-41D9-A752-0170A93C5342"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Dave Crocker , perpass , Scott Brim , "" , Peter Saint-Andre , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:00:36 -0000 --Apple-Mail=_585CC653-AC9C-41D9-A752-0170A93C5342 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Sep 10, 2013, at 20:46, Hannes Tschofenig = wrote: > One approach to focus the discussion is to limit it to what the IETF = can do. and, for those important topics that we aren't quite sure what the IETF = impact is going to be or even if there is any, I want to mention that it = is always possible to spin up a related research group in the IRTF. = "Research" in the widest possible sense of "not (yet) engineering" - not = necessarily academic science. It'd need a few folks determined to run the show and grow/form the = community. There certainly seems to be energy in this space at the = moment. The nice thing about the IRTF is that have way fewer processes than the = IETF; for example, IRTF groups need not operate by consensus and can = even be closed membership. Lars --Apple-Mail=_585CC653-AC9C-41D9-A752-0170A93C5342 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQCVAwUBUjh8mNZcnpRveo1xAQK6vwP+NvcjCSZIRe9IptuNAjVsk0k/munlTBrv ajZG86N0OWMgHnzs7TmkvUhvnXeg7P53UOI1RLyHSUX1ecintwGdD4plh7i2eOPj umPWpT2+lmtHX+I2I3l87X2sER/Et/nXynL7hM5MAxTcduESUlt52C6F4fOFEBJn SIA1S9Oo/jE= =w/Wi -----END PGP SIGNATURE----- --Apple-Mail=_585CC653-AC9C-41D9-A752-0170A93C5342-- From benl@google.com Tue Sep 17 09:09:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5BA11E82B3 for ; Tue, 17 Sep 2013 09:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8Fl3SwsJ5CH for ; Tue, 17 Sep 2013 09:09:18 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id EF59F11E80EA for ; Tue, 17 Sep 2013 09:09:17 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id qd12so10289509ieb.22 for ; Tue, 17 Sep 2013 09:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XSn9ofP2CovoGUTCZSpEjbKHAzs6X5m/uAhyDWbI8NA=; b=D96qtDw0gzUE5K1hRpyYq5GX63wlv6gneVrDZg378GRMevcs92sp2JTm7FLXlriLF5 8Ip95eYX37QxDopzk++IBHTdKvTlc1UYVVVJzw1xvkMtYVAt34jCrRnXHtiaYuzBkkWe pAi97wIhGeDo7m2F1DyXU3UACBsErGD4l0s5/YsQvo0bWQ3umPdzIBtVEDoqmRESAi/1 h3OaRt6mrj5o3C/kZjCtRVaMaUAEvJma1yOQ0twjN6u8G25O9w+J3Ona10uL5LWjrU6x wpPEe8XJIMtGfIv8CKLT2IxBQD3d7mviEHvcihoS4uorlN3dK53qTIagJnDxCOoQWQKG sTWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XSn9ofP2CovoGUTCZSpEjbKHAzs6X5m/uAhyDWbI8NA=; b=a+YLjiX5ezktxImeyfZeW2oWEQwWKcKtjEO//EeN0YfxfAXFZxMQCVJuY8VmnLgVzQ 1hEzqMR5NtRlxdMlQpxMVNzh30ZoeKc9wlmrfW6fZlKJ9ZqUkUT4/WZ8eZqp5/koVKWj BWoa+NRA//ISwTYtP45YYj+D6E7mwgz0pBbYxvM7rMvGi1kxzK8zbb15V0c/F0JP7ji0 Vheg+K1E7v+O6LXe3/EbIfdXzaOAD3R/tP/KngKIuzSFZaCTtjhjpcvJ7pl51yWjKCBl zOkVkh+Se7gsvPJRKfsV5XcZRhBJbjeHB3C2z/DdasBJSA4tMaPpFpQ0bQWglguVAfPU LsuQ== X-Gm-Message-State: ALoCoQkB83DmmDvruYDtdz0QGdmClBkMjy3jFCT2Mv5x4qyMyq+zVAUjN8gjyn3vQzcF6FqbIBB+nUOSPcOYj4SPUgzow1G/P3OBFCSCIO91IMyKZliNUv0nUXMiZfW3EpgUYehOnDEzdkT4SPw7KEMPA/0WVNwH2hzgZ5FhZE/q0jS2pMsEpHVTvd/oA+EWDi1NW7xK8iLF MIME-Version: 1.0 X-Received: by 10.50.122.102 with SMTP id lr6mr1390191igb.0.1379434157231; Tue, 17 Sep 2013 09:09:17 -0700 (PDT) Received: by 10.64.230.140 with HTTP; Tue, 17 Sep 2013 09:09:17 -0700 (PDT) In-Reply-To: References: <522DF017.2030504@cs.tcd.ie> <522DF9D8.10607@stpeter.im> <522F6637.2080700@dcrocker.net> <522F691E.3010101@gmx.net> Date: Tue, 17 Sep 2013 17:09:17 +0100 Message-ID: From: Ben Laurie To: "Eggert, Lars" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dave Crocker , perpass , Scott Brim , "" , Peter Saint-Andre , Hannes Tschofenig , Stephen Farrell Subject: Re: [perpass] BoFing in Vancouver X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:09:18 -0000 On 17 September 2013 17:00, Eggert, Lars wrote: > Hi, > > On Sep 10, 2013, at 20:46, Hannes Tschofenig = wrote: >> One approach to focus the discussion is to limit it to what the IETF can= do. > > and, for those important topics that we aren't quite sure what the IETF i= mpact is going to be or even if there is any, I want to mention that it is = always possible to spin up a related research group in the IRTF. "Research"= in the widest possible sense of "not (yet) engineering" - not necessarily = academic science. > > It'd need a few folks determined to run the show and grow/form the commun= ity. There certainly seems to be energy in this space at the moment. > > The nice thing about the IRTF is that have way fewer processes than the I= ETF; for example, IRTF groups need not operate by consensus and can even be= closed membership. Hmmm... "The CFRG is chaired by David McGrew(mcgrew@cisco.com) and Kevin Igoe (kmigoe@nsa.gov)." From mark@handley.org.uk Tue Sep 17 09:09:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5259611E8129 for ; Tue, 17 Sep 2013 09:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBrbchvXZWh8 for ; Tue, 17 Sep 2013 09:09:40 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id DA76611E82C2 for ; Tue, 17 Sep 2013 09:09:40 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6387E211C5 for ; Tue, 17 Sep 2013 12:09:39 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute1.internal (MEProxy); Tue, 17 Sep 2013 12:09:39 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=RRYUJzmCSWL6sKnzvt+UCGPvHgQ=; b=lr+ nnEmmY+7RA3Adxa4oIqMLLKGf8puoY0moy5hD7g5e3yr3tNYVZdvGYiivy6rQqpl EG8ceu/1bGL6z3eUC8qmQw+HH3LPNA4ufdDjhUeoA4pnkI+8LAhJ1nWg1KwXFgg/ BNim1xU9hs1AS5TttMa5dvc1/PImGTLbUy0ehOxE= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 42B2710B304; Tue, 17 Sep 2013 12:09:39 -0400 (EDT) Message-Id: <1379434179.362.23091425.0AF3B413@webmail.messagingengine.com> X-Sasl-Enc: gOMrPky3KJbYnzp6cTXQAM2aYe7sAdVYMtZWGQsOkeOY 1379434179 From: Mark Handley To: perpass@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-d310b333 In-Reply-To: <20130917161331.47daed82@quill> References: <52381D13.2010604@cs.tcd.ie> <52381DB6.1030200@cs.tcd.ie> <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> <20130917161331.47daed82@quill> Date: Tue, 17 Sep 2013 09:09:39 -0700 Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:09:45 -0000 On Tue, Sep 17, 2013, at 07:13 AM, Norbert Bollow wrote: > Mark Handley wrote: > > > The key reason for an approach at this layer in the stack is that it > > gets you the most bang for the buck. By leveraging the TCP handshake, > > you can get sessions encypted very easily with minimal infrastructure > > deployment, and only a single change to the stack. > > I've tried to find (in the draft or in the paper) information on the > server's entropy consumption, and the practical consequences. > > Can entropy generation become performance-limiting on servers that > receive a lot of connection requests? > > What kind of source of randomness did you use in the experiments? That is a good question. I don't know what Andrea's implementation currently does. A few thoughts (but it would be better to ask one of the security people on the draft rather than me): A busy server will be handling a lot of packets per second, and the precise arrival times (as measured by CPU cycle counter) of those packets is not predictable, so the more traffic a server receives, the more entropy it has from this source. This helps less if you've got an eavesdropper very close to the server, but precise arrival times will still have some unobservable entropy. We could require the client supplies another random (encrypted) nonce right after the key exchange. This would be sufficient to top up the entropy pool in the presence of a passive eavesdropper, assuming entropy generation is easier at the client. An active attacker could try to deplete this entropy source by making a lot of connections and sending known values of this nonce, but they'd have to drown out all the legitimate clients, which would be difficult on a busy server, and would likely reveal the presence of the attack. And they'd need to combine this with eavesdropping very close to the server, or all they'd do is add randomness to the pool from their packet arrival times. Regards, Mark From benl@google.com Tue Sep 17 09:15:20 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF8B11E84A2 for ; Tue, 17 Sep 2013 09:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R558nMgSv715 for ; Tue, 17 Sep 2013 09:15:20 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 05C8A11E84A0 for ; Tue, 17 Sep 2013 09:15:18 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id u16so10493454iet.33 for ; Tue, 17 Sep 2013 09:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OTCRnkDecBGyPyC2irNU9KwmNYxra6kocx+X/u5um1A=; b=ZIHhXjD7nVdFKhTJpLMp+Ee1UCeuQakhUCPW+GTvC7UeuPN6j+et+Hm7L4PW12/rUK cdsd5e/eeE+keM9+1YC/BukzE9It8CJ6Yih/TUh7llQem1t0RKjU3aGYpLfWCfqL9NXW sPH8KovkRusG+3bBc2lb8nZ+kIJtICM9eUDqxRWmE7uA8L1JRB73eG/rw1sSiMSUgKeZ SnCINQZL1F2qqUBFcEgZDL6YmH+A4zE6lI8TLh6bw8OH17yzMY2f3GbGOQLjGZNY7Rbm Y3SvwyA0y5ro/dlN38/B0G1529DTqc4phB5cTDtZrjZ4R/cslUurBMvsiuiiLXHVrUSE sBLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OTCRnkDecBGyPyC2irNU9KwmNYxra6kocx+X/u5um1A=; b=MKRGd+RQ+B3m4weXucBM+pzariVVojs0gDpNDkcM6pQCAnN9b+8kSTWoRSuxN1Mntt 4fKnnGygaZRK9CPcrouvv00SMKEQKPq2yhPoDhkrO9O555KaKaOdf80lABozy5PBlAGX JRmpGNOkCFHZBgzg0yHOOoaLqZuDSo6ALsm7coT/n4+1Ja1Th/7YwxwUTP4xbAoDpsv+ EXH7zVIIkywXQvpaTdhQlC8SYAzcI/aR32q+mHPy8+ZDNff26fxa9jBq4QyGjWXBR0Qb qDgsdMP4NNPvTInge9TTcEoty30QeorYC+XO3PDd1d6f5H4l3pSJjAgC4wNj36IwmhrT aQdQ== X-Gm-Message-State: ALoCoQnFa8TZxhinDBOQNkd6wssQuGCIc6/jFlhSZ6+RszZJlEBw0jgSnr/c8OhJ5IwoWx8xW/PcT+QkQHzuGI5zveIb1+PqN7zPLJqnaA4rvb4+HvYznBZKJlImndS/szCm0IjneWtdyHfl7P/ZG2yjR8uqwlihhLlVbF5VVXFE3momIla1hiIz96PRG7bYD7QBe1UHj/bX MIME-Version: 1.0 X-Received: by 10.50.108.71 with SMTP id hi7mr1298437igb.59.1379434518572; Tue, 17 Sep 2013 09:15:18 -0700 (PDT) Received: by 10.64.230.140 with HTTP; Tue, 17 Sep 2013 09:15:18 -0700 (PDT) In-Reply-To: <1379420277.11365.23001593.66645932@webmail.messagingengine.com> References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> <52383CAE.10105@cs.tcd.ie> <1379420277.11365.23001593.66645932@webmail.messagingengine.com> Date: Tue, 17 Sep 2013 17:15:18 +0100 Message-ID: From: Ben Laurie To: Mark Handley Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Scott Brim Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:15:20 -0000 On 17 September 2013 13:17, Mark Handley wrote: > > On Tue, Sep 17, 2013, at 04:40 AM, Scott Brim wrote: > > With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly so > interesting. > > QUIC is pretty interesting as a protocol and does a lot of things that TCP > should have evolved to do. From a security point of view, if I understand > the design documents correctly, it's really a drop-in replacement for > TLS/TCP. Thus it seems to suffer from the same issues TLS does - not > enabled sufficiently frequently (you can argue about why, but we've been > doing that for a very long time), and dependence on the CA infrastructure. > Thus it seems likely to be mostly deployed in places that already do TLS. > > QUIC could, of course, take the same approach as tcpcrypt. Do encryption by > default using ephemeral public keys, even with no configuration, but provide > the hooks to enable various forms of authentication. From what I've read, > it doesn't seem to do that. Please correct me if I misunderstood though. You are right, but there's no reason not to extend QUIC to do ephemeral encryption. That wasn't the use case we were thinking about when we designed it. Seems like a useful thing for the IETF to consider. From watsonbladd@gmail.com Tue Sep 17 09:23:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7456311E84AD for ; Tue, 17 Sep 2013 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUOgqhM26zk8 for ; Tue, 17 Sep 2013 09:23:11 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 56B5011E82BE for ; Tue, 17 Sep 2013 09:23:11 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ea20so4610152lab.13 for ; Tue, 17 Sep 2013 09:23:09 -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; bh=c+t4C+l3QK6ki60lxpS4LU0YAkR4+QNlgerABURZQuE=; b=RnOQkVFRb00I4wkgY6tDaNKdNWW0yDtta/BmrqRUEUOULJt04WazUv2OYC3+TzJlQh dNY8XXx2d7IwPz3gf8W5MSR20prIFBqaX2f0pztSrE6CZ/ddsdLxf1ly6f4KsvESJpXP +LahAFG48MtnEqXseRlaX95TrUHijNw3Xwx7BDioHjRvHGKKVjpoZcmZ9T84EdH1p13E dpnDpzwFvuxRqOIwegoZM8WdNmW7UuZ+4dR1cZ6PxC5fv1xenUBhnvbkoX0ydBE0T+Re rAh8irjIwo+2zkmD2U2UZTtV5BvuvpWwezbIWxJVkhWfqqA/ibXF1YnCspdOhkPhnIDj 8RBw== MIME-Version: 1.0 X-Received: by 10.152.36.170 with SMTP id r10mr713257laj.48.1379434987789; Tue, 17 Sep 2013 09:23:07 -0700 (PDT) Received: by 10.152.1.66 with HTTP; Tue, 17 Sep 2013 09:23:07 -0700 (PDT) In-Reply-To: <1379434179.362.23091425.0AF3B413@webmail.messagingengine.com> References: <52381D13.2010604@cs.tcd.ie> <52381DB6.1030200@cs.tcd.ie> <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> <20130917161331.47daed82@quill> <1379434179.362.23091425.0AF3B413@webmail.messagingengine.com> Date: Tue, 17 Sep 2013 09:23:07 -0700 Message-ID: From: Watson Ladd To: Mark Handley Content-Type: text/plain; charset=UTF-8 Cc: perpass@ietf.org Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:23:12 -0000 On Tue, Sep 17, 2013 at 9:09 AM, Mark Handley wrote: > > On Tue, Sep 17, 2013, at 07:13 AM, Norbert Bollow wrote: >> Mark Handley wrote: >> >> > The key reason for an approach at this layer in the stack is that it >> > gets you the most bang for the buck. By leveraging the TCP handshake, >> > you can get sessions encypted very easily with minimal infrastructure >> > deployment, and only a single change to the stack. >> >> I've tried to find (in the draft or in the paper) information on the >> server's entropy consumption, and the practical consequences. >> >> Can entropy generation become performance-limiting on servers that >> receive a lot of connection requests? >> >> What kind of source of randomness did you use in the experiments? > > That is a good question. I don't know what Andrea's implementation > currently does. > We could require the client supplies another random (encrypted) nonce > right after the key exchange. This would be sufficient to top up the > entropy pool in the presence of a passive eavesdropper, assuming entropy > generation is easier at the client. An active attacker could try to > deplete this entropy source by making a lot of connections and sending > known values of this nonce, but they'd have to drown out all the > legitimate clients, which would be difficult on a busy server, and would > likely reveal the presence of the attack. And they'd need to combine > this with eavesdropping very close to the server, or all they'd do is > add randomness to the pool from their packet arrival times. Exhibit A of why we need mathematicians on this list. The difference between AES in counter mode and actually random numbers is miniscule. Any server has enough entropy to reseed say once a second, which will be fine for less than 2^64 connections per second. Please, check what /dev/urandom actually does, and what actual cryptographers say about generating random numbers in practice. > > Regards, > Mark > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From stephen.farrell@cs.tcd.ie Tue Sep 17 09:37:20 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E615611E82C1 for ; Tue, 17 Sep 2013 09:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn1gevb5umWq for ; Tue, 17 Sep 2013 09:37:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C7E4811E810B for ; Tue, 17 Sep 2013 09:37:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E48BBE59; Tue, 17 Sep 2013 17:37:00 +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 CtmQWik+Kh9z; Tue, 17 Sep 2013 17:36:59 +0100 (IST) Received: from [10.36.81.109] (unknown [95.83.250.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2AF92BE53; Tue, 17 Sep 2013 17:36:59 +0100 (IST) References: <52381D13.2010604@cs.tcd.ie> <52381DB6.1030200@cs.tcd.ie> <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> <20130917161331.47daed82@quill> <1379434179.362.23091425.0AF3B413@webmail.messagingengine.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <914CC127-33C5-49D8-B2BF-275C5C2D99D0@cs.tcd.ie> X-Mailer: iPhone Mail (10B329) From: Stephen Farrell Date: Tue, 17 Sep 2013 17:36:52 +0100 To: Watson Ladd Cc: Mark Handley , "perpass@ietf.org" Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:37:21 -0000 On 17 Sep 2013, at 17:23, Watson Ladd wrote: > Exhibit A of why we need mathematicians on this list. Not necessarily this list. Our job for now is to identify bits of work that'= ll help and people who are willing. Perfecting the details will be for elsew= here in most cases. S= From mark@handley.org.uk Tue Sep 17 09:39:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A59A11E82B3 for ; Tue, 17 Sep 2013 09:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL5uWwd8QuRX for ; Tue, 17 Sep 2013 09:39:10 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id D0CD211E82C5 for ; Tue, 17 Sep 2013 09:39:09 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9807821FE3; Tue, 17 Sep 2013 12:39:02 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute5.internal (MEProxy); Tue, 17 Sep 2013 12:39:02 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=pDzerKZyyJJCARv1bAF5MQQ+hoo=; b=Fal+6 /m8nK4UDeH2hCVO64D8qieWyorMQcmOI+DJA8ssRo5or1yPlZJCC5ssljvYrgGKJ 0cDOqIJxChJodEFfRpI9Jb0t53j3bUmymXSCl2vXG0b1jsFwpbkD/etG9i7IH0aG cBTDnSCFY/u+BPjZPPtmZGRWWEljz3nV6iylBM= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 6D71810B97F; Tue, 17 Sep 2013 12:39:02 -0400 (EDT) Message-Id: <1379435942.15715.23115805.149B2498@webmail.messagingengine.com> X-Sasl-Enc: jiTWsMtsYhj1AdbiUyj6lUIKgkrVSdeCsBfaYSMHdLft 1379435942 From: Mark Handley To: Ben Laurie MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-d310b333 Date: Tue, 17 Sep 2013 09:39:02 -0700 In-Reply-To: References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> <52383CAE.10105@cs.tcd.ie> <1379420277.11365.23001593.66645932@webmail.messagingengine.com> Cc: perpass , Scott Brim Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:39:15 -0000 On Tue, Sep 17, 2013, at 09:15 AM, Ben Laurie wrote: > On 17 September 2013 13:17, Mark Handley wrote: > > QUIC could, of course, take the same approach as tcpcrypt. Do encryption by > > default using ephemeral public keys, even with no configuration, but provide > > the hooks to enable various forms of authentication. From what I've read, > > it doesn't seem to do that. Please correct me if I misunderstood though. > > You are right, but there's no reason not to extend QUIC to do > ephemeral encryption. That wasn't the use case we were thinking about > when we designed it. > > Seems like a useful thing for the IETF to consider. Agreed - seems like a very useful thing to work on, and would probably help QUIC reach applications and scenarios it otherwise wouldn't be used for. I think that shouldn't stop us trying to fix TCP as well though - indeed the QUIC design docs talk about retrofitting QUIC mechanisms to TCP in the long run. Not sure if that's still the intent. But getting deployment of ephemeral encryption in QUIC is certainly likely to be faster :-) - Mark From mark@handley.org.uk Tue Sep 17 09:54:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76F011E853E for ; Tue, 17 Sep 2013 09:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zct7TucdQX+f for ; Tue, 17 Sep 2013 09:54:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id BE7ED11E8528 for ; Tue, 17 Sep 2013 09:54:43 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id D1D812243F; Tue, 17 Sep 2013 12:54:40 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute4.internal (MEProxy); Tue, 17 Sep 2013 12:54:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=/j67SgTM9y6b9pSpKz72StiOFg4=; b=WFE t+78SWwCNYTchNb5Kt1p16H85twS6ZERJmNBK8GtXukkYXUVWt5vcoJxyJJjaHij hUw8328ZRBF5JJlbeBPlqXlq64gewf7RbeJPQ4krZjEzuHm0LczKhAEf+NBDgoSM Aad7bWCsjxpPWJVLRhBCg3tHVkcYYhspEr3T1iV4= Received: by web4.nyi.mail.srv.osa (Postfix, from userid 99) id 2E4EB108E40; Tue, 17 Sep 2013 12:54:40 -0400 (EDT) Message-Id: <1379436880.22327.23122413.6A104B54@webmail.messagingengine.com> X-Sasl-Enc: x+k6K5qTWpWug4dFGg7wWwcVoAyrzcIV0W9mbrBJ1X8S 1379436880 From: Mark Handley To: Watson Ladd MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-d310b333 In-Reply-To: References: <52381D13.2010604@cs.tcd.ie> <52381DB6.1030200@cs.tcd.ie> <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> <20130917161331.47daed82@quill> <1379434179.362.23091425.0AF3B413@webmail.messagingengine.com> Date: Tue, 17 Sep 2013 09:54:40 -0700 Cc: perpass@ietf.org Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:54:54 -0000 On Tue, Sep 17, 2013, at 09:23 AM, Watson Ladd wrote: > On Tue, Sep 17, 2013 at 9:09 AM, Mark Handley > > On Tue, Sep 17, 2013, at 07:13 AM, Norbert Bollow wrote: > >> Mark Handley wrote: > Exhibit A of why we need mathematicians on this list. And precisely why tcpcrypt is the result of a collaboration with people like Dan (who doesn't usually hang out on IETF mailing lists). Norbert's original question was not a dumb question though, even if the answer is there's nothing to be concerned about. Mark From hallam@gmail.com Tue Sep 17 11:44:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2567311E812E for ; Tue, 17 Sep 2013 11:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWnRdjPGazeO for ; Tue, 17 Sep 2013 11:44:09 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DC7D511E812B for ; Tue, 17 Sep 2013 11:44:08 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eo20so4801639lab.31 for ; Tue, 17 Sep 2013 11:44:07 -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=7PzIyc3OxPrS64k8yLzPoi+1NHzonMVK1DwTI9ep5HY=; b=QO4L3vrZz9vA7dcfZjgZIuDWekxFfDb9WOQxawEoj4uX1j3D162d6BiJWlpq9FaigC Q7+qkRdnEDaRuQC+i38XHHasEGxIrtjNt4XmHnYLjjU3Kj/YZjpMpsZ+DTykC41KeT/+ tixq6DyxKhZ/pclzDLuLCsgnlaSOL+3gWp+TkbcxNHROM1w5IR1fnI2zwHZpz8gC/VTH cPy0E/JDBfQRrI0OP8o8rw630kAbcIu1EO5KIFF/eldGLR36ciLrilT4MIrGz9vzjcbB ui2A2WeLetk7Lm3g80uraDzlFHzYyQxmhv0DDau79MBqXVBg0/wbWkk9pRyn8cqVbd6f WK6w== MIME-Version: 1.0 X-Received: by 10.112.158.225 with SMTP id wx1mr2554542lbb.37.1379443447667; Tue, 17 Sep 2013 11:44:07 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Tue, 17 Sep 2013 11:44:07 -0700 (PDT) Date: Tue, 17 Sep 2013 14:44:07 -0400 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=001a11c34932afa6fb04e698b450 Subject: [perpass] PRISM-HARDENING Increasing the work factor X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 18:44:10 -0000 --001a11c34932afa6fb04e698b450 Content-Type: text/plain; charset=ISO-8859-1 My phrase PRISM-Proofing seems to have created some interest in the press. PRISM-Hardening might be more important, especially in the short term. The objective of PRISM-hardening is not to prevent an attack absolutely, it is to increase the work factor for the attacker attempting ubiquitous surveillance. Examples include: Forward Secrecy: Increases work factor from one public key per host to one public key per TLS session. Smart Cookies: Using cookies as authentication secrets and passing them as plaintext bearer tokens is stupid. It means that all an attacker needs to do is to compromise TLS once and they have the authentication secret. The HTTP Session-ID draft I proposed a while back reduces the window of compromise to the first attack. I am sure there are other ways to increase the work factor. -- Website: http://hallambaker.com/ --001a11c34932afa6fb04e698b450 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My phrase PRISM-Proofing seems to have created some intere= st in the press.

PRISM-Hardening might be more important= , especially in the short term. The objective of PRISM-hardening is not to = prevent an attack absolutely, it is to increase the work factor for the att= acker attempting ubiquitous surveillance.

Examples include:

Forward Secr= ecy: Increases work factor from one public key per host to one public key p= er TLS session.

Smart Cookies: Using cookies as au= thentication secrets and passing them as plaintext bearer tokens is stupid.= It means that all an attacker needs to do is to compromise TLS once and th= ey have the authentication secret. The HTTP Session-ID draft I proposed a w= hile back reduces the window of compromise to the first attack.


I am sure there are other ways to increa= se the work factor.=A0


<= br>
--
Website: http://hallamb= aker.com/
--001a11c34932afa6fb04e698b450-- From malbrain@yahoo.com Tue Sep 17 12:19:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24211E8138 for ; Tue, 17 Sep 2013 12:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UINfRw3WIER for ; Tue, 17 Sep 2013 12:19:10 -0700 (PDT) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 06D0A11E82B2 for ; Tue, 17 Sep 2013 12:19:09 -0700 (PDT) Received: from [66.196.81.174] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 17 Sep 2013 19:19:08 -0000 Received: from [98.139.212.242] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 17 Sep 2013 19:19:08 -0000 Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 17 Sep 2013 19:19:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 435880.39206.bm@omp1051.mail.bf1.yahoo.com Received: (qmail 63318 invoked by uid 60001); 17 Sep 2013 19:19:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379445547; bh=9qvqBJLMmh6l4b6+k5+QiBvSJWvU8l7MyqVflEbM+/0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bDjIOP2jGev3i9ES0qPKZr4OwsdIMszbZ58Uz6tkOWEYr+2X1xBUc/oNmN7L6AXzxUFyOcgtPyVMwJ2a2bJ9s+urmSR1Z3Yr/V0Qnkxo0fuWIGC2bhgcFV07Modbow4FPBHeV4CBvm2Xo24OzQQROY8LlBisHtCxtEvCPFdd8sE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AE61FktoFW+vNYre2VsPrhkbCEwic76q3WbZdyzsIT5eWzNRzPRUI8ZWt3Wh5SrT5dvrQTQ1HZbWhIWSTUof0KKViaz9VdjYc9T6GjbqmdrUaNY9g7bMAuEh1vV9xS/KcEJt+U96prt7tLOVlgN+2X/mfw4qSVc1hdwCq9AQDso=; X-YMail-OSG: LhK1704VM1nZP3a2M0sE92GX41S2jbgInL1SKvt18H5Rax9 q3sLOo7t_EffIUePIGh.dvsYcnwIdlS2FImJYmVTf7Pl2CHuqWVNr3WWenCB FAPN1zYQRdI4M0mP6ecNWS7kVooow2ZEC9XH76mz32r.0Cz5cOwt6UzVOlzf AJvOBPJFmn2USTJNpszM_Va.ZUbcgKQPs9sRi55VseXCLe1A_gKt0wtiOeB2 0Swh9wI_hJQZq5jJBW8NOxbf.tQYjw3I9Aw5ElXHW.RRREbO47HYukvbB9ll yaDjjt_EmY1qXtFtGCPF_QBobeDaBBfabKkIU8Xhn8wM5DbrPa5XSEDyy2b. 8JWe.gskrlq6hdlY9QIFCIe5ZGnjffZhCQg.lC7er9pCI1ysXULTc9sAuxuA 9cJNcRKTLlPqCt8Nb8gt.Q38ByFXyxlKewkZY9nsFabPcrXuWq_6N0_n9CTn KT8h_BNZvgSoBA6Brg_ZmHaV88UUatFNeYAsJHta5ot1F7J2E_RmtgpFFnOr F2BnNJJaREHxz7xWDMouAbVKOWT7_JS3EaaFYB6fuuE5z2.SScFvSee2RFU9 gaJ7I10DnyjFrIKfvI1Sf6rHGzMmgCuJ23HFxTpKJkkrK4ANIXGzuioZd2hT BD4tvpBlodnGrwfE8ERm6NLR4bvrJ5hXTXgBPaUY6E4K7sNbrqfLjxDxe_ep _OnT5D6Ui9r9rVzWyxUNUQ6C2Y_RMITr_fidaCIqVfkmQ66mHgi0ok2ZPDr9 xwFeuLfLTf6MqAFzPtuxvYLpBxshM.IjwgHJoODlRzP4bEZy3QYSn2kp9nLj owS0o_jtvdySK5sfo9tZvU9ybwuFhSQ3ghzso0nF0egcezsMNVjEdP2EPIUW ns85h1OracuPYQkKpeEVSByM0h2Vhx7_wxNr6cv0a0iPir578MBuVN6Wctlb J1FoK4L5fvXO3TI8HeZn4MqkymugO3xrJ_QoXmIfDSX.p7XNRdAVYAqV.m7c h5Soe07pPJ3l5jd3m2FICGSg5J7ieQOkuDN3CRXv_iG_dSHoNd.We5WCze5W jWc5TWDagKi4C9nh9SN3BajdCevauJVwjGg-- Received: from [50.201.233.2] by web125503.mail.ne1.yahoo.com via HTTP; Tue, 17 Sep 2013 12:19:07 PDT X-Rocket-MIMEInfo: 002.001, SSd2ZSB1cGxvYWRlZCBhIGRyYWZ0IG9uIHRscyBzdHJvbmcgYXV0aGVudGljYXRpb24gZGVwbG95bWVudDoKwqAKaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYWxicmFpbi10bHMtc3Ryb25nLWF1dGhlbnRpY2F0aW9uCkFueSBjb21tZW50cyB3b3VsZCBiZSBhcHByZWNpYXRlZC4KwqAgCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPgpUbzogPUplZmZIIDxKZWZmLkhvZGdlc0BLaW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> Message-ID: <1379445547.56870.YahooMailNeo@web125503.mail.ne1.yahoo.com> Date: Tue, 17 Sep 2013 12:19:07 -0700 (PDT) From: Karl Malbrain To: Stephen Farrell In-Reply-To: <52381C78.8090504@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2005986409-1490859369-1379445547=:56870" Cc: perpass Subject: Re: [perpass] tld strong authentication deployment draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 19:19:15 -0000 ---2005986409-1490859369-1379445547=:56870 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've uploaded a draft on tls strong authentication deployment:=0A=A0=0Ahttp= ://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication=0AAny = comments would be appreciated.=0A=A0 =0A=0A________________________________= =0A From: Stephen Farrell =0ATo: =3DJeffH =0ACc: perpass =0ASent: Tuesda= y, September 17, 2013 2:10 AM=0ASubject: Re: [perpass] rough list of concre= te stuff from list=0A =0A=0A=0AHi Jeff,=0A=0AOn 09/17/2013 02:45 AM, =3DJe= ffH wrote:=0A> Here's some items not as yet on the "rough list of concrete = stuff"=0A> AFAICT, which perhaps should be, at least from a completeness=0A= > perspective (YMMV)...=0A=0AMaybe I need to clarify: I put stuff on that l= ist where I=0Afelt happy that I understood how the end result in the=0AIETF= might look. Its not meant to be a complete list of=0Arelevant stuff, nor m= ost important stuff, just the stuff=0Athat's already concrete enough that i= f it did end up in=0Aan RFC, I reckon I understand more-or-less what'd be i= n=0Athat and how we might get it done.=0A=0ABut those links do certainly lo= ok relevant and it'd be=0Agood to see some discussion of them (in new threa= ds=0Aplease).=0A=0AI'll start one thread in a minute on tcpcrypt.=0A=0AChee= rs,=0AS.=0A=0A> =0A> Background/Requirements/Opportunities..=0A> =0A> Adam = Langley, 2009, W2SP. "Opportunistic Encryption Everywhere". W2SP.=0A> http:= //w2spconf.com/2009/papers/s1p2.pdf=0A> =0A> Andrea Bittau, et al. (2010-08= -13). "The case for ubiquitous=0A> transport-level encryption". 19th USENIX= Security Symposium.=0A> http://www.usenix.org/events/sec10/tech/full_paper= s/Bittau.pdf=0A> =0A> Opportunistic encryption (has list of various applica= ble projects)=0A> http://en.wikipedia.org/wiki/Opportunistic_encryption=0A>= =0A> Linux FreeS/WAN Project - Opportunistic Encryption=0A> Henry Spencer,= D. Hugh Redelmeier.=0A> http://www.freeswan.org/freeswan_trees/freeswan-1.= 91/doc/opportunism.spec=0A> =0A> =0A> =0A> examples..=0A> =0A> tcpcrypt=0A>= http://en.wikipedia.org/wiki/Tcpcrypt=0A> https://tools.ietf.org/html/draf= t-bittau-tcp-crypt-03=0A> =0A> =0A> Obfuscated TCP=0A> http://en.wikipedia.= org/wiki/Obfuscated_TCP=0A> =0A> [tcpm] Faster application handshakes with = SYN/ACK payloads=0A> http://www.ietf.org/mail-archive/web/tcpm/current/msg0= 3829.html=0A> http://tools.ietf.org/html/draft-agl-tcpm-sadata-01=0A> =0A> = IETF rejects Obfuscated TCP=A0 (email thread on tcpm@)=0A> http://comments.= gmane.org/gmane.network.peer-to-peer.p2p-hackers/2099=0A> =0A> =0A> freeS/W= AN, Openswan, Libreswan et al.=0A> http://en.wikipedia.org/wiki/FreeS/WAN= =0A> =0A> =0A> =0A> =0A> HTH,=0A> =0A> =3DJeffH=0A> _______________________= ________________________=0A> perpass mailing list=0A> perpass@ietf.org=0A> = https://www.ietf.org/mailman/listinfo/perpass=0A> =0A______________________= _________________________=0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps= ://www.ietf.org/mailman/listinfo/perpass ---2005986409-1490859369-1379445547=:56870 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've uploa= ded a draft on tls strong authentication deployment:
 
Any comments wo= uld be appreciated.
 
From: Stephen= Farrell <stephen.farrell@cs.tcd.ie>
Cc: perpass <perpass@ietf.org&= gt;
Sent: Tuesday, Se= ptember 17, 2013 2:10 AM
Subject:= Re: [perpass] rough list of concrete stuff from list


Hi Jeff,

On 09/17/20= 13 02:45 AM, =3DJeffH wrote:
> Here's some items not as yet on the "r= ough list of concrete stuff"
> AFAICT, which perhaps should be, at le= ast from a completeness
> perspective (YMMV)...

Maybe I need t= o clarify: I put stuff on that list where I
felt happy that I understood= how the end result in the
IETF might look. Its not meant to be a comple= te list of
relevant stuff, nor most important stuff, just the stuff
t= hat's already concrete enough that if it did end up in
an RFC, I reckon I und= erstand more-or-less what'd be in
that and how we might get it done.
=
But those links do certainly look relevant and it'd be
good to see s= ome discussion of them (in new threads
please).

I'll start one th= read in a minute on tcpcrypt.

Cheers,
S.

>
> Bac= kground/Requirements/Opportunities..
>
> Adam Langley, 2009, W= 2SP. "Opportunistic Encryption Everywhere". W2SP.
> http://w2spconf.com/2= 009/papers/s1p2.pdf
>
> Andrea Bittau, et al. (2010-08-13)= . "The case for ubiquitous
> transport-level encryption". 19th USENIX= Security Symposium.
> http://www.usenix.org/events= /sec10/tech/full_papers/Bittau.pdf
>
> Opportunistic encryption (has list of various applicable projects)
> http= ://en.wikipedia.org/wiki/Opportunistic_encryption
>
> Linu= x FreeS/WAN Project - Opportunistic Encryption
> Henry Spencer, D. Hu= gh Redelmeier.
> http://www.freeswan.org= /freeswan_trees/freeswan-1.91/doc/opportunism.spec
>
> >
> examples..
>
> tcpcrypt
> http://en.wikipedia.or= g/wiki/Tcpcrypt
> https://tools.ietf.org/html/draft-bitt= au-tcp-crypt-03
>
>
> Obfuscated TCP
> http://en.wikipedia.org/wiki/Obfuscated_TCP
> =
> [tcpm] Faster application handshakes with SYN/ACK payloads
>= http://www.ietf.org/mail-archive/web/tcpm/current/msg03= 829.html
> http://tools.ietf.org/html/draft-agl-tcpm-sadat= a-01
>
> IETF rejects Obfuscated TCP  (email thread o= n tcpm@)
> http://comments.gmane.org/gmane.n= etwork.peer-to-peer.p2p-hackers/2099
>
>
> freeS/WA= N, Openswan, Libreswan et al.
> http://en.wikipedia.org/wiki/FreeS/WAN<= br>>
>
>
>
> HTH,
>
> =3DJeffH<= br>> _______________________________________________
> perpass mailing li= st
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo= /perpass
>
_______________________________________________perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman= /listinfo/perpass


---2005986409-1490859369-1379445547=:56870-- From jmg@h2.funkthat.com Tue Sep 17 09:38:22 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133F711E82B8 for ; Tue, 17 Sep 2013 09:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsyMZarGWefZ for ; Tue, 17 Sep 2013 09:38:17 -0700 (PDT) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by ietfa.amsl.com (Postfix) with ESMTP id DA9C211E810B for ; Tue, 17 Sep 2013 09:38:16 -0700 (PDT) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r8HGcASG096273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 09:38:11 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r8HGcAQ7096272; Tue, 17 Sep 2013 09:38:10 -0700 (PDT) (envelope-from jmg) Date: Tue, 17 Sep 2013 09:38:10 -0700 From: John-Mark Gurney To: Watson Ladd Message-ID: <20130917163810.GM68682@funkthat.com> References: <52381D13.2010604@cs.tcd.ie> <52381DB6.1030200@cs.tcd.ie> <1379415967.11685.22973261.14E5A5B4@webmail.messagingengine.com> <20130917161331.47daed82@quill> <1379434179.362.23091425.0AF3B413@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 17 Sep 2013 09:38:11 -0700 (PDT) Cc: Mark Handley , perpass@ietf.org Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 20:15:52 -0000 Watson Ladd wrote this message on Tue, Sep 17, 2013 at 09:23 -0700: > On Tue, Sep 17, 2013 at 9:09 AM, Mark Handley wrote: > > > > On Tue, Sep 17, 2013, at 07:13 AM, Norbert Bollow wrote: > >> Mark Handley wrote: > >> > >> > The key reason for an approach at this layer in the stack is that it > >> > gets you the most bang for the buck. By leveraging the TCP handshake, > >> > you can get sessions encypted very easily with minimal infrastructure > >> > deployment, and only a single change to the stack. > >> > >> I've tried to find (in the draft or in the paper) information on the > >> server's entropy consumption, and the practical consequences. > >> > >> Can entropy generation become performance-limiting on servers that > >> receive a lot of connection requests? > >> > >> What kind of source of randomness did you use in the experiments? > > > > That is a good question. I don't know what Andrea's implementation > > currently does. > > > We could require the client supplies another random (encrypted) nonce > > right after the key exchange. This would be sufficient to top up the > > entropy pool in the presence of a passive eavesdropper, assuming entropy > > generation is easier at the client. An active attacker could try to > > deplete this entropy source by making a lot of connections and sending > > known values of this nonce, but they'd have to drown out all the > > legitimate clients, which would be difficult on a busy server, and would > > likely reveal the presence of the attack. And they'd need to combine > > this with eavesdropping very close to the server, or all they'd do is > > add randomness to the pool from their packet arrival times. > > Exhibit A of why we need mathematicians on this list. The difference > between AES in counter mode and > actually random numbers is miniscule. Any server has enough entropy to > reseed say once a second, which will be fine for > less than 2^64 connections per second. Please, check what /dev/urandom > actually does, and what actual cryptographers say > about generating random numbers in practice. Also, the randomness is only needed when a new client connects or we decide to rekey an existing host. A single host can connect many additional times w/o requiring additional entropy. It does look like there cannot be a DoS attack against the entropy pool as the sever doesn't need to generate N_S until the client has responded to PKCONF and they must response w/ the proper ACKCOOKIE if the server provided a SYNCOOKIE in the PKCONF packet. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From dean.willis@softarmor.com Tue Sep 17 16:39:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED74B11E8638 for ; Tue, 17 Sep 2013 16:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7lxATxv-icL for ; Tue, 17 Sep 2013 16:39:49 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2F01311E8637 for ; Tue, 17 Sep 2013 16:39:45 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id v1so3049125yhn.39 for ; Tue, 17 Sep 2013 16:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=PcK71AuOdZkthYayD/IGPUFhI9X35ybeEe9rc5OfykY=; b=FbysPJdtsOT03FZW5eKR49Z/HswbYMwFcJWxlxcXATbuXYH1+4aehUuGT4yRZgjg4a aR1eWlywk6Fn9Z59UZzoo+bhAKz0Gtng5Se16ygJdYW1VS4wowBd1AKuvBKdk89YZQNS EomQ4QnrgegU6LB3noNwCzAFzYi1tKhnI0Aj0= 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:message-id:references:to; bh=PcK71AuOdZkthYayD/IGPUFhI9X35ybeEe9rc5OfykY=; b=JPLzJtUCmWtsfVJ5Lxoo4+Cc7YAEdWPccnjqLm/vzcURVYkL6X1fw6C1ENzcfLg3BZ lUdI0lLfcBkvUFWNV2v0hF4d3obpNimpd+4XkolQ4BSAwEKmIjUg8LFewgOOqHlLqyev QpphabnxTS9FfKICotNOlQsJYVWecoMe4KvNO9XcaPwBalT7hpVd9VeUBO2vUC+pVK+I ioxCMLJD/eapblEgg+gr33sV2gsoeLjhfVCWowKclcIPzvdlKFK1u15TU3wQj3epm4WD xOh3ZKbpIRJ0aWlFDfvPghlgoJS/PRagDPrrKlL7EV+Kly1u5dSe3X9WwN+6SEFcUW0n JiBg== X-Gm-Message-State: ALoCoQmzVI8T6MvgJ3OpgFxSAFfb+NAPZsJjds7gt3718Fe6lOOpA/WqbLjmSYHnQ5QzFVVImgnC X-Received: by 10.236.148.138 with SMTP id v10mr39017341yhj.27.1379461185513; Tue, 17 Sep 2013 16:39:45 -0700 (PDT) Received: from [192.168.2.112] (cpe-72-181-157-19.tx.res.rr.com. [72.181.157.19]) by mx.google.com with ESMTPSA id x29sm49992807yhd.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 16:39:44 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_CA52565E-D937-436B-AA77-892BDB2238E5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dean Willis In-Reply-To: <52381D13.2010604@cs.tcd.ie> Date: Tue, 17 Sep 2013 18:39:42 -0500 Message-Id: <9AA989B6-A3E6-43E7-B560-B430D51CF441@softarmor.com> References: <52381D13.2010604@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: perpass Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 23:39:50 -0000 --Apple-Mail=_CA52565E-D937-436B-AA77-892BDB2238E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 17, 2013, at 4:12 AM, Stephen Farrell = wrote: >=20 > Hi, >=20 > Jeff raised tcpcrypt [1] in his earlier email. I personally thought tcpcrypt was an awesome idea. It was, IIRC, "down = talked" by some of the people who have been more instrumental in = blocking other solid security suggestions, like zRTP. Possibly even for = technical reasons, but that's a debate worth reliving. Perhaps we could also consider a "policy" level of document, perhaps a = BCP, that sets high goals for security and surveillance resistance in = all new work. A formal declaration that fundamental security IS a = priority, that protocols lacking it "harm the Internet" just as badly = as those lacking congestion control. -- Dean --Apple-Mail=_CA52565E-D937-436B-AA77-892BDB2238E5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJSOOg+AAoJENG95ttGtcqrC4kP/RboBoLKXRoUYsaFNgg4XRZo rIWTvkGZMJYn8hYQqbnrnoxinernpWp1sncbXimcHyPGpFLabw8p5GyKBvVbZcMr aUUV99D4waNrT/BYVVs6HUQGkNFUt3f7uyKjCbgpvlbM4MzeHnXF2TUADlmG1EkZ zST45KAAI22Ju0n8V+QVFnCwzhXxFzB81zQRYVgNNQGZPDHhY6mFvFo3eXrLY+KV Bwvv8O43r+jPvSAieUN9OiJQu+xkyZqK02enQ68wRMtj/iC1wIQH0oEDrxUcMMgX dpTw2iXb2lNW1gUeWp0Ge03sXuArqY2HEVQx+cYyPcfzQBTB9hU0UsbhPh4OMe2a TTCX5QNmX50w0e8LEpGfP5i4Xd5H0ecUURb+12VbwVXHDCkKCfofUi7u8y3Ozpvy Wxnc7A272kjU99X20EOuuZWkrVp0U8B1e05n1bk0gBrSBxDd1UiDSXEhQkTsxSWU D2tcbGkc+FmMYIH0vkTh9kpvY1n7nxIsPXddBwQ3nfbOAE9idhN900LC2H8raIEQ kvc8JacyIAZ3IP+4XbYIU42S9rklQVCmngZQsKD/u41Qr7R+jhyrHiKx4PNzyCFj bhQQX3AmZL4pyGVLUpd/oQKic/H0f0gdLs/+qjC1PAidZ5TSn3a/y7fIQ9GPNCoe EQ+k7d7i0ehU7ev9G5v1 =sx60 -----END PGP SIGNATURE----- --Apple-Mail=_CA52565E-D937-436B-AA77-892BDB2238E5-- From trammell@tik.ee.ethz.ch Tue Sep 17 22:56:50 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08BA11E8129 for ; Tue, 17 Sep 2013 22:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1rLYg3Km3xm for ; Tue, 17 Sep 2013 22:56:44 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AF52B11E811A for ; Tue, 17 Sep 2013 22:56:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 72EE5D930B; Wed, 18 Sep 2013 07:56:42 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DklA35W6w6-S; Wed, 18 Sep 2013 07:56:42 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 13A10D930A; Wed, 18 Sep 2013 07:56:42 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_E0ABFBCE-1584-463D-B431-D5DAF5B275B5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <9AA989B6-A3E6-43E7-B560-B430D51CF441@softarmor.com> Date: Wed, 18 Sep 2013 07:56:41 +0200 Message-Id: References: <52381D13.2010604@cs.tcd.ie> <9AA989B6-A3E6-43E7-B560-B430D51CF441@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1508) Cc: perpass , Stephen Farrell Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 05:56:50 -0000 --Apple-Mail=_E0ABFBCE-1584-463D-B431-D5DAF5B275B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 18, 2013, at 1:39 AM, Dean Willis = wrote: >=20 > On Sep 17, 2013, at 4:12 AM, Stephen Farrell = wrote: >=20 >>=20 >> Hi, >>=20 >> Jeff raised tcpcrypt [1] in his earlier email. >=20 > I personally thought tcpcrypt was an awesome idea. It was, IIRC, "down = talked" by some of the people who have been more instrumental in = blocking other solid security suggestions, like zRTP. Possibly even for = technical reasons, but that's a debate worth reliving. +1. In doing so, we should also make sure that either the mechanism is = applicable to alternate transports under consideration for the HTTP/2 = effort, or that those transports have equivalent mechanisms for = opportunistic encryption. > Perhaps we could also consider a "policy" level of document, perhaps a = BCP, that sets high goals for security and surveillance resistance in = all new work. A formal declaration that fundamental security IS a = priority, that protocols lacking it "harm the Internet" just as badly = as those lacking congestion control. +n. IMO, this would be an update of RFC 2804, which would say in effect = "remember when we said it's not okay for us to work on protocols that = allow through their design the surveillance of targeted parties (point 4 = of the wiretapping definition in section 3: "...when the third party = acts deliberately to target the transmission of the first party, either = because he is of interest, or because the second party's reception is of = interest")? it's also not okay in the case that everyone is a target." (I was about to say we could just strike point 4 from the definition = there, but in the interests of pedantry we should probably rework the = definition, since one could say that points 1 and 2 don't hold in the = case of pervasive passive surveillance, since = post-Snowden/Poitras/Greenwald, everyone has a reasonable suspicion that = everything which can be delivered to any third party by any means = available.) Cheers, Brian --Apple-Mail=_E0ABFBCE-1584-463D-B431-D5DAF5B275B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSOUCZAAoJENt3nsOmbNJc3hcH+QFEVUmcIwRlrHuebcer0udY 2iO33GKJqTZCZg5kAsVjxfrBOEld5rNhMpI5E85yNXYDZva1jjMhRjOQm01BB5Tg iwsnhunT/i08ZsOlxz0V/WkOBoYR9yrXzN2Bg/mUTlo7UEX6cLZpgw0yVu1yoyQA DKnE4tHNFIk6NkH08zZ8W+5ipqxILfplVmjr/o3Lwy3mlQyXiOCyjtdjrnJf0Dnx 9nuIfTeY5Se46t5057j3CpA8MlVD11PcTiKiJ+W/21xEbCEphITUzwtoXUq/ZtMc CVHD2bXpPxeZxs/4i0Z1bKTRPBYadJawV9XKC6RwAHOZUzFU96XJZ2XOSutAN7E= =uZ5/ -----END PGP SIGNATURE----- --Apple-Mail=_E0ABFBCE-1584-463D-B431-D5DAF5B275B5-- From karl@petzent.com Wed Sep 18 10:55:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CE611E80A2 for ; Wed, 18 Sep 2013 10:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.841 X-Spam-Level: X-Spam-Status: No, score=0.841 tagged_above=-999 required=5 tests=[AWL=0.922, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDDbBfYJGUKN for ; Wed, 18 Sep 2013 10:55:39 -0700 (PDT) Received: from mail.petzent.com (50-201-233-2-static.hfc.comcastbusiness.net [50.201.233.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F44111E80E4 for ; Wed, 18 Sep 2013 10:55:38 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 18 Sep 2013 10:55:44 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Wed, 18 Sep 2013 10:55:45 -0700 From: Karl Malbrain To: "Stephen Farrell (stephen.farrell@cs.tcd.ie)" Thread-Topic: [perpass] proposed 'Authentication' layer built on tcpcrypt Thread-Index: Ac60mEtQ3m7+gt7VRKOGzS5G1/L1UA== Date: Wed, 18 Sep 2013 17:55:45 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E837480F588D5@mail2010> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E837480F588D5mail2010_" MIME-Version: 1.0 Cc: "perpass@ietf.org" Subject: [perpass] proposed 'Authentication' layer built on tcpcrypt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 17:55:45 -0000 --_000_65EEC6E375AA474A847D510D5B7E837480F588D5mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With the introduction of tcpcrypt to handle channel encryption, we have the= opportunity to define a new standard PKI "authentication" layer. This wou= ld leave user authentication via account & password as it is now at the app= lication layer, while authenticating for ALL applications the user via his = public/private key pair. The authentication layer should not use certificat= e signing. Karl Malbrain --_000_65EEC6E375AA474A847D510D5B7E837480F588D5mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

With the introduction of tcpcrypt to handle channel = encryption, we have the opportunity to define a new standard PKI “aut= hentication” layer.  This would leave user authentication via ac= count & password as it is now at the application layer, while authenticating for ALL applications the user via his public/private = key pair. The authentication layer should not use certificate signing.=

 

Karl Malbrain

 

 

 

--_000_65EEC6E375AA474A847D510D5B7E837480F588D5mail2010_-- From Jeff.Hodges@KingsMountain.com Wed Sep 18 12:44:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A573C21F8F4A for ; Wed, 18 Sep 2013 12:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.313 X-Spam-Level: X-Spam-Status: No, score=-100.313 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctkqK-tNyGs2 for ; Wed, 18 Sep 2013 12:44:05 -0700 (PDT) Received: from oproxy7-pub.mail.unifiedlayer.com (oproxy7-pub.mail.unifiedlayer.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id C258F21F9935 for ; Wed, 18 Sep 2013 12:43:53 -0700 (PDT) Received: (qmail 22682 invoked by uid 0); 18 Sep 2013 19:43:32 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.mail.unifiedlayer.com with SMTP; 18 Sep 2013 19:43:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=sj++TgfABU6l0zK4SKDhnhawrZTyi07IzNrffi91nTM=; b=eHGVWEoxTlmGDBF2luPanu00F+TuZMmt5tr9+dNgHv8djLQ7dqcatgi23zS1Exav56GjZ0Cg+Ixd5MU1MuvlfSO0N4vnY53FXY56pdSwXp0bveKdAwDauE9nY5tZN/YB; Received: from [24.4.122.173] (port=38896 helo=[192.168.11.14]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VMNeu-0006Y3-3M; Wed, 18 Sep 2013 13:43:32 -0600 Message-ID: <523A0263.7060705@KingsMountain.com> Date: Wed, 18 Sep 2013 12:43:31 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: perpass Subject: Re: [perpass] rough list of concrete stuff from list X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 19:44:10 -0000 > Maybe I need to clarify: I put stuff on that list where I "that list" meaning [1,2] (to be a pedant here) > felt happy that I understood how the end result in the > IETF might look. Its not meant to be a complete list of > relevant stuff, nor most important stuff, just the stuff > that's already concrete enough that if it did end up in > an RFC, I reckon I understand more-or-less what'd be in > that and how we might get it done. just to clarify my intent/methodology, I sent those item to at least get them ensconced in the perpass@ mailing list archive in a relevant thread, whether or not they ended up on [1,2]. And just to note also for the record that several of such extant or historic projects do have at least a relevant internet-draft(s), and there's also RFC4322 in freeS/WAN et al's case. HTH, =JeffH [1] https://down.dsg.cs.tcd.ie/misc/perpass.txt [2] http://down.dsg.cs.tcd.ie/misc/perpass.txt From hannes.tschofenig@gmx.net Thu Sep 19 08:59:57 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA65321F8DA3 for ; Thu, 19 Sep 2013 08:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.93 X-Spam-Level: X-Spam-Status: No, score=-101.93 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKfxAOau5qK9 for ; Thu, 19 Sep 2013 08:59:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4E30721F8F24 for ; Thu, 19 Sep 2013 08:59:33 -0700 (PDT) Received: from [10.255.130.67] ([194.251.119.201]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M9wrU-1VBiHi1VZw-00B2Jh for ; Thu, 19 Sep 2013 17:59:22 +0200 Message-ID: <523B1F4F.9050301@gmx.net> Date: Thu, 19 Sep 2013 18:59:11 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: perpass Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ZKAU3S1fbrbxhsTm891MhXgQPYTcl7zOBOrEX0djC7hKcLGhh1M 6UrWPidyUsUSISrgGm1lF+z/I3ufluRzbl/NlqDhMpgrXn+OiZVgodWTgaSFBG+MbesQDV/ E9OwBDKG7I5KsmDwR9DVFHclDQucyLZpLrCjcWXlrrXSR9R1F9aKJBI3PzL3BDmJPPJ7euG j5AOQ70hEGBIxTQjcztNQ== Cc: hannes.tschofenig@gmx.net Subject: [perpass] draft-ietf-avt-srtp-not-mandatory: Is this a good document to publish? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:59:58 -0000 Hi all, I just ran into this document recently and I am wondering (in light of the recent discussions) whether this is a good document to publish: Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution draft-ietf-avt-srtp-not-mandatory-13.txt Abstract This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture. http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-13 I am wondering whether we do ourselves a favor with trying to justify the situation and whether there is a chance to fix the problem, at least on the specification side. Ciao Hannes From stephen.farrell@cs.tcd.ie Thu Sep 19 09:59:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B5621F93D4 for ; Thu, 19 Sep 2013 09:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UlKyAErGGhj for ; Thu, 19 Sep 2013 09:59:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A265F21F93F3 for ; Thu, 19 Sep 2013 09:59:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BBEABBE80; Thu, 19 Sep 2013 17:59:52 +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 3etcIhRNa-Ag; Thu, 19 Sep 2013 17:59:52 +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 96855BE79; Thu, 19 Sep 2013 17:59:52 +0100 (IST) Message-ID: <523B2D89.8070001@cs.tcd.ie> Date: Thu, 19 Sep 2013 17:59:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hannes Tschofenig References: <523B1F4F.9050301@gmx.net> In-Reply-To: <523B1F4F.9050301@gmx.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] draft-ietf-avt-srtp-not-mandatory: Is this a good document to publish? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:59:59 -0000 Hiya, That one's been the topic of extended discussions between more than one generation of SEC ADs and authors/wg chairs. (History at [1].) It has a companion document [2] that is intended to lay out the available options. (That one is less mature, or was last I looked.) I think to an extent the filename for that draft is no longer accurate, (it used to be), and its not as scary as it seems - the title is now much closer to what its about, so I hope the current content is actually ok, but comments on the content are welcome (and ought be directed to the avtcore wg [3]). To an extent, there is a bit of a mess, with the zoo of RTP profiles and applications all differing wildly to the extent that it is hard to see how one set of strong security mechanisms could be used. I haven't thought at all about whether the new threat model we're discussing here ought change our position on this one. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/history/ [2] http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-03 [3] https://datatracker.ietf.org/wg/avtcore/ On 09/19/2013 04:59 PM, Hannes Tschofenig wrote: > Hi all, > > I just ran into this document recently and I am wondering (in light of > the recent discussions) whether this is a good document to publish: > > Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single > Media Security Solution > draft-ietf-avt-srtp-not-mandatory-13.txt > > Abstract > > This memo discusses the problem of securing real-time multimedia > sessions, and explains why the Real-time Transport Protocol (RTP), > and the associated RTP control protocol (RTCP), do not mandate a > single media security mechanism. Guidelines for designers and > reviewers of future RTP extensions are provided, to ensure that > appropriate security mechanisms are mandated, and that any such > mechanisms are specified in a manner that conforms with the RTP > architecture. > > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-13 > > I am wondering whether we do ourselves a favor with trying to justify > the situation and whether there is a chance to fix the problem, at least > on the specification side. > > Ciao > Hannes > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From stephen.farrell@cs.tcd.ie Fri Sep 20 03:56:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2AC21F9371 for ; Fri, 20 Sep 2013 03:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjbewZ9SpOaF for ; Fri, 20 Sep 2013 03:56:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E1CF921F92CD for ; Fri, 20 Sep 2013 03:56:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E78C7BE5F; Fri, 20 Sep 2013 11:56:16 +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 prbe9dLPiAOD; Fri, 20 Sep 2013 11:56:16 +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 C6D4ABE58; Fri, 20 Sep 2013 11:56:16 +0100 (IST) Message-ID: <523C29D0.2060308@cs.tcd.ie> Date: Fri, 20 Sep 2013 11:56:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass References: <523BD51A.2080101@gmail.com> In-Reply-To: <523BD51A.2080101@gmail.com> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <523BD51A.2080101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brian E Carpenter Subject: [perpass] Fwd: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt] X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 10:56:23 -0000 Hi, I asked Brian if he'd try collate the recent discussions on ietf@ietf.org on this topic, and I think he's done a fine job on that. (Thanks again Brian.) This mail is mostly to get that recorded in this archive, but feel free to start new threads here on some of the topics noted in Brian's draft. Cheers, S. -------- Original Message -------- Subject: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt] Date: Fri, 20 Sep 2013 16:54:50 +1200 From: Brian E Carpenter Organization: University of Auckland To: IETF discussion list I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian -------- Original Message -------- Subject: I-D Action: draft-carpenter-prismatic-reflections-00.txt Date: Thu, 19 Sep 2013 21:47:18 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Prismatic Reflections Author(s) : Brian Carpenter Filename : draft-carpenter-prismatic-reflections-00.txt Pages : 9 Date : 2013-09-19 Abstract: Recent public disclosure of allegedly pervasive surveillance of Internet traffic has led to calls for action by the IETF. This draft exists solely to collect together a number of possible actions that were mentioned in a vigorous discussion on the IETF mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-prismatic-reflections There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-prismatic-reflections-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From karn@philkarn.net Fri Sep 20 07:50:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E25D21F9B35 for ; Fri, 20 Sep 2013 07:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9Hu32gHxJ7x for ; Fri, 20 Sep 2013 07:50:18 -0700 (PDT) Received: from homer.ka9q.net (homer.ka9q.net [75.60.237.89]) by ietfa.amsl.com (Postfix) with ESMTP id AF7A721F9B28 for ; Fri, 20 Sep 2013 07:50:15 -0700 (PDT) Received: from ip-64-134-136-120.public.wayport.net ([64.134.136.120] helo=[192.168.5.15]) by homer.ka9q.net with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VN228-0006Bm-9p; Fri, 20 Sep 2013 07:50:12 -0700 Message-ID: <523C6083.6020703@philkarn.net> Date: Fri, 20 Sep 2013 07:49:39 -0700 From: Phil Karn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: perpass@ietf.org References: <5224DF25.60503@cs.tcd.ie> <7C92613E-33E8-48A6-A152-E9DBB29DEC04@softarmor.com> <522A328A.5060008@cs.tcd.ie> <522E17F9.4000206@bbn.com> <522F685B.8040106@gmx.net> <20130910185544.GF29237@thunk.org> <5232D366.1000803@appelbaum.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Howdy! X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:50:24 -0000 On 09/13/2013 10:49 AM, Randy Bush wrote: > i might go further. having some protocols in the clear allows the > attacker to better focus their efforts on what is encrypted. also, > though some data themselves might not require privacy, the nature of > the conversation may facilitate traffic analysis. Yes. We've seen indications that the NSA stores all encrypted traffic for a rainy day, so the more chaff we can generate the sooner the NSA will have to look for new real estate in Utah. --Phil From benl@google.com Fri Sep 20 07:56:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1512A21F9B35 for ; Fri, 20 Sep 2013 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGcOtm5FaZ8y for ; Fri, 20 Sep 2013 07:56:33 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by ietfa.amsl.com (Postfix) with ESMTP id 95FA121F9A70 for ; Fri, 20 Sep 2013 07:56:30 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so1082887ieb.0 for ; Fri, 20 Sep 2013 07:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IjX8kyVSJ7k+O/SVqFLNLGwITp8FYd/X9oP0kG5Bd6Y=; b=c2ubt4UR8SWUIKDT+6xc//TGqCLAKWhzS2Simdmwnzlj3CJFJBJtxstEXSQq/R6nl+ eUvU5F33xnGb/8/vP2BN2nQNEaIxFkZcE6SnV9P2EO9HAAGd4jvjcFOyVq5OqwavIVHh 95dL7xh5L0Evt1vK8Ii1fTRHT7lrXz/wfRxQ68yGbayQw1GdbAHFJ2HrpToWnVIP8s2e suUvdcrFx7H5fgGxNmLNetA/qxrT3mKqt6xQYX494Q+BqFmD8yr7tM988NZG3sTHyJQL 4eRlosDoxP9iriLrDqeUKJ7yDrMdRblDD6Ztbs188nWAfUmin6lNsAtN43owXRznFPXG Cl7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IjX8kyVSJ7k+O/SVqFLNLGwITp8FYd/X9oP0kG5Bd6Y=; b=W+jTotzTul/AIitJXUe/36MpDQJMjjy6HpjTMtBCNZM+YPTXEEz/ylpZ/aZTjLzX+g wjQBZCCkUj+yf4lGEG2GPL35xPmY05QbZABi/Ve6HhJ0IFU0LqtOUssQv+89zvIYAs+w /6lOcMsulrZuuBJBXmpT4CQscnNaeCDCbCftbThQnTXnf09e5FoHZlpMg/Y0ifj49Rjn ql+cLIrjeyW6lTT2jmszfZ8/3/0QM4M7yOVJc8kUQ7CuPBh7rPb5RVeW3qRPRuph4ZD9 mTBJ2z8MxElMT/Qqw1fXNB/e+BDaCYlpTnhrUNeiAkdTZTkbdiI0w8dkz9bFgZ4J6KQ4 w1sw== X-Gm-Message-State: ALoCoQmAqiWC6PaTm8VORdEBK8NjA0jO3kkXgfF2BdS9LuHVZJa4R6nEWu0zPiIq9xdK3NdIk4/0kB0q3ypAyvCiG7blBbmK0KwRwnulLYuyMuRTNVvmuGXYJ3wN+GDYkPbJh6az3hWPeWrKnPPwIdQvhGCQzM4sR8cpkmEyGjdammWU50Wvau+cp6jUwSPKQzwRFUjMxcuT MIME-Version: 1.0 X-Received: by 10.42.97.71 with SMTP id m7mr2903789icn.33.1379688974685; Fri, 20 Sep 2013 07:56:14 -0700 (PDT) Received: by 10.64.230.140 with HTTP; Fri, 20 Sep 2013 07:56:14 -0700 (PDT) In-Reply-To: <523C29D0.2060308@cs.tcd.ie> References: <523BD51A.2080101@gmail.com> <523C29D0.2060308@cs.tcd.ie> Date: Fri, 20 Sep 2013 15:56:14 +0100 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Brian E Carpenter Subject: Re: [perpass] Fwd: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt] X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:56:40 -0000 FWIW, apropos of some of the points there, my team are shortly going to start looking at DNSSEC transparency. Also, I'd be very happy to work on transparency for email keys. On making S/MIME or PGP useful, the "last 5%" is: a) Probably rather more than that, and b) Not something the IETF usually gets involved in, namely UI/UX. But perhaps its time that changed? On 20 September 2013 11:56, Stephen Farrell wrote: > > Hi, > > I asked Brian if he'd try collate the recent discussions on > ietf@ietf.org on this topic, and I think he's done a fine > job on that. (Thanks again Brian.) > > This mail is mostly to get that recorded in this archive, > but feel free to start new threads here on some of the > topics noted in Brian's draft. > > Cheers, > S. > > > -------- Original Message -------- > Subject: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt] > Date: Fri, 20 Sep 2013 16:54:50 +1200 > From: Brian E Carpenter > Organization: University of Auckland > To: IETF discussion list > > I got my arm slightly twisted to produce the attached: a simple > concatenation of some of the actionable suggestions made in the > discussion of PRISM and Bruce Schneier's call for action. > > Brian > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-prismatic-reflections-00.txt > Date: Thu, 19 Sep 2013 21:47:18 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Prismatic Reflections > Author(s) : Brian Carpenter > Filename : draft-carpenter-prismatic-reflections-00.txt > Pages : 9 > Date : 2013-09-19 > > Abstract: > Recent public disclosure of allegedly pervasive surveillance of > Internet traffic has led to calls for action by the IETF. This draft > exists solely to collect together a number of possible actions that > were mentioned in a vigorous discussion on the IETF mailing list. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-carpenter-prismatic-reflections > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-carpenter-prismatic-reflections-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From stephen.farrell@cs.tcd.ie Fri Sep 20 09:37:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92CC21F9BF2 for ; Fri, 20 Sep 2013 09:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+FX6Pw5wotD for ; Fri, 20 Sep 2013 09:36:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 01D2321F992A for ; Fri, 20 Sep 2013 09:36:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6AD2CBE79 for ; Fri, 20 Sep 2013 17:36: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 O72Awk6SSnsC for ; Fri, 20 Sep 2013 17:36:56 +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 385DBBE50 for ; Fri, 20 Sep 2013 17:36:56 +0100 (IST) Message-ID: <523C79A8.5050902@cs.tcd.ie> Date: Fri, 20 Sep 2013 17:36:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass References: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> In-Reply-To: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] Fwd: New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 16:37:02 -0000 FYI. Comments welcome. S. -------- Original Message -------- Subject: New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt Date: Fri, 20 Sep 2013 09:23:52 -0700 From: internet-drafts@ietf.org To: Alissa Cooper , Sean Turner , Stephen Farrell A new version of I-D, draft-cooper-ietf-privacy-requirements-00.txt has been successfully submitted by Alissa Cooper and posted to the IETF repository. Filename: draft-cooper-ietf-privacy-requirements Revision: 00 Title: Privacy Requirements for IETF Protocols Creation date: 2013-09-20 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-cooper-ietf-privacy-requirements-00.txt Status: http://datatracker.ietf.org/doc/draft-cooper-ietf-privacy-requirements Htmlized: http://tools.ietf.org/html/draft-cooper-ietf-privacy-requirements-00 Abstract: It is the consensus of the IETF that IETF protocols be designed to avoid privacy violations to the extent possible. This document establishes a number of protocol design choices as Best Current Practices for the purpose of avoiding such violations. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From karl@petzent.com Fri Sep 20 11:50:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB5B21F9D95 for ; Fri, 20 Sep 2013 11:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.718 X-Spam-Level: X-Spam-Status: No, score=0.718 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7omGih-QG6yt for ; Fri, 20 Sep 2013 11:50:08 -0700 (PDT) Received: from mail.petzent.com (50-201-233-2-static.hfc.comcastbusiness.net [50.201.233.2]) by ietfa.amsl.com (Postfix) with ESMTP id 754B921F9AE6 for ; Fri, 20 Sep 2013 11:50:08 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Fri, 20 Sep 2013 11:50:17 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Fri, 20 Sep 2013 11:50:17 -0700 From: Karl Malbrain To: "stephen.farrell@cs.tcd.ie" , "acooper@cdt.org" Thread-Topic: RE: [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt Thread-Index: Ac62Mj0FsrS9no+ARXy8djDewUYepA== Date: Fri, 20 Sep 2013 18:50:17 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E837480F599D6@mail2010> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E837480F599D6mail2010_" MIME-Version: 1.0 Cc: "perpass@ietf.org" Subject: Re: [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 18:50:14 -0000 --_000_65EEC6E375AA474A847D510D5B7E837480F599D6mail2010_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Note that this is contingent on practicality - if some personal data really has to be sent in clear for a protocol to be able to operate, and even opportunistic encryption is not possible, then a standards- track protocol that does not define how to protect that data will be consistent with this BCP. The IETF will have to decide in such cases whether standardizing that protocol benefits the Internet or not." 1. Is the value of a personal public key considered "personal data"? In TL= S client authentication, these keys are requested. 2. Under the goal of MITM resistance, how can opportunistic encryption prov= ide security without authentication? I think that an authentication layer o= n top of opportunistic encryption is required. --_000_65EEC6E375AA474A847D510D5B7E837480F599D6mail2010_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

"Note that this is contingent on practicality -= if some personal data

   really has to be sent in clear for a pr= otocol to be able to operate,

   and even opportunistic encryption is no= t possible, then a standards-

   track protocol that does not define how= to protect that data will be

   consistent with this BCP.  The IET= F will have to decide in such cases

   whether standardizing that protocol ben= efits the Internet or not."

 

 

1. Is the value of a personal public key considered = "personal data"?  In TLS client authentication, these keys a= re requested.

 

 

2. Under the goal of MITM resistance, how can opport= unistic encryption provide security without authentication? I think that an= authentication layer on top of opportunistic encryption is required.<= /o:p>

 

--_000_65EEC6E375AA474A847D510D5B7E837480F599D6mail2010_-- From hallam@gmail.com Fri Sep 20 11:58:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15DD21F9D98 for ; Fri, 20 Sep 2013 11:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaiH0adDmFXk for ; Fri, 20 Sep 2013 11:58:59 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9762F21F9D95 for ; Fri, 20 Sep 2013 11:58:58 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id gx14so683855lab.9 for ; Fri, 20 Sep 2013 11:58:57 -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=vq2FkiEVZsQFEJqZPzgb6GCMnOYlhSRxQc/7PYRsi1Q=; b=jPC9CTrGZcYqJVQMCHnwn1kZWDFt1NW30FFqjtVO06cWw8RqVw12ZMZ4jUHu/X00cX UF/8NST8TxXcgV7mv0I1EHg6jMWg6OnvO2LfQV8SOCdP4bBfQlFEmW5jAb0o3MtKLqw1 IN3C9fooKa5bq/k2ZMOquQccHdLTw6oKf+zulTB7t38AEPS2ThxAZHlKd2qSwqWhgs8x KMqLXyzuPny2YcFhPfXKCEl8f/wst/Rey5cb2C7r+FNMZfzhbJ7CZzkrhhOom6sdxJq+ 4z7bZbQlaHTYlUTOHj0K7PsnG1DqAa/MIHJMERxTrIWDUUK7hduE08mpxzbllbhar5pr 6RVw== MIME-Version: 1.0 X-Received: by 10.112.129.163 with SMTP id nx3mr91733lbb.60.1379703537521; Fri, 20 Sep 2013 11:58:57 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 20 Sep 2013 11:58:57 -0700 (PDT) Date: Fri, 20 Sep 2013 14:58:57 -0400 Message-ID: From: Phillip Hallam-Baker To: perpass Content-Type: multipart/alternative; boundary=047d7b3a7f663fda0304e6d5433e Subject: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 18:58:59 -0000 --047d7b3a7f663fda0304e6d5433e Content-Type: text/plain; charset=ISO-8859-1 We need an email security infrastructure and recent events demonstrate that the infrastructure we develop needs to be proof against PRISM-class attacks. By PRISM-class I mean an attack that attempts pervasive surveillance with budgets in excess of $100 million rather than the PRISM program in particular. Neither OpenPGP nor S/MIME is capable of providing protection against this class of attack because they are not widely enough used. We can only hope for these to be useful if at least 5% of Internet users start sending mail securely. But while the legacy protocols are not sufficient, 95% of the existing work is fine and does not need to be repeated although there may be some details of execution that can be improved. The part that is going to need new research is in the area of trust models. As someone who has seen the documents said to me this week, given a choice between A and B, the NSA does both. We have to do the same. Rather than have a pointless argument about whether Web 'o Trust or PKIX is the way to go, let everyone do both. Let people get a certificate from a CA and then get it endorsed by their peers: belt and braces. The idea in this draft is to split up the problem space so that people who know email clients can write code to support any of the research ideas that might be proposed and any of the research ideas can be used with any of the mail clients that have been enabled. The draft is to be found at: http://www.ietf.org/id/draft-hallambaker-prismproof-dep-00.txt -- Website: http://hallambaker.com/ --047d7b3a7f663fda0304e6d5433e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We need an email security infrastructure and recent e= vents demonstrate that the infrastructure we develop needs to be proof agai= nst PRISM-class attacks.

By PRISM-class I mean an = attack that attempts pervasive surveillance with budgets in excess of $100 = million rather than the PRISM program in particular.

Neither OpenPGP nor S/MIME is capable of providing prot= ection against this class of attack because they are not widely enough used= . We can only hope for these to be useful if at least 5% of Internet users = start sending mail securely.

But while the legacy protocols are not sufficient, 95% = of the existing work is fine and does not need to be repeated although ther= e may be some details of execution that can be improved.

The part that is going to need new research is in the area of tr= ust models. As someone who has seen the documents said to me this week, giv= en a choice between A and B, the NSA does both. We have to do the same. Rat= her than have a pointless argument about whether Web 'o Trust or PKIX i= s the way to go, let everyone do both. Let people get a certificate from a = CA and then get it endorsed by their peers: belt and braces.

The idea in this draft is to split up the problem space= so that people who know email clients can write code to support any of the= research ideas that might be proposed and any of the research ideas can be= used with any of the mail clients that have been enabled.


The draft is to be found at:
<= br>
http://www.ietf.org/id/draft-hallambaker-prismproof-dep-00.txt=


--
Website: http://hallambaker.com/
--047d7b3a7f663fda0304e6d5433e-- From stephen.farrell@cs.tcd.ie Fri Sep 20 12:08:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7695C21F9D3B for ; Fri, 20 Sep 2013 12:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvdNAOnKeaIP for ; Fri, 20 Sep 2013 12:08:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6388E21F9D44 for ; Fri, 20 Sep 2013 12:08:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 300E5BE79; Fri, 20 Sep 2013 20:08:53 +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 tbFHZdOEb5G4; Fri, 20 Sep 2013 20:08:51 +0100 (IST) Received: from [10.87.48.3] (unknown [86.42.17.191]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0A757BE76; Fri, 20 Sep 2013 20:08:51 +0100 (IST) Message-ID: <523C9D42.9030409@cs.tcd.ie> Date: Fri, 20 Sep 2013 20:08:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Karl Malbrain References: <65EEC6E375AA474A847D510D5B7E837480F599D6@mail2010> In-Reply-To: <65EEC6E375AA474A847D510D5B7E837480F599D6@mail2010> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "perpass@ietf.org" , "acooper@cdt.org" Subject: Re: [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 19:08:59 -0000 On 09/20/2013 07:50 PM, Karl Malbrain wrote: > "Note that this is contingent on practicality - if some personal > data really has to be sent in clear for a protocol to be able to > operate, and even opportunistic encryption is not possible, then a > standards- track protocol that does not define how to protect that > data will be consistent with this BCP. The IETF will have to decide > in such cases whether standardizing that protocol benefits the > Internet or not." > > > 1. Is the value of a personal public key considered "personal data"? > In TLS client authentication, these keys are requested. I doubt there's any data-protection regulator views on that (TLS client-auth being so rare on the public Internet) but basically, I'd say yeah, its an identifier that generally won't change for extended periods. That's one of the motivations for doing TLS 1.3 - to hide such handshake data for example. > 2. Under the goal of MITM resistance, how can opportunistic > encryption provide security without authentication? I think that an > authentication layer on top of opportunistic encryption is required. I disagree. "Security" is not a binary state of affairs. Opportunistic encryption without authentication can provide some value, esp in this context where it forces a more active and presumably expensive and more likely detected attack if you want to pervasively monitor everyone. S. > > > > > _______________________________________________ perpass mailing list > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > From scott.brim@gmail.com Sat Sep 21 10:42:33 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B8611E8170 for ; Sat, 21 Sep 2013 10:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibwL4P6WFuTL for ; Sat, 21 Sep 2013 10:42:32 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id B980311E8173 for ; Sat, 21 Sep 2013 10:42:32 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id wn1so2053022obc.38 for ; Sat, 21 Sep 2013 10:42: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; bh=cxpi+l18MiA7SHaodXD+IvnKY+PccURuIStHY0GmJLY=; b=dNRH1vTpZa36y8i2tys1U6PTnhaxgi9oDE4S8p1QiqJ24rzTLYX/txzYZ9ENh+YrTC Pa1dUcXQkXDrGX61CktfZKvML8j+ifJHLsi/V2Ou83RZBW9xIRbv/U6geqhEW6jJKK3w rUiZ6Uyl7qbQhgDWsdDi3VYQ9nbLjITI8A5WyGk0GLWJcHHkJOv8UCFU5h3imDgf+jvl ImK7KJY8PYrnaDO3YV9bm6vGZ9s8q0uePBS5bXHrotxOHgcBi5YMZbp6csonIB3/3Vby th+Yd8LvDE4066rh2Kxzw69BRNZuaZ0WbGXJg4Cc7MdnRk8fK6MUrKzCq/m+UlBmZO06 A48w== MIME-Version: 1.0 X-Received: by 10.60.173.205 with SMTP id bm13mr11367901oec.25.1379785350239; Sat, 21 Sep 2013 10:42:30 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Sat, 21 Sep 2013 10:42:29 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Sat, 21 Sep 2013 10:42:29 -0700 (PDT) In-Reply-To: <523C9D42.9030409@cs.tcd.ie> References: <65EEC6E375AA474A847D510D5B7E837480F599D6@mail2010> <523C9D42.9030409@cs.tcd.ie> Date: Sat, 21 Sep 2013 13:42:29 -0400 Message-ID: From: Scott Brim To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e01160706aadc2304e6e84f71 Cc: perpass , Alissa Cooper , Karl Malbrain Subject: Re: [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 17:42:33 -0000 --089e01160706aadc2304e6e84f71 Content-Type: text/plain; charset=ISO-8859-1 On Sep 20, 2013 3:09 PM, "Stephen Farrell" wrote: > On 09/20/2013 07:50 PM, Karl Malbrain wrote: > > 1. Is the value of a personal public key considered "personal data"? > > In TLS client authentication, these keys are requested. > > I doubt there's any data-protection regulator views on that > (TLS client-auth being so rare on the public Internet) but > basically, I'd say yeah, its an identifier that generally won't > change for extended periods. That's one of the motivations > for doing TLS 1.3 - to hide such handshake data for example. If you are signing something then you are explicitly deciding to reveal the related information. You made the decision to release it into public view, so your privacy is not violated. You need to be doubly careful of other correlatable info. However, if you are not using a particular public key generally, but restricting its use, then yes it should be kept within the intended scope of confidentiality. Scott --089e01160706aadc2304e6e84f71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 20, 2013 3:09 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
> On 09/20/2013 07:50 PM, Karl Malbrain wrote:
> > 1. Is the value of a personal public key considered "persona= l data"?
> > In TLS client authentication, these keys are requested.
>
> I doubt there's any data-protection regulator views on that
> (TLS client-auth being so rare on the public Internet) but
> basically, I'd say yeah, its an identifier that generally won'= t
> change for extended periods. That's one of the motivations
> for doing TLS 1.3 - to hide such handshake data for example.

If you are signing something then you are explicitly decidin= g to reveal the related information. You made the decision to release it in= to public view, so your privacy is not violated. You need to be doubly care= ful of other correlatable info. However, if you are not using a particular = public key generally, but restricting its use, then yes it should be kept w= ithin the intended scope of confidentiality.

Scott

--089e01160706aadc2304e6e84f71-- From derhoermi@gmx.net Sun Sep 22 05:46:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0149921F9FCE for ; Sun, 22 Sep 2013 05:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_40=-0.185, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2+mcGwewDC8 for ; Sun, 22 Sep 2013 05:46:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id A276021F9FBF for ; Sun, 22 Sep 2013 05:46:21 -0700 (PDT) Received: from netb.Speedport_W_700V ([84.180.239.50]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0Meutp-1VYxTG121R-00OXbi for ; Sun, 22 Sep 2013 14:46:20 +0200 From: Bjoern Hoehrmann To: Phillip Hallam-Baker Date: Sun, 22 Sep 2013 14:46:18 +0200 Message-ID: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:emfVTg6+5ZF92JoRrjX83LsURNLT1XdEjZ+o+/VC5GqeWw3UoDC mwU1WrPP61IYIZeczeNCgXTmqq78eRY0eG3PJPtZ6oGIUO6036X4TkGg21QqEczJdAVP5/C UWs8Jqx8YcBWFy42EygJq+oCqyunShElQAjtP8HvQWSclNUWeReQXWwfvNKtROWSSOPNsaf QKWMaEycBZZaSXMAnV+iA== Cc: perpass Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 12:46:26 -0000 * Phillip Hallam-Baker wrote: >We need an email security infrastructure and recent events demonstrate that >the infrastructure we develop needs to be proof against PRISM-class attacks. >http://www.ietf.org/id/draft-hallambaker-prismproof-dep-00.txt The document is a bit of a mixed bag mixing analysis, requirements, pro- posals, and other things in a manner I find hard to follow. To turn this a bit around, if I wanted to create a secure email system, the first thing I would probably think about is scope. You mention "PRISM". If "PRISM" is some sort of "FAA 702" program, and that law seems to be [The] Attorney General and the Director of National Intelligence may direct, in writing, an electronic communication service provider to (A) immediately provide the Government with all information, facilities, or assistance necessary to accomplish the acquisition in a manner that will protect the secrecy of the acquisition and produce a minimum of interference with the services that such electronic communication service provider is providing to the target of the acquisition; ... one scenario I would think about two people with tablet computers that run the Acme tablet operating system and they are both using the Acme Web Mail system through the Acme browser and they are connected to the Internet over Acme Fibre. Now the United States want to read their mails to determine whether they or their associates need to be brought free- dom and democracy, and they tell Acme to make that happen using the law above. Is the system supposed to help the two exchange mails securely? Another scenario is that the supposedly secure email system relies on personal private long-term cryptographic secrets, and then the system becomes popular. How long before helpful cloud backup and cross device synchronisation systems compromise the keys? For that matter, how many will surrender the keys freely to their web mail system, for spam and virus checks, or a coupon? On Google's Android system you can get some cloud backup service, but only if you let Google have all "your" Wi-Fi passwords (which often aren't yours to share with Google). I also wonder whether active MITM attacks, where the bits on the wire are changed, are really much of a concern for such a system, compared perhaps to mass-scale passive eavesdropping; how important is being able to find out whether your conversations are being monitored? Another point is compatibility with the deployed email infrastructure. It seems rather trivial these days to establish new communication sys- tems to hundreds of millions of users; it's been done quite a number of times in recent years. It seems to disregarding the deployed protocol might make many desirable features available that are difficult to fit in with the existing system, like encrypting subject headers and local parts of addresses. Similarily, some features might be easy to let go of, asynchronous offline delivery for instance is less interesting in a always-on world. That is what comes to mind thinking about securing the email system and it is a bit of a long way from there to issues around web browsers ge- nerating cryptographic certificates or the merits of S/MIME. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From adam@adamcaudill.com Sun Sep 22 13:55:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CBB11E814C for ; Sun, 22 Sep 2013 13:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAaHCLCL4-gE for ; Sun, 22 Sep 2013 13:55:54 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A155111E814B for ; Sun, 22 Sep 2013 13:55:54 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id e14so4816622iej.24 for ; Sun, 22 Sep 2013 13:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamcaudill.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3rKMyI2VKvCILLitxq6QZ5mfSv82l2R8003nVvooHHw=; b=bprKKxMV0nXHNBBRrP+sVqR6yk4WcLp5vbd5Q+XsbzabsBejjg01SXoGIvnwqZro9Z E3v+Xmp2ce2sKy19GVVoFHtoZ/WW+6HqOW2ozWj1w8c0FpftHxovdb7qzBTMagzP/5XN 9YpoBtzBRsfq9hUCZHnSx5rZ8ofgMRkU58GqQ= 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:message-id:references:to; bh=3rKMyI2VKvCILLitxq6QZ5mfSv82l2R8003nVvooHHw=; b=Txmd5QqtWibbv76FTwn9Dwuzbj6+oJfayeRiOorzKoBwNtHLVXbND1idzIHAAJLP/4 7AJMVCzasdKKJCbDQ7cSTea4Fekk5AHi8/kGXNJdSZbbbLXzKervjTRK4iacTu54ziyd 7Cni9kT0GcEGulg1qpCWlCz65GRdqqQA87fX9Q9g8WCtxRDgF9TT/k9skFjCwiYLt64v tmJOH/0qpQiP+U6Yq9IpaUTH4zVMC2WkN+/Rvq56CV1AGOkKCjOd5NKQSBAf7tKmomXc 0uGwSoC5Jz4IFIQJ4pIraTBJfdPBvl/0hmPzxjYqRWStusIQe0YAjmApOK1Boq8oKKkO CC8w== X-Gm-Message-State: ALoCoQlnBBDJ7tScH3ojpIIetGvv7gqEn6gmaYv6TCwl45jMGh8TNPbDZBupiwM+skCo17ORzjur X-Received: by 10.42.250.201 with SMTP id mp9mr10906400icb.0.1379883353639; Sun, 22 Sep 2013 13:55:53 -0700 (PDT) Received: from [192.168.1.60] (mobile-166-147-103-182.mycingular.net. [166.147.103.182]) by mx.google.com with ESMTPSA id cl4sm9914837igc.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Sep 2013 13:55:52 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E26B1F42-3917-4DC8-BD66-E10454B70783"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Adam Caudill In-Reply-To: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> Date: Sun, 22 Sep 2013 16:55:49 -0400 Message-Id: <584C0F31-7B8E-476E-B65E-57F2C0315EAE@adamcaudill.com> References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1510) Cc: perpass , Phillip Hallam-Baker Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 20:55:55 -0000 --Apple-Mail=_E26B1F42-3917-4DC8-BD66-E10454B70783 Content-Type: multipart/alternative; boundary="Apple-Mail=_E5CF460E-002E-4CDB-BB41-73F42950BFC2" --Apple-Mail=_E5CF460E-002E-4CDB-BB41-73F42950BFC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 22, 2013, at 8:46 AM, Bjoern Hoehrmann wrote: > Another point is compatibility with the deployed email infrastructure. > It seems rather trivial these days to establish new communication sys- > tems to hundreds of millions of users; it's been done quite a number = of > times in recent years. It seems to disregarding the deployed protocol > might make many desirable features available that are difficult to fit > in with the existing system, like encrypting subject headers and local > parts of addresses. Similarily, some features might be easy to let go > of, asynchronous offline delivery for instance is less interesting in > a always-on world. As much as I dislike breaking compatibility with the existing = infrastructure, I think this might be necessary. I see three significant = issues trying to make this work in the current system: 1). As you mentioned, the difficulty of integrating these privacy = enhancing features in a system that wasn't designed with this in mind. = Building a new system with security and privacy as a primary goal would = minimize the compromises necessary to maintain compatibility with = current infrastructure. 2). Lack of user confidence / awareness. One of the issues I have with = the current email infrastructure is that as a user, I have no idea how = my messages are handled once they reach my SMTP server. Is SSL/TLS used = for the hop to the recipient's server? How about between the recipient = and their server? Are the servers actually validating the certificates? = Are they subject to a downgrade attack to force the data to be = transmitted in the clear? With this proposal - or likely any proposal to = update the current system, the user will remain unaware of this = information. This is one of the areas where browser developers have done (reasonably) = well, providing a visual cue indicating if the data is being protected; = while not necessarily perfect, it's far batter than what we have for = transport security in the email system. 3). Transition time. This likely would be a very long process - and as = per section 3.2, during the transition compatibility takes precedence = over security. Given how long this transition will take, it's possible = that these concessions will still be in play for a number of years to = come - opening gaps that could be used to enable PRISM like programs. If a new system is developed, it would be ideal if it was designed in = such a way that gateways could be deployed to provide a compatibility = layer with current infrastructure (of course messages traveling across = said gateways should trigger some form of alert to the user so they know = the security is likely to be reduced). --=20 Adam Caudill adam@adamcaudill.com http://adamcaudill.com/ --Apple-Mail=_E5CF460E-002E-4CDB-BB41-73F42950BFC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 derhoermi@gmx.net> = wrote:

Another point is compatibility = with the deployed email infrastructure.
It seems rather trivial these = days to establish new communication sys-
tems to hundreds of millions = of users; it's been done quite a number of
times in recent years. It = seems to disregarding the deployed protocol
might make many desirable = features available that are difficult to fit
in with the existing = system, like encrypting subject headers and local
parts of addresses. = Similarily, some features might be easy to let go
of, asynchronous = offline delivery for instance is less interesting in
a always-on = world.

As much as I dislike = breaking compatibility with the existing infrastructure, I think this = might be necessary. I see three significant issues trying to make this = work in the current system:

1). As you = mentioned, the difficulty of integrating these privacy enhancing = features in a system that wasn't designed with this in mind. Building a = new system with security and privacy as a primary goal would minimize = the compromises necessary to maintain compatibility with current = infrastructure.

2). Lack of user confidence / = awareness. One of the issues I have with the current email = infrastructure is that as a user, I have no idea how my messages are = handled once they reach my SMTP server. Is SSL/TLS used for the hop to = the recipient's server? How about between the recipient and their = server? Are the servers actually validating the certificates? Are they = subject to a downgrade attack to force the data to be transmitted in the = clear? With this proposal - or likely any proposal to update the current = system, the user will remain unaware of this = information.

This is one of the areas where = browser developers have done (reasonably) well, providing a visual cue = indicating if the data is being protected; while not necessarily = perfect, it's far batter than what we have for transport security in the = email system.

3). Transition time. This likely = would be a very long process - and as per section 3.2, during the = transition compatibility takes precedence over security. Given how long = this transition will take, it's possible that these concessions will = still be in play for a number of years to come - opening gaps that could = be used to enable PRISM like programs.

If a new = system is developed, it would be ideal if it was designed in such a way = that gateways could be deployed to provide a compatibility layer with = current infrastructure (of course messages traveling across said = gateways should trigger some form of alert to the user so they know the = security is likely to be reduced).

-- 
Adam = Caudill
adam@adamcaudill.com
http://ad= amcaudill.com/

= --Apple-Mail=_E5CF460E-002E-4CDB-BB41-73F42950BFC2-- --Apple-Mail=_E26B1F42-3917-4DC8-BD66-E10454B70783 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSP1lVAAoJENMzqGjemG5MTR4QAI7CRnrvI4VeIx7m0EKnLf+o bIutMGUgDs8f0dG4lz0U8RmvL5BQUlSU9uEV54EElDPbcMPAT/WYIYEqKcSvmq1U 8Gx1eYVXqt9VBd4JPB3G/zVJA48DoDoLvMyFEjEffNbRCL+cVK9yzL0rP1lPvDK/ MoXu1vOXuzFxfqhCrHsrdElIFmmv8Nwgn/ackJJcjgsAbPrOfC8C7tmIGMECeMCW sOeRIBLHKj9AgT76glNWTc6fKurFUhb5V1fHMpNi1Oia45Olmb8CenNjWknoeyAu IdhR/nNkcQd+vzEjbE+cU/WWy/LmQPaOpL27AjVazdHnPwFMkvCAIkqvC0WsBnKv rWPANaKICpqq7XmNSm9P5PJNvQsrPHUoEkI3paQvQFmGgBHM3eyp8lquUJh4Z/in UlklLcvQK0slj1/fKwkv8uTftwc6KuUAfM8210us0wkha3Ha3dWIPciOrLEBK9dV OWDfs7DjCmmGauV20nLgFzXLM5DcfujscT6Ha5GgSddjZiouv1bTki8KvROl58pU OKGaT9fxnIsnJ8VEvUhGZ38C4h/x+2J4R0EWJuANDdbc0G1Ko39t5hb5thME41Ui JRLcfZ14nBo9n+o2EnN57j/csm3GYQcWPbQgCgWcmxeAecIs5knp9cUa7C7VcfxY aYeN9fz3Y/pekzJwjsye =gnx8 -----END PGP SIGNATURE----- --Apple-Mail=_E26B1F42-3917-4DC8-BD66-E10454B70783-- From leifj@mnt.se Sun Sep 22 23:29:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6621F9D96 for ; Sun, 22 Sep 2013 23:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY94fe1atpb0 for ; Sun, 22 Sep 2013 23:29:52 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5833621F9D1B for ; Sun, 22 Sep 2013 23:29:52 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so2330749lbh.33 for ; Sun, 22 Sep 2013 23:29:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4tec79XAyQEC10WNp2H8pWkwDfGEqBVMNqcdvXuVJ04=; b=JbO/CHkfiin0v+baqZmZFn9ZX2lNC7FgY87R0zoJcSnaU8z8tJElKpiLNXpo7fGqWD /nclTAEe+Qw5LkCr85weTE+UXPdDYSCotboEhiGoNZ9QvbBGiAJjzr8J/tv95ycYTmDL +rE6zZcL8GeiQyfiQjQ7SIVr7r+rDARtcpbjz8OHdc5l4A8Yyph6dvgb+o3SVOT3KHRv LUEHFKNHIaukYgQlvBnh0RXzRs+krIIU4m4n29dE4ostpa++QTmIO9Abiezuz9u9j/9O 48W4+wl0fQq4Q7b+6xtv197/UEtY8RIliEhQYFQJ0YnFIi0cbyERofyQCUVtzXIpSEqq LvYg== X-Gm-Message-State: ALoCoQlHyRPsrhfwM8Sm0CyLBwcKKeC+bHEs+ze7maTAm4nnT2ZMnmdCbB6bYhRcwjSqZ05lci1B X-Received: by 10.152.37.166 with SMTP id z6mr1275011laj.25.1379917790934; Sun, 22 Sep 2013 23:29:50 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id ao4sm11782091lac.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Sep 2013 23:29:50 -0700 (PDT) Message-ID: <523FDFDC.6010909@mnt.se> Date: Mon, 23 Sep 2013 08:29:48 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> In-Reply-To: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 06:29:58 -0000 On 09/22/2013 02:46 PM, Bjoern Hoehrmann wrote: >> >> one scenario I would think about two people with tablet computers that >> run the Acme tablet operating system and they are both using the Acme >> Web Mail system through the Acme browser and they are connected to the >> Internet over Acme Fibre. Now the United States want to read their mails >> to determine whether they or their associates need to be brought free- >> dom and democracy, and they tell Acme to make that happen using the law >> above. Is the system supposed to help the two exchange mails securely? >> I think your analysis is correct: legal intercept will often be a right that sovereign states assign to themselves. Instead of tilting at that windmill, would it be possible to build a mechanism for making detection of 3rd party intercept tools and other malware in software easy? Maybe we should be talking about transparency (in the sense of certificate transparency) for software. Maybe it should be *hard* for a vendor to hide capabilities in software targeted at specific customers by making it *easy* to audit datasets (like software binary packages). Cheers Leif From trammell@tik.ee.ethz.ch Mon Sep 23 00:41:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EC511E80DE; Mon, 23 Sep 2013 00:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npO8NQFpbnMI; Mon, 23 Sep 2013 00:41:10 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3FB11E80D3; Mon, 23 Sep 2013 00:41:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 75196D9300; Mon, 23 Sep 2013 09:41:06 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KRQ1RB9k821F; Mon, 23 Sep 2013 09:41:06 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C9B01D9305; Mon, 23 Sep 2013 09:41:05 +0200 (MEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_87A13F12-1090-4BC7-871B-751CB9E8C810"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <8E31A51D-6452-4A82-9FA6-3EBA26628416@tik.ee.ethz.ch> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Mon, 23 Sep 2013 09:40:57 +0200 References: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> <523C79A8.5050902@cs.tcd.ie> To: perpass , ietf-privacy@ietf.org In-Reply-To: <523C79A8.5050902@cs.tcd.ie> X-Mailer: Apple Mail (2.1510) Subject: Re: [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 07:41:15 -0000 --Apple-Mail=_87A13F12-1090-4BC7-871B-751CB9E8C810 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Stephen, all, (copying ietf-privacy as requested in the draft) I've read the draft; it's a very good and welcome start at extending = 6973 to a set of concrete recommendations for protocol design. I've got = one comment on opportunistic encryption, though: In section 3, halfway down the page: "...at minimum, opportunistic = encryption needs to be well-defined for almost all new IETF standards = track protocols."=20 I understand the rationale behind that "almost", but the lines around it = will need to be very clearly drawn. On brief consideration, I cannot = think of a single _new_ protocol for which opportunistic encryption = shouldn't be the default, for reasons other than interoperability with = an existing protocol that has a significant installed base. Even in such = cases, I think it would be useful to be very clear that communication in = the clear for interoperability is an exception, a "legacy" mode, "to be = deprecated", or other not-very-happy-sounding words that mean "we = realize we're stuck with it in this case but that's really no excuse." The information radiated even from protocols which have no obvious = connection with personal data can be correlated with other information = which can paint a very rich behavioral picture, that only takes one = unprotected link in the chain to associate with an identity. = Opportunistic encryption everywhere reduces the content of this radiated = information, as well as reducing the risk of unprotected links holding = some associable identifier. So exceptions will have to be very well = justified if an aim of this work is protection of privacy against = pervasive surveillance. Cheers, Brian On Sep 20, 2013, at 6:36 PM, Stephen Farrell = wrote: >=20 > FYI. Comments welcome. >=20 > S. >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-cooper-ietf-privacy-requirements-00.txt > Date: Fri, 20 Sep 2013 09:23:52 -0700 > From: internet-drafts@ietf.org > To: Alissa Cooper , Sean Turner , > Stephen Farrell >=20 >=20 > A new version of I-D, draft-cooper-ietf-privacy-requirements-00.txt > has been successfully submitted by Alissa Cooper and posted to the > IETF repository. >=20 > Filename: draft-cooper-ietf-privacy-requirements > Revision: 00 > Title: Privacy Requirements for IETF Protocols > Creation date: 2013-09-20 > Group: Individual Submission > Number of pages: 11 > URL: > = http://www.ietf.org/internet-drafts/draft-cooper-ietf-privacy-requirements= -00.txt > Status: > http://datatracker.ietf.org/doc/draft-cooper-ietf-privacy-requirements > Htmlized: > http://tools.ietf.org/html/draft-cooper-ietf-privacy-requirements-00 >=20 >=20 > Abstract: > It is the consensus of the IETF that IETF protocols be designed to > avoid privacy violations to the extent possible. This document > establishes a number of protocol design choices as Best Current > Practices for the purpose of avoiding such violations. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_87A13F12-1090-4BC7-871B-751CB9E8C810 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSP/CQAAoJENt3nsOmbNJcpAwH/316xH7A8J3EOX0wh1P628ix TwjX4rHMM1KK385OX2Tq9SspTf8yl9F3783UrYW56yakkw5qbiP49AeZENaOFuuU HYVet/Lv0Dqdmc4llRVqdc2fTb7obw+ryTAQOqM2IP0SITt8CsiLB5GkM03a59PF Hn7KF+lthnWKAQvCYX5L02hwd+dMRjDLtiOHJiYHqsmaiYDXOs6Vlh9lumP/aNel nrHV/hXlWGzPjYFhYMDi+Y8cFP2DiiIoGbi5X7HVgQpyWa6NPj12soh/0E1RxK2+ xLe6ozwAMDYKLLMj6753G5il/Ma6Nu9w8YpkHpQuQehVhJfHhc+QE2wYcEChNHU= =2JFU -----END PGP SIGNATURE----- --Apple-Mail=_87A13F12-1090-4BC7-871B-751CB9E8C810-- From joe@cdt.org Mon Sep 23 02:23:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45A511E81A8 for ; Mon, 23 Sep 2013 02:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.211 X-Spam-Level: * X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu7cYQOJCMv4 for ; Mon, 23 Sep 2013 02:23:03 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4017811E8170 for ; Mon, 23 Sep 2013 02:22:31 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 23 Sep 2013 05:22:26 -0400 References: <65EEC6E375AA474A847D510D5B7E837480F599D6@mail2010> <523C9D42.9030409@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11A465) From: Joseph Lorenzo Hall Date: Mon, 23 Sep 2013 05:22:25 -0400 To: Scott Brim Cc: perpass , Alissa Cooper , Karl Malbrain , Stephen Farrell Subject: Re: [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 09:23:08 -0000 > On Sep 21, 2013, at 13:42, Scott Brim wrote: >=20 > If you are signing something then you are explicitly deciding to reveal th= e related information. You can certainly sign something intended for an audience that is less than p= ublic, so this doesn't hold. best, Joe -- Joseph Lorenzo Hall Senior Staff Technologist Center for Democracy & Technology https://www.cdt.org/= From jon.callas@icloud.com Mon Sep 23 00:33:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1744F21F9D2E for ; Mon, 23 Sep 2013 00:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+ysFPf5c4GM for ; Mon, 23 Sep 2013 00:33:10 -0700 (PDT) Received: from st11p01mm-asmtp001.mac.com (st11p01mm-asmtpout004.mac.com [17.172.204.239]) by ietfa.amsl.com (Postfix) with ESMTP id 8A24421F9CF5 for ; Mon, 23 Sep 2013 00:33:03 -0700 (PDT) Received: from [192.168.137.2] (78-25-226-166.static.dsl.as8607.net [78.25.226.166]) by st11p01mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTK00LT8IARME30@st11p01mm-asmtp001.mac.com> for perpass@ietf.org; Mon, 23 Sep 2013 07:32:56 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-22_03:2013-09-22, 2013-09-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1309230004 References: In-reply-to: MIME-version: 1.0 (1.0) Content-type: text/plain; charset=us-ascii Message-id: <30C1E498-045A-4F75-920B-165C30E3042B@icloud.com> Content-transfer-encoding: quoted-printable X-Mailer: iPad Mail (11A465) From: Jon Callas Date: Mon, 23 Sep 2013 08:32:51 +0100 To: Phillip Hallam-Baker X-Mailman-Approved-At: Mon, 23 Sep 2013 03:52:52 -0700 Cc: perpass Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 07:34:08 -0000 . >=20 > By PRISM-class I mean an attack that attempts pervasive surveillance with b= udgets in excess of $100 million rather than the PRISM program in particular= . Rather than using a word like PRISM-class to mean something other than what i= t sounds like (which is a good idea), invent a new term or just say what you= mean. >=20 > Neither OpenPGP nor S/MIME is capable of providing protection against this= class of attack because they are not widely enough used. We can only hope f= or these to be useful if at least 5% of Internet users start sending mail se= curely. I understand what you are trying to say, but you have now created an objecti= on that all new protocols fail against. So now nothing can meet the requirem= ents because it has to be born with a user base.=20 I have been saying that something new should use components that are availab= le now. Each of OpenPGP and S/MIME suffer from nothing more than cruft accum= ulated over time and things we can do better from the start because we have a= n additional 20+ years of thought and techniques.=20 Throwing them out because we can and should just do better is both bold and s= imple.=20 Jon= From hallam@gmail.com Mon Sep 23 04:52:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3021F8B07 for ; Mon, 23 Sep 2013 04:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoykLWL-d1lV for ; Mon, 23 Sep 2013 04:52:10 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8807421F8E2D for ; Mon, 23 Sep 2013 04:50:24 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id u14so2552879lbd.26 for ; Mon, 23 Sep 2013 04:50:20 -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; bh=fWJrU/IhyWdz6KwcaYFeopn70+2D9OTNszI/AuBgf8M=; b=dp15cP+DZbOVglDFk6RRDn8vpAcSsUFvSveecu7z5e4KY3q5hBDyDLSWTwzjBhnzr2 preAdQ4uiMmS002ttCSMLR9zqYXstEeerIS10U8wG5cRxYTrZHXGLub09C76ixzbpE+b tyZdV6Rkj83e5OdxKlHjSG0w8eV55vwE2VcAM32j5i9Q+QuAd5gQV2sroH8TwrCKGMW0 Qzx455bPfd34LDJKSw1T8/fVxvO009rYWcp+bXUTjjP2EPQVvQdVg7KgKWgS2Bvcfol0 h0xFqHFRO3hdHFhrgWEUcCDUfmyuNLWaw2egykkipKKIG57xsdZEs4E0BJmAwOO1n1oc aRPg== MIME-Version: 1.0 X-Received: by 10.152.9.37 with SMTP id w5mr6404576laa.23.1379937020607; Mon, 23 Sep 2013 04:50:20 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Mon, 23 Sep 2013 04:50:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Sep 2013 07:50:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Jon Callas Content-Type: multipart/alternative; boundary=089e014946f4ed035704e70b9fbc Cc: perpass Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:52:32 -0000 --089e014946f4ed035704e70b9fbc Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 23, 2013 at 3:30 AM, Jon Callas wrote: > . > > > > By PRISM-class I mean an attack that attempts pervasive surveillance > with budgets in excess of $100 million rather than the PRISM program in > particular. > > Rather than using a word like PRISM-class to mean something other than > what it sounds like (which is a good idea), invent a new term or just say > what you mean. Maybe that is the case inside the field. Outside the field, PRISM has a different meaning, one that is very widely understood and tapping into that is a good way to build critical mass. > > Neither OpenPGP nor S/MIME is capable of providing protection against > this class of attack because they are not widely enough used. We can only > hope for these to be useful if at least 5% of Internet users start sending > mail securely. > > I understand what you are trying to say, but you have now created an > objection that all new protocols fail against. So now nothing can meet the > requirements because it has to be born with a user base. > I don't think we can expect S/MIME or OpenPGP to get to 5% by just waiting for the inevitable success like we have been doing for 20 years. I have been saying that something new should use components that are > available now. Each of OpenPGP and S/MIME suffer from nothing more than > cruft accumulated over time and things we can do better from the start > because we have an additional 20+ years of thought and techniques. > > Throwing them out because we can and should just do better is both bold > and simple. > Umm, not sure what you mean. I don't want to have to revisit the interfacing to mail part of the problem which is where most of the horror show ends up being. And there are a billion+ email clients that are capable of receiving encrypted email that are worth building on. I don't think it is the accumulated cruft that is the problem. It is the lack of key discovery, security policy and the monolithic trust model. -- Website: http://hallambaker.com/ --089e014946f4ed035704e70b9fbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 23, 2013 at 3:30 AM, Jon Callas <<= a href=3D"mailto:joncallas@me.com" target=3D"_blank">joncallas@me.com&g= t; wrote:
.
>
> By PRISM-class I mean an attack that attempts pervasive surveillance w= ith budgets in excess of $100 million rather than the PRISM program in part= icular.

Rather than using a word like PRISM-class to mean something other tha= n what it sounds like (which is a good idea), invent a new term or just say= what you mean.

Maybe that is the case insi= de the field.=A0

Outside the field, PRISM has a different meaning, one t= hat is very widely understood and tapping into that is a good way to build = critical mass.

=A0
> Neither OpenPGP nor S/MIME is capable of providing protection against = this class of attack because they are not widely enough used. We can only h= ope for these to be useful if at least 5% of Internet users start sending m= ail securely.

I understand what you are trying to say, but you have now created an = objection that all new protocols fail against. So now nothing can meet the = requirements because it has to be born with a user base.

I don't think we can expect S/MIME or OpenPGP to ge= t to 5% by just waiting for the inevitable success like we have been doing = for 20 years.=A0


I have been saying that something new should use components that are availa= ble now. Each of OpenPGP and S/MIME suffer from nothing more than cruft acc= umulated over time and things we can do better from the start because we ha= ve an additional 20+ years of thought and techniques.

Throwing them out because we can and should just do better is both bold and= simple.
=A0
Umm, not sure what you mean. I= don't want to have to revisit the interfacing to mail part of the prob= lem which is where most of the horror show ends up being. And there are a b= illion+ email clients that are capable of receiving encrypted email that ar= e worth building on.

I don't= think it is the accumulated cruft that is the problem. It is the lack of k= ey discovery, security policy and the monolithic trust model.
--089e014946f4ed035704e70b9fbc-- From wilton@isoc.org Mon Sep 23 04:19:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7F321F9B21 for ; Mon, 23 Sep 2013 04:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZYVaT5qpeZ2 for ; Mon, 23 Sep 2013 04:19:19 -0700 (PDT) Received: from smtp156.iad.emailsrvr.com (smtp156.iad.emailsrvr.com [207.97.245.156]) by ietfa.amsl.com (Postfix) with ESMTP id 41D7F21F9FC7 for ; Mon, 23 Sep 2013 04:19:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 1F5C3300C01; Mon, 23 Sep 2013 07:19:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp25.relay.iad1a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id C55F13002FF; Mon, 23 Sep 2013 07:19:05 -0400 (EDT) References: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> <523C79A8.5050902@cs.tcd.ie> <8E31A51D-6452-4A82-9FA6-3EBA26628416@tik.ee.ethz.ch> In-Reply-To: <8E31A51D-6452-4A82-9FA6-3EBA26628416@tik.ee.ethz.ch> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Mon, 23 Sep 2013 12:22:09 +0100 To: Brian Trammell X-Mailman-Approved-At: Mon, 23 Sep 2013 05:11:43 -0700 Cc: "ietf-privacy@ietf.org" , perpass Subject: Re: [perpass] [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 11:19:24 -0000 I am seriously considering trying to gain enough weight that I can fit this o= nto myself as a tattoo: "The information radiated even from protocols which have no obvious connecti= on with personal data can be correlated with other information which can pai= nt a very rich behavioral picture, that only takes one unprotected link in t= he chain to associate with an identity." ;^) Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 23 Sep 2013, at 08:40, Brian Trammell wrote: > hi Stephen, all, >=20 > (copying ietf-privacy as requested in the draft) >=20 > I've read the draft; it's a very good and welcome start at extending 6973 t= o a set of concrete recommendations for protocol design. I've got one commen= t on opportunistic encryption, though: >=20 > In section 3, halfway down the page: "...at minimum, opportunistic encrypt= ion needs to be well-defined for almost all new IETF standards track protoco= ls."=20 >=20 > I understand the rationale behind that "almost", but the lines around it w= ill need to be very clearly drawn. On brief consideration, I cannot think of= a single _new_ protocol for which opportunistic encryption shouldn't be the= default, for reasons other than interoperability with an existing protocol t= hat has a significant installed base. Even in such cases, I think it would b= e useful to be very clear that communication in the clear for interoperabili= ty is an exception, a "legacy" mode, "to be deprecated", or other not-very-h= appy-sounding words that mean "we realize we're stuck with it in this case b= ut that's really no excuse." >=20 > The information radiated even from protocols which have no obvious connect= ion with personal data can be correlated with other information which can pa= int a very rich behavioral picture, that only takes one unprotected link in t= he chain to associate with an identity. Opportunistic encryption everywhere r= educes the content of this radiated information, as well as reducing the ris= k of unprotected links holding some associable identifier. So exceptions wil= l have to be very well justified if an aim of this work is protection of pri= vacy against pervasive surveillance. >=20 > Cheers, >=20 > Brian >=20 > On Sep 20, 2013, at 6:36 PM, Stephen Farrell w= rote: >=20 >>=20 >> FYI. Comments welcome. >>=20 >> S. >>=20 >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-cooper-ietf-privacy-requirements-00.txt >> Date: Fri, 20 Sep 2013 09:23:52 -0700 >> From: internet-drafts@ietf.org >> To: Alissa Cooper , Sean Turner , >> Stephen Farrell >>=20 >>=20 >> A new version of I-D, draft-cooper-ietf-privacy-requirements-00.txt >> has been successfully submitted by Alissa Cooper and posted to the >> IETF repository. >>=20 >> Filename: draft-cooper-ietf-privacy-requirements >> Revision: 00 >> Title: Privacy Requirements for IETF Protocols >> Creation date: 2013-09-20 >> Group: Individual Submission >> Number of pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-cooper-ietf-privacy-requirement= s-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-cooper-ietf-privacy-requirements >> Htmlized: >> http://tools.ietf.org/html/draft-cooper-ietf-privacy-requirements-00 >>=20 >>=20 >> Abstract: >> It is the consensus of the IETF that IETF protocols be designed to >> avoid privacy violations to the extent possible. This document >> establishes a number of protocol design choices as Best Current >> Practices for the purpose of avoiding such violations. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submiss= ion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > ietf-privacy mailing list > ietf-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-privacy From stephen.farrell@cs.tcd.ie Mon Sep 23 05:25:31 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FD021F9DD6; Mon, 23 Sep 2013 05:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX9B3YFI+26h; Mon, 23 Sep 2013 05:24:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7811421F9F08; Mon, 23 Sep 2013 05:24:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9747ABE56; Mon, 23 Sep 2013 13:24:24 +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 IS2NufMMeTDF; Mon, 23 Sep 2013 13:24:24 +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 759A3BE39; Mon, 23 Sep 2013 13:24:24 +0100 (IST) Message-ID: <524032F9.2060302@cs.tcd.ie> Date: Mon, 23 Sep 2013 13:24:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Trammell References: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> <523C79A8.5050902@cs.tcd.ie> <8E31A51D-6452-4A82-9FA6-3EBA26628416@tik.ee.ethz.ch> In-Reply-To: <8E31A51D-6452-4A82-9FA6-3EBA26628416@tik.ee.ethz.ch> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ietf-privacy@ietf.org, perpass Subject: Re: [perpass] [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 12:25:37 -0000 Hi Brian, On 09/23/2013 08:40 AM, Brian Trammell wrote: > hi Stephen, all, > > (copying ietf-privacy as requested in the draft) > I've read the draft; it's a very good and welcome start at extending > 6973 to a set of concrete recommendations for protocol design. I've > got one comment on opportunistic encryption, though: > > In section 3, halfway down the page: "...at minimum, opportunistic > encryption needs to be well-defined for almost all new IETF standards > track protocols." > > I understand the rationale behind that "almost", but the lines around > it will need to be very clearly drawn. Yep. And that's tricky. Better wording is very welcome. > On brief consideration, I > cannot think of a single _new_ protocol for which opportunistic > encryption shouldn't be the default, for reasons other than > interoperability with an existing protocol that has a significant > installed base. Well, we don't say that *use* of OE should be the default. That is, we do not say "OE or better SHOULD be used." I would like it if we did say that, but I don't think we'd get IETF consensus for it. The current draft says only that OE (or better) must be well-defined and leaves it to those deploying as to whether that's turned on or not. (We could probably make that clearer I guess, e.g. by saying that OE or better is mandatory to implement.) If there are folks who think that we should go further, (and think that we could get IETF consensus for that,) then please propose text. I do know there are folks who don't want us to go that far on the basis that that'd mean the IETF would be specifying policy and not just protocol. There are also folks who do middleboxes of various kinds that'd probably be upset too:-) Cheers, S. > Even in such cases, I think it would be useful to be > very clear that communication in the clear for interoperability is an > exception, a "legacy" mode, "to be deprecated", or other > not-very-happy-sounding words that mean "we realize we're stuck with > it in this case but that's really no excuse." > > The information radiated even from protocols which have no obvious > connection with personal data can be correlated with other > information which can paint a very rich behavioral picture, that only > takes one unprotected link in the chain to associate with an > identity. Opportunistic encryption everywhere reduces the content of > this radiated information, as well as reducing the risk of > unprotected links holding some associable identifier. So exceptions > will have to be very well justified if an aim of this work is > protection of privacy against pervasive surveillance. > > Cheers, > > Brian > > On Sep 20, 2013, at 6:36 PM, Stephen Farrell > wrote: > >> >> FYI. Comments welcome. >> >> S. >> >> >> -------- Original Message -------- Subject: New Version >> Notification for draft-cooper-ietf-privacy-requirements-00.txt >> Date: Fri, 20 Sep 2013 09:23:52 -0700 From: >> internet-drafts@ietf.org To: Alissa Cooper , Sean >> Turner , Stephen Farrell >> >> >> >> A new version of I-D, >> draft-cooper-ietf-privacy-requirements-00.txt has been successfully >> submitted by Alissa Cooper and posted to the IETF repository. >> >> Filename: draft-cooper-ietf-privacy-requirements Revision: 00 >> Title: Privacy Requirements for IETF Protocols Creation date: >> 2013-09-20 Group: Individual Submission Number of pages: 11 URL: >> http://www.ietf.org/internet-drafts/draft-cooper-ietf-privacy-requirements-00.txt >> >> Status: >> http://datatracker.ietf.org/doc/draft-cooper-ietf-privacy-requirements >> >> Htmlized: >> http://tools.ietf.org/html/draft-cooper-ietf-privacy-requirements-00 >> >> >> >> Abstract: >> It is the consensus of the IETF that IETF protocols be designed to >> avoid privacy violations to the extent possible. This document >> establishes a number of protocol design choices as Best Current >> Practices for the purpose of avoiding such violations. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ perpass mailing >> list perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > > > _______________________________________________ ietf-privacy mailing > list ietf-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-privacy > From scott.brim@gmail.com Mon Sep 23 06:09:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E175821F9FA5 for ; Mon, 23 Sep 2013 06:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBfjnt2cfXrv for ; Mon, 23 Sep 2013 06:09:24 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD7721F9FA2 for ; Mon, 23 Sep 2013 06:09:23 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l10so490911oag.31 for ; Mon, 23 Sep 2013 06:09:22 -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; bh=T96flRTI8YLEohOghiYAQLb/Lvc9A/ah59QhZ7mGlsg=; b=xoUL6lARBu+9MKnLB2k96YUsR5TXoEuB634GlEG5CXWG921a32VwX/0/Vtd4aveble wzIzrmkntTKBKZmOjTqPwEihLZJ7Ncm1Q4cpwdB84ulUgIxIyQ7Bgz+4yX+7k9HGBAj3 OWO+ndgsh4ajCFcf0y7oZ4teFhr1vX8Lx5cpTVsGg0Bx16JFLyhaV511Ff9IXKRKhd+O 6TpM51GYoT+DY4bctiKxTzZZewg1wrXwyQrFEX1JMxKts0LC/39xMSYjkRDi/enZhejP wzSKE+QWdrP3dJ+r66JNei+hUv8yXtIkmO6W0CEEaSlzTOOhG2aFfZAObibI/4VWHsUX jMtg== MIME-Version: 1.0 X-Received: by 10.60.68.135 with SMTP id w7mr20100402oet.9.1379941762632; Mon, 23 Sep 2013 06:09:22 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Mon, 23 Sep 2013 06:09:22 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Mon, 23 Sep 2013 06:09:22 -0700 (PDT) In-Reply-To: References: <65EEC6E375AA474A847D510D5B7E837480F599D6@mail2010> <523C9D42.9030409@cs.tcd.ie> Date: Mon, 23 Sep 2013 09:09:22 -0400 Message-ID: From: Scott Brim To: Joseph Lorenzo Hall Content-Type: multipart/alternative; boundary=001a1134c4c2929a0504e70cba6e Cc: perpass , Alissa Cooper , Karl Malbrain , Stephen Farrell Subject: Re: [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:09:25 -0000 --001a1134c4c2929a0504e70cba6e Content-Type: text/plain; charset=ISO-8859-1 Joe, yes, that's what I meant in the rest if the message. Story if it wasn't well constructed, I'm using a phone for mail. On Sep 23, 2013 5:22 AM, "Joseph Lorenzo Hall" wrote: > > > > On Sep 21, 2013, at 13:42, Scott Brim wrote: > > > > If you are signing something then you are explicitly deciding to reveal > the related information. > > You can certainly sign something intended for an audience that is less > than public, so this doesn't hold. > > best, Joe > > -- > Joseph Lorenzo Hall > Senior Staff Technologist > Center for Democracy & Technology > https://www.cdt.org/ > --001a1134c4c2929a0504e70cba6e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Joe, yes, that's what I meant in the rest if the message= . Story if it wasn't well constructed, I'm using a phone for mail. =

On Sep 23, 2013 5:22 AM, "Joseph Lorenzo Ha= ll" <joe@cdt.org> wrote:


> On Sep 21, 2013, at 13:42, Scott Brim <scott.brim@gmail.com> wrote:
>
> If you are signing something then you are explicitly deciding to revea= l the related information.

You can certainly sign something intended for an audience that is less than= public, so this doesn't hold.

best, Joe

--
Joseph Lorenzo Hall
Senior Staff Technologist
Center for Democracy & Technology
https://www.cdt.org/=
--001a1134c4c2929a0504e70cba6e-- From scott.brim@gmail.com Mon Sep 23 06:17:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B05D21F9F97 for ; Mon, 23 Sep 2013 06:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVcnE8pdLeQH for ; Mon, 23 Sep 2013 06:17:09 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8771621F9F84 for ; Mon, 23 Sep 2013 06:17:09 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h16so485367oag.24 for ; Mon, 23 Sep 2013 06:17:08 -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; bh=MUd7J1ncMHuM4Z6s2OQ6zSeWi5gZpnWmLX7yTGwLPy8=; b=oiDdodXOctAag+Vvs8GyyUpiLiNkqC506AglLWP57nnenAT/YlQe0wBjJaEo2nou63 zMNjumPwy20zljB76yJE47RbArUxNhnoPrbxEk3IJAHLc4LjjuCUPj/MAVNw/tM9M3EV bH4biBy9YaMGnLSC5Uy1NjLIKQOQCRfi5swLJijIdMxUdxDZ+MCxGf1LCqRudXIpfwf1 zoa/KXCjXEZyYx1KGaTmJ2/g7cz/xOZuopfZ0MFwEEQw3lhcCrNhOliRGKpbtFZSRJHw mhD5qhFHbfOpXYh2s3q9GsJiPUGCqZ15tBhFML0LY6/AYw0//CH5qi72eIriK8LLVcyr zyLQ== MIME-Version: 1.0 X-Received: by 10.60.52.244 with SMTP id w20mr6071877oeo.30.1379942228868; Mon, 23 Sep 2013 06:17:08 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Mon, 23 Sep 2013 06:17:08 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Mon, 23 Sep 2013 06:17:08 -0700 (PDT) In-Reply-To: <523FDFDC.6010909@mnt.se> References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> <523FDFDC.6010909@mnt.se> Date: Mon, 23 Sep 2013 09:17:08 -0400 Message-ID: From: Scott Brim To: Leif Johansson Content-Type: multipart/alternative; boundary=001a113346005cc4e804e70cd697 Cc: perpass Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:17:10 -0000 --001a113346005cc4e804e70cd697 Content-Type: text/plain; charset=ISO-8859-1 On Sep 23, 2013 2:30 AM, "Leif Johansson" wrote: > Instead of tilting at that windmill, would it be possible to build a > mechanism for making detection of 3rd party intercept tools and > other malware in software easy? Nice idea. Back when I tried, my experience was that it's very hard to distinguish good intercepts from bad ones. Would you get away from all middleboxes? Scott --001a113346005cc4e804e70cd697 Content-Type: text/html; charset=ISO-8859-1


On Sep 23, 2013 2:30 AM, "Leif Johansson" <leifj@mnt.se> wrote:
> Instead of tilting at that windmill, would it be possible to build a
> mechanism for making detection of 3rd party intercept tools and
> other malware in software easy?

Nice idea. Back when I tried, my experience was that it's very hard to distinguish good intercepts from bad ones. Would you get away from all middleboxes?

Scott

--001a113346005cc4e804e70cd697-- From leifj@mnt.se Mon Sep 23 07:12:13 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E79121F9F19 for ; Mon, 23 Sep 2013 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.177 X-Spam-Level: X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKOl9k1eEJ53 for ; Mon, 23 Sep 2013 07:12:07 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 85FAA21F9F01 for ; Mon, 23 Sep 2013 07:12:03 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id u14so2697308lbd.2 for ; Mon, 23 Sep 2013 07:12:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=KAlPGu1olh/vJ0tJchdJgWkVKQ3T0UawzI4+8ggGD0A=; b=e0lruuA40Ixi4y3x2M6sVPVQNx1cx/RsorQJCJeDp0sLXh1Gz4/btyp3OkozDAHGR7 p/iGa84H/pklBXIgQpMLYYAoPNHtqwd7cLgsXji7AbzqXjIcaC6B/zWXQqyw7IbC/8xg UikUnX9hvXqiYWdTm3WF7NGYC54EljUXcYBeqvEF2sb3uZ0rPeIxcWXzJNsSLF1iTgTx Hxx/4li7eE1WZPwe4gw6Kxf3AP31JCC8Tr3mdADcohV8hw3ZTepNOo6Cr4utQoFYG8ur TRVtM26K8IfszdOlvfFQHgltTqIfHXIwRdtSggMtS3wo6E6D7QqGeAgEZz1ODM5TxbWC GYYQ== X-Gm-Message-State: ALoCoQlRSp7KhNXfbPV/VgN5b/GrBi4+Z2+Q0d1XaAqfwk9tJzkmg2X/Cj2CIOalTchLsBvm4NtK X-Received: by 10.152.3.42 with SMTP id 10mr20715786laz.22.1379945522419; Mon, 23 Sep 2013 07:12:02 -0700 (PDT) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id zw2sm12187642lbb.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 07:12:00 -0700 (PDT) Message-ID: <52404C2E.2080007@mnt.se> Date: Mon, 23 Sep 2013 16:11:58 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Brim References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> <523FDFDC.6010909@mnt.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010704090303010809040401" Cc: perpass Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:12:13 -0000 This is a multi-part message in MIME format. --------------010704090303010809040401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/23/2013 03:17 PM, Scott Brim wrote: > > > On Sep 23, 2013 2:30 AM, "Leif Johansson" > wrote: > > Instead of tilting at that windmill, would it be possible to build a > > mechanism for making detection of 3rd party intercept tools and > > other malware in software easy? > > Nice idea. Back when I tried, my experience was that it's very hard to > distinguish good intercepts from bad ones. Would you get away from all > middleboxes? > > Scott > I might not be able to get away from them but I would like to know they exist. My guess is that endpoint intercept malware will slip through the hands of govt owners and into the hands of regular criminals at which point I *really* do want the reporter to be able to know if the local maffioso is running intercepts on her laptop to find out what she is going to be writing about next... Cheers Leif --------------010704090303010809040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/23/2013 03:17 PM, Scott Brim wrote:


On Sep 23, 2013 2:30 AM, "Leif Johansson" <leifj@mnt.se> wrote:
> Instead of tilting at that windmill, would it be possible to build a
> mechanism for making detection of 3rd party intercept tools and
> other malware in software easy?

Nice idea. Back when I tried, my experience was that it's very hard to distinguish good intercepts from bad ones. Would you get away from all middleboxes?

Scott

I might not be able to get away from them but I would like to know they exist.

My guess is that endpoint intercept malware will slip through the hands
of govt owners and into the hands of regular criminals at which point I
*really* do want the reporter to be able to know if the local maffioso is
running intercepts on her laptop to find out what she is going to be writing
about next...

        Cheers Leif
--------------010704090303010809040401-- From acooper@cdt.org Mon Sep 23 07:32:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7257411E8182; Mon, 23 Sep 2013 07:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.052 X-Spam-Level: X-Spam-Status: No, score=-102.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtkoVGPBz7+7; Mon, 23 Sep 2013 07:32:49 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 77E7411E80DF; Mon, 23 Sep 2013 07:32:48 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Mon, 23 Sep 2013 10:32:47 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_B350BDE5-C411-4894-A48F-18E5FDB121ED"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Alissa Cooper In-Reply-To: <8E31A51D-6452-4A82-9FA6-3EBA26628416@tik.ee.ethz.ch> Date: Mon, 23 Sep 2013 10:32:49 -0400 Message-Id: References: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> <523C79A8.5050902@cs.tcd.ie> <8E31A51D-6452-4A82-9FA6-3EBA26628416@tik.ee.ethz.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1499) Cc: ietf-privacy@ietf.org, perpass Subject: Re: [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 14:32:54 -0000 --Apple-Mail=_B350BDE5-C411-4894-A48F-18E5FDB121ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian, Thanks for your comments. On Sep 23, 2013, at 3:40 AM, Brian Trammell = wrote: > hi Stephen, all, >=20 > (copying ietf-privacy as requested in the draft) >=20 > I've read the draft; it's a very good and welcome start at extending = 6973 to a set of concrete recommendations for protocol design. I've got = one comment on opportunistic encryption, though: >=20 > In section 3, halfway down the page: "...at minimum, opportunistic = encryption needs to be well-defined for almost all new IETF standards = track protocols."=20 >=20 > I understand the rationale behind that "almost", but the lines around = it will need to be very clearly drawn. On brief consideration, I cannot = think of a single _new_ protocol for which opportunistic encryption = shouldn't be the default, for reasons other than interoperability with = an existing protocol that has a significant installed base. Even in such = cases, I think it would be useful to be very clear that communication in = the clear for interoperability is an exception, a "legacy" mode, "to be = deprecated", or other not-very-happy-sounding words that mean "we = realize we're stuck with it in this case but that's really no excuse." I have not been super comfortable with the "almost" either. I've been = thinking instead of something like: "As a consequence, at minimum, opportunistic encryption needs to be = well-defined for new IETF standards track protocols. This requirement = may be waved only in exceptional circumstances where the protocol's = utility would be eliminated or severely diminished if opportunistic = encryption were defined." >=20 > The information radiated even from protocols which have no obvious = connection with personal data can be correlated with other information = which can paint a very rich behavioral picture, that only takes one = unprotected link in the chain to associate with an identity. = Opportunistic encryption everywhere reduces the content of this radiated = information, as well as reducing the risk of unprotected links holding = some associable identifier. So exceptions will have to be very well = justified if an aim of this work is protection of privacy against = pervasive surveillance. I'm not ready to ink this on my skin, but it does seem like good text to = add to the document, with minimal tweaks. :) Alissa >=20 > Cheers, >=20 > Brian >=20 > On Sep 20, 2013, at 6:36 PM, Stephen Farrell = wrote: >=20 >>=20 >> FYI. Comments welcome. >>=20 >> S. >>=20 >>=20 >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-cooper-ietf-privacy-requirements-00.txt >> Date: Fri, 20 Sep 2013 09:23:52 -0700 >> From: internet-drafts@ietf.org >> To: Alissa Cooper , Sean Turner , >> Stephen Farrell >>=20 >>=20 >> A new version of I-D, draft-cooper-ietf-privacy-requirements-00.txt >> has been successfully submitted by Alissa Cooper and posted to the >> IETF repository. >>=20 >> Filename: draft-cooper-ietf-privacy-requirements >> Revision: 00 >> Title: Privacy Requirements for IETF Protocols >> Creation date: 2013-09-20 >> Group: Individual Submission >> Number of pages: 11 >> URL: >> = http://www.ietf.org/internet-drafts/draft-cooper-ietf-privacy-requirements= -00.txt >> Status: >> = http://datatracker.ietf.org/doc/draft-cooper-ietf-privacy-requirements >> Htmlized: >> http://tools.ietf.org/html/draft-cooper-ietf-privacy-requirements-00 >>=20 >>=20 >> Abstract: >> It is the consensus of the IETF that IETF protocols be designed to >> avoid privacy violations to the extent possible. This document >> establishes a number of protocol design choices as Best Current >> Practices for the purpose of avoiding such violations. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_B350BDE5-C411-4894-A48F-18E5FDB121ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJSQFERAAoJEIXyHQftqgBQlfkH/iomI4qSEOE0Oa6ii9y+pyWZ 7nxL3wYzaUAk9cjhAGsnwZmS6cNdjROIXvHqT6Ghb0tHMptChAcWTsR07QJq7Yrr Lp1EIiXp/m+xJFATkYI9s2NCBLliS94FYsc1EUB0xA5/+0yal4RGs20eKAVFwEFQ gmf76FY/LKHrZ/nZAhiYT/nmykkYZVrjJPQ1H87ft002c4n+Ddm5zRrxDhbalBm8 xD9x/iphhOXZavg3kXlFmuMYn2XeUqwljpXzk7rSZOhpkrsQ5LRzKJ0d+5V/uMZ9 NV6Hx03F4vT3SSVXyqRoqBruDrryBbnTlb0UZPWgrPJ8KzKr04si4XNJF8ndbHM= =O8/p -----END PGP SIGNATURE----- --Apple-Mail=_B350BDE5-C411-4894-A48F-18E5FDB121ED-- From trammell@tik.ee.ethz.ch Mon Sep 23 08:15:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C90E21F9BC3; Mon, 23 Sep 2013 08:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3jJsaJzKZFp; Mon, 23 Sep 2013 08:15:52 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 17B8921F9BBD; Mon, 23 Sep 2013 08:15:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E984ED9307; Mon, 23 Sep 2013 17:15:48 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1cwWqBR7Q54l; Mon, 23 Sep 2013 17:15:48 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id ADBE5D9300; Mon, 23 Sep 2013 17:15:48 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_8335088C-3785-4631-8F2E-260FCB5C1BAA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: Date: Mon, 23 Sep 2013 17:15:48 +0200 Message-Id: <2BB181AD-2269-4B91-B109-67E7E912F513@tik.ee.ethz.ch> References: <20130920162352.23295.48024.idtracker@ietfa.amsl.com> <523C79A8.5050902@cs.tcd.ie> <8E31A51D-6452-4A82-9FA6-3EBA26628416@tik.ee.ethz.ch> To: Alissa Cooper X-Mailer: Apple Mail (2.1508) Cc: ietf-privacy@ietf.org, perpass Subject: Re: [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:15:58 -0000 --Apple-Mail=_8335088C-3785-4631-8F2E-260FCB5C1BAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Alissa, On 23 Sep 2013, at 16:32 , Alissa Cooper wrote: > Hi Brian, >=20 > Thanks for your comments. >=20 > On Sep 23, 2013, at 3:40 AM, Brian Trammell = wrote: >=20 >> hi Stephen, all, >>=20 >> (copying ietf-privacy as requested in the draft) >>=20 >> I've read the draft; it's a very good and welcome start at extending = 6973 to a set of concrete recommendations for protocol design. I've got = one comment on opportunistic encryption, though: >>=20 >> In section 3, halfway down the page: "...at minimum, opportunistic = encryption needs to be well-defined for almost all new IETF standards = track protocols."=20 >>=20 >> I understand the rationale behind that "almost", but the lines around = it will need to be very clearly drawn. On brief consideration, I cannot = think of a single _new_ protocol for which opportunistic encryption = shouldn't be the default, for reasons other than interoperability with = an existing protocol that has a significant installed base. Even in such = cases, I think it would be useful to be very clear that communication in = the clear for interoperability is an exception, a "legacy" mode, "to be = deprecated", or other not-very-happy-sounding words that mean "we = realize we're stuck with it in this case but that's really no excuse." >=20 > I have not been super comfortable with the "almost" either. I've been = thinking instead of something like: >=20 > "As a consequence, at minimum, opportunistic encryption needs to be = well-defined for new IETF standards track protocols. This requirement = may be waved only in exceptional circumstances where the protocol's = utility would be eliminated or severely diminished if opportunistic = encryption were defined." This is a better version of what I've been trying to come up with. (Nit: = s/waved/waived/) >> The information radiated even from protocols which have no obvious = connection with personal data can be correlated with other information = which can paint a very rich behavioral picture, that only takes one = unprotected link in the chain to associate with an identity. = Opportunistic encryption everywhere reduces the content of this radiated = information, as well as reducing the risk of unprotected links holding = some associable identifier. So exceptions will have to be very well = justified if an aim of this work is protection of privacy against = pervasive surveillance. >=20 > I'm not ready to ink this on my skin, but it does seem like good text = to add to the document, with minimal tweaks. :) Now that I've seen the direction this draft is going in, I'm hoping to = get back to -perpass-ppa soon, to move it more in the direction of a = catalog of information radiation to look for. Cheers, Brian --Apple-Mail=_8335088C-3785-4631-8F2E-260FCB5C1BAA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSQFskAAoJENt3nsOmbNJcMLkH/1pbuSGeZMIlCEhTRy4aQiST JAJ9nhJPFC4TXVhK3D7DNnPx0p8vGTVvCOOY9HqF+gwi9CEL44nFfBM50tMFW5ob gkz7/0b3E3oAMm3o8H6jySJmTSWnG5SJj2QCqBehpuOWmvSHFV/KIGWgC8Minehe dMyKldgES/Zl1Z6eQajkB32B9CEqd65FE1SSAK0UGBJVsf45oPp47uBpsB4lxbLU V2JDeQqNCqcUy4UfrGcNauHeRr7LtZkhNmMAd3eOMEY9kHUvfBNeEhSHK8RRWJG2 85c1vkrFdtnNY4fbP5MfANcXOOXmW5ZfgMTr82B53SEqjCJkfCdK3Yc/RX20qO0= =j537 -----END PGP SIGNATURE----- --Apple-Mail=_8335088C-3785-4631-8F2E-260FCB5C1BAA-- From karl@petzent.com Mon Sep 23 09:32:52 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED3521F9E1D; Mon, 23 Sep 2013 09:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.667 X-Spam-Level: X-Spam-Status: No, score=0.667 tagged_above=-999 required=5 tests=[AWL=0.749, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NllMMCMLlGHi; Mon, 23 Sep 2013 09:32:45 -0700 (PDT) Received: from mail.petzent.com (50-201-233-2-static.hfc.comcastbusiness.net [50.201.233.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8731821F9E12; Mon, 23 Sep 2013 09:32:45 -0700 (PDT) Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Mon, 23 Sep 2013 09:32:49 -0700 Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Mon, 23 Sep 2013 09:32:58 -0700 From: Karl Malbrain To: Stephen Farrell Thread-Topic: [perpass] [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt Thread-Index: Ac64eo+J2j5pSX7HTlC8v8KofsrKFA== Date: Mon, 23 Sep 2013 16:32:57 +0000 Message-ID: <65EEC6E375AA474A847D510D5B7E837480F59A8F@mail2010> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.0.1.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf-privacy@ietf.org" , "perpass@ietf.org" , "acooper@cdt.org" Subject: Re: [perpass] [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 16:32:52 -0000 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Friday, September 20, 2013 12:09 > To: Karl Malbrain > Cc: acooper@cdt.org; perpass@ietf.org > Subject: Re: [perpass] New Version Notification for draft-cooper-ietf-pri= vacy- > requirements-00.txt >=20 >=20 >=20 > On 09/20/2013 07:50 PM, Karl Malbrain wrote: > > "Note that this is contingent on practicality - if some personal data > > really has to be sent in clear for a protocol to be able to operate, > > and even opportunistic encryption is not possible, then a > > standards- track protocol that does not define how to protect that > > data will be consistent with this BCP. The IETF will have to decide > > in such cases whether standardizing that protocol benefits the > > Internet or not." > > > > > > 1. Is the value of a personal public key considered "personal data"? > > In TLS client authentication, these keys are requested. >=20 > I doubt there's any data-protection regulator views on that (TLS client-a= uth > being so rare on the public Internet) but basically, I'd say yeah, its an= identifier > that generally won't change for extended periods. That's one of the motiv= ations > for doing TLS 1.3 - to hide such handshake data for example. > Apart from the desirability of encrypting the personal public key when it i= s sent (e.g. OE), is association with a person on a server of a hash of the= public key for subsequent authentication purposes covered by this BCP? =20 > > 2. Under the goal of MITM resistance, how can opportunistic encryption > > provide security without authentication? I think that an > > authentication layer on top of opportunistic encryption is required. >=20 > I disagree. "Security" is not a binary state of affairs. > Opportunistic encryption without authentication can provide some value, e= sp in > this context where it forces a more active and presumably expensive and m= ore > likely detected attack if you want to pervasively monitor everyone. I think that a security evaluation should be broken down into individual at= tributes, each of which can be evaluated yes/no. Resistance to MITM attack= for example. Resistance to passive surveillance is another attribute. Karl Malbrain From pkyzivat@alum.mit.edu Mon Sep 23 13:01:05 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C32B21F9CA8 for ; Mon, 23 Sep 2013 13:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUpOUVHvM22M for ; Mon, 23 Sep 2013 13:00:59 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 8477121F8A7B for ; Mon, 23 Sep 2013 13:00:57 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta07.westchester.pa.mail.comcast.net with comcast id Uc8U1m0081HzFnQ57k0wGR; Mon, 23 Sep 2013 20:00:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id Uk0w1m00o3ZTu2S3ak0wmx; Mon, 23 Sep 2013 20:00:56 +0000 Message-ID: <52409DF7.10206@alum.mit.edu> Date: Mon, 23 Sep 2013 16:00:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> <523FDFDC.6010909@mnt.se> <52404C2E.2080007@mnt.se> In-Reply-To: <52404C2E.2080007@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379966456; bh=5Hx+GinSI5pZ+5U6SWPUMAPrZXu8xjR9k8krKVT00QA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NdeY8ikWDsWLSpNtIWMfyj37Ipo4XY2RNEb6sVJtLk3WE4ebNdGzFUocbaD+CBdCF TdHsZKqfvhcBgGb+BQuZWp9iR2dYfh78VXQjYd8bHQU3HTSePRWpAIflNvITNQYjZs eMArvjWwtJRzRJKKBCsYiaVrLAfMAWttOPxart9UYIxN8+1+JKLyiswLoqTZGPcutl gQRYdw/knzqsa2+tMaKSfcmZBjbFVL4j+VTbWOXX6n0wLNL2mf4j01/W1s3NNsriXS keW5ZWtWEZI4J686T7DodkUGtalpfrwYQVBVuiNllqtj6EJiCopg0dvkmt2PzFqIlY OB85a7pWJ+pGg== Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:01:05 -0000 On 9/23/13 10:11 AM, Leif Johansson wrote: > On 09/23/2013 03:17 PM, Scott Brim wrote: >> >> >> On Sep 23, 2013 2:30 AM, "Leif Johansson" > > wrote: >> > Instead of tilting at that windmill, would it be possible to build a >> > mechanism for making detection of 3rd party intercept tools and >> > other malware in software easy? >> >> Nice idea. Back when I tried, my experience was that it's very hard to >> distinguish good intercepts from bad ones. Would you get away from all >> middleboxes? >> >> Scott >> > I might not be able to get away from them but I would like to know they > exist. That's interesting if some of your messages are intercepted and others are not. But once you see that 100% of your messages are intercepted by Big Brother, then it isn't very helpful. > My guess is that endpoint intercept malware will slip through the hands > of govt owners and into the hands of regular criminals at which point I > *really* do want the reporter to be able to know if the local maffioso is > running intercepts on her laptop to find out what she is going to be writing > about next... Do you expect that it will be easy to tell who is operating the intercept? Of that the local maffioso doesn't get his data from a ring that intercepts Big Brother's intercept? Thanks, Paul From stephen.farrell@cs.tcd.ie Tue Sep 24 01:26:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F064E21F9D0A; Tue, 24 Sep 2013 01:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXSfx1+YGMum; Tue, 24 Sep 2013 01:26:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9139B21F92B8; Tue, 24 Sep 2013 01:26:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 86AFBBE74; Tue, 24 Sep 2013 09:26:00 +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 klAqYHtmYTNK; Tue, 24 Sep 2013 09:26:00 +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 609EDBE73; Tue, 24 Sep 2013 09:26:00 +0100 (IST) Message-ID: <52414C98.1080506@cs.tcd.ie> Date: Tue, 24 Sep 2013 09:26:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Karl Malbrain References: <65EEC6E375AA474A847D510D5B7E837480F59A8F@mail2010> In-Reply-To: <65EEC6E375AA474A847D510D5B7E837480F59A8F@mail2010> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ietf-privacy@ietf.org" , "perpass@ietf.org" , "acooper@cdt.org" Subject: Re: [perpass] [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 08:26:12 -0000 Hi Karl, On 09/23/2013 05:32 PM, Karl Malbrain wrote: > > >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, September 20, 2013 >> 12:09 To: Karl Malbrain Cc: acooper@cdt.org; perpass@ietf.org >> Subject: Re: [perpass] New Version Notification for >> draft-cooper-ietf-privacy- requirements-00.txt >> >> >> >> On 09/20/2013 07:50 PM, Karl Malbrain wrote: >>> "Note that this is contingent on practicality - if some personal >>> data really has to be sent in clear for a protocol to be able to >>> operate, and even opportunistic encryption is not possible, then >>> a standards- track protocol that does not define how to protect >>> that data will be consistent with this BCP. The IETF will have >>> to decide in such cases whether standardizing that protocol >>> benefits the Internet or not." >>> >>> >>> 1. Is the value of a personal public key considered "personal >>> data"? In TLS client authentication, these keys are requested. >> >> I doubt there's any data-protection regulator views on that (TLS >> client-auth being so rare on the public Internet) but basically, >> I'd say yeah, its an identifier that generally won't change for >> extended periods. That's one of the motivations for doing TLS 1.3 - >> to hide such handshake data for example. >> > > Apart from the desirability of encrypting the personal public key > when it is sent (e.g. OE), is association with a person on a server > of a hash of the public key for subsequent authentication purposes > covered by this BCP? Well, its not a BCP yet, its a proposal. But assuming for the moment it became a BCP unchanged, then I'd say that the protocol used to access a person's public key or public key hash from such a server would be covered by the BCP yes. >>> 2. Under the goal of MITM resistance, how can opportunistic >>> encryption provide security without authentication? I think that >>> an authentication layer on top of opportunistic encryption is >>> required. >> >> I disagree. "Security" is not a binary state of affairs. >> Opportunistic encryption without authentication can provide some >> value, esp in this context where it forces a more active and >> presumably expensive and more likely detected attack if you want to >> pervasively monitor everyone. > > I think that a security evaluation should be broken down into > individual attributes, each of which can be evaluated yes/no. > Resistance to MITM attack for example. Resistance to passive > surveillance is another attribute. Yes, those are different things. And there can be a tension between them. S. > > Karl Malbrain _______________________________________________ perpass > mailing list perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From sm@resistor.net Tue Sep 24 01:30:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7469621F93DB for ; Tue, 24 Sep 2013 01:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.725 X-Spam-Level: X-Spam-Status: No, score=-102.725 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjLdyMMeN8L9 for ; Tue, 24 Sep 2013 01:30:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6DB21F8413 for ; Tue, 24 Sep 2013 01:30:36 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8O8URsY005359; Tue, 24 Sep 2013 01:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380011432; bh=8CNfZb937IgYAnJ60fx0KwB6kfU9HKMcT6e9HOSbcFs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jNOtbmZeNu3S8818hc/bJPmZCtyYpzymxUkWPLhJH2jlbB1WgMApnqt9Fep7Lb3gs cXp6U+8PcBjMwV74UJkO/XCRD8ADoKTK2YZIfGVOPQJZkO435j6DMZjuH5BLeWT4/i mtlVdQcge1kiC6ThmzwhSwMV3yiRaYc/xMh4GQaw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1380011432; i=@resistor.net; bh=8CNfZb937IgYAnJ60fx0KwB6kfU9HKMcT6e9HOSbcFs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HYrXeoKwXslXf8LinH2iRprK3rCORFY6WTbcK20efsziBuPgHoNDop7TV/mOgvmX6 vr+4ps/PjJiYLahDljEbcDMkhOw8qZr+HtzGv/NifYT0PRdpQjRdtQPMGKgnOixLl2 Z91rzFu5F7R8pXgqyw1mo2+zH/9f1HCu/C2BGrgw= Message-Id: <6.2.5.6.2.20130923234903.0c854c78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Sep 2013 01:21:12 -0700 To: Bjoern Hoehrmann From: SM In-Reply-To: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.d e> References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 08:30:40 -0000 Hi Bjoern, At 05:46 22-09-2013, Bjoern Hoehrmann wrote: >Another scenario is that the supposedly secure email system relies on >personal private long-term cryptographic secrets, and then the system >becomes popular. How long before helpful cloud backup and cross device >synchronisation systems compromise the keys? For that matter, how many >will surrender the keys freely to their web mail system, for spam and >virus checks, or a coupon? On Google's Android system you can get some >cloud backup service, but only if you let Google have all "your" Wi-Fi >passwords (which often aren't yours to share with Google). I'll comment on a part of the above only. The receiver no longer has the ability to perform spam and virus verifications when the message (body) is encrypted. The receiver can ask the users for their keys to perform those verifications. That is already done in unrelated scenarios and some of the users hand over their passwords [1]. The question I would ask is what is the secure email system supposed to provide to the user. Regards, -sm 1. I am not arguing that it is okay to do that. From stephen.farrell@cs.tcd.ie Tue Sep 24 01:36:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A50A21F9654 for ; Tue, 24 Sep 2013 01:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.839 X-Spam-Level: X-Spam-Status: No, score=-102.839 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eqTRbrI790C for ; Tue, 24 Sep 2013 01:36:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAE221F9634 for ; Tue, 24 Sep 2013 01:36:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 787E3BE74; Tue, 24 Sep 2013 09:36:17 +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 KY2hVt7MHcG4; Tue, 24 Sep 2013 09:36:17 +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 506BEBE73; Tue, 24 Sep 2013 09:36:17 +0100 (IST) Message-ID: <52414F01.7010606@cs.tcd.ie> Date: Tue, 24 Sep 2013 09:36:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ben Laurie References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> <52383CAE.10105@cs.tcd.ie> <1379420277.11365.23001593.66645932@webmail.messagingengine.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mark Handley , perpass , Scott Brim Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 08:36:24 -0000 Hi Ben, Mark, On 09/17/2013 05:15 PM, Ben Laurie wrote: > On 17 September 2013 13:17, Mark Handley wrote: >> >> On Tue, Sep 17, 2013, at 04:40 AM, Scott Brim wrote: >> >> With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly so >> interesting. >> >> QUIC is pretty interesting as a protocol and does a lot of things that TCP >> should have evolved to do. From a security point of view, if I understand >> the design documents correctly, it's really a drop-in replacement for >> TLS/TCP. Thus it seems to suffer from the same issues TLS does - not >> enabled sufficiently frequently (you can argue about why, but we've been >> doing that for a very long time), and dependence on the CA infrastructure. >> Thus it seems likely to be mostly deployed in places that already do TLS. >> >> QUIC could, of course, take the same approach as tcpcrypt. Do encryption by >> default using ephemeral public keys, even with no configuration, but provide >> the hooks to enable various forms of authentication. From what I've read, >> it doesn't seem to do that. Please correct me if I misunderstood though. > > You are right, but there's no reason not to extend QUIC to do > ephemeral encryption. That wasn't the use case we were thinking about > when we designed it. > > Seems like a useful thing for the IETF to consider. So does someone have some concrete next steps in this master plan? (Which sounds interesting to me at least.) Maybe make a proposal to the tcpm wg to adopt tcpcrypt, examine tcpcrypt as an approach for mptcp and then start on a QUIC-with-similar-crypto or something? If its too early for that last step, is someone gonna propose one or both of the others? Or something else? This being the IETF, someone needs to push it along or nothing will happen. Cheers, S. From stephen.farrell@cs.tcd.ie Tue Sep 24 01:43:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8A621F9F62 for ; Tue, 24 Sep 2013 01:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.824 X-Spam-Level: X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h42N7NUlrj2N for ; Tue, 24 Sep 2013 01:43:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0098A21F9BB6 for ; Tue, 24 Sep 2013 01:43:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5A9BEBE73 for ; Tue, 24 Sep 2013 09:43:51 +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 MITwZnac3bVR for ; Tue, 24 Sep 2013 09:43:51 +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 D235CBE7D for ; Tue, 24 Sep 2013 09:43:50 +0100 (IST) Message-ID: <524150C7.2020602@cs.tcd.ie> Date: Tue, 24 Sep 2013 09:43:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 08:43:56 -0000 Hiya, I've not seen mention of this so far here that I recall. Even as we improve the security of loads of protocols, there will still be issues with meta-data monitoring based on DNS queries for example. This point was sort of raised on the IETF list e.g. in [1]. DNSSEC doesn't provide any confidentiality. There are proposals that do try do that. Do we think this is worth looking at? If so, anyone up for doing some work on that? If so, how, or starting from what? S. [1] http://www.ietf.org/mail-archive/web/ietf/current/msg82696.html From benl@google.com Tue Sep 24 03:21:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFD121F9649 for ; Tue, 24 Sep 2013 03:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa5KapCWEpIQ for ; Tue, 24 Sep 2013 03:21:17 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D55B421E8056 for ; Tue, 24 Sep 2013 03:21:12 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id e14so8840651iej.34 for ; Tue, 24 Sep 2013 03:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6sDLm4FzKJhSyK7a/2zZrFDheN50HPUP8uXndZEd9nA=; b=mEXYCrQmHdQaIPdR+DWhH/f9UtbLhheob/1T0lgcL/2qJMg5g7nA8SIPom0CUfsFJB LTEOpbT7nQfRBPEa1GFvSQNOipJUKaD8EMCqkZL9yFWnasc5Rs68SkmNAN4pI9o85bvQ LTz8vhqxP+x4UfTT3+u9FOxGzu0uaVlAWkAc43P9SYh0GAK/bo47AYGlW5Jxict78S5W TJ0J5GYc6NkUd0gLDnITBkVT52904w/2x8Laj0pPWeDDXWV8JqSXbERm5qRnCQz/koOc YqA/R4TGnd8/3zTwjU6rEssN9SaNikWVDgLReFSMFTZThFPX4EJnbtmUivC8HvIoZhly AwoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6sDLm4FzKJhSyK7a/2zZrFDheN50HPUP8uXndZEd9nA=; b=YLVBxx3iMJp43TiaXnycKtQqJlHkwcsVWAuEJd96qyEykNB9IOhl/GvU6Wm42SklYn 2ScDdz2kgOBY9lAMkKcKb1y+ixKS44VHTaSDKNH5w6dkWeIVBJz5kViOWRnplaaKU/+D 8kzIaSVhT8KVofo1sBqM9xi5QV8Y3pl+pUR6Vc/EE7qZNl8HjsxUVwwRuUlQs+S6jKMj TUoVaM48JYI+9270CAzCx8USNJGdCsMg1gPRyfhrv1Pw2kqOvsbXNO5Uh2rAZFanc0WL IoqgBpeLyJrwXiZ//fLOsctXOeUWaoZvSlPLMwXgUvAmSQbBDJCmJFl7+kBE/hJRuyet 3T4A== X-Gm-Message-State: ALoCoQkoG1bexvNZ7+uT91PMubfv4WD6qaAvtVM9pldBk3uOpcsnGHNmj6Lnv1b/wrAwbN7O83ux43Gogxf0IOHq9l6wVp/1UVkgqrN5RZZwBO/wmh0Z+6nKqXYWE4vft6Cf/Ys+dcvF2HR17p6eVXfM8nGstb9D2+1B/ChZyvem7sP2xs0lNDgl/dKvnlDeRXKScwpRUkbq MIME-Version: 1.0 X-Received: by 10.43.151.12 with SMTP id kq12mr8400569icc.55.1380018072111; Tue, 24 Sep 2013 03:21:12 -0700 (PDT) Received: by 10.64.230.140 with HTTP; Tue, 24 Sep 2013 03:21:11 -0700 (PDT) In-Reply-To: <52414F01.7010606@cs.tcd.ie> References: <1379416419.15120.22982881.17FB934A@webmail.messagingengine.com> <52383CAE.10105@cs.tcd.ie> <1379420277.11365.23001593.66645932@webmail.messagingengine.com> <52414F01.7010606@cs.tcd.ie> Date: Tue, 24 Sep 2013 11:21:11 +0100 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: Mark Handley , perpass , Scott Brim Subject: Re: [perpass] tcpcrypt - worth another look? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 10:21:18 -0000 On 24 September 2013 09:36, Stephen Farrell wrote: > > Hi Ben, Mark, > > On 09/17/2013 05:15 PM, Ben Laurie wrote: >> On 17 September 2013 13:17, Mark Handley wrote: >>> >>> On Tue, Sep 17, 2013, at 04:40 AM, Scott Brim wrote: >>> >>> With the entire web moving To UDP and QUIC, tcpcrypt isn't nearly so >>> interesting. >>> >>> QUIC is pretty interesting as a protocol and does a lot of things that TCP >>> should have evolved to do. From a security point of view, if I understand >>> the design documents correctly, it's really a drop-in replacement for >>> TLS/TCP. Thus it seems to suffer from the same issues TLS does - not >>> enabled sufficiently frequently (you can argue about why, but we've been >>> doing that for a very long time), and dependence on the CA infrastructure. >>> Thus it seems likely to be mostly deployed in places that already do TLS. >>> >>> QUIC could, of course, take the same approach as tcpcrypt. Do encryption by >>> default using ephemeral public keys, even with no configuration, but provide >>> the hooks to enable various forms of authentication. From what I've read, >>> it doesn't seem to do that. Please correct me if I misunderstood though. >> >> You are right, but there's no reason not to extend QUIC to do >> ephemeral encryption. That wasn't the use case we were thinking about >> when we designed it. >> >> Seems like a useful thing for the IETF to consider. > > So does someone have some concrete next steps in this master > plan? (Which sounds interesting to me at least.) > > Maybe make a proposal to the tcpm wg to adopt tcpcrypt, > examine tcpcrypt as an approach for mptcp and then start > on a QUIC-with-similar-crypto or something? > > If its too early for that last step, is someone gonna > propose one or both of the others? We're certainly interested in bringing QUIC to the IETF. Extending it for ephemeral sounds like a useful thing to me. > > Or something else? > > This being the IETF, someone needs to push it along or > nothing will happen. > > Cheers, > S. > From simon@josefsson.org Tue Sep 24 03:48:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7321F9CAF for ; Tue, 24 Sep 2013 03:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO48FawiDU2y for ; Tue, 24 Sep 2013 03:48:24 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id DA4CE21F8E1F for ; Tue, 24 Sep 2013 03:48:23 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OAm1GD006837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 12:48:04 +0200 From: Simon Josefsson To: Karl Malbrain References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> <1379445547.56870.YahooMailNeo@web125503.mail.ne1.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130924:stephen.farrell@cs.tcd.ie::Ak59LwNK1T8xk7AP:aIb X-Hashcash: 1:22:130924:perpass@ietf.org::yKyLJg/Jh8syyvxl:B/UE X-Hashcash: 1:22:130924:malbrain@yahoo.com::2XxSFxiJTVJVa1RC:Ux01 Date: Tue, 24 Sep 2013 12:48:00 +0200 In-Reply-To: <1379445547.56870.YahooMailNeo@web125503.mail.ne1.yahoo.com> (Karl Malbrain's message of "Tue, 17 Sep 2013 12:19:07 -0700 (PDT)") Message-ID: <87k3i6pkbj.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: perpass , Stephen Farrell Subject: Re: [perpass] tld strong authentication deployment draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 10:48:24 -0000 Karl Malbrain writes: > I've uploaded a draft on tls strong authentication deployment: >   > http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication > Any comments would be appreciated. I believe that anything based on DNS is the wrong way forward if your problem statement involve well funded adversaries. I think DNS-based distribution of keying material is a good way to simplify and bootstrap opportunistic encrypted channels, however, it would not provide strong authentication in the way that I would like to define it. /Simon From andrewgwilson@gmail.com Tue Sep 24 04:31:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E4F11E8118 for ; Tue, 24 Sep 2013 04:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmRnzLn3NpbO for ; Tue, 24 Sep 2013 04:31:13 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 79E0211E8116 for ; Tue, 24 Sep 2013 04:31:11 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id mx11so1620779bkb.18 for ; Tue, 24 Sep 2013 04:31:10 -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; bh=6b+Pj7QWvRuUHwTl1zb+NFvgkef6xU7Gd/FMf9k7byQ=; b=S3BfyFbqbEWhOvKnffZYRZ1+UK+Tja1gS3xoX8mWuBDPTpQHhBcsQFQDlmKSWenwrn 4rEHeKo3zJAOoBYhAz0x9sEK4mIi8XbJj6VSCul4RtwUoAMDg21JDuALPXrvBAhNkNaU GxP8C8yvSok7DqDHVXnrexnklRqoLk2+h2pc1XPCZVGJPS9SRp1yu33vnWEvkvJi0/BL 2jzz77u6dR9yUgQ2238h2mSX56N9SxcpMg3Hsa1VDSLEttIXGGcP9VCuC9tMHFHt1GY/ Qae5bUqUTZezsYNVnEfVAFafBbIPMmr8aITzoHYxPWcj858IZbC0XNYW2gSYiIqHAJEJ YXqw== MIME-Version: 1.0 X-Received: by 10.204.168.197 with SMTP id v5mr22361929bky.24.1380022270379; Tue, 24 Sep 2013 04:31:10 -0700 (PDT) Received: by 10.205.18.193 with HTTP; Tue, 24 Sep 2013 04:31:10 -0700 (PDT) In-Reply-To: <524150C7.2020602@cs.tcd.ie> References: <524150C7.2020602@cs.tcd.ie> Date: Tue, 24 Sep 2013 23:31:10 +1200 Message-ID: From: Andy Wilson To: Stephen Farrell Content-Type: multipart/alternative; boundary=bcaec52c5efb357d1c04e71f79ed Cc: perpass Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 11:31:14 -0000 --bcaec52c5efb357d1c04e71f79ed Content-Type: text/plain; charset=UTF-8 Have you seen DNSCurve? http://dnscurve.org/ There are a few opensource implementations of it out there, OpenDNS for one have implemented it on their resolvers On 24 September 2013 20:43, Stephen Farrell wrote: > > Hiya, > > I've not seen mention of this so far here that I recall. > > Even as we improve the security of loads of protocols, there > will still be issues with meta-data monitoring based on > DNS queries for example. This point was sort of raised on > the IETF list e.g. in [1]. > > DNSSEC doesn't provide any confidentiality. There are > proposals that do try do that. > > Do we think this is worth looking at? > If so, anyone up for doing some work on that? > If so, how, or starting from what? > > S. > > [1] http://www.ietf.org/mail-archive/web/ietf/current/msg82696.html > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > -- Regards Andy --bcaec52c5efb357d1c04e71f79ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Have you seen DNSCurve?=C2=A0http://dnscurve.org/
There are a few opensource implementations= of it out there, OpenDNS for one have implemented it on their resolvers


On 24 Septemb= er 2013 20:43, Stephen Farrell <stephen.farrell@cs.tcd.ie><= /span> wrote:

Hiya,

I've not seen mention of this so far here that I recall.

Even as we improve the security of loads of protocols, there
will still be issues with meta-data monitoring based on
DNS queries for example. This point was sort of raised on
the IETF list e.g. in [1].

DNSSEC doesn't provide any confidentiality. There are
proposals that do try do that.

Do we think this is worth looking at?
If so, anyone up for doing some work on that?
If so, how, or starting from what?

S.

[1] http://www.ietf.org/mail-archive/web/ietf/current/ms= g82696.html
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass



--
Regards
<= br>Andy
--bcaec52c5efb357d1c04e71f79ed-- From stpeter@stpeter.im Tue Sep 24 05:30:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398D311E8110 for ; Tue, 24 Sep 2013 05:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.257 X-Spam-Level: X-Spam-Status: No, score=-102.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyHdaoOKKD5v for ; Tue, 24 Sep 2013 05:29:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6AB11E8120 for ; Tue, 24 Sep 2013 05:29:59 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F20F7415DF; Tue, 24 Sep 2013 06:35:08 -0600 (MDT) Message-ID: <524185C7.9000209@stpeter.im> Date: Tue, 24 Sep 2013 06:29:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Josefsson References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> <1379445547.56870.YahooMailNeo@web125503.mail.ne1.yahoo.com> <87k3i6pkbj.fsf@latte.josefsson.org> In-Reply-To: <87k3i6pkbj.fsf@latte.josefsson.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , Karl Malbrain , Stephen Farrell Subject: Re: [perpass] tld strong authentication deployment draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:30:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/24/13 4:48 AM, Simon Josefsson wrote: > Karl Malbrain writes: > >> I've uploaded a draft on tls strong authentication deployment: >> >> http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication >> >> Any comments would be appreciated. > > I believe that anything based on DNS is the wrong way forward if > your problem statement involve well funded adversaries. I think > DNS-based distribution of keying material is a good way to simplify > and bootstrap opportunistic encrypted channels, however, it would > not provide strong authentication in the way that I would like to > define it. Agreed. Unfortunately, it seems that we need to build on more solid foundations than most of today's Internet provides. I'd include centralized ISPs in the list of structures that are problematic. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQYXHAAoJEOoGpJErxa2pqVYP/0tRBMf1bYoTtwuoerS3/6jF pCGul2CM9w8D+yJW98j6HzepL34SrUN7utnhsLKGMgMduIYNdI0DdcMOIMwufIdn C7ZDGd4ZycUNI7cYo8zDTDF6Me13yijIKae4Nl/r2XFnndQ1z7Sr3/mezGt+6sf6 WiyrwT7Bjyo/W7xDPwm/SjB8cNLYHjuYHNwoVegYsBaZTTjTwm8/qmWKoSnOFJLC qhdtWeIJSgKcbAN5OSZEGYdDP1ZsVBvGTwpy4yI7Bt737Dsac4+qaZwJFpN3nM3p Au36N6FGHiuVvAb0o48Mdmyr+HU0tbuxm2krg6EqfJdZbOIWZuFSnFTopNuNTSKP 2g8pdSZjhdY8lKOqvB+J6BvBajaynsMwsPiaFE+ysMU7gEOWxyWU+bHXC/rz7LLh V05UMP0OHwGwGjkojL4Em11pS9Tb/lwqnH5Yjla2NO4CggUt9r4Hx7LFOJQh3qNG +FaO+RLpuTPWwMu0scfJEvNQeiuKkoV6mvdI08HefOznSkajT2py+dsLDxK9Komh u/YXCT/T4oPMpItVzsuZFjlxWEa426RySXEgMYqL964fNiwaLhVpLB8NwoQnwWQr f3/e/msbtaZXmxpiKnUsFUheBXgLEbkcOrZGzR7xeLq3N94/Y5aDrk0TFl6yjwSg FmvZc/M8ZduQBMUsQ/R5 =ZncW -----END PGP SIGNATURE----- From derhoermi@gmx.net Tue Sep 24 05:49:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C986611E8126 for ; Tue, 24 Sep 2013 05:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jldmuvfqecvn for ; Tue, 24 Sep 2013 05:49:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEAA11E811F for ; Tue, 24 Sep 2013 05:49:14 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.39.163]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0McUnM-1V6vAO094a-00HjO5 for ; Tue, 24 Sep 2013 14:49:12 +0200 From: Bjoern Hoehrmann To: SM Date: Tue, 24 Sep 2013 14:49:12 +0200 Message-ID: References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.d e> <6.2.5.6.2.20130923234903.0c854c78@resistor.net> In-Reply-To: <6.2.5.6.2.20130923234903.0c854c78@resistor.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:HUcxAvd8tHyhbRhxb9hAEgX7p74eKfNjSnqDLY21JzGx0fDRfww 2reBymvA+6a+ZsOTOAA1pxKAzh3j5AD3YBXHtSIGUkbTNzkb629UjenhiblwjXCGrvG8860 s4lSEAYHaMGgEDQ3YUaeHWhzEqmDl22Cm633YjpuIHqU/61nrIbTh9zAl0ibe0isYzC/tAy WF9Xoj007rGT2zMXuD5OQ== Cc: perpass@ietf.org Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 12:49:19 -0000 * SM wrote: >At 05:46 22-09-2013, Bjoern Hoehrmann wrote: >>Another scenario is that the supposedly secure email system relies on >>personal private long-term cryptographic secrets, and then the system >>becomes popular. How long before helpful cloud backup and cross device >>synchronisation systems compromise the keys? For that matter, how many >>will surrender the keys freely to their web mail system, for spam and >>virus checks, or a coupon? On Google's Android system you can get some >>cloud backup service, but only if you let Google have all "your" Wi-Fi >>passwords (which often aren't yours to share with Google). > >I'll comment on a part of the above only. The receiver no longer has >the ability to perform spam and virus verifications when the message >(body) is encrypted. The receiver can ask the users for their keys >to perform those verifications. That is already done in unrelated >scenarios and some of the users hand over their passwords [1]. Whoever is meant to read the message can perform, and ask others to perform, spam and virus checks as they see fit, with little need to reveal much about the message to third parties (by employing fully homomorphic encryption, generating noise, pulling blacklists in full instead of pushing specific items to a third party to check whether they are on the blacklist, for instance) and the ability to do so selectively (mails from people I have had a lot of contact with in the past do not need to be checked for spam, while I might not mind if strangers have to jump through extra hoops to send confidential mails to me). That's not on the path of least resistance, of course. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From malbrain@yahoo.com Tue Sep 24 13:31:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FED321F9AB4 for ; Tue, 24 Sep 2013 13:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb2Z17dbRB-q for ; Tue, 24 Sep 2013 13:31:09 -0700 (PDT) Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 227D421F9A8C for ; Tue, 24 Sep 2013 13:31:08 -0700 (PDT) Received: from [98.139.212.144] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2013 20:31:06 -0000 Received: from [98.139.212.211] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2013 20:31:06 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 24 Sep 2013 20:31:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 381826.75378.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 62536 invoked by uid 60001); 24 Sep 2013 20:31:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380054665; bh=9i7bVHh1pmn+hdS7q+45MgJLyS01/0l3ih+FVa2Yfy0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=F3+35hky0PJUOdtL85VHQa35Sq7+UZ4m3Uy25izsLn615VsinY7G1oTZ/QrdIqr+6weoRhHsQwOYZsFEhFvC9wSHSBQRaDEymZRLJLtgAmAVJOF5KSOtkcODbVIROihDvtzwW7XFDmz7ipnITsym7wioyaAQaMOX67DLhHGKGlw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tMARgAfVaS8l7neW5Cs4dfn4ajxFn3P3qOgmNcPl7IFVbRFe5VFia+osEsh2jmD5/10o3Mt3mGy4QZF8GDcjqrXXWmmJ0YbhpZvND0zxmhiZ04V/9XYkCXZEaF1baaJpy5FrJxc1w8kjyT3SngX4l+6qdpeBPp225YukiTpJGpc=; X-YMail-OSG: tzBKu.gVM1kSgdHn3a62Lo3fg9pW2lpTf7m1mrOSGkvvrLu sa3v6HT3CXlc4W91l1ETR7I_O4a9.lnb.o7YkcVsIx8jnrrM2FI.vcQKEP2v FkykGsGSUqecePNI1jSTy800Isl9VitVMrXj2P9Unfm7cBU5DjYEykFZ73DY VeM8u8OB9ESUbEflXdjygRHf.NQTqruTfh9rOHCMYAOAsy5NlnaODSGF2BeE L6DgAIq_gU29v.Ta5EETFXe20i_NljW7caRu0s0gYxWqjAom6qmM3Hwu2CcY mOWyYhzSTAcQKq9AdBYYUnuK5r4qJ2.l1XZFMIWlkzgyMTDEBUHmd82Jy0Pj 1gqTOvCpJmkcyerJLBHDyM_YV33LZ5Yp0Drsf4rY9EET17iDb1BdTHQxMzLF mvybUVfmjgQir88I20.1hfYs5XI.YImskQIEvyOQCxWTD9eyO_3scBEEr_ch fhw3fl8qOI.xsG6tvb4p7EoR_UCEx4fr_w9XSBDszS1aTKElAVx6gvZjnUfV fabmrx4rbCIb_LI5d_CPqrt4cz0idgS1ACL4IiuSu.sr6qW7Va9zIspLI9Sy bN8axjTaEvfcB5g5l8fOQ9syq_Z0f37CG Received: from [50.201.233.2] by web125505.mail.ne1.yahoo.com via HTTP; Tue, 24 Sep 2013 13:31:05 PDT X-Rocket-MIMEInfo: 002.001, VG8gb2J2aWF0ZSB0aGUgaGFydmVzdGluZyBvZiBtZXRhLWRhdGEsIHdlIGRvIG5lZWQgYSBzZWN1cmUgaW50ZXJmYWNlIHRvIEROUy4KwqAKTUlUTSByZXNpc3RhbmNlIChhdXRoZW50aWNhdGlvbikgaXMgYWxzbyBnb2luZyB0byBiZSByZXF1aXJlZCBpbiBETlMgc2VydmVyIGNvbm5lY3Rpb25zLiBNYXliZSB3ZWxsIGtub3duIGNlcnRpZmljYXRlcyBmb3IgRE5TIHNlcnZlcnPCoGluY29ycG9yYXRlZCBpbnRvIGJyb3dzZXIgc29mdHdhcmUKwqAKR2l2ZW4gdGhlIHJlbHVjdGFuY2Ugb2YgYnJvd3NlciB3cmkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <524150C7.2020602@cs.tcd.ie> Message-ID: <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> Date: Tue, 24 Sep 2013 13:31:05 -0700 (PDT) From: Karl Malbrain To: Stephen Farrell , perpass In-Reply-To: <524150C7.2020602@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-781490481-1923434291-1380054665=:62304" Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 20:31:15 -0000 ---781490481-1923434291-1380054665=:62304 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable To obviate the harvesting of meta-data, we do need a secure interface to DN= S.=0A=A0=0AMITM resistance (authentication) is also going to be required in= DNS server connections. Maybe well known certificates for DNS servers=A0in= corporated into browser software=0A=A0=0AGiven the reluctance of browser wr= iters=A0to implement DANE,=A0 we're going to need something like encrypted = QUIC available as a transport first.=0A=A0=0AKarl Malbrain=A0 =0A =0A=0A___= _____________________________=0A From: Stephen Farrell =0ATo: perpass =0ASent: Tuesday, September 24, 20= 13 1:43 AM=0ASubject: [perpass] DNS confidentiality=0A =0A=0A=0AHiya,=0A= =0AI've not seen mention of this so far here that I recall.=0A=0AEven as we= improve the security of loads of protocols, there=0Awill still be issues w= ith meta-data monitoring based on=0ADNS queries for example. This point was= sort of raised on=0Athe IETF list e.g. in [1].=0A=0ADNSSEC doesn't provide= any confidentiality. There are=0Aproposals that do try do that.=0A=0ADo we= think this is worth looking at?=0AIf so, anyone up for doing some work on = that?=0AIf so, how, or starting from what?=0A=0AS.=0A=0A[1] http://www.ietf= .org/mail-archive/web/ietf/current/msg82696.html=0A________________________= _______________________=0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps:/= /www.ietf.org/mailman/listinfo/perpass ---781490481-1923434291-1380054665=:62304 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
To obviate= the harvesting of meta-data, we do need a secure interface to DNS.<= /div>
 
MITM resistance (authenticati= on) is also going to be required in DNS server connections. Maybe well know= n certificates for DNS servers incorporated into browser software
 
Given the reluctance of br= owser writers to implement DANE,  we're going to need something l= ike encrypted QUIC available as a transport first.
<= /span> 
Karl Malbrain 

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>= ;
To: perpass <perp= ass@ietf.org>
Sent: Tuesday, September 24, 2013 1:43 AM
Subject: [perpass] DNS confidentiality
<= div class=3D"y_msg_container">

Hiya,

I've not seen mention of= this so far here that I recall.

Even as we improve the security of = loads of protocols, there
will still be issues with meta-data monitoring= based on
DNS queries for example. This point was sort of raised on
t= he IETF list e.g. in [1].

DNSSEC doesn't provide any confidentiality= . There are
proposals that do try do that.

Do we think this is worth loo= king at?
If so, anyone up for doing some work on that?
If so, how, or= starting from what?

S.

[1] http://www.iet= f.org/mail-archive/web/ietf/current/msg82696.html
__________________= _____________________________
perpass mailing list
perpass@ietf.org<= br>https://www.ietf.org/mailman/listinfo/perpass


---781490481-1923434291-1380054665=:62304-- From malbrain@yahoo.com Tue Sep 24 13:39:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29BA21F8EA8 for ; Tue, 24 Sep 2013 13:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-5oW9HRM9Ls for ; Tue, 24 Sep 2013 13:39:37 -0700 (PDT) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id B1D1421F9D96 for ; Tue, 24 Sep 2013 13:39:35 -0700 (PDT) Received: from [98.139.212.148] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2013 20:39:34 -0000 Received: from [98.139.212.216] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 24 Sep 2013 20:39:34 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 24 Sep 2013 20:39:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 767764.35971.bm@omp1025.mail.bf1.yahoo.com Received: (qmail 35952 invoked by uid 60001); 24 Sep 2013 20:39:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380055173; bh=USyF06c1JauAsKO8AOZahxYCJWzURRTgqy3MlyVDTVw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=w9EejLRkz/tLtSI9g5hPH2QnPSz91wFgqkCVvYn9ZF9RC9bT2tvCH1Q12taTF6cfN4/12vhj/pNUdpckfPJ2Cq4PuaOnoRHBok5j/xUV9wioZTnSJrmQx68rHsZzTA8EHi5lrjxqePBYy39KS0pkqAiQ4ioyGJGyNlLFoDtOl1M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=owbUc4dmaOLaDsyE6lL/KEdfaczhZOsLZw9bFHNLX7rrNZfxg9EMIRSKy2ZRMyodPlIW2IxX/F9AnXFy1KSKgHj+4LOFK41Z7ElxK0fgP3o7n66yRlG0VF/RQ2ATDsus4uVKvrBbAlW+l3Wh5y7Il4n08/P3zenwzXDgCFYG1xY=; X-YMail-OSG: 4gw7c84VM1lP_7sn75scYNr6zIC2hrPY8UQuFH0pyLwptoQ OfZGCcPF1O..NeisoJkDRHbcNxmXbPVpjwU_.NNDJ8V2Gm9EXC5_P0pzKOkd OEtWG_HnHumhAwFNDwM7y3U6KhjTOVRUoCnkNgACf2xQFETdRH9vyMViyEMt myWCdmMdtRFoptbnWomr5uWGVgmIFkANgBeNvKbofR1RtIrx9WDnhj70hOvl RGPlNxe_oAQLxB9YIp0shLQnixXpV4bP5V7dPu0BeEUXWlgDCm7PLsygbHTV 5Vfx5gYtAgyRDCHSuOCC4SpUa2zer2VOt9O5Bo64DgU1kXPQ0Q.8Q4YK6mW_ iBQ_vWgUm7mUgaQCyWNJ_PSsplZvqjZw55oFxCxqj2qv6I55d_oxapWNxH_2 aO3er9hVyKTZertTkLBQKD4ij_npm5wAFf3F7l7AiLtI6zUiKwb.pOl_eNvy YeH484GBVRpmuxyGJs7W0AAiNQ7XMK_FeK2v0MdhVcoHm9wCuUmPNRQGASSE FFKw3tU43gt.bDonXHN_rbnfwDYzyNXpqPUY4deEfPenpLbXB2eIIDOukcO8 UczO8R357vMRY1UanWYRSXsjGCkbVGhNBvlxFnQ-- Received: from [50.201.233.2] by web125503.mail.ne1.yahoo.com via HTTP; Tue, 24 Sep 2013 13:39:33 PDT X-Rocket-MIMEInfo: 002.001, SSd2ZSBiZWd1biB0byBwcm9wb3NlIGFuIGFsdGVybmF0aXZlIHRvIEROUy9EQU5FLCB0aGXCoFBFUlNQRUNUSVZFUyBwcm9qZWN0IGZyb20gQ01VLCBpbiB2ZXJzaW9uIDAxIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudDogaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYWxicmFpbi10bHMtc3Ryb25nLWF1dGhlbnRpY2F0aW9uLgrCoApIYXZlIHlvdSBjb25zaWRlcmVkIHdoYXQgY2hhbmdlcyB0byB0aGUgRE5TIHN5c3RlbSB3b3VsZCBhZGRyZXNzIHlvdXIgY29uY2VybnM_wqAgSSd2ZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> <1379445547.56870.YahooMailNeo@web125503.mail.ne1.yahoo.com> <87k3i6pkbj.fsf@latte.josefsson.org> Message-ID: <1380055173.35886.YahooMailNeo@web125503.mail.ne1.yahoo.com> Date: Tue, 24 Sep 2013 13:39:33 -0700 (PDT) From: Karl Malbrain To: Simon Josefsson In-Reply-To: <87k3i6pkbj.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2005986409-1660849184-1380055173=:35886" Cc: perpass , Stephen Farrell Subject: Re: [perpass] tld strong authentication deployment draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 20:39:42 -0000 ---2005986409-1660849184-1380055173=:35886 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've begun to propose an alternative to DNS/DANE, the=A0PERSPECTIVES projec= t from CMU, in version 01 of the problem statement: http://datatracker.ietf= .org/doc/draft-malbrain-tls-strong-authentication.=0A=A0=0AHave you conside= red what changes to the DNS system would address your concerns?=A0 I've pro= posed encrypted and authenticated connections in another thread.=0A=A0=0AKa= rl Malbrain=0A =0A=0A________________________________=0A From: Simon Josefs= son =0ATo: Karl Malbrain =0ACc: p= erpass ; Stephen Farrell =0AS= ent: Tuesday, September 24, 2013 3:48 AM=0ASubject: Re: [perpass] tld stron= g authentication deployment draft=0A =0A=0AKarl Malbrain writes:=0A=0A> I've uploaded a draft on tls strong authentication deplo= yment:=0A> =A0=0A> http://datatracker.ietf.org/doc/draft-malbrain-tls-stron= g-authentication=0A> Any comments would be appreciated.=0A=0AI believe that= anything based on DNS is the wrong way forward if your=0Aproblem statement= involve well funded adversaries.=A0 I think DNS-based=0Adistribution of ke= ying material is a good way to simplify and bootstrap=0Aopportunistic encry= pted channels, however, it would not provide strong=0Aauthentication in the= way that I would like to define it.=0A=0A/Simon=0A________________________= _______________________=0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps:/= /www.ietf.org/mailman/listinfo/perpass ---2005986409-1660849184-1380055173=:35886 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've begun= to propose an alternative to DNS/DANE, the PERSPECTIVES project from = CMU, in version 01 of the problem statement: ht= tp://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication.=
 
Have you considered w= hat changes to the DNS system would address your concerns?  I've propo= sed encrypted and authenticated connections in another thread.
=
 
Karl Malbrain
From: Simon Josefsson <simon@josefsson.org>
= To: Karl Malbrain <malb= rain@yahoo.com>
Cc:= perpass <perpass@ietf.org>; Stephen Farrell <stephen.farrell@cs.t= cd.ie>
Sent: Tuesd= ay, September 24, 2013 3:48 AM
Su= bject: Re: [perpass] tld strong authentication deployment draft<= br>

Karl Malbrain <ma= lbrain@yahoo.com> writes:

> I've uploaded a draft on tls s= trong authentication deployment:
>  
> http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authenticatio= n
> Any comments would be appreciated.

I believe that anyt= hing based on DNS is the wrong way forward if your
problem statement inv= olve well funded adversaries.  I think DNS-based
distribution of ke= ying material is a good way to simplify and bootstrap
opportunistic encr= ypted channels, however, it would not provide strong
authentication in t= he way that I would like to define it.

/Simon
___________________= ____________________________
perpass mailing list
perpass@ietf.orghttps://www.ietf.org/mailman/listinfo/perpass

<= /div>
---2005986409-1660849184-1380055173=:35886-- From ietf@rozanak.com Tue Sep 24 14:09:11 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E95811E8167 for ; Tue, 24 Sep 2013 14:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlfvXsbyBLre for ; Tue, 24 Sep 2013 14:08:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D25B421F9B85 for ; Tue, 24 Sep 2013 14:08:47 -0700 (PDT) Received: from kopoli (g225191241.adsl.alicedsl.de [92.225.191.241]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lee62-1WEcWt3CF4-00qAaR; Tue, 24 Sep 2013 17:08:23 -0400 From: "Hosnieh Rafiee" To: "'Karl Malbrain'" References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> In-Reply-To: <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> Date: Tue, 24 Sep 2013 23:08:14 +0200 Message-ID: <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01CEB97A.F6E95AC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOGj5UkWbfuDhxpmMKtaAoIXGv7QHKq7oDmMhJ/mA= Content-Language: en-us X-Provags-ID: V02:K0:c2HIEsLHBlNKj/wgZMQa277jaxckG1AGICfxmUwjZS+ 19KMlZMe3kUQLp7liElXg911UQk8b6Z3VJLuDN+Qmr0tc41YYa ztnLhNp8mxWBy9pbX7QclR1id6eFeK9eKoeSJ5fBdJOyVY8V9I lwYwJsVvzSdTQACdD11s6LyFZCicAZIUUWcDZ4jhuonD+AeZp/ z2oL34ZOuW0VtwTYqXtOPLTKsrFDi/NkjXB7K5Lgm18xCcfXpi J/PWK2nKNozb+4cxxDZsLhit/ksBCQ35PE4BjitUVl6jMoWSNZ ULfAgCUQ7jw6k+6xToZMOsKA64oCIf7IEtBlglI03x9/3Chyzh gsEwnjtxfV1baCGRy5Ic= Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 21:09:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006B_01CEB97A.F6E95AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MITM attack can be prevented by signing the data. Please check cga-tsig draft. Hosnieh From: perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Behalf Of Karl Malbrain Sent: Tuesday, September 24, 2013 10:31 PM To: Stephen Farrell; perpass Subject: Re: [perpass] DNS confidentiality To obviate the harvesting of meta-data, we do need a secure interface to DNS. MITM resistance (authentication) is also going to be required in DNS server connections. Maybe well known certificates for DNS servers incorporated into browser software Given the reluctance of browser writers to implement DANE, we're going to need something like encrypted QUIC available as a transport first. Karl Malbrain From: Stephen Farrell To: perpass Sent: Tuesday, September 24, 2013 1:43 AM Subject: [perpass] DNS confidentiality Hiya, I've not seen mention of this so far here that I recall. Even as we improve the security of loads of protocols, there will still be issues with meta-data monitoring based on DNS queries for example. This point was sort of raised on the IETF list e.g. in [1]. DNSSEC doesn't provide any confidentiality. There are proposals that do try do that. Do we think this is worth looking at? If so, anyone up for doing some work on that? If so, how, or starting from what? S. [1] http://www.ietf.org/mail-archive/web/ietf/current/msg82696.html _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass ------=_NextPart_000_006B_01CEB97A.F6E95AC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MITM attack can be prevented by signing the data. Please check = cga-tsig draft.

 

 

Hosnieh

 

 

From:= = perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Behalf = Of Karl Malbrain
Sent: Tuesday, September 24, 2013 10:31 = PM
To: Stephen Farrell; perpass
Subject: Re: = [perpass] DNS confidentiality

 

To obviate the = harvesting of meta-data, we do need a secure interface to = DNS.

 

MITM resistance (authentication) is also going to = be required in DNS server connections. Maybe well known certificates for = DNS servers incorporated into browser = software

 

Given the reluctance of browser writers to = implement DANE,  we're going to need something like encrypted QUIC = available as a transport first.

 

Karl Malbrain  =

 

F= rom: = Stephen Farrell <stephen.farrell@cs.tcd.ie&g= t;
To: perpass <perpass@ietf.org> =
Sent: Tuesday, September 24, 2013 1:43 AM
Subject: = [perpass] DNS confidentiality



Hiya,

I've not seen mention of this = so far here that I recall.

Even as we improve the security of = loads of protocols, there
will still be issues with meta-data = monitoring based on
DNS queries for example. This point was sort of = raised on
the IETF list e.g. in [1].

DNSSEC doesn't provide = any confidentiality. There are
proposals that do try do = that.

Do we think this is worth looking at?
If so, anyone up = for doing some work on that?
If so, how, or starting from = what?

S.

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg82= 696.html
_______________________________________________
perpas= s mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

------=_NextPart_000_006B_01CEB97A.F6E95AC0-- From paul@cypherpunks.ca Tue Sep 24 14:11:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B980B21F9228 for ; Tue, 24 Sep 2013 14:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYTJG9H3tLwx for ; Tue, 24 Sep 2013 14:11:03 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id D122421F8F2A for ; Tue, 24 Sep 2013 14:10:59 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ckw6d4NB8z9Xn; Tue, 24 Sep 2013 17:10:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id zoOB-TwXpZlK; Tue, 24 Sep 2013 17:10:47 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 24 Sep 2013 17:10:47 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 98F668009E; Tue, 24 Sep 2013 17:10:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 682F58002E; Tue, 24 Sep 2013 17:10:47 -0400 (EDT) Date: Tue, 24 Sep 2013 17:10:47 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Karl Malbrain In-Reply-To: <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> Message-ID: References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: perpass , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 21:11:17 -0000 On Tue, 24 Sep 2013, Karl Malbrain wrote: > To obviate the harvesting of meta-data, we do need a secure interface to DNS. It might help but giving people urls that will trigger dns requests for tracking is pretty easy. Only something like tor might safeguard against that. > Given the reluctance of browser writers to implement DANE,  we're going to need something like encrypted QUIC available as a transport > first. There will be dane in browsers, once we ensure it is cheap enough on high latency devices. Eg see http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query-00 It's easy to add anonymous IPsec to open resolvers (and I'm in the process od doing so) but hiding DNS queries involves a lot more than just encrypting queries. Paul From simon@josefsson.org Tue Sep 24 14:11:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3FC21F93E4 for ; Tue, 24 Sep 2013 14:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbezAD8UelJy for ; Tue, 24 Sep 2013 14:11:20 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 1135C21F9005 for ; Tue, 24 Sep 2013 14:11:11 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OLB0ru021981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 23:11:02 +0200 Date: Tue, 24 Sep 2013 23:11:00 +0200 From: Simon Josefsson To: Karl Malbrain Message-ID: <20130924231100.6fcde98f@latte.josefsson.org> In-Reply-To: <1380055173.35886.YahooMailNeo@web125503.mail.ne1.yahoo.com> References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> <1379445547.56870.YahooMailNeo@web125503.mail.ne1.yahoo.com> <87k3i6pkbj.fsf@latte.josefsson.org> <1380055173.35886.YahooMailNeo@web125503.mail.ne1.yahoo.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: perpass , Stephen Farrell Subject: Re: [perpass] tld strong authentication deployment draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 21:11:21 -0000 I believe the perspectives approach is better, but it seems difficult to implement over the DNS since you can't escape its organizational warts. I think an approach like Certificate Transparency would be even better. /Simon You wrote: > I've begun to propose an alternative to DNS/DANE, the=A0PERSPECTIVES > project from CMU, in version 01 of the problem statement: > http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication. > Have you considered what changes to the DNS system would address your > concerns?=A0 I've proposed encrypted and authenticated connections in > another thread. Karl Malbrain=20 >=20 > ________________________________ > From: Simon Josefsson > To: Karl Malbrain =20 > Cc: perpass ; Stephen Farrell > Sent: Tuesday, September 24, 2013 3:48 AM > Subject: Re: [perpass] tld strong authentication deployment draft > =20 >=20 > Karl Malbrain writes: >=20 > > I've uploaded a draft on tls strong authentication deployment: > > =A0 > > http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication > > Any comments would be appreciated. >=20 > I believe that anything based on DNS is the wrong way forward if your > problem statement involve well funded adversaries.=A0 I think DNS-based > distribution of keying material is a good way to simplify and > bootstrap opportunistic encrypted channels, however, it would not > provide strong authentication in the way that I would like to define > it. >=20 > /Simon > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From paul@cypherpunks.ca Tue Sep 24 14:16:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2533811E816D for ; Tue, 24 Sep 2013 14:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phE9iTjl29Tf for ; Tue, 24 Sep 2013 14:16:21 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6234321F9BC4 for ; Tue, 24 Sep 2013 14:16:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ckwDt4RKNz9PB; Tue, 24 Sep 2013 17:16:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oGv0jzt6FYpH; Tue, 24 Sep 2013 17:16:13 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 24 Sep 2013 17:16:13 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 643728009E; Tue, 24 Sep 2013 17:16:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 56C148002E; Tue, 24 Sep 2013 17:16:14 -0400 (EDT) Date: Tue, 24 Sep 2013 17:16:14 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Karl Malbrain In-Reply-To: <1380055173.35886.YahooMailNeo@web125503.mail.ne1.yahoo.com> Message-ID: References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> <1379445547.56870.YahooMailNeo@web125503.mail.ne1.yahoo.com> <87k3i6pkbj.fsf@latte.josefsson.org> <1380055173.35886.YahooMailNeo@web125503.mail.ne1.yahoo.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: Simon Josefsson , perpass , Stephen Farrell Subject: Re: [perpass] tld strong authentication deployment draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 21:16:27 -0000 On Tue, 24 Sep 2013, Karl Malbrain wrote: > I've begun to propose an alternative to DNS/DANE, the PERSPECTIVES project from CMU, in version 01 of the problem statement: > http://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication. >   > Have you considered what changes to the DNS system would address your concerns?  I've proposed encrypted and authenticated connections > in another thread. strong authentication in clients will lead to less anonimity. What is wrong with the model of the (anonymous) client authenticating the TLS server against MITM, and than on that private channel, do client auth, eg via basic auth? I'm not sure what you are trying to solve by moving the client authentication from the inner protected layer to the outer layer. I'm also not sure what the draft is supposed to convey.... Paul From ned+perpass@mrochek.com Tue Sep 24 19:15:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E151411E819F for ; Tue, 24 Sep 2013 19:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BCezXltYHJS for ; Tue, 24 Sep 2013 19:15:15 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8293D11E81A3 for ; Tue, 24 Sep 2013 19:15:13 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OYT4J42SCW0047RH@mauve.mrochek.com> for perpass@ietf.org; Tue, 24 Sep 2013 19:10:11 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OYSWEERTPS00004S@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for perpass@ietf.org; Tue, 24 Sep 2013 19:10:08 -0700 (PDT) From: ned+perpass@mrochek.com Message-id: <01OYT4J2OJ3600004S@mauve.mrochek.com> Date: Tue, 24 Sep 2013 16:23:09 -0700 (PDT) In-reply-to: "Your message dated Tue, 24 Sep 2013 14:49:12 +0200" References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.d> <6.2.5.6.2.20130923234903.0c854c78@resistor.net> To: Bjoern Hoehrmann Cc: SM , perpass@ietf.org Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 02:15:21 -0000 > * SM wrote: > >At 05:46 22-09-2013, Bjoern Hoehrmann wrote: > >>Another scenario is that the supposedly secure email system relies on > >>personal private long-term cryptographic secrets, and then the system > >>becomes popular. How long before helpful cloud backup and cross device > >>synchronisation systems compromise the keys? For that matter, how many > >>will surrender the keys freely to their web mail system, for spam and > >>virus checks, or a coupon? On Google's Android system you can get some > >>cloud backup service, but only if you let Google have all "your" Wi-Fi > >>passwords (which often aren't yours to share with Google). > > > >I'll comment on a part of the above only. The receiver no longer has > >the ability to perform spam and virus verifications when the message > >(body) is encrypted. The receiver can ask the users for their keys > >to perform those verifications. That is already done in unrelated > >scenarios and some of the users hand over their passwords [1]. > Whoever is meant to read the message can perform, and ask others to > perform, spam and virus checks as they see fit, with little need to > reveal much about the message to third parties (by employing fully > homomorphic encryption, generating noise, pulling blacklists in full > instead of pushing specific items to a third party to check whether > they are on the blacklist, for instance) and the ability to do so > selectively (mails from people I have had a lot of contact with in > the past do not need to be checked for spam, while I might not mind > if strangers have to jump through extra hoops to send confidential > mails to me). That's not on the path of least resistance, of course. OK... So I believe the goal here to make it harder if not impossible to perform widespread surveilance on and interception of Internet traffic. In the case of email, meeting that goal with end-to-end encryption mechanisms like S/MIME or PGP is necessarily going to mean having a nonnegligable amount of email traffic encrypted. The minute that happens spammers are going to join the party in a big way precisely because of the ability this confers to get past transport-side content inspection and filtering. State of the art AS/AV vendors employ honeypots and other forms of feedback to rapidly generate rules, patterns, hashes, and other information, which is then rapidly distributed to filtering systems attached to vast numbers of ingress MTAs operated by their customers. Some of this filtering is done on the basis of IP addresses, envelope, or outer header information, but a lot of it depends on content analysis - analysis that will be blocked by encryption. Even so, nasty stuff still makes it through, so vendors also implement various schemes to "undeliver" mail containing malware that was only detected after the fact. These mechanisms are if anything even more dependent on content analysis than ingress filtering is. It follows that one effect of the widespread use of end-to-end encryption will be an *enormous* increase in the amount of spam and malware that can't be blocked at the transport layer and will end up getting delivered to user mailboxes. Irrespective of what happens to this email after delivery, it's going to represent a significant cost increase to ISPs and MSPs. Any plan to significantly increase the use of end-to-end encryption is going to have to address this issue. And as for what happens to spam and malware-laden email after delivery, one reason that things have shifted to a centralized scanning approach is it's been shown over and over and over again that end users cannot be relied upon to perform this sort of filtering themselves. So this is another issue that is going to have to be addressed - how filtering can done reliably at this stage. For better or worse, while the IETF has been spending time holding PGP key signing parties and designers the S/MIME extension du jour, the ISPs and MSPs have been busy building a vast infrastructure used by hundreds of millions if not billions of people that is heavily dependent on the *lack* of widespread use of end-to-end encryption. (The need for content analysis by AS/AV mechanisms is only one example of this; there are many others.) Any halfway realistic plan to deploy end-to-end encryption at Internet scale is going to have deal with the totality of contemporary email services and usage in addition to solving the myriad problems surrounding key/certificate distribution and management as well as UI issues. (As if the latter weren't difficult enough.) Finally, the desire to address the surveilance/intercept problem may be so strong that people may be tempted to dismiss these sorts of issues as "someone else's problem". So let me close by noting that quite a lot of spam originates from infected PCs, and is done by sending those messages using whatever submission mechanism that user uses, borrowing their credentials in the process. And if those credentials include a private key, that's going to be borrowed as well. Anything that increases the rate at which malware makes it to end user mail accounts is going to increase the rate of infection, and that in turn is going to compromise the integrity of the end-to-end security system you're trying to deploy. Ned From bortzmeyer@nic.fr Wed Sep 25 05:16:29 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E9021F92B7 for ; Wed, 25 Sep 2013 05:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcZiEmMMo-Ip for ; Wed, 25 Sep 2013 05:16:24 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE5B21F923D for ; Wed, 25 Sep 2013 05:16:24 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id A5F3A280627; Wed, 25 Sep 2013 14:15:51 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id A110D28060F; Wed, 25 Sep 2013 14:15:51 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay2.nic.fr (Postfix) with ESMTP id 9E7C8B38055; Wed, 25 Sep 2013 14:15:21 +0200 (CEST) Date: Wed, 25 Sep 2013 14:15:21 +0200 From: Stephane Bortzmeyer To: Andy Wilson Message-ID: <20130925121521.GA31952@nic.fr> References: <524150C7.2020602@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 7.1 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: perpass , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:16:29 -0000 On Tue, Sep 24, 2013 at 11:31:10PM +1200, Andy Wilson wrote a message of 104 lines which said: > Have you seen DNSCurve? http://dnscurve.org/ Channel-security solutions like the non-standard and poorly documented DNScurve provide confidentiality against a passive third-party observer. Not against the operators of the authoritative name servers who see a lot of traffic and can share it with others. (For instance, several of the root name servers are managed by the US army or a US government agency.) Not to mention the resolvers of the ISP or the big open resolvers like OpenDNS or Google Public DNS, both based in PRISMland. (They see even more since the caching does not "protect" against them.) To summary, modify DNS to ensure confidentiality is highly non-trivial. From benl@google.com Wed Sep 25 05:26:46 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CE721F9FA7 for ; Wed, 25 Sep 2013 05:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w30YHeRRDRx1 for ; Wed, 25 Sep 2013 05:26:46 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E05E621F9F08 for ; Wed, 25 Sep 2013 05:26:45 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so10895045ieb.0 for ; Wed, 25 Sep 2013 05:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8a6f7SC+j3uIU+5C6CeQvQR6pIxE/Q7XafaPR5Ioc4M=; b=gwn/H3LcAAE8WJIUk49JaEecGKapyolcV84cYJLtiALdHKx94Vsb8mBrQOD/oe9lln 7g71DLhm81qYxG2bkk2clZx8N9oYRHQnkAQT60OsP2/M0ifG6/sxCUw3WFr1HagGjEkv O3lWhssP5ojcAlVl+AWs9FvO6FNrHX9fC2A9TpEOkhXNSd1I2a4nwtmrWD+1OUK73A+y fKdpIyd7RhdOJJ+e811qOyN/T5nQWeqkKMERVNcs9VEcODFxazXpMYWwvPagFx9CORlB SgKEzwQI9wBOeCpafjz0sB+82wgPBZoVIPm1zjuaqow7dYh8etVTd5oHLvzrbrrc9y75 CQqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8a6f7SC+j3uIU+5C6CeQvQR6pIxE/Q7XafaPR5Ioc4M=; b=iLQnxC553w+3e+SfD03b30wgGRtH6/KGnJInnUgHPyJfFeHLTfvuIuhIE2Iu0xZn+P xMMxSVN6CiCePP0kMhNBewaGf11+Kx8KwSO8EvYUzN3JqidjV7PjSyWQm5eRcBbX9orH iMh0eA/dmph6gQKcKpu2k6xSIEcVFA4R6FOVJro7L04HwXXn8ZakNT5X8EVJkRhLliBo vbUyM3GNbWoaAIkJbyY/maI5uIhXkFmqs5PPKKr+6OImgUXCee52R/q7kexx8wyDa+Su EGUTSzpFwbX/OxeVqBMhcJrSk9uOL13NUO+iFCJ+Qu7tS+xobWdRW7aStgZA23guWyd2 TUbw== X-Gm-Message-State: ALoCoQmH0JhsRN/5xO+hgWDXd3pwGsXZ5G8mVifWfAOk2RCpyvW0kaZFR177mOd6gd/Uqwu5phhQoCC0YsCL++VVvZPFjK1Lp4GNHZ859Pgj80AIa/iwg2giRozYk20ly/0EwQoEbie/O5IC+XS3HLOR/O1rX/5AqMxD92SaMbiuSuQJXNTKavyLLVq0TIQZAVlTXwZl6F7p MIME-Version: 1.0 X-Received: by 10.42.97.71 with SMTP id m7mr19159335icn.33.1380112004085; Wed, 25 Sep 2013 05:26:44 -0700 (PDT) Received: by 10.64.230.140 with HTTP; Wed, 25 Sep 2013 05:26:43 -0700 (PDT) In-Reply-To: References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> Date: Wed, 25 Sep 2013 13:26:43 +0100 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Karl Malbrain , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:26:46 -0000 On 24 September 2013 22:10, Paul Wouters wrote: > On Tue, 24 Sep 2013, Karl Malbrain wrote: > >> To obviate the harvesting of meta-data, we do need a secure interface to >> DNS. > > > It might help but giving people urls that will trigger dns requests for > tracking is pretty easy. Only something like tor might safeguard against > that. Presumably the threat is not the provider of the URL but an observer of your traffic? From mark@handley.org.uk Wed Sep 25 05:31:43 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A2811E8103 for ; Wed, 25 Sep 2013 05:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZSePcWmDQxe for ; Wed, 25 Sep 2013 05:31:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id BA38D11E8102 for ; Wed, 25 Sep 2013 05:31:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9B31A20EAE; Wed, 25 Sep 2013 08:31:36 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Wed, 25 Sep 2013 08:31:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=TBE0lQ+cGnvUEiRn0AjLKc6vE00=; b=a0j os5bmLgMYPQ3Q5IvK+CNu++/1wNOs2WcleMlIwmKxt2XWcrP78KUd13rbgvEC/9C wd1xCAueTqEHfk1o9XwTl5t9/J/4bbgPU9uMuZDA3nMmZV1Mfr9fYRchAC+/Jfb9 aPs8xA5W6so5VAJj0hyd0NsMxn2YiyFa0Oqr9Ldk= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 6F35128D2EE; Wed, 25 Sep 2013 08:31:36 -0400 (EDT) Message-Id: <1380112296.24169.26259409.78E695F3@webmail.messagingengine.com> X-Sasl-Enc: s4srCbd1+o26VDbsoYAVcLjns9qgLAgA1cLjr4kFHdp0 1380112296 From: Mark Handley To: Stephane Bortzmeyer , Andy Wilson MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-df213e79 In-Reply-To: <20130925121521.GA31952@nic.fr> References: <524150C7.2020602@cs.tcd.ie> <20130925121521.GA31952@nic.fr> Date: Wed, 25 Sep 2013 05:31:36 -0700 Cc: perpass , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:31:43 -0000 On Wed, Sep 25, 2013, at 05:15 AM, Stephane Bortzmeyer wrote: > On Tue, Sep 24, 2013 at 11:31:10PM +1200, > Andy Wilson wrote=20 > a message of 104 lines which said: >=20 > > Have you seen DNSCurve? http://dnscurve.org/ >=20 > Channel-security solutions like the non-standard and poorly documented > DNScurve provide confidentiality against a passive third-party > observer. Not against the operators of the authoritative name servers > who see a lot of traffic and can share it with others. (For instance, > several of the root name servers are managed by the US army or a US > government agency.) >=20 > Not to mention the resolvers of the ISP or the big open resolvers like > OpenDNS or Google Public DNS, both based in PRISMland. (They see even > more since the caching does not "protect" against them.) A long time ago we looked into pushing DNS NS data in bulk, primarily as a way to make it more robust against DDoS attack. But solutions in this general space might also be used to improve privacy: http://www.cs.ucl.ac.uk/staff/m.handley/papers/dnspush.pdf=E2=80=8E Cheers, Mark From stephen.farrell@cs.tcd.ie Wed Sep 25 05:36:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A5211E8102 for ; Wed, 25 Sep 2013 05:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G+bkyrWJzBw for ; Wed, 25 Sep 2013 05:35:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B35E211E810A for ; Wed, 25 Sep 2013 05:35:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 21678BE51; Wed, 25 Sep 2013 13:35:54 +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 JBwPcd+IIudD; Wed, 25 Sep 2013 13:35:54 +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 F1F84BE2F; Wed, 25 Sep 2013 13:35:53 +0100 (IST) Message-ID: <5242D8AA.4040108@cs.tcd.ie> Date: Wed, 25 Sep 2013 13:35:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Stephane Bortzmeyer , Andy Wilson References: <524150C7.2020602@cs.tcd.ie> <20130925121521.GA31952@nic.fr> In-Reply-To: <20130925121521.GA31952@nic.fr> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:36:01 -0000 Hi Stephane, On 09/25/2013 01:15 PM, Stephane Bortzmeyer wrote: > On Tue, Sep 24, 2013 at 11:31:10PM +1200, > Andy Wilson wrote > a message of 104 lines which said: > >> Have you seen DNSCurve? http://dnscurve.org/ > > Channel-security solutions like the non-standard and poorly documented Non-standard we can fix and we do our best to help with poorly documented as well:-) > DNScurve provide confidentiality against a passive third-party > observer. Not against the operators of the authoritative name servers > who see a lot of traffic and can share it with others. (For instance, > several of the root name servers are managed by the US army or a US > government agency.) > > Not to mention the resolvers of the ISP or the big open resolvers like > OpenDNS or Google Public DNS, both based in PRISMland. (They see even > more since the caching does not "protect" against them.) > > To summary, modify DNS to ensure confidentiality is highly > non-trivial. Right, I agree its non-trivial and that some servers somewhere will see the queries and responses and could be part of a monitoring network via collusion or coercion or as a result of being hacked. I guess I'm wondering though if its worthwhile and if there are folks who'd be willing and able to do the work. Or at least some initial work - I don't think this is one where I'd expect its likely somoene can just write a nice short draft and be finished very quickly. S. > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From bortzmeyer@nic.fr Wed Sep 25 05:42:17 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E548E21F9F08 for ; Wed, 25 Sep 2013 05:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuoXSY5SXBq5 for ; Wed, 25 Sep 2013 05:42:01 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5E921F9E77 for ; Wed, 25 Sep 2013 05:42:00 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 9B73028062C; Wed, 25 Sep 2013 14:41:29 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 9665C280627; Wed, 25 Sep 2013 14:41:29 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay2.nic.fr (Postfix) with ESMTP id 8A667B38055; Wed, 25 Sep 2013 14:40:59 +0200 (CEST) Date: Wed, 25 Sep 2013 14:40:59 +0200 From: Stephane Bortzmeyer To: Stephen Farrell Message-ID: <20130925124059.GA8996@nic.fr> References: <524150C7.2020602@cs.tcd.ie> <20130925121521.GA31952@nic.fr> <5242D8AA.4040108@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5242D8AA.4040108@cs.tcd.ie> X-Operating-System: Debian GNU/Linux 7.1 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: perpass , Stephane Bortzmeyer , Andy Wilson Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:42:17 -0000 On Wed, Sep 25, 2013 at 01:35:54PM +0100, Stephen Farrell wrote a message of 49 lines which said: > I guess I'm wondering though if its worthwhile and if there are > folks who'd be willing and able to do the work. Or at least some > initial work - I don't think this is one where I'd expect its likely > somoene can just write a nice short draft and be finished very > quickly. May be starting with the more modest but certainly useful "DNS privacy considerations" Internet-Draft? Such a document, just documenting the problem, would be a good idea, IMHO. From joe@cdt.org Wed Sep 25 06:59:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0810F11E8118 for ; Wed, 25 Sep 2013 06:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=1.605, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iAzzFxbECJR for ; Wed, 25 Sep 2013 06:59:33 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB5A11E8108 for ; Wed, 25 Sep 2013 06:59:28 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Wed, 25 Sep 2013 09:59:25 -0400 Message-ID: <5242EC3D.2090204@cdt.org> Date: Wed, 25 Sep 2013 09:59:25 -0400 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <524150C7.2020602@cs.tcd.ie> <20130925121521.GA31952@nic.fr> <5242D8AA.4040108@cs.tcd.ie> <20130925124059.GA8996@nic.fr> In-Reply-To: <20130925124059.GA8996@nic.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass , Andy Wilson , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 13:59:40 -0000 On Wed Sep 25 08:40:59 2013, Stephane Bortzmeyer wrote: > On Wed, Sep 25, 2013 at 01:35:54PM +0100, > Stephen Farrell wrote > a message of 49 lines which said: > >> I guess I'm wondering though if its worthwhile and if there are >> folks who'd be willing and able to do the work. Or at least some >> initial work - I don't think this is one where I'd expect its likely >> somoene can just write a nice short draft and be finished very >> quickly. > > May be starting with the more modest but certainly useful "DNS privacy > considerations" Internet-Draft? Such a document, just documenting the > problem, would be a good idea, IMHO. +1 (since I would love to read such a thing but likely have little expertise in the drafting.) -- Joseph Lorenzo Hall Senior Staff Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: BE7E A889 7742 8773 301B 4FA1 C0E2 6D90 F257 77F8 From mdietf@demmers.org Wed Sep 25 11:09:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6439021F9DFA for ; Wed, 25 Sep 2013 11:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_05=-1.11, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9YsIGWvOo8T for ; Wed, 25 Sep 2013 11:09:48 -0700 (PDT) Received: from remote.demmers.org (mdemmers.virt.spiritone.com [216.99.193.151]) by ietfa.amsl.com (Postfix) with ESMTP id EB7DD21F9D1E for ; Wed, 25 Sep 2013 11:09:44 -0700 (PDT) Received: from cicero.demmers.org ([50.45.172.192]) by remote.demmers.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8PI9bNs003489 for ; Wed, 25 Sep 2013 11:09:38 -0700 Date: Wed, 25 Sep 2013 11:09:34 -0700 From: Mike Demmers To: Perpass List Submit Message-ID: <20130925110934.464c7592@cicero.demmers.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 18:25:26 -0000 > In the case of email, meeting that goal with end-to-end encryption mechan= isms > like S/MIME or PGP is necessarily going to mean having a nonnegligable am= ount > of email traffic encrypted. The minute that happens spammers are going to= join > the party in a big way precisely because of the ability this confers to g= et > past transport-side content inspection and filtering. This is a real serious problem. But it may also be an unprecedented golden opportunity. The reason we have spam is that email is default 'permit'.=20 What if encrypted email were default 'deny'? This would require the user whitelist anyone that was to be communicated wi= th in encrypted email. The normal unencrypted systems would still be in place, default 'permit', a= nd all the filtering would still work just as before.=20 So, the very first time I email someone, it MUST be in plain text. They the= n whitelist me (if they wish), and henceforth our mail is encrypted.=20 If you labeled the whitelist or blacklist buttons 'Friend' and 'Unfriend' p= robably millions of people would use such a system reflexively. This would require some technical changes - the email server would need to = have a list of whitelisted people for each user. I think most large systems= probably already have a way for individual users to whitelist or blacklist= addresses or envelope senders, so that shoud not be too difficult. And the= se lists would be small, most people only communicate with a few others - f= amily, friends, work. There would need to be some way for mail server to mail server connections = to indicate a message is encrypted, since at that point the server sees onl= y the connecting ip and envelope sender. Perhaps that could be done by anot= her hack on 'HELO' in the connection dialog (as is done now to indicate ext= ended commands with 'EHLO'), perhaps something like changing the last lette= r to E, 'EHLE'. (E for encrypted ;-) ) =46rom the user agent point of view, if you want 'default to encrypted', the = user agent could try to send encrypted, if that fails, let the user know im= mediately and ask them if they wish to send unencrypted. I think the changes needed to do this might be pretty easy to make; in Send= mail, at least, they could probably be done just though the normal sendmail= .cf and some scripts. > So let me close by noting that quite a lot of spam originates > from infected PCs, and is done by sending those messages using whatever > submission mechanism that user uses, borrowing their credentials in the > process. Consider the result under a default deny system. If a spammer has hacked a = machine, they may be able to use the users credentials, but they can ONLY s= end encrypted emails to someone who has whitelisted them. So they can't hac= k a machine and send out 10,000 emails - only ONE would actually be accepte= d. Their remaining choice would be to send unencrypted, in which case the u= sual filtering would be applied. Over time, as more and more people used encrypted email, spammers would hav= e a harder time of it. -Mike From malbrain@yahoo.com Wed Sep 25 12:08:51 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46DC21F9A16 for ; Wed, 25 Sep 2013 12:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bhVKXYdpWY3 for ; Wed, 25 Sep 2013 12:08:46 -0700 (PDT) Received: from nm3-vm4.bullet.mail.gq1.yahoo.com (nm3-vm4.bullet.mail.gq1.yahoo.com [98.136.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 33AF021F9A72 for ; Wed, 25 Sep 2013 12:08:46 -0700 (PDT) Received: from [98.137.12.57] by nm3.bullet.mail.gq1.yahoo.com with NNFMP; 25 Sep 2013 19:08:38 -0000 Received: from [216.39.60.203] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 25 Sep 2013 19:08:38 -0000 Received: from [127.0.0.1] by omp1090.mail.gq1.yahoo.com with NNFMP; 25 Sep 2013 19:08:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 509113.45606.bm@omp1090.mail.gq1.yahoo.com Received: (qmail 83479 invoked by uid 60001); 25 Sep 2013 19:08:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380136117; bh=LvXXO6wQlwzDrhdGiCG6CgTn9IqeGfPDXw49CMYcbcM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XrVtwy+o4DEoBpNvAhxxUQ9VmkAe9MtwtWEltcvYCvp/IIPDEqCTloCx2y7NkJiuR5sG91/4SV0R/GrH/sJG1DgqVgLyXLzPWR9iA4ZNSE/woWSG/sQHctWHHJVkL4H/VQwREKXWpzQFwKZ9QqjNNIzaEfNoRQPEKF0Juv/H8Ns= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vFtn+DE56ITRqJK1vtB275xijxs/AFh4SebuL9kCHXCsAHX+JARJwCZVXRvlsbGeLnj6Oo1Pn+0B3s0Bw62t+GwjpyZBKDErbwSnTRL7B4QuDUDJgx6h0fZsvh+jNgeK5pPCCC6ptyDxY2TbAV0T6Rwbmj0ZJYnYJHK/nXTiUPU=; X-YMail-OSG: g4f2FC8VM1mNnBP_5WemfS_fhuAmQqFf1sUA_FZ99GG3RZY P3CzeYjmgrfN_Y0_ed7W2aVd08gaNDYwhZWXgq4a_HZEAKx_ZEaVzVBMLd31 07JElf9e6piqQaI0HvyiVkW6CHKKFCKxdhnwP98vXEorq6_dMFadyMNLRNLU kqYru5wdyEcaaJq4hgqC582kvgtFMudo1QZlJ71asMGGUjWUUlzWa4eYaU1q ichvfGcMGOK0jQoSjAAj0gXlvuOc5FPOC5UvyB7WG3EKtalOq3y2kw6Ywial fdPZUv1hjrsZ.WB67bL8kdSaZV3xujzep6b9Kj6IGbkiQxaVhZYA2sKY8Imt I_cVN6ScYsYD6kdc9n37ta1cftTwmdQ81ioicyN5eIPBaDpIB8cmBfmAIICm WpTl.IE6_oHAP94lb0bbe0s.zpP8eTGk7fEIDsh0W4KyOivAlEoX0NTGNsDP x2LjSn0RAmg9rCRocqpvnmRX4hf8jAm_TRHZYeOhcP2SP2uzOEZikl_WsPwv 2navxjcvxYyzh84TOROJgE.I7r4gpVDvhN5SY.Ezc_Oo1wVXReGhSnAnj8DE JjhYzH7mtlrXpyfp3F_2heabqkcsxnp1R Received: from [50.201.233.2] by web125503.mail.ne1.yahoo.com via HTTP; Wed, 25 Sep 2013 12:08:37 PDT X-Rocket-MIMEInfo: 002.001, SSdtIHNvcnJ5IGZvciB0aGUgaW5pdGlhbCBjb25mdXNpb24gbWlzLWxhYmVsaW5nIGNsaWVudCBhbmQgc2VydmVyIGF1dGhlbnRpY2F0aW9uLsKgIFBsZWFzZSBzZWUgdGhlIG1vc3QgcmVjZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHdoZXJlIEkgdHJpZWQgdG8gc3RyYWlnaHRlbiB0aGlzIG91dC4KwqAKWWVzLCBzdHJvbmcgYXV0aGVudGljYXRpb24gb2Ygc2VydmVycyBieSBjbGllbnRzIGlzIHRoZSBzdGVwIG5lZWRlZCBmb3IgTUlUTSByZXNpc3RhbmNlLsKgIFRoZSBxdWVzdGlvbiByYWlzZWQgaW4gdGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <5237B44C.7000405@KingsMountain.com> <52381C78.8090504@cs.tcd.ie> <1379445547.56870.YahooMailNeo@web125503.mail.ne1.yahoo.com> <87k3i6pkbj.fsf@latte.josefsson.org> <1380055173.35886.YahooMailNeo@web125503.mail.ne1.yahoo.com> Message-ID: <1380136117.78172.YahooMailNeo@web125503.mail.ne1.yahoo.com> Date: Wed, 25 Sep 2013 12:08:37 -0700 (PDT) From: Karl Malbrain To: Paul Wouters In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2005986409-1681829989-1380136117=:78172" Cc: perpass Subject: Re: [perpass] tls strong authentication deployment draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:08:51 -0000 ---2005986409-1681829989-1380136117=:78172 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm sorry for the initial confusion mis-labeling client and server authenti= cation.=A0 Please see the most recent version of the draft where I tried to= straighten this out.=0A=A0=0AYes, strong authentication of servers by clie= nts is the step needed for MITM resistance.=A0 The question raised in the d= raft about authentication by servers of clients is that it should be occuri= ng where strong authentication is desired -- say by a bank, or government a= gency, to verify that the server is talking directly to the client.=A0 It's= for non-anonymous relationships where the server holds some agency status = and legal liability=A0toward the user.=0A=A0=0AThe draft is meant to outlin= e a problem statement for a larger audience that addresses not only protoco= l security improvements, but policy decisions.=0A=A0=0A=0A_________________= _______________=0A From: Paul Wouters =0ATo: Karl Malb= rain =0ACc: Simon Josefsson ; per= pass ; Stephen Farrell =0ASen= t: Tuesday, September 24, 2013 2:16 PM=0ASubject: Re: [perpass] tld strong = authentication deployment draft=0A =0A=0AOn Tue, 24 Sep 2013, Karl Malbrai= n wrote:=0A=0A> I've begun to propose an alternative to DNS/DANE, the=A0PER= SPECTIVES project from CMU, in version 01 of the problem statement:=0A> htt= p://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication.=0A> = =A0=0A> Have you considered what changes to the DNS system would address yo= ur concerns?=A0 I've proposed encrypted and authenticated connections=0A> i= n another thread.=0A=0Astrong authentication in clients will lead to less a= nonimity. What is=0Awrong with the model of the (anonymous) client authenti= cating the TLS=0Aserver against MITM, and than on that private channel, do = client auth,=0Aeg via basic auth?=0A=0AI'm not sure what you are trying to = solve by moving the client=0Aauthentication from the inner protected layer = to the outer layer.=0A=0AI'm also not sure what the draft is supposed to co= nvey....=0A=0APaul=0A_______________________________________________=0Aperp= ass mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo= /perpass ---2005986409-1681829989-1380136117=:78172 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm sorry for th= e initial confusion mis-labeling client and server authentication.  Pl= ease see the most recent version of the draft where I tried to straighten t= his out.
 
Yes, strong authentication of servers b= y clients is the step needed for MITM resistance.  The question raised= in the draft about authentication by servers of clients is that it should = be occuring where strong authentication is desired -- say by a bank, or gov= ernment agency, to verify that the server is talking directly to the client= .  It's for non-anonymous relationships where the server holds some agency status and legal liability toward= the user.
 
The draft is meant to outline a probl= em statement for a larger audience that addresses not only protocol security improvements, but policy decisions.
 
= From: Paul Wouters <paul@cypherpunks.ca>
To: Karl Malbrain <malbrain@yahoo.co= m>
Cc: Simon Josefs= son <simon@josefsson.org>; perpass <perpass@ietf.org>; Stephen = Farrell <stephen.farrell@cs.tcd.ie>
Sent: Tuesday, September 24, 2013 2:16 PM
Subject: Re: [perpass] tld strong = authentication deployment draft

On Tue, 24 Sep 2013, Karl Malbrain wrote:

> I've begun= to propose an alternative to DNS/DANE, the PERSPECTIVES project from = CMU, in version 01 of the problem statement:
> http://datatracker.iet= f.org/doc/draft-malbrain-tls-strong-authentication.
>  
> = Have you considered what changes to the DNS system would address your conce= rns?  I've proposed encrypted and authenticated connections
> in= another thread.

strong authentication in clients will lead to less = anonimity. What is
wrong with the model of the (anonymous) client authen= ticating the TLS
server against MITM, and than on that private channel, = do client auth,
eg via basic auth?

I'm not sure what you are tryi= ng to solve by moving the client
authentication from the inner protected layer to the outer layer.

I'm also not sure what the draf= t is supposed to convey....

Paul
________________________________= _______________
perpass mailing list
perpass@ietf.org
https://ww= w.ietf.org/mailman/listinfo/perpass

= ---2005986409-1681829989-1380136117=:78172-- From malbrain@yahoo.com Wed Sep 25 12:19:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7B621F9CB0 for ; Wed, 25 Sep 2013 12:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ssyFWKfh4ms for ; Wed, 25 Sep 2013 12:18:59 -0700 (PDT) Received: from nm31-vm6.bullet.mail.gq1.yahoo.com (nm31-vm6.bullet.mail.gq1.yahoo.com [98.136.216.213]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3021F9C38 for ; Wed, 25 Sep 2013 12:18:59 -0700 (PDT) Received: from [98.137.12.62] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 25 Sep 2013 19:18:58 -0000 Received: from [98.137.12.229] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 25 Sep 2013 19:18:58 -0000 Received: from [127.0.0.1] by omp1037.mail.gq1.yahoo.com with NNFMP; 25 Sep 2013 19:18:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 558010.24038.bm@omp1037.mail.gq1.yahoo.com Received: (qmail 94048 invoked by uid 60001); 25 Sep 2013 19:18:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380136737; bh=1AyHeiQ3zn8hmDs31o+zns94g/RQu8HprfLQV8fF9ew=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iQj3MyE5CbaYhkOhjd9p0GsPjBFYeQgn5MaTWJEtFwUxt29eSRSoAF36pM/fxrUFLCp2Nk32BvXY9v+kjt5FeZFl/XcaXwpN2pUHLS9I6tZ+lZEMzZKLd/gGA28GanRAHsQkUzzvnnqXbEt8/W1naSwvjJxeNLNDgl2DMuRBqaU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ykcMBfQo0HqGzdc8Lx6Sf3jtZZWPfjHRWik1BJvhBnIMHUdx2MjUJWKUNED8ptuK+iRn2VKF0qJanjYmiSms51/0VBGTPd3epYgkCT3ZDIfBH/1ubszb4zqtylBP9xxIBKPoGPFDuy3jaFoyNKZ46WYsq89nQrSnj+A06Pt3vdM=; X-YMail-OSG: jBFiFfYVM1k9X9DRFL2kk8Oo28UCQaiCn2p6Cr7Os2zoQ7v _OtO5EorpoR13YoMvI17B2qFTRYcvSnAyYnyeW1ubiN6ylGOrTKuFGTfG_GH ngfOnYqwXkr9D1zNOnS1GmGfqJRjlTX9ICMvKkco_2gN8MbUVd8_Ce2atlvT 6pOyvy0uxVzFM9nxppeOfkexOCnuEAL93CWN2dDvACooQHw9apCcBLytAd0d HJiPRNIZpdpQykwopKkxhX92d2Iw16Eon1Eox3XZUsnWEYorcE4wlJlExXqx iSfxvILNMhgC0AUUjacQAjoTQfHQJgS9S7R3K5S7HCmv3tuTiS3ALPCV8mLl my2ejpgSQKGwIUS5gcSSxSUft8_cgMBQSVr10sVJGrRL9nj9WdL__HaPKG.2 4Gg_PVv1YYLr69YzZEiAmu3oJ5Kip2chZhdOu0AAHZD6PEhFP1Jq7lX_Tb0I DHNRxRu459jC5fETp.NQedR37avWe1cnQyf3NTONkcSUKxQ7gV1hsx72ag7O 99_.IqktCeIMjiIwycJKvCOqh4T2E2yrZAERBgxroBuJPSr.yHKDdeNm3F5L 04dCe6rpdclf9Pl9tTt2RQ1n08yEVWSJgayDnI0FgyPt8i_XksA3ITDIYx.R inS_CTXEuhFdUu3pX_mLbtqDtfnE9iyUHL.DzlVXKMnlNQVXWZEkh7emoy7x OBfLkfHpuDQcQ.VRnZkEJkV1DcBZQRg-- Received: from [50.201.233.2] by web125503.mail.ne1.yahoo.com via HTTP; Wed, 25 Sep 2013 12:18:56 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlLCAyNCBTZXAgMjAxMywgS2FybCBNYWxicmFpbiB3cm90ZToKCj4.IFRvIG9idmlhdGUgdGhlIGhhcnZlc3Rpbmcgb2YgbWV0YS1kYXRhLCB3ZSBkbyBuZWVkIGEgc2VjdXJlIGludGVyZmFjZSB0byBETlMuCgo.SXQgbWlnaHQgaGVscCBidXQgZ2l2aW5nIHBlb3BsZSB1cmxzIHRoYXQgd2lsbCB0cmlnZ2VyIGRucyByZXF1ZXN0cyBmb3IKPnRyYWNraW5nIGlzIHByZXR0eSBlYXN5LiBPbmx5IHNvbWV0aGluZyBsaWtlIHRvciBtaWdodCBzYWZlZ3VhcmQgYWdhaW5zdAo.dGhhdC4KwqAKSSdtIG5vdCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> Message-ID: <1380136736.93860.YahooMailNeo@web125503.mail.ne1.yahoo.com> Date: Wed, 25 Sep 2013 12:18:56 -0700 (PDT) From: Karl Malbrain To: Paul Wouters In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2005986409-1349360503-1380136736=:93860" Cc: perpass , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:19:04 -0000 ---2005986409-1349360503-1380136736=:93860 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 24 Sep 2013, Karl Malbrain wrote:=0A=0A>> To obviate the harvesting= of meta-data, we do need a secure interface to DNS.=0A=0A>It might help bu= t giving people urls that will trigger dns requests for=0A>tracking is pret= ty easy. Only something like tor might safeguard against=0A>that.=0A=A0=0AI= 'm not following you here.=A0 Can you elaborate on the threat?=A0 I was ref= erring to passive monitoring of DNS traffic by third parties who want to kn= ow what domains you are visiting.=0A=0A>> Given the reluctance of browser w= riters=A0to implement DANE,=A0 we're going to need something like encrypted= >>QUIC available as a transport=0A>> first.=0A=0A>There will be dane in br= owsers, once we ensure it is cheap =0A>enough on high latency devices. Eg s= ee=0A=0A>http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query-00= =0A=0A>It's easy to add anonymous IPsec to open resolvers (and I'm in the= =0A>process od doing so) but hiding DNS queries involves a lot more than=0A= >just encrypting queries.=0A=0A>Paul ---2005986409-1349360503-1380136736=:93860 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, 24 Sep 2= 013, Karl Malbrain wrote:

>> To obviate the harvesting of meta= -data, we do need a secure interface to DNS.

>It might help but g= iving people urls that will trigger dns requests for
>tracking is pre= tty easy. Only something like tor might safeguard against
>that.
 
I'm not following you here.  Can you elaborate = on the threat?  I was referring to passive monitoring of DNS traffic b= y third parties who want to know what domains you are visiting.
<= br>>> Given the reluctance of browser writers to implement DANE,=   we're going to need something like encrypted >>QUIC available = as a transport
>> first.

>There will be dane in browsers= , once we ensure it is cheap
>enough on high latency devices. Eg see

>http://tools.ietf.org/html/draft-wou= ters-edns-tcp-chain-query-00

>It's easy to add anonymous IPse= c to open resolvers (and I'm in the
>process od doing so) but hiding = DNS queries involves a lot more than
>just encrypting queries.
>Paul
  
---2005986409-1349360503-1380136736=:93860-- From paul@cypherpunks.ca Wed Sep 25 12:34:50 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF6411E80EC for ; Wed, 25 Sep 2013 12:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38TEt0rOG2qt for ; Wed, 25 Sep 2013 12:34:44 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7DB21F9B10 for ; Wed, 25 Sep 2013 12:34:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3clTx94V3SzC3Q; Wed, 25 Sep 2013 15:34:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NTxvUGo2l6dg; Wed, 25 Sep 2013 15:34:36 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 25 Sep 2013 15:34:36 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 5E6E68009E; Wed, 25 Sep 2013 15:34:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4096E8002E; Wed, 25 Sep 2013 15:34:32 -0400 (EDT) Date: Wed, 25 Sep 2013 15:34:32 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Karl Malbrain In-Reply-To: <1380136736.93860.YahooMailNeo@web125503.mail.ne1.yahoo.com> Message-ID: References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <1380136736.93860.YahooMailNeo@web125503.mail.ne1.yahoo.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: perpass , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:34:50 -0000 On Wed, 25 Sep 2013, Karl Malbrain wrote: > On Tue, 24 Sep 2013, Karl Malbrain wrote: > > >> To obviate the harvesting of meta-data, we do need a secure interface to DNS. > > >It might help but giving people urls that will trigger dns requests for > >tracking is pretty easy. Only something like tor might safeguard against > >that. >   > I'm not following you here.  Can you elaborate on the threat?  I was referring to passive monitoring of DNS traffic by third parties who > want to know what domains you are visiting. A passive monitor can just wait and ignore your DNS and then see you connect to IP a.b.c.d. They can easilly find what's hosted there. I mean netcraft even runs a public website where you can ask for all the vhosts running on a certain IP. And if you're going to use tor to hide that, than your DNS should also have gone via TCP on the tor network. An active attacker trying to de-anonymise you could use specifically crafted DNS queries to lure you into resolving something that only exists to catch you. I think of the DNS as one of the only required non-encrypted services to kickstart encryption, but I agree that we could hide DNS better using Opportunistic Encryption (IPsec based). You would still need some unencrypted DNS to setup the IPsec to the DNS servers though. What we don't need though is another dns-like protocol to do so. (and definitely not dnscurve, as it does not support dns data authenticity, only transport security) Paul From malbrain@yahoo.com Wed Sep 25 12:38:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9901A11E80EC for ; Wed, 25 Sep 2013 12:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBW6R7-ri9py for ; Wed, 25 Sep 2013 12:38:02 -0700 (PDT) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9E11E8136 for ; Wed, 25 Sep 2013 12:37:58 -0700 (PDT) Received: from [98.139.214.32] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2013 19:37:56 -0000 Received: from [98.139.212.217] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2013 19:37:56 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 25 Sep 2013 19:37:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 570716.93066.bm@omp1026.mail.bf1.yahoo.com Received: (qmail 48695 invoked by uid 60001); 25 Sep 2013 19:37:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380137875; bh=LysR5p5dxR2q0Gv97oJSMH9zXZEO5DbpP7LGxmO2/4E=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BSrA9F8ldFGjqyQwIljcU99vDyK7MmktHOFc2y8vTmniftvXXMduRZfuOJ1OK1elZX1AE2ZT0eDjnld8tOi1CHQbfYZgBe4PgDcK6/NRI2BuH0MA5Y7l68Xevg2/BejZBeNS30aOctU0e6pw9H3Jnp0k+mV4sfB3KZJHCWnLxaE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PCE52DWKr9w4nABuzLRKjnz4cCDdJHPzlCytrI1ASrhOR9Vk2ZfcT2lUx1GAyKqj/Amz0UBksgeNRDFrK1ZAd5vxFUNERHlNQSgehZU7hOCyovHwqhVdggTzdc/CM4WGBMUl53DqiW+q6tQG9Hz+zTdZrWtrGrVfYxE0t+VcIiQ=; X-YMail-OSG: vadXurUVM1mmiSuqnYskNe4lGN5UHXfVl_P5jeT7zlbxYL_ D_t0t_7kOZ1jXrnd4lLY0WBZBJCYVLRprCShrL6UppWYRiWxR1CkoY66ufBj DHvOxa.pwncYMwbKvsSOzFeSkoy9dLIIhdHl5.QW0MNJy1Fht2oSesCIRFiD MzXbUIC52Ck1MfdvbMKTAMjlU.S2Dp915MBz2D.7ivnTdi4jjR0XkqpIS4jk 63w1H778q6yWuhlZ2BvgZSHPKsFGvNvJzFOvDt76njBKnzHbZ650Wiy6iBYJ etmnMwFQRH1PPtveifpX1Ta5e5C5dqChHSk8hAp5Jq4.JYOlWZlazCf9NLSJ 8ZlEHMSLqV2c0ydZRFhp.tbyiuWdtjuMLwtxMvAARgtZ.BbdHafq0xLyZOc1 _O3JAZSLI2ma.WlRYw8ST3LNpW07kd7WLkwBkQZZlZok8uxesKpgvakrD2Tl 2r_.kw8lTXUBpV5s1g3jAQVVY_StLvZj6kH2Lsv4pz3q6EfAoa73W6uc5rzC jIJztfwwGxWgVbB5rsKNqyb8Y4AZI.mL.5kKtUnUTcPcqe.3Cg5G.m3upj_F LZAqs2sZdGLOXuPzCF9FIHGmWbr2RFiyC Received: from [50.201.233.2] by web125502.mail.ne1.yahoo.com via HTTP; Wed, 25 Sep 2013 12:37:54 PDT X-Rocket-MIMEInfo: 002.001, WWVzLCBNSVRNIGNhbiBiZSBwcmV2ZW50ZWQgaWYgeW91IGhhdmUgYSBjb3B5IG9mIHRoZSBwdWJsaWMgY2VydGlmaWNhdGUgb2J0YWluZWQgdGhyb3VnaCBleHRlcmlvdXIgbWVhbnMgdG8gY2hlY2sgdGhlIHNpZ25hdHVyZSBvdmVyIHRoZSBkYXRhLsKgIElmIHlvdXIgY2VydGlmaWNhdGUgaXMgcHJvdmlkZWQgYnkgTUlUTSB5b3UgbmF0dXJhbGx5IGxvc2UgdGhhdCBzaWduYXR1cmUgcHJvdGVjdGlvbi4KCiAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiBIb3NuaWVoIFJhZmllZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> Message-ID: <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> Date: Wed, 25 Sep 2013 12:37:54 -0700 (PDT) From: Karl Malbrain To: Hosnieh Rafiee In-Reply-To: <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1546730761-358384175-1380137874=:48631" Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:38:07 -0000 ---1546730761-358384175-1380137874=:48631 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes, MITM can be prevented if you have a copy of the public certificate obt= ained through exteriour means to check the signature over the data.=A0 If y= our certificate is provided by MITM you naturally lose that signature prote= ction.=0A=0A =0A=0A________________________________=0A From: Hosnieh Rafiee= =0ATo: 'Karl Malbrain' =0ACc: 'perp= ass' ; 'Stephen Farrell' =0AS= ent: Tuesday, September 24, 2013 2:08 PM=0ASubject: Re: [perpass] DNS confi= dentiality=0A =0A=0A=0AMITM attack can be prevented by signing the data. P= lease check cga-tsig draft.=0A=A0=0A=A0=0AHosnieh=0A=A0=0A=A0=0AFrom:perpas= s-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Behalf Of Karl Malb= rain=0ASent: Tuesday, September 24, 2013 10:31 PM=0ATo: Stephen Farrell; pe= rpass=0ASubject: Re: [perpass] DNS confidentiality=0A=A0=0ATo obviate the h= arvesting of meta-data, we do need a secure interface to DNS.=0A=A0=0AMITM = resistance (authentication) is also going to be required in DNS server conn= ections. Maybe well known certificates for DNS servers=A0incorporated into = browser software=0A=A0=0AGiven the reluctance of browser writers=A0to imple= ment DANE,=A0 we're going to need something like encrypted QUIC available a= s a transport first.=0A=A0=0AKarl Malbrain=A0 =0A=A0=0AFrom:Stephen Farrell= =0ATo: perpass =0ASent: Tues= day, September 24, 2013 1:43 AM=0ASubject: [perpass] DNS confidentiality=0A= =0A=0AHiya,=0A=0AI've not seen mention of this so far here that I recall.= =0A=0AEven as we improve the security of loads of protocols, there=0Awill s= till be issues with meta-data monitoring based on=0ADNS queries for example= . This point was sort of raised on=0Athe IETF list e.g. in [1].=0A=0ADNSSEC= doesn't provide any confidentiality. There are=0Aproposals that do try do = that.=0A=0ADo we think this is worth looking at?=0AIf so, anyone up for doi= ng some work on that?=0AIf so, how, or starting from what?=0A=0AS.=0A=0A[1]= http://www.ietf.org/mail-archive/web/ietf/current/msg82696.html=0A________= _______________________________________=0Aperpass mailing list=0Aperpass@ie= tf.org=0Ahttps://www.ietf.org/mailman/listinfo/perpass=0A=0A=0A____________= ___________________________________=0Aperpass mailing list=0Aperpass@ietf.o= rg=0Ahttps://www.ietf.org/mailman/listinfo/perpass ---1546730761-358384175-1380137874=:48631 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, MITM = can be prevented if you have a copy of the public certificate obtained thro= ugh exteriour means to check the signature over the data.  If your cer= tificate is provided by MITM you naturally lose that signature protection.<= /span>

From: Hosnieh Rafiee <iet= f@rozanak.com>
To: = 'Karl Malbrain' <malbrain@yahoo.com>
Cc: 'perpass' <perpass@ietf.org>; 'Stephen Farrell' <stephen= .farrell@cs.tcd.ie>
Sent: Tuesday, September 24, 2013 2:08 PM
Subject: Re: [perpass] DNS confidentiality

MITM attack can be pre= vented by signing the data. Please check cga-tsig draft.
 
 
Hosnieh=
 
 
= From:= perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Beh= alf Of Karl Malbrain
Sent: Tuesday, September 24, 2013 10:31 = PM
To: Stephen Farrell; perpass
Subject: Re: [perpass] = DNS confidentiality
 
To obviate = the harvesting of meta-data, we do need a secure interface to DNS.
 
MITM resistance (authentication) is also going to be required= in DNS server connections. Maybe well known certificates for DNS servers&n= bsp;incorporated into browser software
 
Given the relu= ctance of browser writers to implement DANE,  we're going to need= something like encrypted QUIC available as a transport first.
=
 
Karl= Malbrain 
 
From: Stephen Farrell <= ;stephen.farrell@cs.tcd.i= e>
To: perpass <perpass= @ietf.org>
Sent: Tuesday, September 24, 2013 1:43 AM
Subject: [perpass] DNS confi= dentiality


Hiya,

I've not seen m= ention of this so far here that I recall.

Even as we improve the sec= urity of loads of protocols, there
will still be issues with meta-data m= onitoring based on
DNS queries for example. This point was sort of raise= d on
the IETF list e.g. in [1].

DNSSEC doesn't provide any confid= entiality. There are
proposals that do try do that.

Do we think t= his is worth looking at?
If so, anyone up for doing some work on that?If so, how, or starting from what?

S.

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg826= 96.html
_______________________________________________
perpass m= ailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass


_____________= __________________________________
perpass mailing list
perpass@ietf.org=
https://www.ietf.org/mailman/listinfo/perpass


---1546730761-358384175-1380137874=:48631-- From malbrain@yahoo.com Wed Sep 25 12:47:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C1021F958A for ; Wed, 25 Sep 2013 12:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4GXxwLtNsvy for ; Wed, 25 Sep 2013 12:47:08 -0700 (PDT) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5A621F9371 for ; Wed, 25 Sep 2013 12:47:08 -0700 (PDT) Received: from [98.139.215.140] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2013 19:47:06 -0000 Received: from [98.139.212.203] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 25 Sep 2013 19:47:06 -0000 Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP; 25 Sep 2013 19:47:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 890688.16985.bm@omp1012.mail.bf1.yahoo.com Received: (qmail 18271 invoked by uid 60001); 25 Sep 2013 19:47:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380138426; bh=LT9tSBvlGa1bvqET2UaXJnoiwg0XMOS5pubkpRUVA94=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rdIZbSyCUWiJOMaTYPxsNoFwztUDnsIkJDTeqD+EmfLQkAPfkqij/nmbin7Vl3czK5ypAdQSOjckFqVMrhIDIGTvpwgJad7EB6hd7s0mw8XZL7rlDh5e47nweftWbCfIElbc7S+4XnzonIxX2XTQourlRdGVQ5jko9jz5QDxmto= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=j0rjyFsBKUzzHIW3sEp8L4oKAi0pCxzjLaN2anSAthoSyl5RAIGUuVkeNifdSWCE67d9dlDjeW1lasRl63EJxWJMbUHmdCNHxYIDGknwgnKyCrcPFP/5WAtFuYxkD3ObDfNFY4puLGeIMRuDdY8Sb/p6Ux9HOtKQCGkM3dnum84=; X-YMail-OSG: OoB6skkVM1kWWJqgJOfhDQJX5ycwd0N1.VK6b4l.fimNsY7 99UInrwnQs02EGGzJoLNdCELDhsnFoSDm6CamTZokjDISnA9HSuCn5s8VI5p qmEsWeJktOBtnCMqdc4L.7PETZnKW90r3YMJwKfnDZvHc0KCcEhHNVu256f1 vC8WS7HldTrp0PEPni4ApHJI3Cv23uMSVdvlcOVMk.FYXdwyfpUHUM1bAtvZ EibslX9m2cSDjMzb8T9wUmPa15r6KNWcdHwECxARQmxM5RKk7lbdHuBrw.Mm kHxc6hW7ZbColoXSwKhqb7_usrEnCTswNO6CFeu8lbIGTBwbkYjuWEW8rDft WK3asMsvxEiVs9vjRe5hOaCxDxjAzpcb5p5R.AO6GVIVqF8qaA1CDBm1Wi6t nFW03hiyuHvyXstemwhhpDNDbCiEBnuQv8W15OXH0l7tLeZHd26.2xlDwKXR oYD5tFkxHGgZca9NaRVSuFxNzh6ZqwUNi_yMV.ifYBI5w18F06QOYLJ_KvJv IOzJlZhk_sCbXILDpXu16Kuj7DSOnEKhA6yBjw4REVAQw_FHFCGKCVKjTvwo 1Qt9r0ik2Ht296RvUR56cU.3hhM2M7ZzDqlk_pQ-- Received: from [50.201.233.2] by web125503.mail.ne1.yahoo.com via HTTP; Wed, 25 Sep 2013 12:47:06 PDT X-Rocket-MIMEInfo: 002.001, SSBzZWUuLi4uLgrCoApUaGVuIHRoZSBkaWZmZXJlbmNlIGluIHNlY3VyaXR5IGlzIHRoYXQgb25jZSB5b3UgYXJlIHRhcmdldHRlZCBpbmRpdmlkdWFsbHksIHlvdXLCoGNvbm5lY3Rpb24gbWV0YS1kYXRhwqBhcmXCoGF2YWlsYWJsZSBmb3IgaGFydmVzdGluZyBhbmQgc29tZXRoaW5nIGxpa2UgdG9yIGlzIHJlcXVpcmVkLsKgIEJ1dCwgaWYgdGhlIG1vbml0b3JpbmcgaXMgYXQgdGhlIEROUyBzZXJ2ZXIgdGhlbiBlbmNyeXB0aW9uIG1ha2VzIGl0IGltcG9zc2libGUgdG8gZGV0ZXJtaW5lIHdobyBzaG91bGQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.157.561 References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <1380136736.93860.YahooMailNeo@web125503.mail.ne1.yahoo.com> Message-ID: <1380138426.6956.YahooMailNeo@web125503.mail.ne1.yahoo.com> Date: Wed, 25 Sep 2013 12:47:06 -0700 (PDT) From: Karl Malbrain To: Paul Wouters In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2005986409-2138097647-1380138426=:6956" Cc: perpass , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 19:47:15 -0000 ---2005986409-2138097647-1380138426=:6956 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I see.....=0A=A0=0AThen the difference in security is that once you are tar= getted individually, your=A0connection meta-data=A0are=A0available for harv= esting and something like tor is required.=A0 But, if the monitoring is at = the DNS server then encryption makes it impossible to determine who should = be targetted next.=0A=A0 =0A=0A________________________________=0A From: Pa= ul Wouters =0ATo: Karl Malbrain = =0ACc: perpass ; Stephen Farrell =0ASent: Wednesday, September 25, 2013 12:34 PM=0ASubject: Re: [perpass= ] DNS confidentiality=0A =0A=0AOn Wed, 25 Sep 2013, Karl Malbrain wrote:= =0A=0A> On Tue, 24 Sep 2013, Karl Malbrain wrote:=0A> =0A> >> To obviate th= e harvesting of meta-data, we do need a secure interface to DNS.=0A> =0A> >= It might help but giving people urls that will trigger dns requests for=0A>= >tracking is pretty easy. Only something like tor might safeguard against= =0A> >that.=0A> =A0=0A> I'm not following you here.=A0 Can you elaborate on= the threat?=A0 I was referring to passive monitoring of DNS traffic by thi= rd parties who=0A> want to know what domains you are visiting.=0A=0AA passi= ve monitor can just wait and ignore your DNS and then see you=0Aconnect to = IP a.b.c.d. They can easilly find what's hosted there. I=0Amean netcraft ev= en runs a public website where you can ask for all the=0Avhosts running on = a certain IP.=0A=0AAnd if you're going to use tor to hide that, than your D= NS should also=0Ahave gone via TCP on the tor network.=0A=0AAn active attac= ker trying to de-anonymise you could use specifically=0Acrafted DNS queries= to lure you into resolving something that only=0Aexists to catch you.=0A= =0AI think of the DNS as one of the only required non-encrypted services to= =0Akickstart encryption, but I agree that we could hide DNS better using=0A= Opportunistic Encryption (IPsec based). You would still need some=0Aunencry= pted DNS to setup the IPsec to the DNS servers though.=0A=0AWhat we don't n= eed though is another dns-like protocol to do so. (and=0Adefinitely not dns= curve, as it does not support dns data authenticity,=0Aonly transport secur= ity)=0A=0APaul ---2005986409-2138097647-1380138426=:6956 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I see.....=
 
Then the difference i= n security is that once you are targetted individually, your connectio= n meta-data are available for harvesting and something like tor i= s required.  But, if the monitoring is at the DNS server then encrypti= on makes it impossible to determine who should be targetted next.
 
From: Paul Wouters <paul@cypherpunks.ca>
To: Karl Malbrain <malbrain@= yahoo.com>
Cc: perp= ass <perpass@ietf.org>; Stephen Farrell <stephen.farrell@cs.tcd.ie= >
Sent: Wednesday,= September 25, 2013 12:34 PM
Subj= ect: Re: [perpass] DNS confidentiality

On Wed, 25 Sep 2013, Karl Malbrain wrote:
<= br>> On Tue, 24 Sep 2013, Karl Malbrain wrote:
>
> >>= To obviate the harvesting of meta-data, we do need a secure interface to D= NS.
>
> >It might help but giving people urls that will tri= gger dns requests for
> >tracking is pretty easy. Only something l= ike tor might safeguard against
> >that.
>  
> I'= m not following you here.  Can you elaborate on the threat?  I was= referring to passive monitoring of DNS traffic by third parties who
>= ; want to know what domains you are visiting.

A passive monitor can = just wait and ignore your DNS and then see you
connect to IP a.b.c.d. Th= ey can easilly find what's hosted there. I
mean netcraft even runs a pub= lic website where you can ask for all the
vhosts running on a certain IP= .

And if you're going to use tor to hide that, than your DNS should = also
have gone via TCP on the tor network.

An active attacker try= ing to de-anonymise you could use specifically
crafted DNS queries to lu= re you into resolving something that only
exists to catch you.

I = think of the DNS as one of the only required non-encrypted services to
k= ickstart encryption, but I agree that we could hide DNS better using
Opp= ortunistic Encryption (IPsec based). You would still need some
unencrypted DNS to setup the IPsec to the DNS servers though.
<= br>What we don't need though is another dns-like protocol to do so. (anddefinitely not dnscurve, as it does not support dns data authenticity,
= only transport security)

Paul


---2005986409-2138097647-1380138426=:6956-- From stephen.farrell@cs.tcd.ie Wed Sep 25 13:00:40 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D5421F9E0B for ; Wed, 25 Sep 2013 13:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQXGsrFSQIfZ for ; Wed, 25 Sep 2013 13:00:10 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BE8DC21F9E50 for ; Wed, 25 Sep 2013 13:00:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8A899BE62; Wed, 25 Sep 2013 21:00:00 +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 24XA13UzrK7P; Wed, 25 Sep 2013 20:59:59 +0100 (IST) Received: from [10.87.48.9] (unknown [86.41.52.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 34948BE5B; Wed, 25 Sep 2013 20:59:59 +0100 (IST) Message-ID: <524340AA.2070400@cs.tcd.ie> Date: Wed, 25 Sep 2013 20:59:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Paul Wouters References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <1380136736.93860.YahooMailNeo@web125503.mail.ne1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 20:00:40 -0000 Hi Paul, On 09/25/2013 08:34 PM, Paul Wouters wrote: > > What we don't need though is another dns-like protocol to do so. (and > definitely not dnscurve, as it does not support dns data authenticity, > only transport security) You might be right about dnscurve, or maybe not. I dunno enough about it yet to be to be honest. But, as you know, DNSSEC is where the IETF has placed its bet for DNS data origin auth. Changing that would maybe require a seismic shift, so for this discussion I was assuming DNSSEC is the answer for data origin auth and just asking if it'd be useful to add confidentiality. So, the fact that dnscurve doesn't do what DNSSEC does isn't really a compelling argument here I think. Cheers, S. PS: Yes, we should all be doing stuff to encourage more deployment of DNSSEC, but I think that's a separate discussion, for other lists probably, even though DNSSEC deployment might make it harder to mount some attacks that are used in monitoring. From ietf@rozanak.com Wed Sep 25 13:08:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F1921F9F40 for ; Wed, 25 Sep 2013 13:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahyzHn944z6v for ; Wed, 25 Sep 2013 13:08:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8D821F9F6F for ; Wed, 25 Sep 2013 13:08:35 -0700 (PDT) Received: from kopoli (g226057076.adsl.alicedsl.de [92.226.57.76]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MXZCY-1VL3m60pi2-00W2gy; Wed, 25 Sep 2013 16:08:18 -0400 From: "Hosnieh Rafiee" To: "'Karl Malbrain'" References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> In-Reply-To: <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> Date: Wed, 25 Sep 2013 22:08:06 +0200 Message-ID: <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01CEBA3B.BBE580E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOGj5UkWbfuDhxpmMKtaAoIXGv7QHKq7oDAZ0lsZ0CNxrNyJirKMmQ Content-Language: en-us X-Provags-ID: V02:K0:rcC3WNKDZCIccP6gj5Hh3fbAbthr405fI9dV2ka/aL6 jtTXq5YW0H5SnAnuqHU61hTgnQa/u6X3E3ZjtofpG751oOeD/K h8aMn/uS1UNJcFsLJVcTOh368W6g/XjCLCraBJRLWMWrLhnJBh ujPaNuW8NrjJZ7m9xlX3bfzd90I2oLAlMckVA8ZXm4bryFbZTr CPjTXd4ErrUjmHMYvkTYbkTBb2kMP+T2Cvy83PkyMh2U3UdRiD cRgVdxRAY/ynvz1UW0RBStMrn9TTiS1AE7QP0De7iOZbsCJcuR c1Pt8sJxwhWF+rW55Vi0dlu7hl4duOGvICJ+qxnY3JdvHymdfC ItQOXMRcoFSYpOJqCZsE= Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 20:08:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005A_01CEBA3B.BBE580E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Not if you use another approach as well as a signature. This means that if the two nodes know the IP address of each other, then nobody can play a role of MITM if they are using CGA-TSIG (http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig) as a means of DNS authentication. Hosnieh From: perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Behalf Of Karl Malbrain Sent: Wednesday, September 25, 2013 9:38 PM To: Hosnieh Rafiee Cc: 'perpass'; 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality Yes, MITM can be prevented if you have a copy of the public certificate obtained through exteriour means to check the signature over the data. If your certificate is provided by MITM you naturally lose that signature protection. From: Hosnieh Rafiee To: 'Karl Malbrain' Cc: 'perpass' ; 'Stephen Farrell' Sent: Tuesday, September 24, 2013 2:08 PM Subject: Re: [perpass] DNS confidentiality MITM attack can be prevented by signing the data. Please check cga-tsig draft. Hosnieh From: perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Behalf Of Karl Malbrain Sent: Tuesday, September 24, 2013 10:31 PM To: Stephen Farrell; perpass Subject: Re: [perpass] DNS confidentiality To obviate the harvesting of meta-data, we do need a secure interface to DNS. MITM resistance (authentication) is also going to be required in DNS server connections. Maybe well known certificates for DNS servers incorporated into browser software Given the reluctance of browser writers to implement DANE, we're going to need something like encrypted QUIC available as a transport first. Karl Malbrain From: Stephen Farrell To: perpass Sent: Tuesday, September 24, 2013 1:43 AM Subject: [perpass] DNS confidentiality Hiya, I've not seen mention of this so far here that I recall. Even as we improve the security of loads of protocols, there will still be issues with meta-data monitoring based on DNS queries for example. This point was sort of raised on the IETF list e.g. in [1]. DNSSEC doesn't provide any confidentiality. There are proposals that do try do that. Do we think this is worth looking at? If so, anyone up for doing some work on that? If so, how, or starting from what? S. [1] http://www.ietf.org/mail-archive/web/ietf/current/msg82696.html _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass ------=_NextPart_000_005A_01CEBA3B.BBE580E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not if you use another approach as well as a signature. This means = that if  the two nodes know the IP address of each other, then = nobody can play a role of MITM if they are using CGA-TSIG (http://= tools.ietf.org/html/draft-rafiee-intarea-cga-tsig) as a means of DNS authentication.

 

 

Hosnieh

 

From:= = perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Behalf = Of Karl Malbrain
Sent: Wednesday, September 25, 2013 9:38 = PM
To: Hosnieh Rafiee
Cc: 'perpass'; 'Stephen = Farrell'
Subject: Re: [perpass] DNS = confidentiality

 

Yes, MITM can be = prevented if you have a copy of the public certificate obtained through = exteriour means to check the signature over the data.  If your = certificate is provided by MITM you naturally lose that signature = protection.

 

F= rom: = Hosnieh Rafiee <ietf@rozanak.com>
To: = 'Karl Malbrain' <malbrain@yahoo.com> =
Cc: 'perpass' <perpass@ietf.org>; 'Stephen = Farrell' <stephen.farrell@cs.tcd.ie&g= t;
Sent: Tuesday, September 24, 2013 2:08 = PM
Subject: Re: [perpass] DNS confidentiality

 

MITM attack can be prevented by signing the data. Please check = cga-tsig draft.

 

 

Hosnieh

 

 

<= div>

F= rom: = Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: = perpass <perpass@ietf.org>
Sent: Tuesday, = September 24, 2013 1:43 AM
Subject: [perpass] DNS = confidentiality



Hiya,

I've not seen mention of this = so far here that I recall.

Even as we improve the security of = loads of protocols, there
will still be issues with meta-data = monitoring based on
DNS queries for example. This point was sort of = raised on
the IETF list e.g. in [1].

DNSSEC doesn't provide = any confidentiality. There are
proposals that do try do = that.

Do we think this is worth looking at?
If so, anyone up = for doing some work on that?
If so, how, or starting from = what?

S.

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg82= 696.html
_______________________________________________
perpas= s mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass<= /o:p>


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

------=_NextPart_000_005A_01CEBA3B.BBE580E0-- From stephen.farrell@cs.tcd.ie Wed Sep 25 13:12:57 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14A21F9D2A for ; Wed, 25 Sep 2013 13:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.442 X-Spam-Level: X-Spam-Status: No, score=-103.442 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599, GB_I_LETTER=-2, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkc3p1aBtc8z for ; Wed, 25 Sep 2013 13:12:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A8A9E21F85E0 for ; Wed, 25 Sep 2013 13:12:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E03FDBE77; Wed, 25 Sep 2013 21:12:50 +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 4O07VP-BZUT7; Wed, 25 Sep 2013 21:12:48 +0100 (IST) Received: from [10.87.48.9] (unknown [86.41.52.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 26B39BE5B; Wed, 25 Sep 2013 21:12:48 +0100 (IST) Message-ID: <524343B5.8010808@cs.tcd.ie> Date: Wed, 25 Sep 2013 21:12:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Mike Demmers , Perpass List Submit References: <20130925110934.464c7592@cicero.demmers.org> In-Reply-To: <20130925110934.464c7592@cicero.demmers.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 20:12:57 -0000 I think that's kinda inventive. A good try at least. I've no idea if it could fly, but it is a possible answer to the good point Ned makes.... maybe. (Apologies to whoever suggested it before, if someone did.) S. On 09/25/2013 07:09 PM, Mike Demmers wrote: > >> In the case of email, meeting that goal with end-to-end encryption mechanisms >> like S/MIME or PGP is necessarily going to mean having a nonnegligable amount >> of email traffic encrypted. The minute that happens spammers are going to join >> the party in a big way precisely because of the ability this confers to get >> past transport-side content inspection and filtering. > > This is a real serious problem. > > But it may also be an unprecedented golden opportunity. > > The reason we have spam is that email is default 'permit'. > > What if encrypted email were default 'deny'? > > This would require the user whitelist anyone that was to be communicated with in encrypted email. > > The normal unencrypted systems would still be in place, default 'permit', and all the filtering would still work just as before. > > So, the very first time I email someone, it MUST be in plain text. They then whitelist me (if they wish), and henceforth our mail is encrypted. > > If you labeled the whitelist or blacklist buttons 'Friend' and 'Unfriend' probably millions of people would use such a system reflexively. > > This would require some technical changes - the email server would need to have a list of whitelisted people for each user. I think most large systems probably already have a way for individual users to whitelist or blacklist addresses or envelope senders, so that shoud not be too difficult. And these lists would be small, most people only communicate with a few others - family, friends, work. > > There would need to be some way for mail server to mail server connections to indicate a message is encrypted, since at that point the server sees only the connecting ip and envelope sender. Perhaps that could be done by another hack on 'HELO' in the connection dialog (as is done now to indicate extended commands with 'EHLO'), perhaps something like changing the last letter to E, 'EHLE'. (E for encrypted ;-) ) > >>From the user agent point of view, if you want 'default to encrypted', the user agent could try to send encrypted, if that fails, let the user know immediately and ask them if they wish to send unencrypted. > > I think the changes needed to do this might be pretty easy to make; in Sendmail, at least, they could probably be done just though the normal sendmail.cf and some scripts. > >> So let me close by noting that quite a lot of spam originates >> from infected PCs, and is done by sending those messages using whatever >> submission mechanism that user uses, borrowing their credentials in the >> process. > > Consider the result under a default deny system. If a spammer has hacked a machine, they may be able to use the users credentials, but they can ONLY send encrypted emails to someone who has whitelisted them. So they can't hack a machine and send out 10,000 emails - only ONE would actually be accepted. Their remaining choice would be to send unencrypted, in which case the usual filtering would be applied. > > Over time, as more and more people used encrypted email, spammers would have a harder time of it. > > -Mike > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From randy@psg.com Wed Sep 25 16:28:08 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0549A21F93BF for ; Wed, 25 Sep 2013 16:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R91NXwW-c5JR for ; Wed, 25 Sep 2013 16:28:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB9711E80E0 for ; Wed, 25 Sep 2013 16:28:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VOyUj-000720-RE; Wed, 25 Sep 2013 23:27:46 +0000 Date: Wed, 25 Sep 2013 13:27:44 -1000 Message-ID: From: Randy Bush To: ned+perpass@mrochek.com In-Reply-To: <01OYT4J2OJ3600004S@mauve.mrochek.com> References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.d> <6.2.5.6.2.20130923234903.0c854c78@resistor.net> <01OYT4J2OJ3600004S@mauve.mrochek.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: SM , perpass@ietf.org, Bjoern Hoehrmann Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 23:28:08 -0000 > It follows that one effect of the widespread use of end-to-end > encryption will be an *enormous* increase in the amount of spam and > malware that can't be blocked at the transport layer and will end up > getting delivered to user mailboxes. almost. for some of us, mailboxes are on hosts we own, and are inside our trust boundary. the local delivery agent could decrypt and analyse. i am not sure i would want the delivery agent decrypting. but i just want to point out an opportunity. randy From dhc@dcrocker.net Wed Sep 25 16:51:33 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0615D11E80ED for ; Wed, 25 Sep 2013 16:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRL+eeXjzdlx for ; Wed, 25 Sep 2013 16:51:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4C23A21F9ACA for ; Wed, 25 Sep 2013 16:51:12 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r8PNp5Er003713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Sep 2013 16:51:08 -0700 Message-ID: <524376C2.3070802@dcrocker.net> Date: Wed, 25 Sep 2013 16:50:26 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Bush References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.d> <6.2.5.6.2.20130923234903.0c854c78@resistor.net> <01OYT4J2OJ3600004S@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 25 Sep 2013 16:51:08 -0700 (PDT) Cc: ned+perpass@mrochek.com, perpass@ietf.org, Bjoern Hoehrmann , SM Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 23:51:33 -0000 On 9/25/2013 4:27 PM, Randy Bush wrote: >> It follows that one effect of the widespread use of end-to-end >> encryption will be an *enormous* increase in the amount of spam and >> malware that can't be blocked at the transport layer and will end up >> getting delivered to user mailboxes. > > almost. for some of us, Except that "almost" and "some of us" don't in any way contradict the original observation. As for there possibly being an "opportunity" to make major changes to a global, distributed infrastructure that is essential for filtering spam, well, uhhh, sure... No doubt a simple and inexpensive and risk-free endeavor. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From malbrain@yahoo.com Thu Sep 26 11:09:31 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D9121F9702 for ; Thu, 26 Sep 2013 11:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPuABxKrpUs2 for ; Thu, 26 Sep 2013 11:09:22 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8721F8B35 for ; Thu, 26 Sep 2013 11:08:38 -0700 (PDT) Received: from [98.139.215.141] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2013 18:08:35 -0000 Received: from [98.139.212.200] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2013 18:08:35 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 26 Sep 2013 18:08:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 123555.1109.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 2241 invoked by uid 60001); 26 Sep 2013 18:08:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380218914; bh=sZTMW3YJMjnMiVmXIcN1HcfCWxkEGYlebB2Ekk5Ot/k=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Iq4+19Y9K6nrECu49gXCGSrG1EeLM/6TT0zMp0mDd51pcy3Eg7h5M4G3MsDpYAHPm2ArpNVsFHWeidakTOJSOx15WJ4q3W3RXW4jJ69Lt+HgTBBReVf+xP5VrYYJmVrJL755brfqFjhjntR0XEqhpQ6G6HBvziZk8m3MQrPJ/9I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UAdFEc3az4+yYpOeAKiCCg5R2vZdNIGUujYRLwZ7gkrNlw3dUFq2Mw/XvTB7rTHv9SUewKMiXlCmXeV+UUnsM6C/CKDZl1oIdRC/0zUT+bp9WXax10VZCE26+4ideZ526gazbrE7YcZ1XfpNG7i09t1Qml5FxrDWZkFFSpRgGb0=; X-YMail-OSG: MfTOuoAVM1kEZPnB.UL8aZPRHmrXxakk46HduOu727fvqPZ kAyv_La5PzQEjzd2Tlc5sJMwrSnZufAIjCU7xFeFkTtD2h21ye8vpXIF5Qps rYIDlbmbpMM2q67iJ1z1eP.OJOnEK2YBEbvK4JvQ4aIeLR.vgAwNPuQ7VWyH CS5LyekH7hfK32c8Nz8S4B0oz9wKvldR_K.TI8ppzVj4E4Q8TT99JOkF0SLG gTrzQz.70uP8lBENTc50sxzx1Y3ORZEuQC9vEwCWftTJRJdps.lAXNiZrywT P3lTbPk82earwKX37WFpNOrIJdYWtNOjytf3VfPkfswbwWhg659185o05179 nolw8uFBedj5y7Tt9iHTSGHXfyd5X42pYKHyBmWvgses5ouLyGaPZe92LULa 8BXgHe6lWPrxFBKpgQgePDRUkeMF_x2K3Sn265ybKfnFW3Liw3xlw4Fpr4RU iUs38bSqcL4vmVV7GBLQK5eMiXSgKerMzYMUPKqxrbIgZS2vtyd5od.I8att YYe5dFM4cXZtGWJLoSIeaQByJdZtH5hWnc4fbEsdom4YhVBUAnI5eaUtNptV gT4l1ZtzanaiCDRjw3_P.Q8SCUrM4BXhWxgwnOQ-- Received: from [50.201.233.2] by web125502.mail.ne1.yahoo.com via HTTP; Thu, 26 Sep 2013 11:08:34 PDT X-Rocket-MIMEInfo: 002.001, Q0dBLVRTSUcgc2VlbXMgdG8gYmUgYSB0cnVzdCBvbiBmaXJzdCB1c2UgcHJvdG9jb2wgZm9yIHN1YnNlcXVlbnRseSB1cGRhdGluZyByZWNvcmRzIHdpdGhpbiBETlMuwqAgSXQgZG9lc24ndCBzZWVtIHRvIGFkZHJlc3MgdGhlIHByb2JsZW0gb2YgYW4gYXJiaXRyYXJ5wqBjbGllbnQgc2VjdXJlbHkgb2J0YWluaW5nIHRoZSBJUC9QdWJsaWMgS2V5IGZvciBhbiBhcmJpdHJhcnkgaG9zdCBmcm9tIEROUyB3aXRob3V0IHRoZSBwb3NzaWJsaXR5IG9mIE1JVE0uwqAgUGVyaGFwcyB5b3UgY291bGQgZXhwbGFpbiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> Message-ID: <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> Date: Thu, 26 Sep 2013 11:08:34 -0700 (PDT) From: Karl Malbrain To: Hosnieh Rafiee In-Reply-To: <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1546730761-1864678133-1380218914=:85280" Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 18:09:32 -0000 ---1546730761-1864678133-1380218914=:85280 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable CGA-TSIG seems to be a trust on first use protocol for subsequently updatin= g records within DNS.=A0 It doesn't seem to address the problem of an arbit= rary=A0client securely obtaining the IP/Public Key for an arbitrary host fr= om DNS without the possiblity of MITM.=A0 Perhaps you could explain further= .=0A=A0=0AKarl Malbrain=A0 =0A=0A________________________________=0A From: = Hosnieh Rafiee =0ATo: 'Karl Malbrain' =0ACc: 'perpass' ; 'Stephen Farrell' =0ASent: Wednesday, September 25, 2013 1:08 PM=0ASubject: Re: [pe= rpass] DNS confidentiality=0A =0A=0A=0ANot if you use another approach as = well as a signature. This means that if=A0 the two nodes know the IP addres= s of each other, then nobody can play a role of MITM if they are using CGA-= TSIG (http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig)as a means o= f DNS authentication.=0A=A0=0A=A0=0AHosnieh=0A=A0=0AFrom:perpass-bounces@ie= tf.org [mailto:perpass-bounces@ietf.org] On Behalf Of Karl Malbrain=0ASent:= Wednesday, September 25, 2013 9:38 PM=0ATo: Hosnieh Rafiee=0ACc: 'perpass'= ; 'Stephen Farrell'=0ASubject: Re: [perpass] DNS confidentiality=0A=A0=0AYe= s, MITM can be prevented if you have a copy of the public certificate obtai= ned through exteriour means to check the signature over the data.=A0 If you= r certificate is provided by MITM you naturally lose that signature protect= ion.=0A=A0=0AFrom:Hosnieh Rafiee =0ATo: 'Karl Malbrain' <= malbrain@yahoo.com> =0ACc: 'perpass' ; 'Stephen Farrell' = =0ASent: Tuesday, September 24, 2013 2:08 PM=0A= Subject: Re: [perpass] DNS confidentiality=0A=A0=0AMITM attack can be preve= nted by signing the data. Please check cga-tsig draft.=0A=A0=0A=A0=0AHosnie= h=0A=A0=0A=A0=0AFrom:perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.= org] On Behalf Of Karl Malbrain=0ASent: Tuesday, September 24, 2013 10:31 P= M=0ATo: Stephen Farrell; perpass=0ASubject: Re: [perpass] DNS confidentiali= ty=0A=A0=0ATo obviate the harvesting of meta-data, we do need a secure inte= rface to DNS.=0A=A0=0AMITM resistance (authentication) is also going to be = required in DNS server connections. Maybe well known certificates for DNS s= ervers=A0incorporated into browser software=0A=A0=0AGiven the reluctance of= browser writers=A0to implement DANE,=A0 we're going to need something like= encrypted QUIC available as a transport first.=0A=A0=0AKarl Malbrain=A0 = =0A=A0=0AFrom:Stephen Farrell =0ATo: perpass =0ASent: Tuesday, September 24, 2013 1:43 AM=0ASubject: [pe= rpass] DNS confidentiality=0A=0A=0AHiya,=0A=0AI've not seen mention of this= so far here that I recall.=0A=0AEven as we improve the security of loads o= f protocols, there=0Awill still be issues with meta-data monitoring based o= n=0ADNS queries for example. This point was sort of raised on=0Athe IETF li= st e.g. in [1].=0A=0ADNSSEC doesn't provide any confidentiality. There are= =0Aproposals that do try do that.=0A=0ADo we think this is worth looking at= ?=0AIf so, anyone up for doing some work on that?=0AIf so, how, or starting= from what?=0A=0AS.=0A=0A[1] http://www.ietf.org/mail-archive/web/ietf/curr= ent/msg82696.html=0A_______________________________________________=0Aperpa= ss mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/= perpass=0A=0A_______________________________________________=0Aperpass mail= ing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/perpass= =0A=0A=0A_______________________________________________=0Aperpass mailing = list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/perpass ---1546730761-1864678133-1380218914=:85280 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
CGA-TSIG s= eems to be a trust on first use protocol for subsequently updating records = within DNS.  It doesn't seem to address the problem of an arbitrary&nb= sp;client securely obtaining the IP/Public Key for an arbitrary host from D= NS without the possiblity of MITM.  Perhaps you could explain further.=
 
Karl Malbrain<= /div> 
From: Hosnieh Rafiee <ietf@rozanak.com>
To: 'Karl Malbrain' <malbrain= @yahoo.com>
Cc: 'pe= rpass' <perpass@ietf.org>; 'Stephen Farrell' <stephen.farrell@cs.t= cd.ie>
Sent: Wedne= sday, September 25, 2013 1:08 PM
= Subject: Re: [perpass] DNS confidentiality

=
Not if you use another approach as well as a = signature. This means that if  the two nodes know the IP address of ea= ch other, then nobody can play a role of MITM if they are using CGA-TSIG (<= /span>http://tools.ietf.org/html/draft-rafiee-= intarea-cga-tsig) as a means of DNS authentication= .
&= nbsp;
Hosnieh
 
From: perpass-bounces@ietf.org [= mailto:perpass-bounces@ietf.org] On Behalf Of Karl Malbrain
Se= nt: Wednesday, September 25, 2013 9:38 PM
To: Hosnieh Rafiee
C= c: 'perpass'; 'Stephen Farrell'
Subject: Re: [perpass] DNS co= nfidentiality
 
Yes, MITM can be prevented if= you have a copy of the public certificate obtained through exteriour means= to check the signature over the data.  If your certificate is provide= d by MITM you naturally lose that signature protection.
<= div>
 
Fro= m:ietf@rozanak.co= m>
To: 'Karl Malbrain' <malbrain@yahoo.com>
Cc: 'perpass' <perpass@ietf.org>; 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>= ;
Sent: Tuesday, September 24, 2013 2:08 PM
Subject: R= e: [perpass] DNS confidentiality
 
MITM attack can be prevented by signing the data. Please check cg= a-tsig draft.
<= div style=3D"background: white;" class=3D"yiv8699288648MsoNormal"> 
<= div>
 
Hosnieh
 
 
From: perpass-bounces@ietf.org [mailto:perpass-bounces@ietf.org] On Behalf Of Karl Mal= brain
Sent: Tuesday, September 24, 2013 10:31 PM
To: St= ephen Farrell; perpass
Subject: Re: [perpass] DNS confidentiality=
 
To obviate the harvesting of meta-data, we do need a secure interfac= e to DNS.
 
MITM resistance (authen= tication) is also going to be required in DNS server connections. Maybe wel= l known certificates for DNS servers incorporated into browser softwar= e
 
Given the reluctance of brows= er writers to implement DANE,  we're going to need something like= encrypted QUIC available as a transport first.
<= span style=3D"color: black;"> 
Kar= l Malbrain 
&= nbsp;
From:
Even as we improve the= security of loads of protocols, there
will still be issues with meta-da= ta monitoring based on
DNS queries for example. This point was sort of r= aised on
the IETF list e.g. in [1].

DNSSEC doesn't provide any co= nfidentiality. There are
proposals that do try do that.

Do we thi= nk this is worth looking at?
If so, anyone up for doing some work on tha= t?
If so, how, or starting from what?

S.

[1] http://www.ietf.org/mail-archive/web/ietf/current/ms= g82696.html
_______________________________________________
perpa= ss mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

______________________________________________= _
perpass mailing list
perpass@ietf.o= rg
https://www.ietf.org/mailman/listinfo/perpass


= _______________________________________________
perpass mailing list
= perpa= ss@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

---1546730761-1864678133-1380218914=:85280-- From hallam@gmail.com Thu Sep 26 17:12:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E28821E80E1 for ; Thu, 26 Sep 2013 17:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI3vbtRtlu58 for ; Thu, 26 Sep 2013 17:12:23 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E197621E80DA for ; Thu, 26 Sep 2013 17:12:20 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so1668971lbh.5 for ; Thu, 26 Sep 2013 17:12:19 -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; bh=rx6vPm021k7s7Ss+FAWsG4lKZfGCUY+L1VnSf2X6w+I=; b=nJYFJ8eWMjPygH+r7lo0KeSIW5HMw3DgHfaD3JnS8TYN05hLNz2AB0oa2qeSOrQIfM s8ZLwdkB2ZUifuJke0S0QFncYHW28tTzq9MIIaNZH80hary0vT1wRZOPlWzgCQ4JN0aC Yok5JK+VYPb8eO/71o6tBruInI6CWN2sd4mVs0hy4t2BywD6/cT7B5wbOlLG8oHP06RC ueEgkcMcobrmXe5MC9yHTqEwH7ZhWDCjfuYEwzrU7UAmtotCUgdMP7wRp77exTuf/hQG LorzzCZyYE3ljZMtAHkt7WAl0BwQ0Oq8zy7pi3cOaJ5nHlw22ALuVdyhlkp4hNcuH4pp zzOg== MIME-Version: 1.0 X-Received: by 10.152.30.74 with SMTP id q10mr2935400lah.27.1380240739650; Thu, 26 Sep 2013 17:12:19 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Thu, 26 Sep 2013 17:12:19 -0700 (PDT) In-Reply-To: <01OYT4J2OJ3600004S@mauve.mrochek.com> References: <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.de> <84mt39ljo4sm6p6h9h5o1ker1fgigcdqke@hive.bjoern.hoehrmann.d> <6.2.5.6.2.20130923234903.0c854c78@resistor.net> <01OYT4J2OJ3600004S@mauve.mrochek.com> Date: Thu, 26 Sep 2013 20:12:19 -0400 Message-ID: From: Phillip Hallam-Baker To: ned+perpass@mrochek.com Content-Type: multipart/alternative; boundary=089e0158c410fdd0c404e7525690 Cc: SM , perpass , Bjoern Hoehrmann Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 00:12:25 -0000 --089e0158c410fdd0c404e7525690 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 24, 2013 at 7:23 PM, wrote: > > > In the case of email, meeting that goal with end-to-end encryption > mechanisms > like S/MIME or PGP is necessarily going to mean having a nonnegligable > amount > of email traffic encrypted. The minute that happens spammers are going to > join > the party in a big way precisely because of the ability this confers to get > past transport-side content inspection and filtering. > Yes, I anticipated that problem. Though I am not sure what the solution is. I consider this to be part of the 'research' problem and didn't want to bias the paper describing the decomposition of the problem. One approach would be to only accept encrypted mail if it is signed by someone in my circle of trust or an adjacent circle. Which is one of the reasons I started looking again at a hybrid of Web o' Trust and CA managed trust. One option would be that a notary allows parties registered to notarize up to 10 key endorsements per week, pick a limit, the bad guys need thousands of disposable addresses every hour. Another would be to get an EV cert and use that to endorse EE certs as legit. Consumers are not going to want to spend that sort of money but it is probably the cheapest solution for an enterprise. > State of the art AS/AV vendors employ honeypots and other forms of > feedback to > rapidly generate rules, patterns, hashes, and other information, which is > then > rapidly distributed to filtering systems attached to vast numbers of > ingress > MTAs operated by their customers. Some of this filtering is done on the > basis > of IP addresses, envelope, or outer header information, but a lot of it > depends > on content analysis - analysis that will be blocked by encryption. > And you need malware blocking and quite a bit of other stuff which is why I suspect that some enterprises will not permit genuinely end-to-end encrypted email. In fact some are blocked by regulation. > Any halfway realistic plan to deploy end-to-end encryption at Internet > scale is > going to have deal with the totality of contemporary email services and > usage > in addition to solving the myriad problems surrounding key/certificate > distribution and management as well as UI issues. (As if the latter weren't > difficult enough.) > The key distribution and key endorsement infrastructure counts as 'research' for that reason. But we can certainly put together a system that is adequate for use within the security community and provides transparent security. That is kind of a no-brainer to deploy since the bad guys have always known that spying on security researchers is most likely to reveal important info. Mitnick was no genius, he just hacked the voicemail of the VMS security guru. -- Website: http://hallambaker.com/ --089e0158c410fdd0c404e7525690 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 24, 2013 at 7:23 PM, <ned+perpass@mroc= hek.com> wrote:
>=
In the case of email, meeting that goal with end-to-end encryption mechanis= ms
like S/MIME or PGP is necessarily going to mean having a nonnegligable amou= nt
of email traffic encrypted. The minute that happens spammers are going to j= oin
the party in a big way precisely because of the ability this confers to get=
past transport-side content inspection and filtering.
=
Yes, I anticipated that problem. Though I am not sure what t= he solution is. I consider this to be part of the 'research' proble= m and didn't want to bias the paper describing the decomposition of the= problem.

One approach would be to only accept encrypted mail if = it is signed by someone in my circle of trust or an adjacent circle. Which = is one of the reasons I started looking again at a hybrid of Web o' Tru= st and CA managed trust.


One option would be that a notary allows= parties registered to notarize up to 10 key endorsements per week, pick a = limit, the bad guys need thousands of disposable addresses every hour.=A0

Another would be to get an EV cert and use that to endo= rse EE certs as legit. Consumers are not going to want to spend that sort o= f money but it is probably the cheapest solution for an enterprise.

=A0
State of the art AS/AV vendors employ honeypots and other forms of feedback= to
rapidly generate rules, patterns, hashes, and other information, which is t= hen
rapidly distributed to filtering systems attached to vast numbers of ingres= s
MTAs operated by their customers. Some of this filtering is done on the bas= is
of IP addresses, envelope, or outer header information, but a lot of it dep= ends
on content analysis - analysis that will be blocked by encryption.

And you need malware blocking and quite a bit o= f other stuff which is why I suspect that some enterprises will not permit = genuinely end-to-end encrypted email. In fact some are blocked by regulatio= n.


=A0
Any halfway realistic plan to deploy end-to-end encryption at Internet scal= e is
going to have deal with the totality of contemporary email services and usa= ge
in addition to solving the myriad problems surrounding key/certificate
distribution and management as well as UI issues. (As if the latter weren&#= 39;t
difficult enough.)

The key distribution= and key endorsement infrastructure counts as 'research' for that r= eason.

But we can certainly put together a system = that is adequate for use within the security community and provides transpa= rent security. That is kind of a no-brainer to deploy since the bad guys ha= ve always known that spying on security researchers is most likely to revea= l important info. Mitnick was no genius, he just hacked the voicemail of th= e VMS security guru.



--
Website: http://hallambaker.com/
--089e0158c410fdd0c404e7525690-- From carl@redhoundsoftware.com Thu Sep 26 19:41:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBBC11E80A2 for ; Thu, 26 Sep 2013 19:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgVKQ-ao3n63 for ; Thu, 26 Sep 2013 19:41:01 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 666A421F9DA0 for ; Thu, 26 Sep 2013 19:41:01 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id j7so135023qaq.16 for ; Thu, 26 Sep 2013 19:40:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=TY9PrkADho08+t7J2OYkAUUMupR7mo7w1D9c3WEEbh0=; b=COwFlepKIBU0kCYOB7PyE8Jbd8eG+IF3x8bV9DgYJkZiEAYSB4c4rUNxiSzfzVt+kO GaJszSdeAakUpIS0uiAOc30+slCvejvOOJc/OsWyeIInYVMSKx5BA0sjcPmQvWMiaa0N fbU+oBP5MPFAyXMpAOcm+qQPFTSONUjGo29VB+El8v88SExTyiuzW6hddyqpwgBZntmg iiVOetNO7STmTTf0vQLOHP3hc3n2kRl9GmCAqBQZmKZ594gqjZTmrWE/OKsXRVu63PVX i3M104RXt19HUCewHkje7pxAdAD19bu2Brmpy6ssH/Z5jdjjNlaDM1dmXwgD6ZaGg2IY Crcg== X-Gm-Message-State: ALoCoQm3h6uE0zlePY++YRis0kt9Vo+ih7OuTENpRA8rFHIJ8CVHVYAy2FocIbVj1puVlrOWLVBl X-Received: by 10.49.6.232 with SMTP id e8mr5919737qea.18.1380249657751; Thu, 26 Sep 2013 19:40:57 -0700 (PDT) Received: from [192.168.2.3] (pool-173-79-121-77.washdc.fios.verizon.net. [173.79.121.77]) by mx.google.com with ESMTPSA id g2sm14467395qaf.12.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Sep 2013 19:40:57 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Thu, 26 Sep 2013 22:40:51 -0400 From: Carl Wallace To: Phillip Hallam-Baker , Message-ID: Thread-Topic: [perpass] A proposal for developing PRISM-Proof email In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3463080057_596698" Cc: SM , perpass , Bjoern Hoehrmann Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 02:41:07 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3463080057_596698 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Phillip Hallam-Baker Date: Thursday, September 26, 2013 8:12 PM To: Cc: SM , perpass , Bjoern Hoehrmann Subject: Re: [perpass] A proposal for developing PRISM-Proof email > On Tue, Sep 24, 2013 at 7:23 PM, wrote: >>> > >> In the case of email, meeting that goal with end-to-end encryption mechanisms >> like S/MIME or PGP is necessarily going to mean having a nonnegligable amount >> of email traffic encrypted. The minute that happens spammers are going to >> join >> the party in a big way precisely because of the ability this confers to get >> past transport-side content inspection and filtering. > > Yes, I anticipated that problem. Though I am not sure what the solution is. I > consider this to be part of the 'research' problem and didn't want to bias the > paper describing the decomposition of the problem. > > One approach would be to only accept encrypted mail if it is signed by someone > in my circle of trust or an adjacent circle. Which is one of the reasons I > started looking again at a hybrid of Web o' Trust and CA managed trust. > > > One option would be that a notary allows parties registered to notarize up to > 10 key endorsements per week, pick a limit, the bad guys need thousands of > disposable addresses every hour. > > Another would be to get an EV cert and use that to endorse EE certs as legit. > Consumers are not going to want to spend that sort of money but it is probably > the cheapest solution for an enterprise. Another would be to encrypt using multiple keys for each recipient. This could help with the multiple device problem. The set of keys used could include a key for a filter if desired. --B_3463080057_596698 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Thursday, September 26, 2013 8:12 PM
T= o: <ned+perpass@mrochek.= com>
Cc: SM <sm@resistor.net>, perpass <perpass@ietf.org>, Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: Re: [perpass] A proposal for developing PRISM-Proof = email

=

One approach would be to only accept encrypted mail if i= t is signed by someone in my circle of trust or an adjacent circle. Which is= one of the reasons I started looking again at a hybrid of Web o' Trust and = CA managed trust.


One option would b= e that a notary allows parties registered to notarize up to 10 key endorseme= nts per week, pick a limit, the bad guys need thousands of disposable addres= ses every hour. 

Another would be to get an EV= cert and use that to endorse EE certs as legit. Consumers are not going to = want to spend that sort of money but it is probably the cheapest solution fo= r an enterprise.

<= div>Another would be to encrypt using multiple keys for each recipient. &nbs= p;This could help with the multiple device problem.  The set of keys us= ed could include a key for a filter if desired.
--B_3463080057_596698-- From hallam@gmail.com Fri Sep 27 08:35:18 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB3A11E815C for ; Fri, 27 Sep 2013 08:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC5YxNHU357X for ; Fri, 27 Sep 2013 08:35:16 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF5B11E8164 for ; Fri, 27 Sep 2013 08:34:55 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id y6so2398629lbh.34 for ; Fri, 27 Sep 2013 08:34:54 -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; bh=qc8YR1SmUw4SWYjULNLd4g8CUqTdEU9MU3SGmU/+VKk=; b=BU+MnZlOz6dXLOMaZ9nusZYVFgewSPjMuwW76UhoZfKw9/g02HbbX2GYxYby4VE9Tx GeojiPV5ok5Zdk6lokCiVV5t5xuQYCvkQOive5GPBCdOxO/UTOH/NAyU3JO5n8+p2qJq 9OXGDEq7xp0X0OlSsMFXNRragZOqIzYazSapmC9ZoyxuAJPfa2k9joX/Gr+6if2j5zWi myyBL7h3lgYVSWPpUNB7BjR8FVeLgKrl0I+BAelYFemoif+MBLaWhXcxv4wbFn7AJ8Kr bu0eZ5U0tkUX4EPvbU2ihA1SEuLBkBQ/CZYzGZ605U70Z+EUMegeAk1av5laOZJ0G8mF BeCw== MIME-Version: 1.0 X-Received: by 10.112.155.70 with SMTP id vu6mr1830555lbb.41.1380296094364; Fri, 27 Sep 2013 08:34:54 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 27 Sep 2013 08:34:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Sep 2013 11:34:54 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: multipart/alternative; boundary=089e0115fe1e63b86804e75f3abc Cc: ned+perpass@mrochek.com, perpass , Bjoern Hoehrmann , SM Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 15:35:18 -0000 --089e0115fe1e63b86804e75f3abc Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 26, 2013 at 10:40 PM, Carl Wallace wrote: > > From: Phillip Hallam-Baker > Date: Thursday, September 26, 2013 8:12 PM > To: > Cc: SM , perpass , Bjoern Hoehrmann < > derhoermi@gmx.net> > Subject: Re: [perpass] A proposal for developing PRISM-Proof email > > > Another would be to get an EV cert and use that to endorse EE certs as > legit. Consumers are not going to want to spend that sort of money but it > is probably the cheapest solution for an enterprise. > > > Another would be to encrypt using multiple keys for each recipient. This > could help with the multiple device problem. The set of keys used could > include a key for a filter if desired. > I came to the exact opposite conclusion, that the decryption key needs to be shared across every device and with no predetermined expiry. You have no idea which of the devices I use that I might read your email on. I have 2 desktops, 2 iphones, one iPad and 3 laptops in regular use. And that is just the ones that I consider essential. The set of devices changes at least once a year. The MacBook typically lasts about 6 months between visits to Apple customer service. There is no security advantage to having mail sent to me encrypted under a different key per device. There is however an advantage to having mail signed under a different key per device and not sharing those across devices . -- Website: http://hallambaker.com/ --089e0115fe1e63b86804e75f3abc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Sep 26, 2013 at 10:40 PM, Carl Wallace &l= t;carl@redho= undsoftware.com> wrote:

From: Phillip Hallam-Baker <hallam@gmail.com>=
Date: Thursday, September 26, = 2013 8:12 PM
To: <ned+perpass@mrochek.com>
Cc: SM <sm@resistor.net>, perpass <perpass@ietf.org>, Bjoern H= oehrmann <derhoer= mi@gmx.net>
Subject: Re: [perpass] A proposal = for developing PRISM-Proof email

=

Another would be to get an EV cert and use that to endorse = EE certs as legit. Consumers are not going to want to spend that sort of mo= ney but it is probably the cheapest solution for an enterprise.

Another wou= ld be to encrypt using multiple keys for each recipient. =A0This could help= with the multiple device problem. =A0The set of keys used could include a = key for a filter if desired.

I came to the exact opposite conclusion, that the de= cryption key needs to be shared across every device and with no predetermin= ed expiry.

You have no idea which of the devices I use that I might read your email on= . I have 2 desktops, 2 iphones, one iPad and 3 laptops in regular use. And = that is just the ones that I consider essential.

The set of devices changes at least once a year. The= MacBook typically lasts about 6 months between visits to Apple customer se= rvice.


There is no security advanta= ge to having mail sent to me encrypted under a different key per device. Th= ere is however an advantage to having mail signed under a different key per= device and not sharing those across devices .

--
Website: http://h= allambaker.com/
--089e0115fe1e63b86804e75f3abc-- From carl@redhoundsoftware.com Fri Sep 27 08:38:07 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94B311E8159 for ; Fri, 27 Sep 2013 08:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY+vJdm2vQdL for ; Fri, 27 Sep 2013 08:38:02 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id DFC1F21F9EB8 for ; Fri, 27 Sep 2013 08:38:01 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id k4so582006qaq.18 for ; Fri, 27 Sep 2013 08:38:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type; bh=uQZSlzSdhi0fB/pSdSaW9B2DCmMteada0LluiZYcDI0=; b=Z2YhWEziETU/U1c44ASURA2SRIt9nc2A2uriBfQURhYR/t5mpgsj57sycSNoPUjfo+ ynvN6BL+mcFaiOUaPbRwC2jyYxJsQ1c719eMucjaC5HxW/XdMzlP0m5rLJLZIm1O85fr 0xy3TaR2j4Or8TGAnkOWA2nS4kBzpHc+hzna3vnTCxFfHutw5oEA/Xew0WKXGP2pxyRr 0sb2wEr65D4PSP+3cMeCZwTPdXh/5oMfNY4drwdk28vRIiP60VBgr0MgXEAA52owDu8O /H8AMFQUyiFzVAakOzKVxtqop3j2nYX6G/z8JmDU5TV3WYNt744bp8dK16Zjp+VTHTq+ Aq8w== X-Gm-Message-State: ALoCoQl2SlTXk3VffdFBrusoRFvTolttTdZXlDRERRv6Lpw408lrCeLGq/QlLp4eqsMNxmobSZ7y X-Received: by 10.224.60.199 with SMTP id q7mr15150998qah.80.1380296280173; Fri, 27 Sep 2013 08:38:00 -0700 (PDT) Received: from [192.168.2.6] (pool-173-79-121-77.washdc.fios.verizon.net. [173.79.121.77]) by mx.google.com with ESMTPSA id h6sm13902461qej.4.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 27 Sep 2013 08:37:59 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Fri, 27 Sep 2013 11:37:54 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [perpass] A proposal for developing PRISM-Proof email In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3463126679_1727662" Cc: ned+perpass@mrochek.com, perpass , Bjoern Hoehrmann , SM Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 15:38:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3463126679_1727662 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit >> >> Another would be to encrypt using multiple keys for each recipient. This >> could help with the multiple device problem. The set of keys used could >> include a key for a filter if desired. > > I came to the exact opposite conclusion, that the decryption key needs to be > shared across every device and with no predetermined expiry. > > You have no idea which of the devices I use that I might read your email on. I > have 2 desktops, 2 iphones, one iPad and 3 laptops in regular use. And that is > just the ones that I consider essential. > > The set of devices changes at least once a year. The MacBook typically lasts > about 6 months between visits to Apple customer service. Sure, but you know what keys are on each device and could publish those accordingly. You also know the key of your filter. If the sender encrypted to your set of keys (instead of single key as is current practice), there are a couple of potential advantages. > > > There is no security advantage to having mail sent to me encrypted under a > different key per device. There is however an advantage to having mail signed > under a different key per device and not sharing those across devices . No security advantage, but a usability advantage. --B_3463126679_1727662 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable <= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4= df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">

Another= would be to encrypt using multiple keys for each recipient.  This coul= d help with the multiple device problem.  The set of keys used could in= clude a key for a filter if desired.

I came to t= he exact opposite conclusion, that the decryption key needs to be shared acr= oss every device and with no predetermined expiry.

You have no idea which of the devices I use that I might read your email on= . I have 2 desktops, 2 iphones, one iPad and 3 laptops in regular use. And t= hat is just the ones that I consider essential.

The set of devices changes at least once a year. The = MacBook typically lasts about 6 months between visits to Apple customer serv= ice.

Sure, but you = know what keys are on each device and could publish those accordingly.  = ;You also know the key of your filter.  If the sender encrypted to your= set of keys (instead of single key as is current practice), there are a cou= ple of potential advantages.



There is no security adva= ntage to having mail sent to me encrypted under a different key per device. = There is however an advantage to having mail signed under a different key pe= r device and not sharing those across devices .

No security advantage, but a usability advantag= e.

--B_3463126679_1727662-- From hallam@gmail.com Fri Sep 27 09:30:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36ADC21F9AD2 for ; Fri, 27 Sep 2013 09:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxIQXZpqPkVf for ; Fri, 27 Sep 2013 09:30:39 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9722721F9E00 for ; Fri, 27 Sep 2013 09:30:31 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id o14so2454931lbi.32 for ; Fri, 27 Sep 2013 09:30:29 -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; bh=L0fEroJkMGX0ZG9yZMCzYY9D7ZWZi88wjzggpCK0WJc=; b=SmGH7BuMOiDd059mIGzsoYOJm/kV0TQu3OxJz+3162jiw46pTCL5YrTdT5N9PQKZPO L0VvEgqlggGGZ5vtlTZfW5Qjtp/cll2nzWk8iP48SCGJRojwEad687UEgUgWTtvgTYaP W98Hok6Uo7yaTEMfEDKO938YVRr7DLOn2QtLeljn9zXsVAqk+pEYMYqwuol4EC12lCG7 bbg9kMTnNto/CI2RPNezLUgGUSD3vjEbmaGDHgieYsinLFHgp6qygPm9AOCPbLPz/JDT OCLFlMQZQ2rQC9Cq7eL6lS9PZeOTMo17C/bUv0yGxMiDGG0rsP0TDNN4ZWxjIcceli/n cVfg== MIME-Version: 1.0 X-Received: by 10.112.155.70 with SMTP id vu6mr2015737lbb.41.1380299427812; Fri, 27 Sep 2013 09:30:27 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 27 Sep 2013 09:30:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Sep 2013 12:30:27 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: multipart/alternative; boundary=089e0115fe1e141de604e760016a Cc: ned+perpass@mrochek.com, perpass , Bjoern Hoehrmann , SM Subject: Re: [perpass] A proposal for developing PRISM-Proof email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 16:30:41 -0000 --089e0115fe1e141de604e760016a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 27, 2013 at 11:37 AM, Carl Wallace wrote: > There is no security advantage to having mail sent to me encrypted under a > different key per device. There is however an advantage to having mail > signed under a different key per device and not sharing those across > devices . > > > No security advantage, but a usability advantage. > I think it is better to work on making it easier and more secure to import the keys. Here is the scheme that I am currently coding for. Note that at present I am only considering how to configure to RECEIVE and decrypt the emails in existing clients. I know that much work is going to have to be done with those clients before it is practical to use them for signed mail or to send encrypted mail. But I don't need to be able to send encrypted mail on every single machine and this can be done with a local proxy in any case. But I absolutely MUST be able to read anywhere. Step 1: To generate my first key: I run the KeyMan tool as follows: keyman /generate hallam@gmail.com /service hallambaker.com /share 5 hallambaker.com is just the pki equivalent of a news server, it is a gateway to the trust infrastructure (whatever that turns out to be) not the infrastructure itself. I assume that there will be multiple trust models. In production mode, the omniconnect service to use and the necessary credentials will be defined as a Windows registry or other platform/user config file. I have included it here so that it is visible. [This is the line mode version of the tool but it is easy to write a UI version as the interaction is trivial.] What this does is to * Generate an RSA2408 keypair (the default alg) * Choose a random 256 bit password to encrypt it with AES256 in a PKCS #12 * Generate a self signed certificate for 10 year validity and a CSR * Submit the CSR, Self Signed cert and PKCS12 to the OmniRegistration service at hallambaker.com * Installs the private key on the machine and configures any email client on the machine to allow use of the key/self signed cert to decrypt messages. * Prints out the five key shares for the 256 bit password to the console in groups of five Base32 characters. [The arbitrary defaults can be over-ridden of course] The user is instructed to write down the five key shares, three of which can be used to reconstruct the key. These can be sent to a printer, but that leads to security issues with the printer having a cache and we probably don't want to add a printer to some builds such as a Raspberry Pi running a stripped / secured stack. The ordinary user would just choose the default and have one password to write down. At this point the email clients on that particular machine can decrypt email encrypted under the self-signed certificate. Now one twist that I have not looked into quite yet is whether this would also allow those email readers to decrypt messages to the same key but under a different certificate. I suspect not for the existing clients and protocols but we could make this possible in principle by adding an extension into any certificates generated by a CA to tell clients that the private key is to be found in the self signed cert container. Alternatively an IMAP proxy might rewrite the S/MIME messages for me. This would allow the next step to be eliminated. 1a) To enable use of a CA issued certificate on the machine keyman /register hallam@gmail.com /service hallambaker.com Note that there are no files involved. The tool is going to talk to the service and only the service. * Tool retrieves the issued cert(s) from the service and installs them for use transferring the private key obtained earlier. At this point the tool might ask the user for the key shares so that the ability of the user to decrypt their key can be verified before telling the service to mark it as 'live'. 2) To enable use of a CA issued certificate on a different device keyman /register hallam@gmail.com /service hallambaker.com [user types in their key shares] If the device is a completely new one it will configure the email service info as well as the private key. Considerations: This is only for encryption keys. There should be a separate signature key for every device. Private keys should never move off a device to which they have been installed. It might well be desirable to let a user generate keypairs on one particular device under controlled circumstances. For example, I might dedicate an SD card to containing a Raspberry Pi build for this exact purpose and only use it for this purpose, generating an encryption keypair and a set of signing keypairs for all my devices in one go, then erasing the contents at the end. While some folk might object to storing their encrypted private key in the cloud, I doubt that the risk is worth worrying about. If AES256 is broken then we are toasty toast and no need to worry about anything. The data is almost certainly going to have to sit on the endpoint machine in less than perfect security. Most users probably don't need to bother with keyshares. A single password will be enough for them. Or they might have a password for personal use and keyshares registered so that survivors can reconstruct the key if needed. Printing the keyshares out on paper is much simpler and more reliable than use of USB fobs or the like. A malicious actor could copy the data but I don't see that mattering in this particular application. The point is to convince the user that they are not going to loose their data due to a hardware failure under any circumstances. -- Website: http://hallambaker.com/ --089e0115fe1e141de604e760016a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 27, 2013 at 11:37 AM, Carl Wallace <carl@redhoundsoftware.com> wrote:
<= div>There is no security advantage to having mail sent to me encrypted unde= r a different key per device. There is however an advantage to having mail = signed under a different key per device and not sharing those across device= s .

No security advan= tage, but a usability advantage.

I think it is better to work on making it easier and more secure to impor= t the keys. Here is the scheme that I am currently coding for.=A0

Note that at present I am only considering how to confi= gure to RECEIVE and decrypt the emails in existing clients. I know that muc= h work is going to have to be done with those clients before it is practica= l to use them for signed mail or to send encrypted mail. But I don't ne= ed to be able to send encrypted mail on every single machine and this can b= e done with a local proxy in any case. But I absolutely MUST be able to rea= d anywhere.


Step 1: To generate my first key:

I run the KeyMan tool as follows:

keyman /generate hallam@gmail.co= m /service hallambaker.com /shar= e 5=A0

hallambaker.com = is just the pki equivalent of a news server, it is a gateway to the trust i= nfrastructure (whatever that turns out to be) not the infrastructure itself= . I assume that there will be multiple trust models.

In production mode, the omniconnect service to use and = the necessary credentials will be defined as a Windows registry or other pl= atform/user config file. I have included it here so that it is visible.

[This is the line mode version of the tool but it is ea= sy to write a UI version as the interaction is trivial.]


What this does is to

* Gener= ate an RSA2408 keypair (the default alg)
* Choose a random 256 bit password to encrypt it with AES256 in = a PKCS #12
* Generate a self signed certificate for 10 year valid= ity and a CSR
* Submit the CSR, Self Signed cert and PKCS12 to th= e OmniRegistration service at hallambake= r.com
* Installs the private key on the machine and configures any email cli= ent on the machine to allow use of the key/self signed cert to decrypt mess= ages.
* Prints out the five key shares for the 256 bit password t= o the console in groups of five Base32 characters.

[The arbitrary defaults can be over-ridden of course]


The user is instructed to write = down the five key shares, three of which can be used to reconstruct the key= . These can be sent to a printer, but that leads to security issues with th= e printer having a cache and we probably don't want to add a printer to= some builds such as a Raspberry Pi running a stripped / secured stack.

The ordinary user would just choose the default and hav= e one password to write down.


At th= is point the email clients on that particular machine can decrypt email enc= rypted under the self-signed certificate. Now one twist that I have not loo= ked into quite yet is whether this would also allow those email readers to = decrypt messages to the same key but under a different certificate. I suspe= ct not for the existing clients and protocols but we could make this possib= le in principle by adding an extension into any certificates generated by a= CA to tell clients that the private key is to be found in the self signed = cert container. Alternatively an IMAP proxy might rewrite the S/MIME messag= es for me.

This would allow the next step to be eliminated.
<= div>

1a) To enable use of a CA issued ce= rtificate on the machine

keyman /register hallam@gmail.com /service =A0hallambaker.com

Note that there are no files involved. The tool is goin= g to talk to the service and only the service.

* T= ool retrieves the issued cert(s) from the service and installs them for use= transferring the private key obtained earlier.

At this point the tool might ask the user for the key s= hares so that the ability of the user to decrypt their key can be verified = before telling the service to mark it as 'live'.


2) To enable use of a CA issued certificate on a = different device

keyman /register hallam@gmail.com /service =A0hallambaker.com
[user types in their key shares]

If the= device is a completely new one it will configure the email service info as= well as the private key.=A0



Considerations:

This is only for encryp= tion keys. There should be a separate signature key for every device.=A0

Private keys should never move off a device to which= they have been installed. It might well be desirable to let a user generat= e keypairs on one particular device under controlled circumstances. For exa= mple, I might dedicate an SD card to containing a Raspberry Pi build for th= is exact purpose and only use it for this purpose, generating an encryption= keypair and a set of signing keypairs for all my devices in one go, then e= rasing the contents at the end.

While some folk might object to storing their encrypted= private key in the cloud, I doubt that the risk is worth worrying about. I= f AES256 is broken then we are toasty toast and no need to worry about anyt= hing. The data is almost certainly going to have to sit on the endpoint mac= hine in less than perfect security.

Most users probably don't need to bother with keysh= ares. A single password will be enough for them. Or they might have a passw= ord for personal use and keyshares registered so that survivors can reconst= ruct the key if needed.

Printing the keyshares out on paper is much simpler and= more reliable than use of USB fobs or the like. A malicious actor could co= py the data but I don't see that mattering in this particular applicati= on. The point is to convince the user that they are not going to loose thei= r data due to a hardware failure under any circumstances.


--
Website: http://hallambaker.com/
--089e0115fe1e141de604e760016a-- From hallam@gmail.com Fri Sep 27 09:51:10 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E27111E8103 for ; Fri, 27 Sep 2013 09:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzuuSaJI1Qdw for ; Fri, 27 Sep 2013 09:51:09 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id C41DE21F9D52 for ; Fri, 27 Sep 2013 09:51:08 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id x18so2441802lbi.24 for ; Fri, 27 Sep 2013 09:51:07 -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; bh=Qk1Ya1dn6PGdBF/SsWsrTd3v8EMd0ljJSkvk0d0sq/4=; b=ewUYLAi2ktneTjK6VdfDTenGryVbcFJ8dlFqRrQA2qM75zBIZ02hgNGCt/puiAswfk uwZaX2iqboFJhd5XsPmfNdmVg5G7mZCGEFl2rx3IH/u73si++uPWrXU4dBEOiL6e7UUB hPQ1X6cWQ7EzLQepID2wYNAYfah9BpNol7j5er2h2tOLyFk9N9iIgQEIhWhBNM7tvSR/ KO1wCi/oqDNsWop2lsRAHF7NcTeT1mgFlatfEs2c2XUyJ5WGz+f9PoDBtiJ+E9drtffm RTFUvy7H5AItZ1eLqNK0l5OdRAiPHW5snq93m0yrlMyujyeJClckKdHWnAOOSODpu95W j68g== MIME-Version: 1.0 X-Received: by 10.112.128.166 with SMTP id np6mr9396593lbb.7.1380300667715; Fri, 27 Sep 2013 09:51:07 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 27 Sep 2013 09:51:07 -0700 (PDT) In-Reply-To: <524150C7.2020602@cs.tcd.ie> References: <524150C7.2020602@cs.tcd.ie> Date: Fri, 27 Sep 2013 12:51:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b343ef2fb895a04e7604aa1 Cc: perpass Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 16:51:10 -0000 --047d7b343ef2fb895a04e7604aa1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 24, 2013 at 4:43 AM, Stephen Farrell wrote: > > Hiya, > > I've not seen mention of this so far here that I recall. > > Even as we improve the security of loads of protocols, there > will still be issues with meta-data monitoring based on > DNS queries for example. This point was sort of raised on > the IETF list e.g. in [1]. > > DNSSEC doesn't provide any confidentiality. There are > proposals that do try do that. > > Do we think this is worth looking at? > If so, anyone up for doing some work on that? > If so, how, or starting from what? > I have been looking at this for over a year now. Does anyone have issues with the following: * The communication between the client and the DNS resolver need not be the same as the protocol between the DNS resolver and the Authoritative servers. * System must offer fault tolerance with the client having access to multiple service points. * Use JSON over HTTP wherever possible * Individual DNS queries MUST result in low latency responses, this limits us to using UDP. * The scheme MUST work in ANY network configuration unless the provider takes explicit steps to block use. Therefore the scheme SHOULD support tunneling over DNS as an option but a clean protocol over UDP is better. * The scheme need not be limited to returning DNS information, if we have a long term security association between a client and a resolution service we can use it for speeding up access to OCSP data and much else if we choose. The above analysis led me to the following conclusion: http://tools.ietf.org/html/draft-hallambaker-omnibroker-06 This does not currently offer the UDP and DNS options but they are what motivated the following proposal: http://tools.ietf.org/html/draft-hallambaker-jsonbcd-00 There are important design differences between this proposal and CBOR. In particular JSON-B is a minimal extension of the JSON framework to add in efficient encoding of strings and binary data while CBOR is a rehash of ASN.1 without the schema. Note that the query currently supported is a replacement for the gethostbyname API call rather than a full DNS interface. The reason for this is that 99% of all applications only perform gethostbyname in the first place. The spec does allow a service to respond with a DNSSEC proof chain as advice on client request. Adding direct DNS queries to the spec is very simple, these can certainly be added if there is a desire for them. I would make one major change however and that is to support multiple DNS queries per request. One of the biggest limitations in the current DNS scheme is that it is only possible to query for one DNS record at a time or the ANY pseudo record which returns everything (and likely forces a TCP switchover). The requests actual applications want to make are things like the following: [example.com ? A, AAAA] [_http._tcp.example.com ? SRV, URI, URI2] Use of extended DNS features would be much easier if a client could tell the resolver to send back data for multiple queries at once. Moving to a pure UDP protocol allows requests and responses to be longer than 500 bytes. It is also possible for a single request packet to return multiple responses. These mean that it is very unlikely that fallback to TCP is ever going to be necessary for client queries where low latency is essential. It is however possible that a complex DNSSEC interaction might require a large amount of response data. -- Website: http://hallambaker.com/ --047d7b343ef2fb895a04e7604aa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 24, 2013 at 4:43 AM, Stephen Farrell = <stephen.= farrell@cs.tcd.ie> wrote:

Hiya,

I've not seen mention of this so far here that I recall.

Even as we improve the security of loads of protocols, there
will still be issues with meta-data monitoring based on
DNS queries for example. This point was sort of raised on
the IETF list e.g. in [1].

DNSSEC doesn't provide any confidentiality. There are
proposals that do try do that.

Do we think this is worth looking at?
If so, anyone up for doing some work on that?
If so, how, or starting from what?

I ha= ve been looking at this for over a year now. Does anyone have issues with t= he following:

* The communication between the clie= nt and the DNS resolver need not be the same as the protocol between the DN= S resolver and the Authoritative servers.

* System must offer fault tolerance with the client hav= ing access to multiple service points.

* Use JSON = over HTTP wherever possible

* Individual DNS queri= es MUST result in low latency responses, this limits us to using UDP.

* The scheme MUST work in ANY network configuration unl= ess the provider takes explicit steps to block use. Therefore the scheme SH= OULD support tunneling over DNS as an option but a clean protocol over UDP = is better.

* The scheme need not be limited to returning DNS infor= mation, if we have a long term security association between a client and a = resolution service we can use it for speeding up access to OCSP data and mu= ch else if we choose.


The above analysis led me to the followi= ng conclusion:


This does not currently offer the UDP and DNS opt= ions but they are what motivated the following proposal:


There are important design differences between th= is proposal and CBOR. In particular JSON-B is a minimal extension of the JS= ON framework to add in efficient encoding of strings and binary data while = CBOR is a rehash of ASN.1 without the schema.=A0


Note that the query currently supported = is a replacement for the gethostbyname API call rather than a full DNS inte= rface. The reason for this is that 99% of all applications only perform get= hostbyname in the first place. The spec does allow a service to respond wit= h a DNSSEC proof chain as advice on client request.=A0


Adding direct DNS queries to the spec is= very simple, these can certainly be added if there is a desire for them. I= would make one major change however and that is to support multiple DNS qu= eries per request. One of the biggest limitations in the current DNS scheme= is that it is only possible to query for one DNS record at a time or the A= NY pseudo record which returns everything (and likely forces a TCP switchov= er).

The requests actual applications want to make are thing= s like the following:

[example.com ? A, AAAA] [_http._t= cp.example.com ? SRV, URI, URI2]

Use of extended DNS features would be much easier if a = client could tell the resolver to send back data for multiple queries at on= ce.


Moving to a pure UDP protocol a= llows requests and responses to be longer than 500 bytes. It is also possib= le for a single request packet to return multiple responses. These mean tha= t it is very unlikely that fallback to TCP is ever going to be necessary fo= r client queries where low latency is essential. It is however possible tha= t a complex DNSSEC interaction might require a large amount of response dat= a.
=A0
--
Website: htt= p://hallambaker.com/
--047d7b343ef2fb895a04e7604aa1-- From hallam@gmail.com Fri Sep 27 10:05:03 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745F411E8162 for ; Fri, 27 Sep 2013 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bXaTMWBoSVC for ; Fri, 27 Sep 2013 10:05:01 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A7E4721F93F3 for ; Fri, 27 Sep 2013 10:04:59 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ep20so2437907lab.29 for ; Fri, 27 Sep 2013 10:04:57 -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; bh=fCXNVr2D6B3yu1aAuiExj0JU1pcjQTA8WcvSxLyoRUA=; b=SSQ5SWWFBo0yS7Yz78GEvglC9zWceqX1F+WZTOtN7ysXgWaiSyb6iwClSTkhY3fYW/ LIonqRhmUP+Z9QYJb1739/OfTMWu0R9RNhXsVK578l8LZeM9KOXePIuIRoHvN/0/xfzr feCmN2r1ex6tdYfiH02270c9A6MLAUBUy2Kdk7bQTO7p7WxnB2dXSxlvh0g7nFA0edUi wnF4NV3awEbr1nVbosvXvfQHO5OCtcw7OJmFfQFbS7aCAH6tA9j1JdZct5Bjd44JSYIp g1SAck6QrH64wy2mZZajkxi9MAJdQ3Roy2JW3TisdPOyd1di4EV9pshub28H/CcZSFfD xiFw== MIME-Version: 1.0 X-Received: by 10.112.155.39 with SMTP id vt7mr9288095lbb.29.1380301497137; Fri, 27 Sep 2013 10:04:57 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 27 Sep 2013 10:04:57 -0700 (PDT) In-Reply-To: <524340AA.2070400@cs.tcd.ie> References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <1380136736.93860.YahooMailNeo@web125503.mail.ne1.yahoo.com> <524340AA.2070400@cs.tcd.ie> Date: Fri, 27 Sep 2013 13:04:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0112c1366b808a04e7607cc5 Cc: perpass , Paul Wouters Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 17:05:03 -0000 --089e0112c1366b808a04e7607cc5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 25, 2013 at 3:59 PM, Stephen Farrell wrote: > > Hi Paul, > > On 09/25/2013 08:34 PM, Paul Wouters wrote: > > > > What we don't need though is another dns-like protocol to do so. (and > > definitely not dnscurve, as it does not support dns data authenticity, > > only transport security) > > You might be right about dnscurve, or maybe not. I dunno > enough about it yet to be to be honest. But, as you know, > DNSSEC is where the IETF has placed its bet for DNS data > origin auth. +1 I really can't see how DNSCurve would have been practical if it had a clear field. But now that we have bet on DNSSEC for authenticating the data within a DNS zone, that is a fixed choice. We can change some of the offensive parts of the DNSSEC architecture like the fact that it grants ICANN entire control over who is in the DNS and who is not. There is no reason that ICANN should have the ability to drop Cuba or Iran out of the root when Ted Cruz is threatening to filibuster the deficit ceiling limit rise if the President won't sign a bill forcing the US corporation to do that. > Changing that would maybe require a seismic > shift, so for this discussion I was assuming DNSSEC is the > answer for data origin auth and just asking if it'd be > useful to add confidentiality. So, the fact that dnscurve > doesn't do what DNSSEC does isn't really a compelling > argument here I think. > What we want from a design point of view is a secure mechanism for securing the channel based on a long term session key. One option for that would be DTLS. But since all we are doing is signing and encrypting packets under a long term session key we can achieve the desired end with a much simpler Kerberos-like scheme. DTLS is actually a poor choice here because TLS is designed on the assumption that the DNS layer stuff has already taken place. It uses certificate chains and PKIX infrastructure that layers over TCP/IP and DNS. > Cheers, > S. > > PS: Yes, we should all be doing stuff to encourage more > deployment of DNSSEC, but I think that's a separate > discussion, for other lists probably, even though DNSSEC > deployment might make it harder to mount some attacks > that are used in monitoring. A replacement for the client-resolver protocol is one of the steps I think would best help deployment of DNSSEC. That is where much of the difficulty in making schemes like DANE practical lies. -- Website: http://hallambaker.com/ --089e0112c1366b808a04e7607cc5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 25, 2013 at 3:59 PM, Stephen Farrell = <stephen.= farrell@cs.tcd.ie> wrote:

Hi Paul,

On 09/25/2013 08:34 PM, Paul Wouters wrote:
>
> What we don't need though is another dns-like protocol to do so. (= and
> definitely not dnscurve, as it does not support dns data authenticity,=
> only transport security)

You might be right about dnscurve, or maybe not. I dunno
enough about it yet to be to be honest. But, as you know,
DNSSEC is where the IETF has placed its bet for DNS data
origin auth.

+1=A0

I really can't see how DNSCurve would have been practical if it had a= clear field. But now that we have bet on DNSSEC for authenticating the dat= a within a DNS zone, that is a fixed choice.

We can change some of the offensive parts of the DNSSEC= architecture like the fact that it grants ICANN entire control over who is= in the DNS and who is not. There is no reason that ICANN should have the a= bility to drop Cuba or Iran out of the root when Ted Cruz is threatening to= filibuster the deficit ceiling limit rise if the President won't sign = a bill forcing the US corporation to do that.

=A0
Changing that w= ould maybe require a seismic
shift, so for this discussion I was assuming DNSSEC is the
answer for data origin auth and just asking if it'd be
useful to add confidentiality. So, the fact that dnscurve
doesn't do what DNSSEC does isn't really a compelling
argument here I think.

What we want fro= m a design point of view is a secure mechanism for securing the channel bas= ed on a long term session key. One option for that would be DTLS. But since= all we are doing is signing and encrypting packets under a long term sessi= on key we can achieve the desired end with a much simpler Kerberos-like sch= eme.

DTLS is actually a poor choice here because TLS is desi= gned on the assumption that the DNS layer stuff has already taken place. It= uses certificate chains and PKIX infrastructure that layers over TCP/IP an= d DNS.=A0

=A0
Cheers,
S.

PS: Yes, we should all be doing stuff to encourage more
deployment of DNSSEC, but I think that's a separate
discussion, for other lists probably, even though DNSSEC
deployment might make it harder to mount some attacks
that are used in monitoring.

A replacement = for the client-resolver protocol is one of the steps I think would best hel= p deployment of DNSSEC. That is where much of the difficulty in making sche= mes like DANE practical lies.


--
Website: http://hallambaker.com/
--089e0112c1366b808a04e7607cc5-- From ietf@rozanak.com Fri Sep 27 10:19:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F3721F9425 for ; Fri, 27 Sep 2013 10:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd9800goNeH9 for ; Fri, 27 Sep 2013 10:19:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 43FE021F9CDF for ; Fri, 27 Sep 2013 10:19:25 -0700 (PDT) Received: from kopoli (g225191041.adsl.alicedsl.de [92.225.191.41]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LtqTF-1VoWc23g1N-011Xor; Fri, 27 Sep 2013 13:19:21 -0400 From: "Hosnieh Rafiee" To: "'Karl Malbrain'" References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> In-Reply-To: <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> Date: Fri, 27 Sep 2013 19:19:10 +0200 Message-ID: <003901cebba5$b2762c10$17628430$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOGj5UkWbfuDhxpmMKtaAoIXGv7QHKq7oDAZ0lsZ0CNxrNyAK3hHhTAo3vF0yYgzAmEA== Content-Language: en-us X-Provags-ID: V02:K0:GCVtQAI6ctfCFu0zJFO16Y0KsWCYTbUqUaBlN+Mv0s0 /Li6t4+itdfapuKmu0B+ItNk3tJQnNotaTuuVifZRXXTMmO8OT FKhW54xITf1d4hQAmVebcgtuqxH9VcIqTcD2AGdWOP/+LGQur2 NiO+Oax6JKgYXSDQprgzszU/mRu8Y7E5GxljAb6TIAy+lIuSt3 p8x9PUlnCBo3xbInF1DtrBawc98+sV3OxwuAZidfSQ8CKl24nY SqA0ILHJdA6zsQo7jQPDF2DVeJwIQB7oYJ5IGSPxVsYDvlldgh knH+OfPp99GyV9DRFn0VF+yQ5h2eEM3Tx1F2ScwldKySkZRPCy sIj5RSFncs75p3Qg7cKg= Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 17:19:44 -0000 >CGA-TSIG seems to be a trust on first use protocol for subsequently Updating records within the DNS. It doesn't seem to address the problem of an arbitrary client securely obtaining the IP/Public Key for >an arbitrary host from DNS without the possibility of MITM. Perhaps you could explain further. The client doesn't need to retrieve their public key from anywhere. They generate it themselves. This is the actual case with CGA-TSIG. So how does it work you ask? It is dependent on the scenarioes. For the resolver scenario: The client knows the IP address of the resolver because it was obtained from a DHCP server or a RA message. When, for the first time, the client wants to resolve its query and the resolver answers, the client finds the binding between the IP address and the public key, which is generated by the DNS server itself. This is actually a capability of CGA (RFC 3972) or SSAS (http://tools.ietf.org/html/draft-rafiee-6man-ssas ), which also provides for the proof of address ownership. So, the client stores the public key of the resolver in its cache. It will subsequently not accept any messages from attackers. Why? Because the attacker doesn't have the private key of the node that he needs in order to spoof the message and since the public key that is involved in the address generation using both algorithms, then it is not possible for the attacker to spoof this IP address and make use the public key of the resolver. In the zone transfer scenario, both DNS servers know the IP address of each other as a result of the first time manual configuration. So, nobody can spoof this IP address and play a man in the middle attack. As all the message is signed by both parties, the attacker cannot spoof the message nor can he claim to be any of those nodes. FQDN and PTR updates are only vulnerable to spoofing attacks the first time an update is run because no association between the FQDN and the IP address has been established. When any clients in the network want to update these records, the DNS server will receive any message from the clients and, after a successful verification, will then add the public key of this client thus creating the association. Then the DNS server stores the public key, which is now associated with the client's hostname, in a new database table which will be maintained for a certain period of time. In this scenario, the only attack possible for the first time update where the attacker claim to have a hostname that was chosen by the client. When it is important for a client to have certain hostname, then the first time manual configuration will solve this problem. If any nodes want to change their IP addresses, do we need to initiate another manual configuration? No, because the node signs the timestamp with the old private key associated with old public key and also signs the message with its own new private key. So if the attacker wants to claim to be this node, since it doesn't have the old private key and the new private key for this node, it cannot sign the message and the signature verification process will fail. If you want to avoid this manual configuration, which is ONLY for the first time of processing, then you need to use trusted third parties. It can work in the same way as the SSL works in retrieving the public key of the DNS as is explained in CGA-TSIG draft. So, CGA-TSIG provides the node with data integrity but as it doesn't encrypt the message and only signs it, it cannot provide data confidentiality. But this doesn't mean that it cannot protect the node against MITM attacks as I explained in a different scenario. More details can be found in the draft. I'm actually in the process of improving the draft by making it more readable by shortening the abstract. We also have a paper which discusses the possibility of encrypting the message using the DNS server public key. Please refer to this paper (http://www.hpi.uni-potsdam.de/fileadmin/hpi/FG_ITS/papers/Trust_and_Securit y_Engineering/2013_Rafiee_NCA.pdf ). This is more applicable to the DNS update (zone transfer, FQDN) scenario. This means that the client first asks for the public key of the DNS server. When using the CGA/ SSAS algorithm, a binding is found between the public key and the IP address of the DNS server. The client then generates a shared secret, encrypts it using the public key of the DNS server, and generates the update message, encrypts it using this shared secret (symmetric encryption - algorithm like AES), and submits it to the DNS server. Since the attacker doesn't know the content of message, it cannot play a role of MITM when using the FQDN scenario for the first time. This approach provides both confidentiality and integrity. But it requires a change to the DNS protocol. Because, instead of the plain update section, prerequisite section, etc. the DNS server receives the encrypted message and needs to use its own private key to decrypt the shared secret and then decrypt the whole update message. If anybody thinks this is useful, I will include it in the content of our paper as a new draft. Hosnieh From malbrain@yahoo.com Fri Sep 27 11:41:33 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD8021F9F77 for ; Fri, 27 Sep 2013 11:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgCVsb+3l5gB for ; Fri, 27 Sep 2013 11:41:28 -0700 (PDT) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) by ietfa.amsl.com (Postfix) with ESMTP id D6DDF21F9433 for ; Fri, 27 Sep 2013 11:41:27 -0700 (PDT) Received: from [98.139.212.147] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 27 Sep 2013 18:41:26 -0000 Received: from [98.139.212.202] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 27 Sep 2013 18:41:26 -0000 Received: from [127.0.0.1] by omp1011.mail.bf1.yahoo.com with NNFMP; 27 Sep 2013 18:41:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 401830.85242.bm@omp1011.mail.bf1.yahoo.com Received: (qmail 92316 invoked by uid 60001); 27 Sep 2013 18:41:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380307286; bh=VFuqBC2smMF+oCy16xFIGA5nhzYhvSlBEnu6Qva8sJ4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dUwItkAHcqWk3Bmh7CI5K4V4B3Cbp+hsLcXirbpDA+YXQaEYDJ2MQCNGzkFkyUm7Z1Vs8f/iTOvqZX1GRyGZ0sCYHWalOxxHHLV2JhDhvjI2cnCCK4buNMfva1rzETIWE1tviVh1egGW+TUXsA+aPnDR2zfgit2XcmFEfuRyi9Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qGQfGTeZ8OoV0QallrcRjcK4uWn9H64bN0MaJ8H1R8F1ZinNgq9sfR4NpGWNI8jxNGLYw+jdn+koVqKjBHEzNHmg+OgeTQkXvCU3c+kn6e0YnchdiU0hl76aaGD63knh/hjpp6LjBBsUgBOhSIj4uV0G9gusYgRBjtgAkchF/vw=; X-YMail-OSG: NJQcfqkVM1nzYDLtwpkiLKIV4sslPVW5jPUexLef_y4sU7u .VfvD3qU6CaRFl9AQ7YBiryHO6dBCztRfc3xquWC1_6uyWkrBXJ5qCZAVTO4 0PVIrZmVZAHf5L73Yn84b7MfPAuCPpeNG8VKo0XJwHd.kdCdOnR5Cd.G36qb qJVLNWb8Yiru9.8kqYt9piJ95Wm61swr.G9E4Gxb3Tlzrc8f5zlC3R_yzChD MJxKL.iRRmTE6PnfNqsXFd7libjtjuZxD6WmWZL7Q3BE3YdNiXWjEBSCBBTS wSHagvu3QEvJSXpsqvc81HKtkxWZ.8tcbFhWo5k51l3M00WA9ZM0CVK_UUef 90ikWYiSPszZdWT_OcPdXogy.cI64RwBjMdHtuMQNjOBwz_7VVtuYWcjwL9T s18E8wHpvulVh4OUaPCm2hONaoa34LFypyqbdvzHZy48WJLh.YuD8WZ5Du82 WljuacQy9waG9reqLGwmqfoH2n9iViOxhWP37mO1fKwY668BJH47FFXPSTL1 Dd2onR.OsWbyfY4Hv2MSCRb5h3aU2pGhbYjOGcpJC2Yw6rURzhnsu6gDTd3b e8cxv0PfM.2RttqvGfKnfuGlBjC__q2_xUJN8CaZ.QEBirOkmoje6RH_AUr5 Ximl2ds7cR6VQWiKyeFnbMcn5vOLLWVxzDBkBc5GgUjIUg7B9lVRCsj1hMBD MhVDspkCbUCZ7X8hExPdAXcldYsosoD3u7gMjwJIipvDMhlZ2pyUHBwb0diQ NjgV48w2u35znbSVpWXam0n5SpaY3khUG70s35OfuquK0_Ml6hM4x4nwkwI4 ZNjG4GOcSwZTxLHRYT1cKmtkyqgnmFzmOgJumSODgoiw0FcHWUcJ2B4c- Received: from [50.201.233.2] by web125501.mail.ne1.yahoo.com via HTTP; Fri, 27 Sep 2013 11:41:25 PDT X-Rocket-MIMEInfo: 002.001, SSdtIGNvbmNlcm5lZCBhYm91dCB0aHJlZSBETlMgc2VjdXJpdHkgcHJvYmxlbXM6CsKgCjEuwqAgUGFzc2l2ZSBzdXJ2ZWlsbGVuY2Ugb2YgdHJhZmZpYyBnb2luZyB0byBETlMgcmVzb2x2ZXJzIHlpZWxkaW5nIG1ldGEtZGF0YS4KwqAKMi7CoCBNSVRNIHdob8KgaW5zZXJ0cyBoaW1zZWxmIGJldHdlZW4gYSBwYXJ0aWN1bGFyIEROUyBjbGllbnQgYW5kIGEgcGFydGljdWxhciBETlMgcmVzb2x2ZXIsIGFuZCBwcm92aWRzIGZhbHNlIGFkZHJlc3NlcyBhbmQgY2VydGlmaWNhdGVzIGZvciB1c2UgaW4gTUlUTSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> Message-ID: <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> Date: Fri, 27 Sep 2013 11:41:25 -0700 (PDT) From: Karl Malbrain To: Hosnieh Rafiee In-Reply-To: <003901cebba5$b2762c10$17628430$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="329289550-507551488-1380307285=:91976" Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 18:41:33 -0000 --329289550-507551488-1380307285=:91976 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm concerned about three DNS security problems:=0A=A0=0A1.=A0 Passive surv= eillence of traffic going to DNS resolvers yielding meta-data.=0A=A0=0A2.= =A0 MITM who=A0inserts himself between a particular DNS client and a partic= ular DNS resolver, and provids false addresses and certificates for use in = MITM attacks.=0A=A0=0A3.=A0A larger adversary who=A0installs=A0his own=A0DN= S resolver=A0for a given geographic area by=A0controlling the traffic at th= e router level into and out of that area to redirect DNS traffic to his DNS= resolver, and then inserts MITM attacks on any connection=A0out of the are= a=A0he desires by supplying bogus addresses and/or server certificates.=0A= =A0=0AI'm not concerned=A0at this time about an even larger adversary capab= le of surveillence of all traffic in a given geographic area, yielding a co= mplete set of meta-data.=A0=0A=0A>The client doesn't need to retrieve their= public key from anywhere.=A0 They=0A>generate it themselves. This is the = actual case with CGA-TSIG. So how does=0A>it work you ask? It is dependent = on the scenarioes. =0A=A0=0AThe client is trying to retrieve the IP address= and public key for an arbitrary server from the DNS resolver.=A0 This is s= ubject to MITM attack.=0A=A0=0A>For the resolver scenario:=0A>The client kn= ows the IP address of the resolver because it was obtained from=0A>a DHCP s= erver or a RA message. When, for the first time, the client wants to=0A>res= olve its query and the resolver answers, the client finds the binding=0A>be= tween the IP address and the public key, which is generated by the DNS=0A>s= erver itself.=0A=A0=0AHow does this prevent MITM from inserting himself bet= ween the client and the resolver on the first connection to the resolver?= =0A=A0=0A>=A0This is actually a capability of CGA (RFC 3972) or SSAS=0A>(ht= tp://tools.ietf.org/html/draft-rafiee-6man-ssas ),=A0 which also provides= =0A>for the proof of address ownership. So, the client stores the public ke= y of=0A>the resolver in its cache. It will subsequently not accept any mess= ages from=0A>attackers.=0A=A0=0AWhat if the public key being stored belongs= to MITM and not the resolver? All=A0client=A0traffic=A0is going to MITM.= =0A=A0=0A>=A0Why?=0A>Because the attacker doesn't have the private key of t= he node=A0 that he needs=0A>in order to spoof the message and since the pub= lic key that is involved in=0A>the address generation using both algorithms= , then it is not possible for=0A>the attacker to spoof this IP address and = make use the public key of the=0A>resolver. =0A=A0=0AMITM provided his publ= ic key in the first connection from the client.=0A=0A>We also have a paper = which discusses the possibility of encrypting the=0A>message using the DNS = server public key. Please refer to this paper=0A>(http://www.hpi.uni-potsda= m.de/fileadmin/hpi/FG_ITS/papers/Trust_and_Security_Engineering/2013_Rafiee= _NCA.pdf=A0 ).=0A>=A0This is more applicable to the DNS=0A>update (zone tra= nsfer, FQDN) scenario. This means that the client first asks=0A>for the pub= lic key of the DNS server. When using the CGA/ SSAS algorithm, a=0A>binding= is found between the public key and the IP address of the DNS=0A>server. T= he client then generates a shared secret, encrypts it using the=0A>public k= ey of the DNS server, and generates the update message, encrypts it=0A>usin= g this shared secret (symmetric encryption - algorithm like AES), and=0A>su= bmits it to the DNS server. Since the attacker doesn't know the content of= =0A>message, it cannot play a role of MITM when using the FQDN scenario for= the=0A>first time.=0A=A0=0AWhom does the client "ask for the public key of= the DNS server" from?=A0 This is the step that is subject to MITM attack.= =0A=A0Karl Malbrain=A0=A0 --329289550-507551488-1380307285=:91976 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm concer= ned about three DNS security problems:
 =
1.  Passive surveillence of traffic going to DNS reso= lvers yielding meta-data.
 
2.  MITM who inserts himself between a particular DNS client = and a particular DNS resolver, and provids false addresses and certificates= for use in MITM attacks.
 
3.=  A larger adversary who installs his own DNS resolver&n= bsp;for a given geographic area by controlling the traffic at the rout= er level into and out of that area to redirect DNS traffic to his DNS resol= ver, and then inserts MITM attacks on any connection out of the area&n= bsp;he desires by supplying bogus addresses and/or server certificates.
 
I'm not concerned at this ti= me about an even larger adversary capable of surveillence of all traffic in= a given geographic area, yielding a complete set of meta-data. 
>The client doesn't need to retrieve their public key from anywhere.&n= bsp; They
>generate it themselves. This is the actual case with CGA-= TSIG. So how does
>it work you ask? It is dependent on the scenarioes= .
 
The client is trying to retrieve the IP addre= ss and public key for an arbitrary server from the DNS resolver.  This= is subject to MITM attack.
 
>For the resolver= scenario:
>The client knows the IP address of the resolver because i= t was obtained from
>a DHCP server or a RA message. When, for the fir= st time, the client wants to
>resolve its query and the resolver answ= ers, the client finds the binding
>between the IP address and the public key, which is generated by the DNS
>server itself.
<= div> 
How does this prevent MITM from inserting himself betw= een the client and the resolver on the first connection to the resolver?
 
> This is actually a capability of CGA (RF= C 3972) or SSAS
>(http://tools.ietf.org/html/draft-rafiee-6man-s= sas ),  which also provides
>for the proof of address owners= hip. So, the client stores the public key of
>the resolver in its cac= he. It will subsequently not accept any messages from
>attackers.
 
What if the public key being stored belongs to MITM= and not the resolver? All client traffic is going to MITM.<= /div>
 
> Why?
>Because the attacker doesn= 't have the private key of the node  that he needs
>in order to spoof the message and since the public key that is involved in
>t= he address generation using both algorithms, then it is not possible for>the attacker to spoof this IP address and make use the public key of t= he
>resolver.
 
MITM provided his public ke= y in the first connection from the client.

>We also have a= paper which discusses the possibility of encrypting the
>message usi= ng the DNS server public key. Please refer to this paper
>(http://www.hpi.uni-po= tsdam.de/fileadmin/hpi/FG_ITS/papers/Trust_and_Security_Engineering/2013_Ra= fiee_NCA.pdf  ).
> This is more applicable to th= e DNS
>update (zone transfer, FQDN) scenario. This means that the cli= ent first asks
>for the public key of the DNS server. When using the CGA/ SSAS algorithm, a
>binding is found between the public key = and the IP address of the DNS
>server. The client then generates a sh= ared secret, encrypts it using the
>public key of the DNS server, and= generates the update message, encrypts it
>using this shared secret = (symmetric encryption - algorithm like AES), and
>submits it to the D= NS server. Since the attacker doesn't know the content of
>message, i= t cannot play a role of MITM when using the FQDN scenario for the
>fi= rst time.
 
Whom does the client "ask for the publ= ic key of the DNS server" from?  This is the step that is subject to MITM attack.
 
Karl Malb= rain  
--329289550-507551488-1380307285=:91976-- From hallam@gmail.com Fri Sep 27 11:55:32 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FD021F9E5E for ; Fri, 27 Sep 2013 11:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1cO1t+WXb9L for ; Fri, 27 Sep 2013 11:55:30 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 763DE21F9994 for ; Fri, 27 Sep 2013 11:55:23 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id z5so2533364lbh.23 for ; Fri, 27 Sep 2013 11:55:21 -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; bh=giuXDz3ezPpC3sm+ESibgCkhZ5LCdPXIBhfkP4y8LIQ=; b=nweXR7mZrBHSTb6FCpuJ2KdnQ/i+r2GMPeQrM8ht+E8jcneK8os/vDUOHCdAudld0W vHOon2Q+k6SpBIhg+I2WhrXzk+MYMC28JK9eMRWi+DneMmhfKXgweIJg9J6mjegDR75G /Pf0teFh4sbFrAHXE/oLgLr/MLv+3iiaq6lZgMKwmwuZ7Np1IiftDxEl22LzLoXikm6y 0c1ZczwbeA6XtYvsMgiNzomsPuS4gbvUpq942n5O4mCM4yHLruJJlorgYvYyShWkPmes PG0bsvIRWRRPuwqXAFC95WLiXcqOVoAODOlOBh31oEiek6Z7kim/0881Np9mjKJbTgOY GGaA== MIME-Version: 1.0 X-Received: by 10.152.23.5 with SMTP id i5mr6701374laf.8.1380308121212; Fri, 27 Sep 2013 11:55:21 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 27 Sep 2013 11:55:21 -0700 (PDT) In-Reply-To: <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> Date: Fri, 27 Sep 2013 14:55:21 -0400 Message-ID: From: Phillip Hallam-Baker To: Karl Malbrain Content-Type: multipart/alternative; boundary=089e0160bb9a3edd9504e7620741 Cc: perpass , Hosnieh Rafiee , Stephen Farrell Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 18:55:32 -0000 --089e0160bb9a3edd9504e7620741 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 27, 2013 at 2:41 PM, Karl Malbrain wrote: > I'm concerned about three DNS security problems: > > 1. Passive surveillence of traffic going to DNS resolvers yielding > meta-data. > Use your own resolver and/or encrypt traffic to the resolver. e.g. Omnibroker. > 2. MITM who inserts himself between a particular DNS client and a > particular DNS resolver, and provids false addresses and certificates for > use in MITM attacks. > Authenticate messages between the client and resolver. e.g. Omnibroker. > 3. A larger adversary who installs his own DNS resolver for a given > geographic area by controlling the traffic at the router level into and out > of that area to redirect DNS traffic to his DNS resolver, and then inserts > MITM attacks on any connection out of the area he desires by supplying > bogus addresses and/or server certificates. > Tunnel your communication traffic to your chosen resolver via available channels, e.g. HTTP or UDP or DNS tunnel e.g. Omnibroker. > I'm not concerned at this time about an even larger adversary capable of > surveillence of all traffic in a given geographic area, yielding a complete > set of meta-data. > That is a harder problem but one that I suspect is not such a great deal due to caching. The NSA is only occasionally going to be able to match one of my requests to outbound traffic. A resolver could even obfusticate those. For example in the case of a cache miss make 20 DNS queries rather than one. -- Website: http://hallambaker.com/ --089e0160bb9a3edd9504e7620741 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Sep 27, 2013 at 2:41 PM, Karl Malbrain &l= t;malbrain@yahoo.co= m> wrote:
I'm concerned about = three DNS security problems:
=A0
1.=A0 Passive surveillence of traffic= going to DNS resolvers yielding meta-data.

Use your own resolver and/or encrypt traffic to t= he resolver.=A0

e.g. Omnibroker.
=A0
2.=A0 MITM who=A0inserts himself between a particular= DNS client and a particular DNS resolver, and provids false addresses and = certificates for use in MITM attacks.

Authenticate messages between the client and resolver.<= /div>

e.g. Omnibroker.
=A0
3.=A0A larger adversary who=A0installs=A0his own=A0DNS resolv= er=A0for a given geographic area by=A0controlling the traffic at the router= level into and out of that area to redirect DNS traffic to his DNS resolve= r, and then inserts MITM attacks on any connection=A0out of the area=A0he d= esires by supplying bogus addresses and/or server certificates.

Tunnel you= r communication traffic to your chosen resolver via available channels, e.g= . HTTP or UDP or DNS tunnel

e.g. Omnibroker.
=A0
I'm not conc= erned=A0at this time about an even larger adversary capable of surveillence= of all traffic in a given geographic area, yielding a complete set of meta= -data.=A0

That is a harder problem but o= ne that I suspect is not such a great deal due to caching. The NSA is only = occasionally going to be able to match one of my requests to outbound traff= ic. A resolver could even obfusticate those. For example in the case of a c= ache miss make 20 DNS queries rather than one.


--
Website: http://hallambaker.com/
--089e0160bb9a3edd9504e7620741-- From ietf@rozanak.com Fri Sep 27 12:22:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C489E21F9F99 for ; Fri, 27 Sep 2013 12:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgZ6kt5GmlGI for ; Fri, 27 Sep 2013 12:22:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 49D4A21F9F86 for ; Fri, 27 Sep 2013 12:22:10 -0700 (PDT) Received: from kopoli (g225191041.adsl.alicedsl.de [92.225.191.41]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LnQ7a-1W4ivF3Jl8-00hupW; Fri, 27 Sep 2013 15:22:00 -0400 From: "Hosnieh Rafiee" To: "'Karl Malbrain'" References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> In-Reply-To: <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> Date: Fri, 27 Sep 2013 21:21:50 +0200 Message-ID: <001b01cebbb6$d5565550$8002fff0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOGj5UkWbfuDhxpmMKtaAoIXGv7QHKq7oDAZ0lsZ0CNxrNyAK3hHhTAo3vF0wCd4OykQJLJu5nmF319iA= Content-Language: en-us X-Provags-ID: V02:K0:HB6wNrk2Ey3COTr6PZ8eZ40T09vkzhJhzPf9YjXl1GD n8Q0VcpNL/a5600i4O5rHso+J3XhDjsZwyNJvMIEDTDrrl4n9R f+grHCK05reDc4rPCnK2nwvsPOhpXIvhX5JCSMUrdkNYi++qvz oOOtcqj3XIIBdDarZ6fzpvvLkkTQF92UqBKQmobx7XmrR41jmV pGnDnjPVQgpseyjbLbe6qS5s5tCOJ1Uv1saQqsviAPAGGDvNFT 0He2bhVjOPFDUK8l7SSAPv8coYEgxP9nNdMyPqChXK/PkIH2ZS P3CRvzFdgN0EWAG5/KdapQkSUskR5qRyHSkM+Y9JtLbopArQVi Ax5f6KVVvCwWDTdbKYJ4= Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 19:22:25 -0000 =A0 >1.=A0 Passive surveillence of traffic going to DNS resolvers yielding meta-data. Again not possible, at least not in IPv6 if your resolvers and recursive resolvers are using cga-tsig. The signature and the CGA/SSAS algorithm prevent it. =A0 >2.=A0 MITM who=A0inserts himself between a particular DNS client and a particular DNS resolver, and provids false addresses and certificates = for use in MITM attacks. Again this is not possible if you are using cga-tsig. =A0 > 3.=A0A larger adversary who=A0installs=A0his own=A0DNS resolver=A0for = a given geographic area by=A0controlling the traffic at the router level into = and out of that area to redirect DNS traffic to his DNS resolver, and then = inserts MITM attacks on any connection=A0out of the area=A0he desires by = supplying bogus addresses and/or server certificates. If you are using SeND with SSAS or centralized RPKI you can retrieve and verify your router in a local link. RA can include the (http://tools.ietf.org/html/rfc6106) DNS server options. This means that = you receive a signed message from a router that was previously authorized = via the centralized local RPK1. I am not sure whether or not DHCPv6 also includes security approaches that can be used for authentication. I = believe that there was a draft about secure authentication using CGA in DHCPv6 = as well. You can also us a scenario, like SSL, to verify your router certificate where the client has already configured the list of CAs. =A0=A0 >The client is trying to retrieve the IP address and public key for an arbitrary server from the DNS resolver.=A0 This is subject to MITM = attack. I guess that you did not quite understand the reasoning behind CGA and = that is why you are asking a question about an issue that I have already explained. Your client retrieves this IP address from the RA message = that is generated by the use of SeND with the DNS RA option (. Since this RA = message is already signed and we assume that this client has already verified = this router (centralized local RPKI that is explained in SSAS or other RPKI approaches) the attacker has no way of spoofing this message as it = cannot spoof the content (due to the signature) and it cannot spoof the public = key due to the binding between the public key and the source IP address >How does this prevent MITM from inserting himself between the client = and the resolver on the first connection to the resolver? Your node already knows the IP address of your resolver. =A0 >=A0This is actually a capability of CGA (RFC 3972) or SSAS >(http://tools.ietf.org/html/draft-rafiee-6man-ssas ),=A0 which also = provides >for the proof of address ownership. So, the client stores the public = key of >the resolver in its cache. It will subsequently not accept any messages from >attackers. =A0 > What if the public key being stored belongs to MITM and not the = resolver? All=A0client=A0traffic=A0is going to MITM. As I explained, you retrieve the IP address of your DNS server using a = safe means after having authorized your router in the local link. Now if your MITM node is somewhere in the other network and tries to intercept the connection between your node and the resolver, since you node already = knows the IP address of the resolver, it will reject the connection because = the CGA/SSAS verification process fails. =A0 >Whom does the client "ask for the public key of the DNS server" = from?=A0 This is the step that is subject to MITM attack. I guess I have already responded this. Hosnieh From ietf@rozanak.com Fri Sep 27 15:13:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2897621F8E51; Fri, 27 Sep 2013 15:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8vjCJ-lSXDH; Fri, 27 Sep 2013 15:13:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id F1A4E21F9808; Fri, 27 Sep 2013 15:13:19 -0700 (PDT) Received: from kopoli (g225191041.adsl.alicedsl.de [92.225.191.41]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MQzYs-1VHXqn3j3O-00U5Ui; Fri, 27 Sep 2013 18:13:18 -0400 From: "Hosnieh Rafiee" To: "perpass" , Date: Sat, 28 Sep 2013 00:13:10 +0200 Message-ID: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac66GAmkrg604EBOQj6E9T/FIDhOTg== Content-Language: en-us X-Provags-ID: V02:K0:qHdZjREDdYsBxNOj/2+4SNOj6BexqynEi7n9Cn6tbfT MYuQCJe6abQcytQphj0p7kpwJywBjB9AIRS2DQXNxZNEFDOESi rlWAZldg+mQn4fC+Ebif+WKUp9Zg4HH0PaIrShzOfBfm90PKuq WVb29YgKgcw/hOtOpAaRg0zBDSkQsKxwIwdBswV3iE8x5qfdLE VW8cN4rve8tgNGitmcjqACzhctR07BwocRhSnax9BPMRttm+rj Mc3r8iaqi8C95s8tppNfZEgoJrOAP34urGzBB0NMBPTMP4vdp8 3CGY6yKE5YyWhqdl+dpcw/Hmhd88o3Z4/bLGCAv0Vo/vX+00ZW nnD4IKh63iE96pJgwELk= Subject: [perpass] Reviewers needed - Secure DNS authentication X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:13:27 -0000 Hello, I am looking for reviewers to review the http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig draft. It deals with the use of CGA (RFC 3972) or SSAS for authentication purposes during various types of scenarios. This is truly possible when the authentication is based on the source IP address. Everything in this authentication is done "on the fly" and only once is there a need to configure the Servers. Advantages: - If the shared secret is compromised (which is true in TSIG, you won't need to repeat the process of re-sharing the shared secret among the many hosts that used the compromised shared secret) - If for any reason the IP address of any nodes involved in authentication is changed, then the other nodes will still be able to verify that it is the same node - It is both easier and preferable to use this approach to prove the address ownership while at the same time performing source IP address authentication. - The nodes don't need to go through the chain of trusts because the magic of CGA or SSAS works well. This means that if the other nodes are aware of one node's real IP address then that is all the information the other nodes need to identify this node. No matter how your node changes its IP address. This draft explains how to easily handle this situation, automatically, without the need for human intervention. I am sure you will find it interesting. The different scenarios that are considered are: - Authentication during FQDN - Authentication during zone transfer - Authentication of the resolvers in stub resolvers - Authentication of root DNS servers to recursive DNS servers We also considered the scenario where the server doesn't support CGA or SeND. The interesting thing about this draft is that you can use a CGA script generator that I will provide and make available to everybody. Then just manually set the IP address for the node that wants to use CGA-TSIG. The CGA-TSIG implementation will thereafter processes the handling for all the CGA parameters. This scenario is good for the future of the Internet where IPv6 is used. I guess many DNS servers now support IPv6 as well as IPv4. I am looking forward to receiving your comments. Thank you, Hosnieh P.S. So if you'll review mine i'll review yours.. Deal??? :-) From sm@resistor.net Fri Sep 27 15:44:05 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C27321F9A2D for ; Fri, 27 Sep 2013 15:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qfd1uwbozUNj for ; Fri, 27 Sep 2013 15:44:04 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0D121F9BC4 for ; Fri, 27 Sep 2013 15:44:03 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8RMhuM2009397; Fri, 27 Sep 2013 15:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380321841; bh=4G6mcqaWY6LeJGNASAjZ6jUVZNB6GqVmqY29z9jQ3vI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=L3z8Fg0WMpeehNPDBzGCg3u/cRCv2Om237UocQIh3A/6ia4HPFn0Rw+zIogqYOUGG 5iQRp5Hv7sxJGsArpMzD+p7Rd0k4HHDW2R16brcqqEo8pQ171AbWoqTdyd7+GS5BV2 OBtveJcbbEq+Kuj1npVxvY8KE+2ZrtoBaDCJFHrQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1380321841; i=@resistor.net; bh=4G6mcqaWY6LeJGNASAjZ6jUVZNB6GqVmqY29z9jQ3vI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HO9k2m07KrGUaiqFEISu0l7Ud7xqhMhGaj6wg/iENdferPBo7X3pn2WcLHvONJhKa IQT3uzZfJr4ELYa26mGKDxBYoMi9m1c4WhHzJsH3w9+U4PDSrKcsHp5+ezce0Ar8xE l9twBjHJJT+z14cwXYh/H4zUUA8BMVX8kJTkLL2s= Message-Id: <6.2.5.6.2.20130927153930.0c738518@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 27 Sep 2013 15:42:36 -0700 To: Hosnieh Rafiee From: SM In-Reply-To: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> References: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] Reviewers needed - Secure DNS authentication X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:44:05 -0000 Hi Hosnieh, At 15:13 27-09-2013, Hosnieh Rafiee wrote: >P.S. So if you'll review mine i'll review yours.. Deal??? :-) I like the spirit. :-) Regards, -sm From warren@kumari.net Fri Sep 27 18:03:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC95821F9A31; Fri, 27 Sep 2013 18:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YICY9RFkGsJ6; Fri, 27 Sep 2013 18:03:51 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC4621F90DC; Fri, 27 Sep 2013 18:03:50 -0700 (PDT) Received: from [10.243.40.142] (mobile-198-228-224-005.mycingular.net [198.228.224.5]) by vimes.kumari.net (Postfix) with ESMTPSA id EFA381B400DE; Fri, 27 Sep 2013 21:03:48 -0400 (EDT) References: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> In-Reply-To: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (11A465) From: Warren Kumari Date: Fri, 27 Sep 2013 21:03:46 -0400 To: Hosnieh Rafiee Cc: perpass , "" Subject: Re: [perpass] [dane] Reviewers needed - Secure DNS authentication X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 01:03:55 -0000 I'm sorry, but this is not related to DANE (nor was it last time you came sh= opping around). I (of course) have no problem with folk reviewing it, just making it clear t= hat it isn't a DANE thing... W Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboar= d. > On Sep 27, 2013, at 6:13 PM, "Hosnieh Rafiee" wrote: >=20 > Hello, >=20 > I am looking for reviewers to review the > http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig draft. It deals > with the use of CGA (RFC 3972) or SSAS for authentication purposes during > various types of scenarios. This is truly possible when the authentication= > is based on the source IP address. Everything in this authentication is do= ne > "on the fly" and only once is there a need to configure the Servers. > Advantages: > - If the shared secret is compromised (which is true in TSIG, you won't ne= ed > to repeat the process of re-sharing the shared secret among the many hosts= > that used the compromised shared secret) > - If for any reason the IP address of any nodes involved in authentication= > is changed, then the other nodes will still be able to verify that it is > the same node > - It is both easier and preferable to use this approach to prove the addre= ss > ownership while at the same time performing source IP address > authentication. > - The nodes don't need to go through the chain of trusts because the magi= c > of CGA or SSAS works well. This means that if the other nodes are aware of= > one node's real IP address then that is all the information the other node= s > need to identify this node. No matter how your node changes its IP addres= s. > This draft explains how to easily handle this situation, automatically, > without the need for human intervention.=20 > I am sure you will find it interesting.=20 >=20 > The different scenarios that are considered are: > - Authentication during FQDN > - Authentication during zone transfer > - Authentication of the resolvers in stub resolvers > - Authentication of root DNS servers to recursive DNS servers >=20 > We also considered the scenario where the server doesn't support CGA or > SeND. The interesting thing about this draft is that you can use a CGA > script generator that I will provide and make available to everybody. Then= > just manually set the IP address for the node that wants to use CGA-TSIG. > The CGA-TSIG implementation will thereafter processes the handling for al= l > the CGA parameters.=20 >=20 > This scenario is good for the future of the Internet where IPv6 is used. I= > guess many DNS servers now support IPv6 as well as IPv4.=20 >=20 > I am looking forward to receiving your comments.=20 >=20 > Thank you, > Hosnieh > P.S. So if you'll review mine i'll review yours.. Deal??? :-) >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From bmanning@isi.edu Sat Sep 28 03:02:46 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FECF11E812C for ; Sat, 28 Sep 2013 03:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbo4qkRmjcyb for ; Sat, 28 Sep 2013 03:02:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 315D911E812D for ; Sat, 28 Sep 2013 03:02:38 -0700 (PDT) Received: from [192.168.1.16] (host-74-211-92-12.beyondbb.com [74.211.92.12]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r8SA1rCQ008028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 28 Sep 2013 03:02:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: <001b01cebbb6$d5565550$8002fff0$@rozanak.com> Date: Sat, 28 Sep 2013 03:02:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> <001b01cebbb6$d5565550$8002fff0$@rozanak.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: 'perpass' , 'Karl Malbrain' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 10:02:46 -0000 you are conflating routing security/authentication with DNS service = opaque capabilities. there already exist a number of methods for securing the DNS channel, = [SIG(0), TSIG, DNSCurve=85] and we can add your technique to the list. =20 protecting the service is very different than protecting the channel. /bill On 27September2013Friday, at 12:21, Hosnieh Rafiee wrote: >=20 > =20 >> 1. Passive surveillence of traffic going to DNS resolvers yielding > meta-data. >=20 > Again not possible, at least not in IPv6 if your resolvers and = recursive > resolvers are using cga-tsig. The signature and the CGA/SSAS algorithm > prevent it. > =20 >> 2. MITM who inserts himself between a particular DNS client and a > particular DNS resolver, and provids false addresses and certificates = for > use in MITM attacks. >=20 > Again this is not possible if you are using cga-tsig. >=20 > =20 >> 3. A larger adversary who installs his own DNS resolver for a given > geographic area by controlling the traffic at the router level into = and out > of that area to redirect DNS traffic to his DNS resolver, and then = inserts > MITM attacks on any connection out of the area he desires by supplying = bogus > addresses and/or server certificates. >=20 > If you are using SeND with SSAS or centralized RPKI you can retrieve = and > verify your router in a local link. RA can include the > (http://tools.ietf.org/html/rfc6106) DNS server options. This means = that you > receive a signed message from a router that was previously authorized = via > the centralized local RPK1. I am not sure whether or not DHCPv6 also > includes security approaches that can be used for authentication. I = believe > that there was a draft about secure authentication using CGA in DHCPv6 = as > well. > You can also us a scenario, like SSL, to verify your router = certificate > where the client has already configured the list of CAs. >=20 > =20 >> The client is trying to retrieve the IP address and public key for an > arbitrary server from the DNS resolver. This is subject to MITM = attack. >=20 > I guess that you did not quite understand the reasoning behind CGA and = that > is why you are asking a question about an issue that I have already > explained. Your client retrieves this IP address from the RA message = that is > generated by the use of SeND with the DNS RA option (. Since this RA = message > is already signed and we assume that this client has already verified = this > router (centralized local RPKI that is explained in SSAS or other RPKI > approaches) the attacker has no way of spoofing this message as it = cannot > spoof the content (due to the signature) and it cannot spoof the = public key > due to the binding between the public key and the source IP address >=20 >=20 >> How does this prevent MITM from inserting himself between the client = and > the resolver on the first connection to the resolver? >=20 > Your node already knows the IP address of your resolver. > =20 >> This is actually a capability of CGA (RFC 3972) or SSAS >> (http://tools.ietf.org/html/draft-rafiee-6man-ssas ), which also = provides >> for the proof of address ownership. So, the client stores the public = key of >> the resolver in its cache. It will subsequently not accept any = messages > from >> attackers. > =20 >> What if the public key being stored belongs to MITM and not the = resolver? > All client traffic is going to MITM. >=20 > As I explained, you retrieve the IP address of your DNS server using a = safe > means after having authorized your router in the local link. Now if = your > MITM node is somewhere in the other network and tries to intercept the > connection between your node and the resolver, since you node already = knows > the IP address of the resolver, it will reject the connection because = the > CGA/SSAS verification process fails. > =20 >> Whom does the client "ask for the public key of the DNS server" from? = This > is the step that is subject to MITM attack. >=20 > I guess I have already responded this. >=20 >=20 > Hosnieh >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From ietf@rozanak.com Sat Sep 28 06:47:55 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C12821E80DD; Sat, 28 Sep 2013 06:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht71Z+efPJi7; Sat, 28 Sep 2013 06:47:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B83C221F9D42; Sat, 28 Sep 2013 06:47:46 -0700 (PDT) Received: from kopoli (g231251251.adsl.alicedsl.de [92.231.251.251]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mgbk7-1VBFjJ3I0d-00NzZw; Sat, 28 Sep 2013 09:47:44 -0400 From: "Hosnieh Rafiee" To: "'Warren Kumari'" References: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> In-Reply-To: Date: Sat, 28 Sep 2013 15:47:32 +0200 Message-ID: <000601cebc51$4caa5fd0$e5ff1f70$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHhNdW1NOP0zz8kGUAEoaOrvgBu5wHF0IV3mafKp4A= Content-Language: en-us X-Provags-ID: V02:K0:adzGBBerLOIAiMS2t+YSYP7Xyy5KDdl0EHylvRxh1/a O2czigbpA9xXm7cyEN5puJBOUtYr0n22iAz9m1x2dV7hZ5lQiG 1hfM0rrzpdLbieccJwFEl2zWhhf8r8SJ1aYSvLlADGPqnsFik7 YZqUlT4Jzfc+0rKDVfWDPnVU7hXnzzsccPX7IBWmdilfbzuz4o mEPEY9s+ixgw7g5V2cekZoGD3eXn/tw92UgbNOr/248trHYiGv hbO67Of6hj4a2BDWaR2pM/c8IXNE4RiNrgsYxVQFqJdClUZV+H OubqXbexVShxW61vSRYx8cMxJnNaxC2AYF+MeoPU8VnZW0zvOC O50Z+2+54vG35fuAqW+s= Cc: Andrew Sullivan , 'perpass' , dane@ietf.org Subject: Re: [perpass] [dane] Reviewers needed - Secure DNS authentication X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 13:47:55 -0000 > I (of course) have no problem with folk reviewing it, just making it clear that it > isn't a DANE thing... You're right it is individual submission which has a document shepherd. I asked Andrew to be a document shepherd for this work. But we are trying to hunt reviewers :-) . Some DNS experts have already reviewed this document and the document improved a lot since the first version. We are now looking for more reviewers (security expert, DNS expert, etc) for technical and organization comments. Any volunteer reviewers that give us more useful comments so that we can proceed with it. The reviewers can send their comments directly to I and Andrew or to the list. Thanks, Hosnieh From ietf@rozanak.com Sat Sep 28 07:11:51 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963F921E80DC for ; Sat, 28 Sep 2013 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC6Zmhmxv3A3 for ; Sat, 28 Sep 2013 07:11:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1545321E80DB for ; Sat, 28 Sep 2013 07:11:45 -0700 (PDT) Received: from kopoli (g231251251.adsl.alicedsl.de [92.231.251.251]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MDz31-1VdwHR3xIF-00HN4O; Sat, 28 Sep 2013 10:11:25 -0400 From: "Hosnieh Rafiee" To: "'manning bill'" References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> <001b01cebbb6$d5565550$8002fff0$@rozanak.com> In-Reply-To: Date: Sat, 28 Sep 2013 16:11:12 +0200 Message-ID: <000701cebc54$9bdbef80$d393ce80$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOGj5UkWbfuDhxpmMKtaAoIXGv7QHKq7oDAZ0lsZ0CNxrNyAK3hHhTAo3vF0wCd4OykQJLJu5nARfcMlYBQCaxophMOPjQ Content-Language: en-us X-Provags-ID: V02:K0:JHOUhVDUisIYDcxjj7VnO1GpLYmy1lJFBioLdJDhesm OPVt29F4adeapZurYXOp+Hc8S83vlnu7YB0jccuO1/BydRFyfy /WoGkRTFr80dZDKO4hLFFk4HLS2ZcMs1RdYzXuup32J5jVsL3q Jw+J6ERoc1bHkKnLFufiGmjNbtv53oW0W2WtUqBd+gJvhE8VUW iR+1Ts0TJkIwvhrbtfGY9S4UJhaZsBDH6aSk0btrDCSY6bQlMp T9KOgVv8qLw5pPzNx+MWLZwg66REVOHEa3udlCdf59gt8SCVIL XsioIcUwP5LoeFHvS7E8+xZPAfGLjZDfiOaI5t9r/QBnFkD0j3 kh0enPgkVPwUtNOYSt/4= Cc: 'perpass' , 'Karl Malbrain' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 14:11:51 -0000 I ask that you please put aside your preconceived ideas and read the cga-tsig document with an open mind before you judge it. The document addresses the problem with the use of TSIG and SIG and introduces a new, combined method which can protect nodes against several types of attack. Karl asked how the node receives the IP address of the DNS as it can be the first point of a MITM attack. I just explained that this is not possible, as earlier explained, the node can retrieve this IP address in a safe manner during a first time retrieval. This has nothing to do with CGA-TSIG as it assumes that the node already learned the IP address of the DNS server in a safe way. This document only explains a new method for secure authentication during different scenarios. Hosnieh > > you are conflating routing security/authentication with DNS service opaque > capabilities. > there already exist a number of methods for securing the DNS channel, [SIG(0), > TSIG, DNSCurve.] > and we can add your technique to the list. > > protecting the service is very different than protecting the channel. > > /bill > > > On 27September2013Friday, at 12:21, Hosnieh Rafiee wrote: > > > > > > >> 1. Passive surveillence of traffic going to DNS resolvers yielding > > meta-data. > > > > Again not possible, at least not in IPv6 if your resolvers and > > recursive resolvers are using cga-tsig. The signature and the CGA/SSAS > > algorithm prevent it. > > > >> 2. MITM who inserts himself between a particular DNS client and a > > particular DNS resolver, and provids false addresses and certificates > > for use in MITM attacks. > > > > Again this is not possible if you are using cga-tsig. > > > > > >> 3. A larger adversary who installs his own DNS resolver for a given > > geographic area by controlling the traffic at the router level into > > and out of that area to redirect DNS traffic to his DNS resolver, and > > then inserts MITM attacks on any connection out of the area he desires > > by supplying bogus addresses and/or server certificates. > > > > If you are using SeND with SSAS or centralized RPKI you can retrieve > > and verify your router in a local link. RA can include the > > (http://tools.ietf.org/html/rfc6106) DNS server options. This means > > that you receive a signed message from a router that was previously > > authorized via the centralized local RPK1. I am not sure whether or > > not DHCPv6 also includes security approaches that can be used for > > authentication. I believe that there was a draft about secure > > authentication using CGA in DHCPv6 as well. > > You can also us a scenario, like SSL, to verify your router > > certificate where the client has already configured the list of CAs. > > > > > >> The client is trying to retrieve the IP address and public key for an > > arbitrary server from the DNS resolver. This is subject to MITM attack. > > > > I guess that you did not quite understand the reasoning behind CGA and > > that is why you are asking a question about an issue that I have > > already explained. Your client retrieves this IP address from the RA > > message that is generated by the use of SeND with the DNS RA option (. > > Since this RA message is already signed and we assume that this client > > has already verified this router (centralized local RPKI that is > > explained in SSAS or other RPKI > > approaches) the attacker has no way of spoofing this message as it > > cannot spoof the content (due to the signature) and it cannot spoof > > the public key due to the binding between the public key and the > > source IP address > > > > > >> How does this prevent MITM from inserting himself between the client > >> and > > the resolver on the first connection to the resolver? > > > > Your node already knows the IP address of your resolver. > > > >> This is actually a capability of CGA (RFC 3972) or SSAS > >> (http://tools.ietf.org/html/draft-rafiee-6man-ssas ), which also > >> provides for the proof of address ownership. So, the client stores > >> the public key of the resolver in its cache. It will subsequently not > >> accept any messages > > from > >> attackers. > > > >> What if the public key being stored belongs to MITM and not the resolver? > > All client traffic is going to MITM. > > > > As I explained, you retrieve the IP address of your DNS server using a > > safe means after having authorized your router in the local link. Now > > if your MITM node is somewhere in the other network and tries to > > intercept the connection between your node and the resolver, since you > > node already knows the IP address of the resolver, it will reject the > > connection because the CGA/SSAS verification process fails. > > > >> Whom does the client "ask for the public key of the DNS server" from? > >> This > > is the step that is subject to MITM attack. > > > > I guess I have already responded this. > > > > > > Hosnieh > > > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass From malbrain@yahoo.com Sat Sep 28 08:28:01 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8D811E810B for ; Sat, 28 Sep 2013 08:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZi3dLo0yNjI for ; Sat, 28 Sep 2013 08:27:55 -0700 (PDT) Received: from nm39-vm3.bullet.mail.bf1.yahoo.com (nm39-vm3.bullet.mail.bf1.yahoo.com [72.30.239.147]) by ietfa.amsl.com (Postfix) with ESMTP id 629B321F8B35 for ; Sat, 28 Sep 2013 08:27:55 -0700 (PDT) Received: from [66.196.81.173] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2013 15:27:54 -0000 Received: from [98.139.212.234] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2013 15:27:54 -0000 Received: from [127.0.0.1] by omp1043.mail.bf1.yahoo.com with NNFMP; 28 Sep 2013 15:27:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 28015.7079.bm@omp1043.mail.bf1.yahoo.com Received: (qmail 13142 invoked by uid 60001); 28 Sep 2013 15:27:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380382073; bh=vatTKgLegYEljRywJrbUrJkvf5nnpqZam/kVS6C1oKQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fUHCbn6ljnCBx26iKrXUGflYvWsC91HQZNmDsuTFkKQb8Zk2LBRtheTkatJ+ljBX47vT93PUFu983aZeNy45D12VHaEfgdd6dKqig9nqFqsYpUxLkdYzf/AdVizY6lmyTncn0A7mN63LvlNDvRr86CemGzZIQ69B5bNQqRfIM7U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5qTZ7cYsMz9rgNfZhXl0aAua8TkRSjSuVy0+VVYyxlEoyOjUIUZFk27jDQgeAbDLZAvp4wjym5w2nl5pTqE2RP7qUbF9CHDVuFpwmo+JmL4iuDMQZsoapkWecLX/+X/ed/b7s7Ssu5OnyzldKdHwS0/q4l89p9tMlXL83DOAB5Q=; X-YMail-OSG: Tua1JrQVM1lXP6_zjMkZxgbZxdDynsf1nwtGVViD_akI6di 6IuB3vVnsw2FUOg4F5VKYAeaUpblqxkdrVDIm9oIfQKZ7P7w5n7xoLhmUdog bWMmcaCQGzfoNsTJLpMUSPAEy3p65NzoQJwu.i6QNG8OQ9JnOLn0p9mndgGw M_Of1.UPUEocQhtZflb_dBETwGeWla1gswVtzjvbHzR4dE4GAE3gTCtShh.T xe5F6scHiE6tQxHDjV4BeaPSZA6nr8wp6FRdA53I2n_NSMaTUOv791D1yEp9 ISY5w_ZA3KaGcAf_bnjzP9mSSPYTAXPFh1zvpUWSaU5foTDs8XwZMKQH1e_J 8g7rWnW6XTSrOdGqDe8yvi9CXO1ZRY26.dDMz7N8wFOUX2vFlOb9BYQHY1Wb 93oGpW20qYBPzaGBMPwvoE1USTlyxpmyiiVDZ1a3GVVVaiLrh6zjGLqm4Kse xEeXceGJTrYKNWAluEnmlDIGGbii9cvTfBSzpeqS8p_MatzpKpbWwlEqG6Aw kdv1fAneTe.v9HiUHH3473_E6viFOoJnj7Xtqyt.jSPN2rWRSDMTbBDz5eVY UpYtYCWPvL.gVFATl6ieOAUL88Fo1AA-- Received: from [50.201.233.2] by web125504.mail.ne1.yahoo.com via HTTP; Sat, 28 Sep 2013 08:27:52 PDT X-Rocket-MIMEInfo: 002.001, VGhlIHJvdXRlcnMgYmVpbmcgY29udHJvbGxlZCBieSB0aGUgbGFyZ2VyIGFkdmVyc2FyeSBhcmUgdGhlIG9uZXMgdGhhdCB0YWtlIHRyYWZmaWMgaW50byBhbmQgb3V0IG9mIHRoZSBnZW9ncmFwaGljIGFyZWEuwqAgVGhlIGFkdmVyc2FyeSBpcyByZS1yb3V0aW5nIGFsbCB0cmFmZmljIHRvwqBETlMgcG9ydHMgdG8gaGlzIGJvZ3VzIEROUyBzZXJ2ZXIgYW5kIHJlcGx5aW5nIHdpdGggSVAgYWRkcmVzc8Kgc3Bvb2ZpbmcgLS0gZS5nLiBhIE1JVE0gYXR0YWNrIG9uIEROUyB0cmFmZmljLgrCoApETlMgbmVlZHMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> <001b01cebbb6$d5565550$8002fff0$@rozanak.com> Message-ID: <1380382072.12590.YahooMailNeo@web125504.mail.ne1.yahoo.com> Date: Sat, 28 Sep 2013 08:27:52 -0700 (PDT) From: Karl Malbrain To: manning bill In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="318864283-230616736-1380382072=:12590" Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 15:28:01 -0000 --318864283-230616736-1380382072=:12590 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The routers being controlled by the larger adversary are the ones that take= traffic into and out of the geographic area.=C2=A0 The adversary is re-rou= ting all traffic to=C2=A0DNS ports to his bogus DNS server and replying wit= h IP address=C2=A0spoofing -- e.g. a MITM attack on DNS traffic.=0A=C2=A0= =0ADNS needs some means of authentication to prevent this.=C2=A0 Certificat= es can be forged. TOFU doesn't work either.=0A=C2=A0=0AThe routers are comp= letely programmable by MITM -- they don't have any security that I know of.= =0A=C2=A0=0A=C2=A0=C2=A0 =0A=0A________________________________=0A From: ma= nning bill =0ATo: Hosnieh Rafiee =0ACc= : 'perpass' ; 'Karl Malbrain' ; 'Step= hen Farrell' =0ASent: Saturday, September 28, 2= 013 3:02 AM=0ASubject: Re: [perpass] DNS confidentiality=0A =0A=0Ayou are = conflating routing security/authentication with DNS service opaque capabili= ties.=0Athere already exist a number of methods for securing the DNS channe= l,=C2=A0 [SIG(0), TSIG, DNSCurve=E2=80=A6]=0Aand we can add your technique = to the list.=C2=A0 =0A=0Aprotecting the service is very different than prot= ecting the channel.=0A=0A/bill=0A=0A=0AOn 27September2013Friday, at 12:21, = Hosnieh Rafiee wrote:=0A=0A> =0A>=C2=A0 =0A>> 1.=C2=A0 Passive surveillence= of traffic going to DNS resolvers yielding=0A> meta-data.=0A> =0A> Again n= ot possible, at least not in IPv6 if your resolvers and recursive=0A> resol= vers are using cga-tsig. The signature and the CGA/SSAS algorithm=0A> preve= nt it.=0A>=C2=A0 =0A>> 2.=C2=A0 MITM who inserts himself between a particul= ar DNS client and a=0A> particular DNS resolver, and provids false addresse= s and certificates for=0A> use in MITM attacks.=0A> =0A> Again this is not = possible if you are using cga-tsig.=0A> =0A>=C2=A0 =0A>> 3. A larger advers= ary who installs his own DNS resolver for a given=0A> geographic area by co= ntrolling the traffic at the router level into and out=0A> of that area to = redirect DNS traffic to his DNS resolver, and then inserts=0A> MITM attacks= on any connection out of the area he desires by supplying bogus=0A> addres= ses and/or server certificates.=0A> =0A> If you are using SeND with SSAS or= centralized RPKI you can retrieve and=0A> verify your router in a local li= nk. RA can include the=0A> (http://tools.ietf.org/html/rfc6106) DNS server = options. This means that you=0A> receive a signed message from a router tha= t was previously authorized via=0A> the centralized local RPK1. I am not su= re whether or not DHCPv6 also=0A> includes security approaches that can be = used for authentication. I believe=0A> that there was a draft about secure = authentication using CGA in DHCPv6 as=0A> well.=0A> You can also us a scena= rio, like SSL, to verify your router certificate=0A> where the client has a= lready configured the list of CAs.=0A> =0A>=C2=A0 =0A>> The client is tryin= g to retrieve the IP address and public key for an=0A> arbitrary server fro= m the DNS resolver.=C2=A0 This is subject to MITM attack.=0A> =0A> I guess = that you did not quite understand the reasoning behind CGA and that=0A> is = why you are asking a question about an issue that I have already=0A> explai= ned. Your client retrieves this IP address from the RA message that is=0A> = generated by the use of SeND with the DNS RA option (. Since this RA messag= e=0A> is already signed and we assume that this client has already verified= this=0A> router (centralized local RPKI that is explained in SSAS or other= RPKI=0A> approaches) the attacker has no way of spoofing this message as i= t cannot=0A> spoof the content (due to the signature) and it cannot spoof t= he public key=0A> due to the binding between the public key and the source = IP address=0A> =0A> =0A>> How does this prevent MITM from inserting himself= between the client and=0A> the resolver on the first connection to the res= olver?=0A> =0A> Your node already knows the IP address of your resolver.=0A= >=C2=A0 =0A>>=C2=A0 This is actually a capability of CGA (RFC 3972) or SSAS= =0A>> (http://tools.ietf.org/html/draft-rafiee-6man-ssas),=C2=A0 which also= provides=0A>> for the proof of address ownership. So, the client stores th= e public key of=0A>> the resolver in its cache. It will subsequently not ac= cept any messages=0A> from=0A>> attackers.=0A>=C2=A0 =0A>> What if the publ= ic key being stored belongs to MITM and not the resolver?=0A> All client tr= affic is going to MITM.=0A> =0A> As I explained, you retrieve the IP addres= s of your DNS server using a safe=0A> means after having authorized your ro= uter in the local link. Now if your=0A> MITM node is somewhere in the other= network and tries to intercept the=0A> connection between your node and th= e resolver, since you node already knows=0A> the IP address of the resolver= , it will reject the connection because the=0A> CGA/SSAS verification proce= ss fails.=0A>=C2=A0 =0A>> Whom does the client "ask for the public key of t= he DNS server" from?=C2=A0 This=0A> is the step that is subject to MITM att= ack.=0A> =0A> I guess I have already responded this.=0A> =0A> =0A> Hosnieh= =0A> =0A> _______________________________________________=0A> perpass maili= ng list=0A> perpass@ietf.org=0A> https://www.ietf.org/mailman/listinfo/perp= ass=0A=0A_______________________________________________=0Aperpass mailing = list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/perpass --318864283-230616736-1380382072=:12590 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The router= s being controlled by the larger adversary are the ones that take traffic i= nto and out of the geographic area.  The adversary is re-routing all t= raffic to DNS ports to his bogus DNS server and replying with IP addre= ss spoofing -- e.g. a MITM attack on DNS traffic.
 
DNS needs some means of authentication to = prevent this.  Certificates can be forged. TOFU doesn't work either.
 
The routers are complet= ely programmable by MITM -- they don't have any security that I know of.
 
 
 = ;
From: manning bill <bmanning@isi.edu>
To: Hosnieh Rafiee <ietf@roza= nak.com>
Cc: 'perpa= ss' <perpass@ietf.org>; 'Karl Malbrain' <malbrain@yahoo.com>; '= Stephen Farrell' <stephen.farrell@cs.tcd.ie>
Sent: Saturday, September 28, 2013 3:02 AM Subject: Re: [perpass] D= NS confidentiality

yo= u are conflating routing security/authentication with DNS service opaque capabilities.
there already exist a number of methods for securing the = DNS channel,  [SIG(0), TSIG, DNSCurve=E2=80=A6]
and we can add your= technique to the list. 

protecting the service is very diffe= rent than protecting the channel.

/bill


On 27September201= 3Friday, at 12:21, Hosnieh Rafiee wrote:

>
> 
>= ;> 1.  Passive surveillence of traffic going to DNS resolvers yield= ing
> meta-data.
>
> Again not possible, at least not in= IPv6 if your resolvers and recursive
> resolvers are using cga-tsig.= The signature and the CGA/SSAS algorithm
> prevent it.
> =
>> 2.  MITM who inserts himself between a particular DNS cl= ient and a
> particular DNS resolver, and provids false addresses and= certificates for
> use in MITM attacks.
>
> Again this = is not possible if you are using cga-tsig.
>
> 
>> 3. A larger adversary who installs his own DNS resolver for a= given
> geographic area by controlling the traffic at the router lev= el into and out
> of that area to redirect DNS traffic to his DNS res= olver, and then inserts
> MITM attacks on any connection out of the a= rea he desires by supplying bogus
> addresses and/or server certifica= tes.
>
> If you are using SeND with SSAS or centralized RPKI y= ou can retrieve and
> verify your router in a local link. RA can incl= ude the
> (http://tools.ietf.org/html/rfc6106) DNS server options. This mea= ns that you
> receive a signed message from a router that was previou= sly authorized via
> the centralized local RPK1. I am not sure whethe= r or not DHCPv6 also
> includes security approaches that can be used = for authentication. I believe
> that there was a draft about secure authentication using CGA in DHCPv6 as
> well.
> You can= also us a scenario, like SSL, to verify your router certificate
> wh= ere the client has already configured the list of CAs.
>
>&nbs= p;
>> The client is trying to retrieve the IP address and public= key for an
> arbitrary server from the DNS resolver.  This is s= ubject to MITM attack.
>
> I guess that you did not quite unde= rstand the reasoning behind CGA and that
> is why you are asking a qu= estion about an issue that I have already
> explained. Your client re= trieves this IP address from the RA message that is
> generated by th= e use of SeND with the DNS RA option (. Since this RA message
> is al= ready signed and we assume that this client has already verified this
&g= t; router (centralized local RPKI that is explained in SSAS or other RPKI> approaches) the attacker has no way of spoofing this message as it cannot
> spoof the content (due to the signature) and it canno= t spoof the public key
> due to the binding between the public key an= d the source IP address
>
>
>> How does this prevent= MITM from inserting himself between the client and
> the resolver on= the first connection to the resolver?
>
> Your node already k= nows the IP address of your resolver.
> 
>>  This= is actually a capability of CGA (RFC 3972) or SSAS
>> (http:= //tools.ietf.org/html/draft-rafiee-6man-ssas),  which also provide= s
>> for the proof of address ownership. So, the client stores the= public key of
>> the resolver in its cache. It will subsequently = not accept any messages
> from
>> attackers.
>  <= br>>> What if the public key being stored belongs to MITM and not the resolver?
> All client traffic is going to MITM.
>
>= ; As I explained, you retrieve the IP address of your DNS server using a sa= fe
> means after having authorized your router in the local link. Now= if your
> MITM node is somewhere in the other network and tries to i= ntercept the
> connection between your node and the resolver, since y= ou node already knows
> the IP address of the resolver, it will rejec= t the connection because the
> CGA/SSAS verification process fails.> 
>> Whom does the client "ask for the public key of t= he DNS server" from?  This
> is the step that is subject to MITM= attack.
>
> I guess I have already responded this.
> >
> Hosnieh
>
> __________________________________= _____________
> perpass mailing list
> perpass@ietf.org
> https:= //www.ietf.org/mailman/listinfo/perpass

________________________= _______________________
perpass mailing list
perpass@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/perpass

=
--318864283-230616736-1380382072=:12590-- From stephen.farrell@cs.tcd.ie Sat Sep 28 08:31:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4632311E80D7 for ; Sat, 28 Sep 2013 08:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFIHxd7DXmhl for ; Sat, 28 Sep 2013 08:31:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DCC4421F91B7 for ; Sat, 28 Sep 2013 08:31:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ABAE9BE61; Sat, 28 Sep 2013 16:31:33 +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 6xjgmGoIH+ya; Sat, 28 Sep 2013 16:31:32 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.60.159]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0FD2CBE5D; Sat, 28 Sep 2013 16:31:32 +0100 (IST) Message-ID: <5246F653.2040300@cs.tcd.ie> Date: Sat, 28 Sep 2013 16:31:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Karl Malbrain References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> <001b01cebbb6$d5565550$8002fff0$@rozanak.com> <1380382072.12590.YahooMailNeo@web125504.mail.ne1.yahoo.com> In-Reply-To: <1380382072.12590.YahooMailNeo@web125504.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: 'perpass' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 15:31:42 -0000 Karl, The subject line is about confidentiality. If you (or others) want to disucss other security issues with DNS, please first read up on DNSSEC and then start new threads. Now, can we get back to discussion of subject of the subject line? Thanks, S. On 09/28/2013 04:27 PM, Karl Malbrain wrote: > The routers being controlled by the larger adversary are the ones that take traffic into and out of the geographic area. The adversary is re-routing all traffic to DNS ports to his bogus DNS server and replying with IP address spoofing -- e.g. a MITM attack on DNS traffic. > > DNS needs some means of authentication to prevent this. Certificates can be forged. TOFU doesn't work either. > > The routers are completely programmable by MITM -- they don't have any security that I know of. > > > > ________________________________ > From: manning bill > To: Hosnieh Rafiee > Cc: 'perpass' ; 'Karl Malbrain' ; 'Stephen Farrell' > Sent: Saturday, September 28, 2013 3:02 AM > Subject: Re: [perpass] DNS confidentiality > > > you are conflating routing security/authentication with DNS service opaque capabilities. > there already exist a number of methods for securing the DNS channel, [SIG(0), TSIG, DNSCurve…] > and we can add your technique to the list. > > protecting the service is very different than protecting the channel. > > /bill > > > On 27September2013Friday, at 12:21, Hosnieh Rafiee wrote: > >> >> >>> 1. Passive surveillence of traffic going to DNS resolvers yielding >> meta-data. >> >> Again not possible, at least not in IPv6 if your resolvers and recursive >> resolvers are using cga-tsig. The signature and the CGA/SSAS algorithm >> prevent it. >> >>> 2. MITM who inserts himself between a particular DNS client and a >> particular DNS resolver, and provids false addresses and certificates for >> use in MITM attacks. >> >> Again this is not possible if you are using cga-tsig. >> >> >>> 3. A larger adversary who installs his own DNS resolver for a given >> geographic area by controlling the traffic at the router level into and out >> of that area to redirect DNS traffic to his DNS resolver, and then inserts >> MITM attacks on any connection out of the area he desires by supplying bogus >> addresses and/or server certificates. >> >> If you are using SeND with SSAS or centralized RPKI you can retrieve and >> verify your router in a local link. RA can include the >> (http://tools.ietf.org/html/rfc6106) DNS server options. This means that you >> receive a signed message from a router that was previously authorized via >> the centralized local RPK1. I am not sure whether or not DHCPv6 also >> includes security approaches that can be used for authentication. I believe >> that there was a draft about secure authentication using CGA in DHCPv6 as >> well. >> You can also us a scenario, like SSL, to verify your router certificate >> where the client has already configured the list of CAs. >> >> >>> The client is trying to retrieve the IP address and public key for an >> arbitrary server from the DNS resolver. This is subject to MITM attack. >> >> I guess that you did not quite understand the reasoning behind CGA and that >> is why you are asking a question about an issue that I have already >> explained. Your client retrieves this IP address from the RA message that is >> generated by the use of SeND with the DNS RA option (. Since this RA message >> is already signed and we assume that this client has already verified this >> router (centralized local RPKI that is explained in SSAS or other RPKI >> approaches) the attacker has no way of spoofing this message as it cannot >> spoof the content (due to the signature) and it cannot spoof the public key >> due to the binding between the public key and the source IP address >> >> >>> How does this prevent MITM from inserting himself between the client and >> the resolver on the first connection to the resolver? >> >> Your node already knows the IP address of your resolver. >> >>> This is actually a capability of CGA (RFC 3972) or SSAS >>> (http://tools.ietf.org/html/draft-rafiee-6man-ssas), which also provides >>> for the proof of address ownership. So, the client stores the public key of >>> the resolver in its cache. It will subsequently not accept any messages >> from >>> attackers. >> >>> What if the public key being stored belongs to MITM and not the resolver? >> All client traffic is going to MITM. >> >> As I explained, you retrieve the IP address of your DNS server using a safe >> means after having authorized your router in the local link. Now if your >> MITM node is somewhere in the other network and tries to intercept the >> connection between your node and the resolver, since you node already knows >> the IP address of the resolver, it will reject the connection because the >> CGA/SSAS verification process fails. >> >>> Whom does the client "ask for the public key of the DNS server" from? This >> is the step that is subject to MITM attack. >> >> I guess I have already responded this. >> >> >> Hosnieh >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From malbrain@yahoo.com Sat Sep 28 08:36:20 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4953921F9EDB for ; Sat, 28 Sep 2013 08:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUfTuCsN3Rhl for ; Sat, 28 Sep 2013 08:36:10 -0700 (PDT) Received: from nm38-vm4.bullet.mail.bf1.yahoo.com (nm38-vm4.bullet.mail.bf1.yahoo.com [72.30.239.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6DC21F9E76 for ; Sat, 28 Sep 2013 08:36:10 -0700 (PDT) Received: from [98.139.212.153] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2013 15:36:09 -0000 Received: from [98.139.212.217] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 28 Sep 2013 15:36:08 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 28 Sep 2013 15:36:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 982244.88576.bm@omp1026.mail.bf1.yahoo.com Received: (qmail 9695 invoked by uid 60001); 28 Sep 2013 15:36:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1380382568; bh=vn4LHlmkvYrudVCRTwbvlY5IBPlPo6824HEj0kJgkaQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=L4nWIAMuigG9lVKBbq9B5RpBSzmkVRwYl2Gc++Yb08rAPZWgyjEVU98l9ZCNzmDLlYMmkrWqqt0UjahVvFeOy58cMr7/lb1ZkWYlnfZg91GtBRTff3rjXsc1WP8HeRQ3ELFS71KLRJDn5SvmGri3S+o0/UqS8DuM8qDjqO0CpPc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ko0H23UjvafXr7f5h2hGJvHOvS3DTskN/2F+p8AZtRYr+WEQi1zq+PSpOBHGEb59eLYprxxLqdp0EAsfTv2MXGeayqdSXhxWsRYkQqX4c05iXWeZn3quBNbP7ZcwsyVqyQy4gJqdwFMPzN+JIeildNYnqh+VwCa2QPHEe2SkQMs=; X-YMail-OSG: gpVp41QVM1m_j1.9dAHY7uawtLH.NQmcruJ2gaMdXqO78g9 VOOWkyXjP9U2NBcarWeaE9OXV80PLOp8KbosV2s1_tyGyRGn_ou9Oo6SlrwY otAkDtla1aoW4HKORYIcqWV9p8ZIcLb_zirVkL5gYn3qHdpE5.al8u1a_SUu tnbzNYEmN65_X4UDDEOMWHbMi5L4sq9YnLtyjAXpP6lGWCKa0FWlbLjZyjaX 3iwmFJNIM_2n2kxMINDbqMidNR0yp50UUHX.SB5Hzf1Ryx06SDpkNDBdsISI scIoC9nN8E9h2r_g1oSufLUGLAWUn0L8Ho5prY_rO3mpKH4jX4kzLDjpwWbF j2_JYi07iEkfYn7KyTgv_P7505koHA6gkBxvcOJiePxH.rY1lywAFxMJWNNK 3hDGF7zOLWoxCTiAuETgSkpItwCp6ncm4qsEmE34RphrGG2HiOu4wR07shTD wSa3x_T73GmBAuMr1WVHIgATNammT54vLuw_8KxzIt9DX4KfgTWzzG4lA9CK ZrjDFFixavCJRkJ_OKWVn43oB691UvWM1kwuFrJO4c8ISaHUYS_Fn_nrKDam R4JTxeCcY_NpuV45A0n3OMb.UiP1zlGqVYU9tPg-- Received: from [50.201.233.2] by web125501.mail.ne1.yahoo.com via HTTP; Sat, 28 Sep 2013 08:36:08 PDT X-Rocket-MIMEInfo: 002.001, PkkgYXNrIHRoYXQgeW91IHBsZWFzZSBwdXQgYXNpZGUgeW91ciBwcmVjb25jZWl2ZWQgaWRlYXMgYW5kIHJlYWQgdGhlCj5jZ2EtdHNpZyBkb2N1bWVudCB3aXRoIGFuIG9wZW4gbWluZCBiZWZvcmUgeW91IGp1ZGdlIGl0LiBUaGUgZG9jdW1lbnQKPmFkZHJlc3NlcyB0aGUgcHJvYmxlbSB3aXRoIHRoZSB1c2Ugb2YgVFNJRyBhbmQgU0lHIGFuZCBpbnRyb2R1Y2VzIGEgbmV3LAo.Y29tYmluZWQgbWV0aG9kIHdoaWNoIGNhbiBwcm90ZWN0IG5vZGVzIGFnYWluc3Qgc2V2ZXJhbCB0eXBlcyBvZiBhdHRhY2suIAoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.160.587 References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> <001b01cebbb6$d5565550$8002fff0$@rozanak.com> <000701cebc54$9bdbef80$d393ce80$@rozanak.com> Message-ID: <1380382568.95722.YahooMailNeo@web125501.mail.ne1.yahoo.com> Date: Sat, 28 Sep 2013 08:36:08 -0700 (PDT) From: Karl Malbrain To: Hosnieh Rafiee , 'manning bill' In-Reply-To: <000701cebc54$9bdbef80$d393ce80$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="329289550-26436379-1380382568=:95722" Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Karl Malbrain List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 15:36:21 -0000 --329289550-26436379-1380382568=:95722 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >I ask that you please put aside your preconceived ideas and read the=0A>cg= a-tsig document with an open mind before you judge it. The document=0A>addr= esses the problem with the use of TSIG and SIG and introduces a new,=0A>com= bined method which can protect nodes against several types of attack. =0A>K= arl asked how the node receives the IP address of the DNS as it can be the= =0A>first point of a MITM attack. I just explained that this is not possibl= e, as=0A>earlier explained, the node can retrieve this IP address in a safe= manner=0A>during a first time retrieval.=0A=A0=0AThis is called Trust On F= irst Use (TOFU).=0A=A0=0AIf the MITM attacker is already in play before the= "first time retrieval" then the node is not talking to the DNS resolver=A0= he thinks he is.=A0 He is talking to MITM instead, who can forge certificat= es and spoof IP addresses.=A0 Just knowing the IP address of the resolver y= ou trust is not enough to protect against MITM.=0A=A0=0A>This has nothing t= o do with CGA-TSIG as it assumes that the node already=0Al>earned the IP ad= dress of the DNS server in a safe way. This document only=0A>explains a new= method for secure authentication during different scenarios.=0A=0AThe prob= lem is that you have not demonstrated a "safe way" to authenticate the DNS = resolver connection. --329289550-26436379-1380382568=:95722 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>I ask that y= ou please put aside your preconceived ideas and read the
>cga-tsig do= cument with an open mind before you judge it. The document
>addresses= the problem with the use of TSIG and SIG and introduces a new,
>comb= ined method which can protect nodes against several types of attack.
&g= t;Karl asked how the node receives the IP address of the DNS as it can be t= he
>first point of a MITM attack. I just explained that this is not p= ossible, as
>earlier explained, the node can retrieve this IP address= in a safe manner
>during a first time retrieval.
 
This is called Trust On First Use (TOFU).
 
If the MITM attacker is already in play before the "first time retrieval"= then the node is not talking to the DNS resolver he thinks he is.  He is talking to MITM instead, who can forge certificates and sp= oof IP addresses.  Just knowing the IP address of the resolver you tru= st is not enough to protect against MITM.
 
>Th= is has nothing to do with CGA-TSIG as it assumes that the node already
l= >earned the IP address of the DNS server in a safe way. This document on= ly
>explains a new method for secure authentication during different = scenarios.

The problem is that you have not demonstrated a "safe way= " to authenticate the DNS resolver connection.
--329289550-26436379-1380382568=:95722-- From ietf@rozanak.com Sat Sep 28 08:53:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC22221F9F8E for ; Sat, 28 Sep 2013 08:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6W+DOPPqMZBA for ; Sat, 28 Sep 2013 08:53:36 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id DB92621E80E4 for ; Sat, 28 Sep 2013 08:53:35 -0700 (PDT) Received: from kopoli (g231251251.adsl.alicedsl.de [92.231.251.251]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MhR5W-1VC6uF3ITS-00MAoM; Sat, 28 Sep 2013 11:53:28 -0400 From: "Hosnieh Rafiee" To: "'Stephen Farrell'" References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> <001b01cebbb6$d5565550$8002fff0$@rozanak.com> <1380382072.12590.YahooMailNeo@web125504.mail.ne1.yahoo.com> <5246F653.2040300@cs.tcd.ie> In-Reply-To: <5246F653.2040300@cs.tcd.ie> Date: Sat, 28 Sep 2013 17:53:19 +0200 Message-ID: <002101cebc62$dda15dc0$98e41940$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJOGj5UkWbfuDhxpmMKtaAoIXGv7QHKq7oDAZ0lsZ0CNxrNyAK3hHhTAo3vF0wCd4OykQJLJu5nARfcMlYBQCaxogJirkqZAWoTwMuYLi7QUA== Content-Language: en-us X-Provags-ID: V02:K0:49lTA9zB09dyporWZuANFf0fYzc/TTjwNB7fU7KAPCU GjWQfEPcYJXnjv3Vz3p1XfAlVPW+Zm+FW7IBD2KhWwL3jb0Hyn lZPM+z2VicPDSFb9BM0foLBOS71COPiAgeRmCrXTpv952T2WvN JsrWZq/oDQoGpUQ0us0jOGoNd31Cxt3uQqd3qQe8K30UHlEB0/ xPAMzsmKLW4wKzF54eOdWakdzEwtUpbdutVyYvkKxxRhYNrOZC Ymrv+dv1u4ztP+4iiaG36g8EhLjp29b2zL5roKNqMqX2EjSV6Y Cb7bs+lTHdIlXyu/ofH+dD2N4AYp3HFU+8lvuH/B4Tuljs3ZcX 8KXvJWlzjacF0pq8GGvk= Cc: 'perpass' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 15:53:41 -0000 Confidentiality is not possible unless all the queries are encrypted. Using asymmetric cryptography for a small message is possible, but for a zone transfer it will have an effect on the DNS performance. So one needs to use symmetric approaches. (something like what was done in the paper that I sent the link to in my last message) Using one way hashing as DNSSEC does with NSEC3 does not completely provide the zone file with data confidentiality. We tested this procedure and it was possible to retrieve thousands of records within 2 hours using a standard computer. The dictionary attack and brute force attack are also possible which leads to zone walking. Hosnieh From huitema@huitema.net Sat Sep 28 23:36:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387FE21F938E for ; Sat, 28 Sep 2013 23:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aD+z+NCbrC9 for ; Sat, 28 Sep 2013 23:35:56 -0700 (PDT) Received: from xsmtp05.mail2web.com (xsmtp25.mail2web.com [168.144.250.191]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8DF21F994A for ; Sat, 28 Sep 2013 23:35:53 -0700 (PDT) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VQAYv-00056I-Ax for perpass@ietf.org; Sun, 29 Sep 2013 02:35:52 -0400 Received: (qmail 3898 invoked from network); 29 Sep 2013 06:33:00 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Sep 2013 06:32:59 -0000 From: "Christian Huitema" To: "'Hosnieh Rafiee'" , "'Stephen Farrell'" References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> <001b01cebbb6$d5565550$8002fff0$@rozanak.com> <1380382072.12590.YahooMailNeo@web125504.mail.ne1.yahoo.com> <5246F653.2040300@cs.tcd.ie> <002101cebc62$dda15dc0$98e41940$@rozanak.com> In-Reply-To: <002101cebc62$dda15dc0$98e41940$@rozanak.com> Date: Sat, 28 Sep 2013 23:32:58 -0700 Message-ID: <007b01cebcdd$be1e1580$3a5a4080$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJOGj5UkWbfuDhxpmMKtaAoIXGv7QHKq7oDAZ0lsZ0CNxrNyAK3hHhTAo3vF0wCd4OykQJLJu5nARfcMlYBQCaxogJirkqZAWoTwMsCGqLfwJgeUg3Q Cc: 'perpass' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 06:36:02 -0000 Hosnieh, CGA only protect against MITM attacks if the addresses are exchanged securely. Otherwise, you get the following situation: * A wants to connect with B; * The evil E convinces A that the address of B is X, a CGA address composed by E; * Using CGA, A establishes a secure channel to X; * Using CGA, E establishes a secure channel from X to B; Voila, the connections are properly secured with CGA, yet E is in the middle. -- Christian Huitema From ietf@rozanak.com Sun Sep 29 07:26:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B1F21F9F96 for ; Sun, 29 Sep 2013 07:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bXWZSX-69gf for ; Sun, 29 Sep 2013 07:25:59 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id F09A921F9654 for ; Sun, 29 Sep 2013 07:25:58 -0700 (PDT) Received: from kopoli (g225037057.adsl.alicedsl.de [92.225.37.57]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MePod-1VCrfC3wMx-00POXs; Sun, 29 Sep 2013 10:25:42 -0400 From: "Hosnieh Rafiee" To: "'Christian Huitema'" Date: Sun, 29 Sep 2013 16:25:35 +0200 Message-ID: <000601cebd1f$c70e1db0$552a5910$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac6861+2FEn/plBtTI2klPMulvUmxQ== X-Provags-ID: V02:K0:ihz5foLopybIf7TYigN2AJh9R6qSj8TgRHiiDTz5nnC 7+l6V9DmZns6ANUW+ae1v7pN8oMmRxf+L3tu9Dubqn+8YUCE2S HhnIG3bZ5QUbQ2pE0n1xYjIn6TFBnbOX7hXdMD5rPbzOG/gvHd 7juZaL8Jsw+VPHJrd1A5DOQlBK4LLnLrhQpHUfqqaslwiefwnm CKm4J8X7v0wqf3awkv7ZDYmP8wvp4DprP0lOKTQqObvwEFMhS9 VLKnaHGSBAep3/W/B+8FcvSgCbMMpB23FJmUML5eIWvZjw0KQ0 QLR9jZPjIoOtdcNFI1bwWIOUBEGec5LEooO8MnV4iFnUVPkxpf Kf6rK1tpodrSz0Qp/BN0= Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS Integrity vs DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 14:26:05 -0000 Hi Christian, Let me first say that I have altered the subject line because, as I explained earlier, our approach does not provide for data confidentiality (one can eavesdrop on the data but one cannot modify and spoof the sender or message content) but does provide for data integrity. If one wants both confidentiality and data integrity then one can use the approach I introduced in the first message I sent. This approach is called CGA-TSIGe (encrypted CGA-TSIG). > > CGA only protect against MITM attacks if the addresses are exchanged > securely. Otherwise, you get the following situation: May I ask you to first read the draft cga-tsig? I guess your assumption is that CGA is valid only in the local link so any other nodes are capable of playing in between, like playing MITM or like Proxy NDP, etc. To answer your concern, I confirm that CGA-TSIG is an application layer protocol, dissimilar to the original CGA, and that the node directly makes use of TCP or UDP to send messages to the DNS server or other nodes. This means that CGA-TSIG options constitute a payload within the TCP message which is signed by the originator. There is thus a binding between the originator IP address and the public key of the signer so this approach works and avoids MITM attacks by providing data integrity. > * A wants to connect with B; > * The evil E convinces A that the address of B is X, a CGA address composed by How does the evil E convince A? This is the question because A already knows the IP address of B and only accepts the messages from B. It will not open any channel with any intermediate nodes as it expects an end to end channel with B whose IP address it knows and the routers in between only route the packets. What I want to tell you here is that we assume that A receives the IP address of B from a resolver that again knows its IP address or obtained it using a secure manner. Your scenario, by the use of cga-tsig, changes to the following: A asks R(resolver) what is the IP address of B. Evil E says that it is X. A checks the signature and proceeds with the CGA verification. It fails. A rejects the answer from E. A receives a response from R. A proceeds using the verification process that is explained in cga-tsig. A accepts R and accepts the message content. R says the IP address is Y. A establishes the connection with B using Y. E fails so E couldn't play the MITM. > E; > * Using CGA, A establishes a secure channel to X; > * Using CGA, E establishes a secure channel from X to B; > > Voila, the connections are properly secured with CGA, yet E is in the middle. I think the data confidentiality doesn't need to use the resolver scenario. Because the resolver responds to anonymous queries it doesn't make sense to decrease the DNS performance the the use of something that is not needed. What I want to explain here is that data confidentiality is good for DNS query updates (zone transfer, FQDN update) in order to avoid leaking zone information. Hosnieh From bortzmeyer@nic.fr Sun Sep 29 11:28:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3302211E813A for ; Sun, 29 Sep 2013 11:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-6mkrXb-KOi for ; Sun, 29 Sep 2013 11:28:10 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) by ietfa.amsl.com (Postfix) with ESMTP id F3DE111E8131 for ; Sun, 29 Sep 2013 11:28:08 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 0B4293B622; Sun, 29 Sep 2013 18:28:07 +0000 (UTC) Received: by mail.sources.org (Postfix, from userid 1000) id 445FE190749; Sun, 29 Sep 2013 20:28:04 +0200 (CEST) Date: Sun, 29 Sep 2013 20:28:04 +0200 From: Stephane Bortzmeyer To: Karl Malbrain Message-ID: <20130929182804.GA20577@sources.org> References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 7.1 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'perpass' , Hosnieh Rafiee , 'Stephen Farrell' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 18:28:15 -0000 On Fri, Sep 27, 2013 at 11:41:25AM -0700, Karl Malbrain wrote a message of 138 lines which said: > I'm concerned about three DNS security problems: You're not concerned about the fact that DNS servers (your resolver, and the authoritative name servers) get a lot of data and can misuse it? It seems to be that it is one of the main weaknesses of DNS, when it comes to confidentiality. A big public resolver, like OpenDNS or Google Public DNS (both located in PRISMland) can learn a lot of things about its users (this has been used often to detect malware, only from its DNS requests, but it could be used for more sinister purposes). A big TLD (say, for example, .com, also located in PRISMland) can also learn a lot. And no amount of cryptographe between the client and this server will help. From huitema@huitema.net Sun Sep 29 16:57:43 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AB321F9EC4 for ; Sun, 29 Sep 2013 16:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Xf3scoFsSFn for ; Sun, 29 Sep 2013 16:57:35 -0700 (PDT) Received: from xsmtp12.mail2web.com (xsmtp32.mail2web.com [168.144.250.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADC921F9ED2 for ; Sun, 29 Sep 2013 16:57:35 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VQQoy-0002Zu-2Q for perpass@ietf.org; Sun, 29 Sep 2013 19:57:34 -0400 Received: (qmail 24116 invoked from network); 29 Sep 2013 23:54:38 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Sep 2013 23:54:36 -0000 From: "Christian Huitema" To: "'Hosnieh Rafiee'" References: <000601cebd1f$c70e1db0$552a5910$@rozanak.com> In-Reply-To: <000601cebd1f$c70e1db0$552a5910$@rozanak.com> Date: Sun, 29 Sep 2013 16:54:35 -0700 Message-ID: <026701cebd6f$4100e400$c302ac00$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQFdd565G0le6r0GATUcZ6BBrRtY/5q/3NOg Cc: 'perpass' , 'Stephen Farrell' Subject: Re: [perpass] DNS Integrity vs DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 23:57:43 -0000 > I guess your assumption is that CGA is valid only in the local link so any > other nodes are capable of playing in between, like playing MITM or like > Proxy NDP, etc. To answer your concern, I confirm that CGA-TSIG is an > application layer protocol, dissimilar to the original CGA, and that the > node directly makes use of TCP or UDP to send messages to the DNS server or > other nodes. This means that CGA-TSIG options constitute a payload within > the TCP message which is signed by the originator. There is thus a binding > between the originator IP address and the public key of the signer so this > approach works and avoids MITM attacks by providing data integrity. The main value of CGA is that it encodes a hash of a public key in the least significant 64 bits of an IP address. You propose to use this property to simplify the configuration of DNS TSIG. To quote your draft, "the current problem with using TSIG is that manual processing is required in order to generate and exchange the shared secrets." The default signature process of DNS-TSIG is an MD5 MAC protected by a shared secret. You propose to replace that by a public signature based the same public key used to generate the IPv6 CGA address, and then add parameters in TSIG to facilitate the verification of the linkage of public key to IPv6 address according to the CGA algorithms. The security of your approach relies on the fact that "the resolver already knows the IPv6 address of the server." That is, the only "secure" configuration needed at the resolver is the CGA IPv6 address of the server. This configuration is critical, because if the IPv6 address can be spoofed, then man in the middle attacks become possible. If we expect to provide secure updates, we will need to also assume that "the server already knows the IPv6 address of the resolver." More precisely, the server would need to maintain the list of IPv6 CGA addresses that are authorized to send updates of records for a given DNS names. Your claim is that configuring the CGA IPv6 address of the servers on the resolvers, and configuring the CGA IPv6 addresses of the authorized resolvers on the server, is simpler than configuring shared secrets on both the servers and the resolvers. I am not sure that this is true in practice. The CGA addresses in your design are used as the authentic signature of an authorized public key. As such, they will need the same level of protection as for example a "key ring" in PGP. If one can securely configure these addresses, one could probably just as well configure a shared secret. Using IPv6 addresses as "trusted key hashes" introduces serious life time issues. IP addresses typically have a shorter life time than the trust relation between a server and a resolver. Making IP addresses the key to security introduces serious complexity in the IP address update process. Your draft proposes some ways to do that, but the whole issue screams "administrative nightmare." It seems that the bulk of the administrative gains in your proposal come from a shift from shared secrets to public keys in TSIG. The transactions end up being protected by the public keys of the servers and resolvers. This may be a valid tradeoff, which could certainly be debated in the DNS working group. However, IPv6 CGA would be just one way to introduce public keys in TSIG. Two alternative come to mind, using TLSA to negotiate a secure DNS transport, and if you really want to use CGA, using CGA in conjunction with TKEY to negotiate the TSIG secrets. -- Christian Huitema From stephen.farrell@cs.tcd.ie Sun Sep 29 17:18:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8383221F9E99 for ; Sun, 29 Sep 2013 17:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZrEcFsneZnH for ; Sun, 29 Sep 2013 17:17:58 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7414021F8F09 for ; Sun, 29 Sep 2013 17:17:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 727B9BE5F for ; Mon, 30 Sep 2013 01:17:55 +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 ltxUiccjjY26 for ; Mon, 30 Sep 2013 01:17:54 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.27.255]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7F8BDBE57 for ; Mon, 30 Sep 2013 01:17:54 +0100 (IST) Message-ID: <5248C332.10504@cs.tcd.ie> Date: Mon, 30 Sep 2013 01:17:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: 'perpass' References: <000601cebd1f$c70e1db0$552a5910$@rozanak.com> <026701cebd6f$4100e400$c302ac00$@huitema.net> In-Reply-To: <026701cebd6f$4100e400$c302ac00$@huitema.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] DNS Integrity vs DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 00:18:04 -0000 I've gotta say: this doesn't seem like a useful diuscssion here. IMO the snr on this list is being affected by that, so please stop discussions that are off-topic for this list. On this list, we're considering how to make pervasive monitoring more expensive. Authenticating end-user devices just is not a part of that. Bulk operations between DNS infratructure nodes is (by itself) just not a part of that. Since those basic functions are not relevant here, please don't continue using this list for that discussion. If you disagree, please start an informed discussion as to how authenticating end-users or their devices assists in making pervasive monitoring harder. Or try argue that protocols used between DNS infrastructure nodes can help make pervasive monitorinng harder. But please do not continue discussion that isn't aimed at making pervasive monitoring harder. Regards, Stephen. (As a list admin) PS: Yes, this mail is a precursor to starting down the road of RFC 3683. If you don't know what that means, please read the RFC. Either way, please stay on topic. From stephen.farrell@cs.tcd.ie Sun Sep 29 17:44:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4110921F81FF for ; Sun, 29 Sep 2013 17:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtLjJpZqFDJY for ; Sun, 29 Sep 2013 17:43:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 821BC21F9E98 for ; Sun, 29 Sep 2013 17:43:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 648F7BE60; Mon, 30 Sep 2013 01:43:57 +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 IDHxdDvPVYQa; Mon, 30 Sep 2013 01:43:56 +0100 (IST) Received: from [10.87.48.11] (unknown [86.42.27.255]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 29013BE5B; Mon, 30 Sep 2013 01:43:56 +0100 (IST) Message-ID: <5248C94B.2010100@cs.tcd.ie> Date: Mon, 30 Sep 2013 01:43:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <524150C7.2020602@cs.tcd.ie> <1380054665.62304.YahooMailNeo@web125505.mail.ne1.yahoo.com> <006a01ceb96a$335c1df0$9a1459d0$@rozanak.com> <1380137874.48631.YahooMailNeo@web125502.mail.ne1.yahoo.com> <005901ceba2a$f854c1a0$e8fe44e0$@rozanak.com> <1380218914.85280.YahooMailNeo@web125502.mail.ne1.yahoo.com> <003901cebba5$b2762c10$17628430$@rozanak.com> <1380307285.91976.YahooMailNeo@web125501.mail.ne1.yahoo.com> <20130929182804.GA20577@sources.org> In-Reply-To: <20130929182804.GA20577@sources.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'perpass' Subject: Re: [perpass] DNS confidentiality X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 00:44:07 -0000 Stephane, On 09/29/2013 07:28 PM, Stephane Bortzmeyer wrote: > On Fri, Sep 27, 2013 at 11:41:25AM -0700, > Karl Malbrain wrote > a message of 138 lines which said: > >> I'm concerned about three DNS security problems: > > You're not concerned about the fact that DNS servers (your resolver, > and the authoritative name servers) get a lot of data and can misuse > it? It seems to be that it is one of the main weaknesses of DNS, when > it comes to confidentiality. A big public resolver, like OpenDNS or > Google Public DNS (both located in PRISMland) can learn a lot of > things about its users (this has been used often to detect malware, > only from its DNS requests, but it could be used for more sinister > purposes). A big TLD (say, for example, .com, also located in > PRISMland) can also learn a lot. > > And no amount of cryptographe between the client and this server will > help. Does that mean that there's scope for a BCP on ways of deploying DNS that are more (or less) privacy friendly? While I guess a bunch of n/w operators might not care, I'm pretty sure some would. (And could perhaps get some competetive benefit from demonstrably caring via following such a BCP.) Additionally, if you're arguing that there's no useful role at all for confidentiality in DNS then I think I'd argue that confidentiality could well be useful, but that it won't by itself be sufficiently useful to be worth deploying and so is only worthwhile in conjunction with some already privacy-friendly deployment of DNS servers. Sound wrong? Or right? If right, then maybe there's scope for some experimental RFC(s) to go with that BCP. Volunteers very welcome as usual:-) If you're one, just go write the internet-draft and we'll catch up with you after you've posted a link here. Cheers, S. > From huitema@huitema.net Sun Sep 29 22:37:14 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C3A21F9D21 for ; Sun, 29 Sep 2013 22:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vprgqfio3BKD for ; Sun, 29 Sep 2013 22:37:08 -0700 (PDT) Received: from xsmtp01.mail2web.com (xsmtp01.mail2web.com [168.144.250.230]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1CF21F9D2E for ; Sun, 29 Sep 2013 22:37:06 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VQW8Y-00017R-0P for perpass@ietf.org; Mon, 30 Sep 2013 01:37:05 -0400 Received: (qmail 15560 invoked from network); 30 Sep 2013 05:35:12 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Sep 2013 05:35:12 -0000 From: "Christian Huitema" To: "'perpass'" Date: Sun, 29 Sep 2013 22:35:10 -0700 Message-ID: <02c001cebd9e$d5af4900$810ddb00$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: Ac69m5NpOu/Q54VBSOCgfKkJCLS0yg== Subject: [perpass] Traffic analysis X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 05:37:14 -0000 The massive monitoring attacks that we know about seem to fall into three categories: listening to the content of communications in transit, accessing content of documents and past exchanges at a server, and analyzing traffic to find patterns of communications and deduce social exchanges. I think we understand the "listening on conversations" attack, and we understand that we need more encryption. We have some good ideas for reducing the risk of accessing contents on server, such as storing encrypted contents on servers, or enabling distributed services so that users can chose server locations that they find more acceptable. But I wonder whether we have a good approach for traffic analysis. Traffic analysis proceeds through the collection of "meta data" such as ip headers, e-mail headers, and other forms of signaling, e.g. SIP headers. DNS traffic analysis also falls in that category. Such data is easy to harvest by monitoring big conduits such as backbone links or submarine cables. In some countries, the data is collected by forcing traffic through a single exchange or through some form of "national firewall." The current internet protocols and applications pay very little attention to traffic analysis. We should obviously take the easy steps, encrypt the DNS, e-mail and SIP connections. But when it comes to IP header analysis, we have pretty few solutions. VPN, of course, but that requires configuration. Could we change that? -- Christian Huitema From d.nix@comcast.net Sun Sep 29 23:11:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5B521F9C53 for ; Sun, 29 Sep 2013 23:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.977 X-Spam-Level: * X-Spam-Status: No, score=1.977 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn-QkV12vfbX for ; Sun, 29 Sep 2013 23:10:53 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id BF66521F9BDB for ; Sun, 29 Sep 2013 23:10:53 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta08.emeryville.ca.mail.comcast.net with comcast id XJ2f1m0021u4NiLA8JAtvs; Mon, 30 Sep 2013 06:10:53 +0000 Received: from [192.168.0.103] ([24.4.240.47]) by omta21.emeryville.ca.mail.comcast.net with comcast id XJAs1m00E123RE08hJAstQ; Mon, 30 Sep 2013 06:10:53 +0000 Message-ID: <524915EA.4000301@comcast.net> Date: Sun, 29 Sep 2013 23:10:50 -0700 From: "d.nix" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <02c001cebd9e$d5af4900$810ddb00$@huitema.net> In-Reply-To: <02c001cebd9e$d5af4900$810ddb00$@huitema.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380521453; bh=Twe4HA86w3hHEIXs+TVLgVb1+fibUvHJ4xZM9MEnQWc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ma3OXLm3+oDdDzS5zxGSyV+IgrrU8A0S5vuvZ/9O/OZ8oRcexm5UzuEdQ2TMMnn8x SehNz8ydTYlB2UaBmjU0UvIuUPs0fpiw64WDODxqYAPIcGl6nIyMUe2LtCD8beNxNu hGZ2HUuDuO89MCcTBpsHrAfGuIgAUXgZEnNKaWxZlfvULNimDeP9rrIUBy3s0i3aWU p1ohpbUBt9gVp6pvbz+E6YgUg0S24sQWWlUstnPWOhDKENmTTs2mGJcUM1NQH/JFNf 7lMJ0C8veY77YiwnvycL5fwKC3skQvqTjV5tylLb9MBtaDGiB7+VqLJg5suX22LwfS bH06baiBmEMHQ== Subject: Re: [perpass] Traffic analysis X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 06:11:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/29/2013 10:35 PM, Christian Huitema wrote: > Traffic analysis proceeds through the collection of "meta data" > such as ip headers, e-mail headers, and other forms of signaling, > e.g. SIP headers. DNS traffic analysis also falls in that category. > Such data is easy to harvest by monitoring big conduits such as > backbone links or submarine cables. In some countries, the data is > collected by forcing traffic through a single exchange or through > some form of "national firewall." > > The current internet protocols and applications pay very little > attention to traffic analysis. We should obviously take the easy > steps, encrypt the DNS, e-mail and SIP connections. But when it > comes to IP header analysis, we have pretty few solutions. VPN, of > course, but that requires configuration. Could we change that? > I feel in general, that while we can go a long way towards making content encryption easier and more robust, and simple to use for non tech savvy users (ie, your parents, aunts, uncles, etc...), *the* single largest issue is traffic analysis of message headers. While there are legit concerns by people to troubleshoot and to identify sources of spam and bulk mail, it's just entirely too easy to build up graphs of communication patterns and who is contacting who and when they are doing it. VPN's are a possibility, but as you say, require careful configuration and setup to prevent leakage of identifying information. Tech that purports to secure or privatize your communication but that actually leaks - or worse, can be coerced into revealing your traffic, is worse than no tech at all. Mix networks, anonymous remailers, and alternative / out of band systems start looking worthy of a lot more study. Dave Nix BM-2D9jC7gYDpnfprbSXuTCGr6a2DsCAXssAc (bitmessage) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSSRXqAAoJEDMbeBxcUNAeO+4H/RAb77DIE4bmk5HdOCstJr5L mKN+dfrwh6DIdxYny7iHqkIIGdupsIVTG6NnwjQ/BzyYvZO4cJT5ooxO2gM1SR1P +gRa6S18sqxNWthkQi2vmCT31aMU0PeP20I5G/MWg0fdvSFL0oJKqA47oD2QE8QZ zSBxdeHJ1h/kint8MGVL6AwzjMWHdJIBaD3KbsFvmYmMk36arLHBzB8cXPNeC/yc Sjbnmta+rq7b094CQR/dZcx5cpe/k+/shdnwHklXaxR+lsOilIqTOTe/Nkl2QBIZ POoCOv3DqKxhT2Jn+isVlj8cdOdlVoKNx8RviaPogjmVWbNmshjQeD55Aviu1G0= =ozsk -----END PGP SIGNATURE----- From trammell@tik.ee.ethz.ch Mon Sep 30 03:49:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F4021F86BE for ; Mon, 30 Sep 2013 03:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.569 X-Spam-Level: X-Spam-Status: No, score=-5.569 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC0uHlwN5ptu for ; Mon, 30 Sep 2013 03:49:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBDB21F9991 for ; Mon, 30 Sep 2013 03:49:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A559CD9307; Mon, 30 Sep 2013 12:49:34 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1X3MCdsr+li1; Mon, 30 Sep 2013 12:49:34 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 6DAFED9300; Mon, 30 Sep 2013 12:49:34 +0200 (MEST) Content-Type: multipart/signed; boundary="Apple-Mail=_920B7C5E-B880-4CEC-AF27-9EBC8787F824"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Trammell In-Reply-To: <524915EA.4000301@comcast.net> Date: Mon, 30 Sep 2013 12:49:34 +0200 Message-Id: References: <02c001cebd9e$d5af4900$810ddb00$@huitema.net> <524915EA.4000301@comcast.net> To: "d.nix" X-Mailer: Apple Mail (2.1510) Cc: perpass@ietf.org Subject: Re: [perpass] Traffic analysis X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 10:49:45 -0000 --Apple-Mail=_920B7C5E-B880-4CEC-AF27-9EBC8787F824 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 30 Sep 2013, at 8:10 , "d.nix" wrote: > On 9/29/2013 10:35 PM, Christian Huitema wrote: >=20 > > Traffic analysis proceeds through the collection of "meta data" > > such as ip headers, e-mail headers, and other forms of signaling, > > e.g. SIP headers. DNS traffic analysis also falls in that category. > > Such data is easy to harvest by monitoring big conduits such as > > backbone links or submarine cables. In some countries, the data is > > collected by forcing traffic through a single exchange or through > > some form of "national firewall." > >=20 > > The current internet protocols and applications pay very little > > attention to traffic analysis. We should obviously take the easy > > steps, encrypt the DNS, e-mail and SIP connections. But when it > > comes to IP header analysis, we have pretty few solutions. VPN, of > > course, but that requires configuration. Could we change that? > >=20 >=20 > I feel in general, that while we can go a long way towards making > content encryption easier and more robust, and simple to use for non > tech savvy users (ie, your parents, aunts, uncles, etc...), *the* > single largest issue is traffic analysis of message headers. >=20 > While there are legit concerns by people to troubleshoot and to > identify sources of spam and bulk mail, it's just entirely too easy to > build up graphs of communication patterns and who is contacting who > and when they are doing it. While traffic analysis can be applied to several areas of investigation, = this is the most directly relevant to "intelligence gathering", and can = be defended against as you say: prevent leakage of identifying = information (which you must be _very_ good at if defense against = identification and association is to work -- one weak observable link = and you might as well have done nothing). > VPN's are a possibility, but as you say, > require careful configuration and setup to prevent leakage of > identifying information. Tech that purports to secure or privatize > your communication but that actually leaks - or worse, can be coerced > into revealing your traffic, is worse than no tech at all. >=20 > Mix networks, anonymous remailers, and alternative / out of band > systems start looking worthy of a lot more study. These are good architectural defenses against association attacks, but = come with (often high) bandwidth and latency costs, as well as = additional operating expenses. Another area of investigation is behavioral classification and = fingerprinting: associating given encrypted traffic with an underlying = protocol or activity. The old SSH keystroke timing attack [1] worked = this way, as well as related identification attacks on anonymized trace = data [2]. This is a completely different type of attack. Defense = requires fingerprint resistance built into the protocol design: in an = end-to-end, point-to-point encrypted communication system which, as most = protocols _implicitly_ are, is optimized somewhere close to the = minimal-bandwidth/minimal-latency curve, the presence of traffic on the = wire means "someone's using the system", which given access to other = information can be enough to answer interesting questions about = associations. Fingerprint resistance necessarily pushes the protocol away from this = curve (with associated costs both in bandwidth and latency), and must = also be done with attention to detail. Even Skype, a protocol which = resists classification to resist blocking by ISPs which provided access = to its customers while competing with it, left a signal reasonably well = visible in flow data as part of its client association process [3] as of = 2011, which at least allowed a single-flow identification of clients and = supernodes. So, I've been thinking about traffic analysis resistance recently (as I = suppose a lot of people have :) ) and the question starts coming down to = how much resistance for what cost, and is there a point at which we can = get a significant win in the face of pervasive surveillance before the = point in the cost benefit curve in which we start giving up things we'd = really like to keep (acceptable latency/jitter for voice/video, = acceptable bandwidth for a given cost, identification and prevention of = email abuse, etc.) Best regards, Brian [1] Song et al "Analysis of Keystrokes and Timing Attacks on SSH", = USENIX Security 2001 [2] Coull et al, "Playing Devil=92s Advocate: Inferring Sensitive = Information from Anonymized Network Traces", NDSS 2007 [3] Trammell et al, "Identifying Skype Traffic in a Large-Scale Flow = Data Repository", TMA 2011 > Dave Nix >=20 > BM-2D9jC7gYDpnfprbSXuTCGr6a2DsCAXssAc (bitmessage) >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_920B7C5E-B880-4CEC-AF27-9EBC8787F824 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSSVc+AAoJENt3nsOmbNJcKzAIAIjgbnxjyAO+FizUbA8hWCGB QalS2YYzesjQ0irzAcIp7nL2Mlj3ooM0KbQ8CyDS03flXJk15KMgL9wJiBa39PNn 6J49jRY4mSg0t1ALVzxVNI9h/6bXB4vJ8kwrUEwtc4ov7wiX4fme0wR2vh0teGFO t9E8doZluu9RHqqdk7ka+KL0lyponQsGxroLCs4uiZW1lzoU/0FCISpuzRYOK+/D 99E1Sb3M/A1e5owklVDrgcV6sDFOKZX5vVx0qGjGnfIZi5tAaOhoLAEDdVRTAFZH 2JB/Xebz59RYTqBHbOV2wuJ06Y8g4TVna3BgMh/hMxvLY1dCMqNjoDXCxLRx+MU= =+6oz -----END PGP SIGNATURE----- --Apple-Mail=_920B7C5E-B880-4CEC-AF27-9EBC8787F824-- From brian.e.carpenter@gmail.com Mon Sep 30 13:02:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B8F21F9DF0 for ; Mon, 30 Sep 2013 13:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z65wXHQCvP9W for ; Mon, 30 Sep 2013 13:02:01 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F04F621F9A61 for ; Mon, 30 Sep 2013 13:02:00 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so6136906pdj.31 for ; Mon, 30 Sep 2013 13:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0VOR5e+/PLrANVqYaWhWOHOTyDTU7mS9Dx1lxHziTVQ=; b=i80kPIvBzE5uFSDHjf9D37mwM8Ld0CHml85JuxY29OI60lZixOUZ31w+/BpurySuQ8 W9HJv7ccE8Q3aQ1gufHRIq7dkTDkJVG+lfRORtAL2SQF0boKAhszsPXhvO0Eq9JRkjMg R4q2hnzyu9YUGYGWa9aGlnA89TTuR5GmapkqJ1wBXDVae2f+8nrAYRtqHE1vOVfg3pBv B0F332wp7ulrF2WuNQed2WIGbA9qxd5jbvS5Af7LH42T0NnbN3N4IUemfHQam7vtrmUg DP6DsB8wN4keVlNZ5bHzEBosL7CQbV4IqhHZ1l7w5Exc2+iTpE/4mv3sSpK0a/dsh1Qv 7Liw== X-Received: by 10.66.168.7 with SMTP id zs7mr4874783pab.152.1380571320595; Mon, 30 Sep 2013 13:02:00 -0700 (PDT) Received: from [192.168.178.20] (54.196.69.111.dynamic.snap.net.nz. [111.69.196.54]) by mx.google.com with ESMTPSA id ed3sm2444929pbc.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 13:01:59 -0700 (PDT) Message-ID: <5249D8B5.5050401@gmail.com> Date: Tue, 01 Oct 2013 09:01:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Huitema References: <02c001cebd9e$d5af4900$810ddb00$@huitema.net> In-Reply-To: <02c001cebd9e$d5af4900$810ddb00$@huitema.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'perpass' Subject: Re: [perpass] Traffic analysis X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 20:02:02 -0000 On 30/09/2013 18:35, Christian Huitema wrote: ... > The current internet protocols and applications pay very little attention to > traffic analysis. We should obviously take the easy steps, encrypt the DNS, > e-mail and SIP connections. But when it comes to IP header analysis, we have > pretty few solutions. VPN, of course, but that requires configuration. Could > we change that? Jon Crowcroft suggested a nice idea a few years ago, although for a different reason: sourceless network architecture (yes, a pun on SNA). Send packets with no source address, and you make the metadata much less useful. (Of course, if the packet is to get a reply, the source address needs to be encrypted in the payload.) As a retro-fit, this is a bit tricky - you'd probably have to set a dummy source address, and that would have to be one that would not get filtered. www.cl.cam.ac.uk/~jac22/talks/sna.ppt Brian From mdietf@demmers.org Mon Sep 30 13:52:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE821F9E6B for ; Mon, 30 Sep 2013 13:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_50=0.001, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpmsC0yd55Vv for ; Mon, 30 Sep 2013 13:52:01 -0700 (PDT) Received: from remote.demmers.org (mdemmers.virt.spiritone.com [216.99.193.151]) by ietfa.amsl.com (Postfix) with ESMTP id A9A2A21F84B7 for ; Mon, 30 Sep 2013 13:52:01 -0700 (PDT) Received: from cicero.demmers.org ([50.45.172.144]) by remote.demmers.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8UKpsPM007809 for ; Mon, 30 Sep 2013 13:51:55 -0700 Date: Mon, 30 Sep 2013 13:51:50 -0700 From: Mike Demmers To: Perpass List Submit Message-ID: <20130930135150.23771137@cicero.demmers.org> In-Reply-To: <524343B5.8010808@cs.tcd.ie> References: <20130925110934.464c7592@cicero.demmers.org> <524343B5.8010808@cs.tcd.ie> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [perpass] A proposal for developing PRISM-Proof email (default deny) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 20:52:23 -0000 Some more thoughts on default deny for encrypted email. (Sorry about the length, I am known for that). I am interested in this because I think Ned has it exactly right: Users are simply not going to put up with encryption that results in (from what I see on my servers) 100 times or more the amount of spam. And if ALL email is encrypted, we will be directly attacking the large services business models: they will fight this tooth and nail and that is a fight I doubt we can win. Email is one of the most used services, along with the web and dns. It is also the closest to someones 'letters and papers', the stuff we would like to be private. Transport level encryption only is not going to solve this as there are too many bad actors in between. We cannot just let this go. So some sort of compromise is needed. I don't know if this is the -best- idea, but if not this, what? The likely result of this would be that people encrypt mail to their friends, family, and maybe work, but not for things like Amazon orders. Since the large services are really more interested in what I want to buy than my notes to my children, this should accommodate their needs to show me better ads, etc. And they would be wise to support something like this, since the alternative may be, increasingly, 'all email encrypted by default'. The best way to see the flaws in an idea is to actually try to implement it. So I have been going through the steps (mentally only, so far) to do this. I had a look at RFC-5321 (apparently 821 is out of date ;-) ). There is no need to mess with 'HELO' 'EHLO'. There is already a mechanism for adding extended commands, that is what EHLO is all about [insert sound of palm slapping head here]. IANA maintains the list at http://www.iana.org/assignments/mail-parameters and there is a clear process to add new commands. I realized there is another clear use case than default rejection of encrypted, mail - it is the exact opposite of this. If you are in an environment that must be REALLY secure, say, a defense contractor, etc., you might want to force ALL email to be encrypted, and reject all others. But humans make errors, so it might be useful to have a situation where all unencrypted email is rejected, and only encrypted email would be allowed to be sent. If done by the server (in this case the server acting as the submission server), a user who accidentally had encryption turned off would get an immediate rejection and be unable to send the email at all - this is much better than say, filtering, where the email (between offices, say) would have gone out in the clear before being rejected. Another realization I had was that if used as described below, this actually creates a user controllable mechanism for default deny even on unencrypted emails, since the MTA just believes what the MUA tells it about the status of the email. The user just needs to lie about whether the email is encrypted. While seemimgly useless, this could actually have some use in filtering. TThe basic concept of default deny for encrypted emails only seems very 'right' to me, because if you are going to the trouble to do this, and handle things like key exchanges, that communication must be pretty special to begin with. Why would you want 'just anyone' to be able to send you encrypted emails? So the problem boils down to this: 1. To create a way for the information that an email is encrypted by the MUA (Mail User Agent or other source) to be passed to the MTA, and all succeeding MTAs, and for the MTA (relay, submission agent, etc.) to be able to make delivery or other decisions on the basis of that status. 2. Additionally, there must be a way for users to whitelist or blacklist email, on a per user basis, and have the MTA be able to make use of those lists. Ideally we could make some new commands and all the MTAs and MUAs would ugrade and everything would be wonderful. Of course that is not how the real world (or the internet) actually works, so we must deal with that reality. There will always be a mix of upgraded and not upgraded systems. There are many different MUAs (hundreds ?), but really just a FEW (maybe 6 or so?) MTAs in common use. The MTAs also tend to be run by businesses, with system administrators, and be upgraded relatively frequently, especially compared to the users mail programs. So it would make sense to put as much of the functionality and changes needed into the MTAs, and even better have a way to use this system even if the users MUA does not support it yet. There should also be a way to handle the situation where an MTA in between two other MTAs that are updated is not, so the information would be lost. So, walking through this step by step: The first problem is how the information that an email is encrypted get passed to the MTA? We would have a new extended mail command registered, perhaps 'PRECRYPTED'. The user agent engages in the submission dialog, with EHLO, if that is ok (meaning the MTA understands extended mail commands), it issues PRECRYPTED (meaning the next message is encrypted by the MUA). If the MTA gives an error at that point, the MUA knows it does not understand this command and proceeds accordingly. Now, what if the NUA does not yet understand this setup, a likely scenario at first? How can the user tell the MTA that an email is encrypted? I suggest two ways. Many MUAs allow the user to set headers. So we have some standard headers that indicate this. Something like: ENCRYPTION: MUA which indicates 'the message has been previously encrypted by the user'. Other things might be on the right side, such as 'TRANSPORT' meaning use transport level encryption for this message if available, or -require- transport level encryption. Or perhap some other use. That would be a required header. Another, optional header might be something like: ENCRYPTION-TYPE: PGP Optional, because the user may not want to make that information available. Now we need one rule for the updated, aware MUA: If it is going to indicate an email is previously encrypted, it MUST also add an ENCRYPTION:MUA header. (This covers the case where only the originating MUA and the last MTA are updated, see below.) Ok, so what if the users MUA doesn't even allow for adding headers? Thanks again to Ned for reminding me of this by his use of a plussed address (ned+perpass). We have a standard 'plussed' address of '+precrypted' which means the email is encrypted. So our user with a really dumb email program may simply adds this to his email that is encrypted to insure it will get through. Now let's add some rules for the MTA: If an MTA is informed by any means that an email is previously encrypted, it MUST updates its status, and insure that the email contains the ENCRYPTION: MUA header, creating it if necessary. And it MUST do this at any stage in the process. (not just upon submission). What this does in handle the case where there are two updated MTAs, but one in the middle relaying is not, and some other errors or special cases. The above is part of addressing the second problem, which is how we insure the encypted status of an email is passed on between MTAs. Here we may have a mixture of updated and non-updated MTAs. If the above rules are followed, in the end, only the LAST MTA, the one that is delivering the emails to local users, has to be updated. That last MTA is either going to have the status passed to it by an updated MTA, or see an ENCRYPTION:MUA header, or see a plussed address, in which case it will follow the rules and treat the email as previously encrypted, also adding the header. The net result of the above is that, for example, a business might only upgrade THEIR MTA, and get the full anti-spam and other benefits of this system. So there is an immediate benefit to the users even if no one else on the internet has upgraded yet. The actual MTA to MTA mail transaction is slightly tricky, as we need to be able to accept or deny based upon the sender, and specifying the sender is the very first transaction in an individual mail submission. MAIL FROM:sombody@somewhwere.com So the status of whether a mail transaction is for an encrypted email needs to be known before that point. Sendmail has a way to delay that check, but this is configurable so cannot be counted on. So I think the way to go here is to use PRECRYPTED as a mode that can be turned on or off. That would also make sending a series of encrypted emails more efficient, since the command would only need to be made once for the block of emails. So we would be looking at something more like: EHLO mail.example.com 220 Howdy there mail.example.com. uptodate-mail V2.1.0 ready for your command. PRECYPTED ON 2xx OK Precrypted mode ON, expecting encrypted emails. MAIL FROM:sombody@somewhwere.com 250 Precrypted Sender OK RCPT TO:goofy@updated.com 250 Recipient OK ... PRECYPTED OFF 2xx OK Precrypted mode OFF expecting normal email ... send normal mail I think I have most of the edge cases covered, but if not, the result would be that an encrypted email is accepted, because the system thinks it is ordinary mail. This can then be dealt with by normal filtering, which, while it may not be able to read the email, should be at least able to recognize an encrypted email, and dump it or otherwise do something sensible. The final problem is the user must be able to communicate whitelists and/or blacklists to the local receiving MTA. This gets pretty system and MTA specific. As I previously mentioned, I doubt this will be much of a problem for large services, since they already are storing loads of metadata in databases, etc. For medium and small systems, it might to be useful to have a somewhat standardized system. For unix style systems and sendmail (using this only because it is what I am most familiar with) I might do something like this: Each user dir has a .mailwhitelist and .mailblacklist file which just contains the raw email addresses. In addition, there is one more file that is the result of putting those lists into the specific format used by the specific MTA in use. So the standarization here is: standard format whitelist and blacklist files (which could also be used by another program, such as spamassassin or procmail), plus an MTA dependent file in that MTAs proper format. So for example with sendmail, it uses /etc/mail/access, so that file in the userdir might be .access. In Sendmails case, what actualy happens is that the access file is where the user puts blocks, etc, but that file must be compiled into a database for actual use by the sendmail program, access.db. Often there is a makefile or similar way that is updated, so the actual addition of the local users whitelists to the main MTA list would be done by that makefile or similar means. In the actual access file itself, Sendmail would need to add the capability to distinguish pre-encryped email in its rules. Currently, for normal email I could make a default deny mode with something like: To:mdeitf@demmers.org REJECT From:joe@example.com OK From:mary@example.com OK which would allow me to receive only mail from those two users. So maybe using something like: To_Precrypted:mdeitf@demmers.org REJECT From_Precrypted:joe@example.com OK From_Precrypted:mary@example.com OK would work well. And we may as well throw in Connect_Precrypted: as well, which will allow for whitelisting by connecting address, domain, etc. I mention above the users should have individual control of whitelists, however, since this is primarily a spam control measure, that is probably not really necessary in the sense of 'only my whitelist applies to me'. It does not really matter if Mary in accounting has whitelisted 'cosultant@accounting.com', since that person will not be a spammer, and will never email me anyway. If they did, I would be unable to read the email since I would not have exchanged keys with them. Normal mail filters could just drop it as well. It is crytal clear that NSA and other state actors are treating encrypted email differently, I even saw a comment by some senator to the effect that 'if you are using encryption, you are proabably a terrorist or criminal'. So until encryption is very commonly used, it might be said that 'Unless everyone has privacy, no one does'. It is not enough to just provide easy ways for people to use encryption, we must actually get them to USE it. Even now, with all the revelations, something like 40 percent of the people seem to not care that NSA etc are collecting, analyzing, and possibly reading their emails. What people pretty much universally DO care about is spam. So I think this is a real sales point to get people to actually USE encryption: 'If you use encryption, you will get NO spam to those accounts, plus have privacy.' Something not really covered here is that I think there should be some guidelines for MUAs concerning standardizing the interface to this. Standard names for functions like adding someone as an encryption only person ('friend'), that MUAs should have standard ways to handle key exchange, etc. But this message is way too long already. So what do you think? Good idea? Flaws to fix? Have a better idea to solve the problem? -Mike Demmers From huitema@huitema.net Mon Sep 30 14:25:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC46421F8B35 for ; Mon, 30 Sep 2013 14:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa+qsmMkrgKW for ; Mon, 30 Sep 2013 14:24:48 -0700 (PDT) Received: from xsmtp12.mail2web.com (xsmtp32.mail2web.com [168.144.250.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0E13621F8E3D for ; Mon, 30 Sep 2013 14:24:46 -0700 (PDT) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VQkxQ-0003na-Io for perpass@ietf.org; Mon, 30 Sep 2013 17:24:45 -0400 Received: (qmail 5143 invoked from network); 30 Sep 2013 21:24:39 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[131.107.192.112]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Sep 2013 21:24:38 -0000 From: "Christian Huitema" To: "'Brian E Carpenter'" References: <02c001cebd9e$d5af4900$810ddb00$@huitema.net> <5249D8B5.5050401@gmail.com> In-Reply-To: <5249D8B5.5050401@gmail.com> Date: Mon, 30 Sep 2013 14:24:37 -0700 Message-ID: <004401cebe23$786e9950$694bcbf0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQI82vRusUl0F61GuyV3qv2zmihuHAJfxLC+mO+RkQA= Content-Language: en-us Cc: 'perpass' Subject: Re: [perpass] Traffic analysis X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 21:25:03 -0000 > Jon Crowcroft suggested a nice idea a few years ago, although for a different reason: > sourceless network architecture (yes, a pun on SNA). > > Send packets with no source address, and you make the metadata much less useful. > (Of course, if the packet is to get a reply, the source address needs to be > encrypted in the payload.) > > As a retro-fit, this is a bit tricky - you'd probably have to set a dummy source > address, and that would have to be one that would not get filtered. > > www.cl.cam.ac.uk/~jac22/talks/sna.ppt There may be a halfway measure that is simpler to implement than just zeroing the IP address. Something along the lines of the IPv6 "privacy" addresses. If the source address that I use changes often, then the correlation of traffic over time becomes more difficult. Of course, the IPv6 privacy addresses only randomizes the lower 64 bits of the address, leaving the top 64 as a perfectly stable reference for correlation. But if the ISP cooperates, maybe we can get the top 64 bits to also change often. -- Christian Huitema