From stephen.farrell@cs.tcd.ie Tue Nov 1 04:30:57 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D4E21F8E9C for ; Tue, 1 Nov 2011 04:30:57 -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 uM5gVDBOpkFv for ; Tue, 1 Nov 2011 04:30:57 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E7BBE21F8E4F for ; Tue, 1 Nov 2011 04:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4083A16FBCB; Tue, 1 Nov 2011 11:30:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1320147054; bh=vc6bT1HlnGjTjA r36Xun4iuTh7n5bfaSHW7OGaUaUh4=; b=nectjWpO8jtBAF1sz/FW+f74PqDmkn ulPT9+RZSVA1aae2SJ5GqV2p4YlnGhw3okePnWtYWsIGpN0Y3YJ0sRmt93wYOMo6 ZTOZLIEuPqVIbeXJ0Skucr6fwgcDJ8oEHZFUyBjGBLVl7VqZ38v2wo888MWUON4o eCvYmDe91feHjP3sYm7uLcaGCuEtAxF6ZKAOArGcwXLYSBgCqr/5BVPnuKrYf66u ZtBfqWK2ePHHDo09trG83Pns/orQ+YBSiTjjy4M/ksmybkym8S1PWHCRTQ/3apje 0j/5fU+SZeuWgMpceKoOoG74QmKw8+UttDVVonMlM0haWUNlA+hs42TQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id kZICln0cLR9j; Tue, 1 Nov 2011 11:30:54 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 08FC1153633; Tue, 1 Nov 2011 11:30:52 +0000 (GMT) Message-ID: <4EAFD861.6040007@cs.tcd.ie> Date: Tue, 01 Nov 2011 11:30:41 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ted Hardie References: <4EA981A9.2080200@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: privacydir@ietf.org Subject: Re: [privacydir] request for a SAVI doc review X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 11:30:58 -0000 Hi Ted, I've also had a read of this now and agree with you. I'm putting in a discuss that says: "This makes no mention at all of privacy which I think needs to be there somewhere. Given that Joel is planning to add text on that to savi-threats I'd be fine if that is just referenced from here, or even if that text is moved from savi-threats to this document, and savi-threats could refer to it here. But the privacy implications of SAVI do need to be covered here too." I think that ought be ok since I expect Joel to do a good job on this in the savi-threats document. I also put in a link to your mail as a comment. Let me know if you think that more or something else is likely to be needed. Thanks again for the review, S. On 10/31/2011 08:07 PM, Ted Hardie wrote: > Hi Stephen, > > I've read through the framework document. My baseline impression is that > the document makes a presumption about the relationship between the host > and the network employing SAVI that is true when it is the access network > (that is, the network assigning the IP address to be verified). In that > deployment scenario, it is expected for the network to be able to associate > layer two identifiers with the layer 3 identifier (after all, it must to be > able to deliver return traffic). > > What's not clear to the naive reader (read: me) is how you prevent SAVI > from operating from other parts of the network; that is, how does the > overall framework guard against SAVI being used by some later network > on-path getting access to these bindings? I assume that this is detailed > elsewhere in the protocol documents, but I believe a short discussion of > the privacy threat in framework, along with a pointer to the protocol > mechanism would be valuable. > > If the expectation is that SAVI can operate from multiple places in the > network (including, say, the destination network), then I believe there is > a more serious privacy concern. > > regards, > > Ted Hardie > > On Thu, Oct 27, 2011 at 9:07 AM, Stephen Farrell > wrote: > >> >> Hi, >> >> There's a SAVI document [1] on the Nov 3 telechat. I'd appreciate >> a review of that from a privacy perspective if someone has the >> time in the next week. (Just reply to this if you've time.) >> >> Previous SAVI documents have generated privacy related >> DISCUSSes [2,3] which may be useful background. >> >> Thanks in advance, >> S. >> >> [1] https://datatracker.ietf.org/**doc/draft-ietf-savi-framework/ >> [2] https://datatracker.ietf.org/**doc/draft-ietf-savi-fcfs/ >> [3] https://datatracker.ietf.org/**doc/draft-ietf-savi-threat-**scope/ >> >> ______________________________**_________________ >> privacydir mailing list >> privacydir@ietf.org >> https://www.ietf.org/mailman/**listinfo/privacydir >> > From ted.ietf@gmail.com Tue Nov 1 07:56:56 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210A921F997D for ; Tue, 1 Nov 2011 07:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, 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 iC1We2vTnaLl for ; Tue, 1 Nov 2011 07:56:55 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 404DD21F997B for ; Tue, 1 Nov 2011 07:56:55 -0700 (PDT) Received: by gyh20 with SMTP id 20so8546591gyh.31 for ; Tue, 01 Nov 2011 07:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i++5kWxwLOhP2zCUrY/IHxGG06i8qnlssiw5G6BhIlQ=; b=p7l/2lQrt1zOsYzo4CJ6JOAE9XU+yd2QsICsgvNd3MOhVJOVlD9oOCCkIgqPl5sKOS Y5U/WKEN/5poXAK21C+lPIUlUYtmZ4UzXjJZbYrkNRC+xKGP2WYcRqqMDhh2H5ET0ZA5 i7yrsG1iaCcwCjP62uu3xbb3sMpnEAjuGe0mc= MIME-Version: 1.0 Received: by 10.236.131.80 with SMTP id l56mr3888184yhi.109.1320159408996; Tue, 01 Nov 2011 07:56:48 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Tue, 1 Nov 2011 07:56:48 -0700 (PDT) In-Reply-To: <4EAFD861.6040007@cs.tcd.ie> References: <4EA981A9.2080200@cs.tcd.ie> <4EAFD861.6040007@cs.tcd.ie> Date: Tue, 1 Nov 2011 07:56:48 -0700 Message-ID: From: Ted Hardie To: Stephen Farrell Content-Type: multipart/alternative; boundary=20cf300e55d79ec1ca04b0ad90fe Cc: privacydir@ietf.org Subject: Re: [privacydir] request for a SAVI doc review X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 14:56:56 -0000 --20cf300e55d79ec1ca04b0ad90fe Content-Type: text/plain; charset=ISO-8859-1 Hi Stephen, This sounds fine to me, regards, Ted On Tue, Nov 1, 2011 at 4:30 AM, Stephen Farrell wrote: > > Hi Ted, > > I've also had a read of this now and agree with you. I'm putting > in a discuss that says: > > "This makes no mention at all of privacy which I think needs to > be there somewhere. Given that Joel is planning to add text on > that to savi-threats I'd be fine if that is just referenced from > here, or even if that text is moved from savi-threats to this > document, and savi-threats could refer to it here. But the > privacy implications of SAVI do need to be covered here too." > > I think that ought be ok since I expect Joel to do a good > job on this in the savi-threats document. I also put in a link > to your mail as a comment. > > Let me know if you think that more or something else is > likely to be needed. > > Thanks again for the review, > > S. > > > On 10/31/2011 08:07 PM, Ted Hardie wrote: > >> Hi Stephen, >> >> I've read through the framework document. My baseline impression is that >> the document makes a presumption about the relationship between the host >> and the network employing SAVI that is true when it is the access network >> (that is, the network assigning the IP address to be verified). In that >> deployment scenario, it is expected for the network to be able to >> associate >> layer two identifiers with the layer 3 identifier (after all, it must to >> be >> able to deliver return traffic). >> >> What's not clear to the naive reader (read: me) is how you prevent SAVI >> from operating from other parts of the network; that is, how does the >> overall framework guard against SAVI being used by some later network >> on-path getting access to these bindings? I assume that this is detailed >> elsewhere in the protocol documents, but I believe a short discussion of >> the privacy threat in framework, along with a pointer to the protocol >> mechanism would be valuable. >> >> If the expectation is that SAVI can operate from multiple places in the >> network (including, say, the destination network), then I believe there is >> a more serious privacy concern. >> >> regards, >> >> Ted Hardie >> >> On Thu, Oct 27, 2011 at 9:07 AM, Stephen Farrell >> **wrote: >> >> >>> Hi, >>> >>> There's a SAVI document [1] on the Nov 3 telechat. I'd appreciate >>> a review of that from a privacy perspective if someone has the >>> time in the next week. (Just reply to this if you've time.) >>> >>> Previous SAVI documents have generated privacy related >>> DISCUSSes [2,3] which may be useful background. >>> >>> Thanks in advance, >>> S. >>> >>> [1] https://datatracker.ietf.org/****doc/draft-ietf-savi-**framework/ >>> >>> > >>> [2] https://datatracker.ietf.org/****doc/draft-ietf-savi-fcfs/ >>> >>> > >>> [3] https://datatracker.ietf.org/****doc/draft-ietf-savi-threat-**** >>> scope/ >>> >>> > >>> >>> ______________________________****_________________ >>> privacydir mailing list >>> privacydir@ietf.org >>> https://www.ietf.org/mailman/****listinfo/privacydir >>> >>> > >>> >>> >> --20cf300e55d79ec1ca04b0ad90fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Stephen,

This sounds fine to me,

regards,

Ted
On Tue, Nov 1, 2011 at 4:30 AM, Stephen Farrel= l <stephe= n.farrell@cs.tcd.ie> wrote:

Hi Ted,

I've also had a read of this now and agree with you. I'm putting in a discuss that says:

"This makes no mention at all of privacy which I think needs to
be there somewhere. Given that Joel is planning to add text on
that to savi-threats I'd be fine if that is just referenced from
here, or even if that text is moved from savi-threats to this
document, and savi-threats could refer to it here. But the
privacy implications of SAVI do need to be covered here too."

I think that ought be ok since I expect Joel to do a good
job on this in the savi-threats document. I also put in a link
to your mail as a comment.

Let me know if you think that more or something else is
likely to be needed.

Thanks again for the review,

S.


On 10/31/2011 08:07 PM, Ted Hardie wrote:
Hi Stephen,

I've read through the framework document. =A0My baseline impression is = that
the document makes a presumption about the relationship between the host and the network employing SAVI that is true when it is the access network (that is, the network assigning the IP address to be verified). =A0In that<= br> deployment scenario, it is expected for the network to be able to associate=
layer two identifiers with the layer 3 identifier (after all, it must to be=
able to deliver return traffic).

What's not clear to the naive reader (read: me) is how you prevent SAVI=
from operating from other parts of the network; that is, how does the
overall framework guard against SAVI being used by some later network
on-path getting access to these bindings? I assume that this is detailed elsewhere in the protocol documents, but I believe a short discussion of the privacy threat in framework, along with a pointer to the protocol
mechanism would be valuable.

If the expectation is that SAVI can operate from multiple places in the
network (including, say, the destination network), then I believe there is<= br> a more serious privacy concern.

regards,

Ted Hardie

On Thu, Oct 27, 2011 at 9:07 AM, Stephen Farrell
<stephen.= farrell@cs.tcd.ie>wrote:


Hi,

There's a SAVI document [1] on the Nov 3 telechat. I'd appreciate a review of that from a privacy perspective if someone has the
time in the next week. (Just reply to this if you've time.)

Previous SAVI documents have generated privacy related
DISCUSSes [2,3] which may be useful background.

Thanks in advance,
S.

[1] https://datatracker.ietf.org/**doc/draft-ietf-s= avi-framework/<https://datatracker.ietf= .org/doc/draft-ietf-savi-framework/>
[2] https://datatracker.ietf.org/**doc/draft-ietf-savi-f= cfs/<https://datatracker.ietf.org/doc/draft-= ietf-savi-fcfs/>
[3] https://datatracker.ietf.org/**doc/draft-i= etf-savi-threat-**scope/<https://datatracke= r.ietf.org/doc/draft-ietf-savi-threat-scope/>

______________________________**_________________
privacydir mailing list
privacydir@ietf.or= g
https://www.ietf.org/mailman/**listinfo/privacydir<= https://www.ietf.org/mailman/listinfo/privacydir>



--20cf300e55d79ec1ca04b0ad90fe-- From turners@ieca.com Sat Nov 12 23:40:09 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E311E80C0 for ; Sat, 12 Nov 2011 23:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.284 X-Spam-Level: X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, 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 Fwox3Q3+czdz for ; Sat, 12 Nov 2011 23:40:08 -0800 (PST) Received: from gateway.websitewelcome.com (gateway09.websitewelcome.com [67.18.14.9]) by ietfa.amsl.com (Postfix) with ESMTP id C029A11E8093 for ; Sat, 12 Nov 2011 23:40:08 -0800 (PST) Received: by gateway.websitewelcome.com (Postfix, from userid 507) id D3159534674FE; Sun, 13 Nov 2011 01:40:07 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway.websitewelcome.com (Postfix) with ESMTP id C38F1534674BB for ; Sun, 13 Nov 2011 01:40:07 -0600 (CST) Received: from [130.129.21.152] (port=51433 helo=dhcp-1598.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RPUff-00075h-BM for privacydir@ietf.org; Sun, 13 Nov 2011 01:40:08 -0600 Message-ID: <4EBF7455.3020200@ieca.com> Date: Sun, 13 Nov 2011 15:40:05 +0800 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: privacydir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-1598.meeting.ietf.org [130.129.21.152]:51433 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [privacydir] request for CSI doc review X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 07:40:09 -0000 Hi, There's a CSI document [1] on the Dec 1st telechat. I'd appreciate a review of that from a privacy perspective if someone has the time in the next two weeks. (Just reply to this if you've time.) My basic issue with this draft is that CGAs [2] have a privacy property. Centrally generating them means that this privacy property is being removed. Thanks in advance, spt [1] https://datatracker.ietf.org/doc/draft-ietf-csi-dhcpv6-cga-ps/ [2] https://datatracker.ietf.org/doc/rfc3972/ From william.polk@nist.gov Mon Nov 14 13:43:26 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F27811E8100; Mon, 14 Nov 2011 13:43:26 -0800 (PST) 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 GH0rNqk9WOfk; Mon, 14 Nov 2011 13:43:25 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 036D211E80FB; Mon, 14 Nov 2011 13:43:25 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 14 Nov 2011 16:43:19 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 14 Nov 2011 16:43:22 -0500 From: "Polk, William T." To: "saag@ietf.org" , "secdir@ietf.org" , "privacydir@ietf.org" Date: Mon, 14 Nov 2011 16:38:50 -0500 Thread-Topic: Meeting on Privacy-Enchancing Cyrptography: Dec 8-9, 2011 Thread-Index: Acyi2ZH/n8Sl1c/cTRSiJ2hP8952JAAPDpR4 Message-ID: References: In-Reply-To: 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" MIME-Version: 1.0 Subject: [privacydir] FW: Meeting on Privacy-Enchancing Cyrptography: Dec 8-9, 2011 X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:43:26 -0000 FYI - I thought this meeting at NIST would be of interest to some on these lists. Thanks, Tim Polk ________________________________________ From: Caswell, Sara J. Sent: Monday, November 14, 2011 9:27 AM To: Polk, William T. Subject: Meeting on Privacy-Enchancing Cyrptography: Dec 8-9, 2011 Meeting on Privacy-Enhancing Cryptography: "Working with encrypted data without decrypting" December 8-9, 2011 NIST Gaithersburg, Maryland USA This workshop will discuss how modern cryptographic techniques can help protect privacy in an environment where many players are collaborating and competing as consumers and producers of digital goods and services. Among the discussion topics are medical databases, on-line auctions, privacy-friendly smart-meters, and identity management as envisioned by the National Strategy for Trusted Identities in Cyberspace. The target audience is industry, the research and academic communities, and Government. Registration Fee: $165.00 USD (Registration deadline December 1) Additional details can be found at: http://www.nist.gov/itl/csd/ct/pec-workshop.cfm From stephen.farrell@cs.tcd.ie Mon Nov 14 14:56:39 2011 Return-Path: X-Original-To: privacydir@ietfa.amsl.com Delivered-To: privacydir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3443211E8250 for ; Mon, 14 Nov 2011 14:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.038 X-Spam-Level: X-Spam-Status: No, score=-100.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=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 tk6dpMQy62OP for ; Mon, 14 Nov 2011 14:56:38 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9044111E80D6 for ; Mon, 14 Nov 2011 14:56:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 03B501535E7 for ; Mon, 14 Nov 2011 22:56:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1321311396; bh=2vgOq5d6vglGfW 9gTk/+Ib6kDZDdsv09yoEG69SXI00=; b=JCosz0/HipjQofFQjm78WBXvmUDo7s fz5e5ppA7aV+1T1zHkS5xcyp7lO5bLdKmJoTEOIqtHqWgEsnwYmF5GZeTwHuV1Nq JdWvVtt2jspkkIP4I+VAw5wb3jjZ3OExRJh0BjGBQa5tXJ/hHYFGH6ZNUmLzqZH0 HsMymb/fDtcZ93diHjrhjl66fmxaEzghgBjWolS0Z26bUicna0MjYbolImMjqyZ+ 99dSM2aU5Yp8iHWxq4aeo9RVYsHt12BK2rGvvbqEBaPXTMEiXHlUwwOPquD5KY7G uFgrPOCStQGHNkDoGxeMJkGUZ3Be+4wS9JnPYgdK9iCFl6V2vRKvRcNw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id GYEvpWVUg8c4 for ; Mon, 14 Nov 2011 22:56:36 +0000 (GMT) Received: from [192.168.0.55] (61-230-53-171.dynamic.hinet.net [61.230.53.171]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2C168171C64 for ; Mon, 14 Nov 2011 22:56:35 +0000 (GMT) Message-ID: <4EC19CA1.9000603@cs.tcd.ie> Date: Mon, 14 Nov 2011 22:56:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: privacydir@ietf.org References: <4EC19886.90809@dcrocker.net> In-Reply-To: <4EC19886.90809@dcrocker.net> X-Forwarded-Message-Id: <4EC19886.90809@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [privacydir] Fwd: Re: [domainrep] Reputation for initiators of transport connections X-BeenThere: privacydir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 22:56:39 -0000 Anyone know about/tracking this? Seems likely scary from a privacy perspective. (I mean the intarea thing, not the repute aspect.) S. -------- Original Message -------- Subject: Re: [domainrep] Reputation for initiators of transport connections Date: Tue, 15 Nov 2011 06:39:02 +0800 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking To: Pete McCann CC: domainrep@ietf.org On 11/14/2011 7:39 PM, Pete McCann wrote: > There has been discussion on the intarea list about adding identifiers > to connection establishment messages that go through Carrier Grade > NATs so that servers can assign individual reputations to the hosts > behind the NAT. One of the options being considered is to add a new > TCP option at the middlebox containing a simple integer. > > I can imagine generalizing such a feature to use domain names... Pete, Since there is some discussion, here, about annotating the source or context from which an identifier's reputation was developed, it is plausible that it would be worth considering annotating the context(s) in which it can/should be applied. The slippery slope, here, is probably the danger of moving from discussing or specifying /attributes/ about a reputation to specifying /mechanisms/ of use, beyond the query mechanism. Unless I've misread our charter, dealing with usage scenarios and mechanisms is outside our charter. d/ ps. I've no idea whether I just spoke as a chair. that probably means I didn't.. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ domainrep mailing list domainrep@ietf.org https://www.ietf.org/mailman/listinfo/domainrep