[perpass] test

Just checking if this list is still working, given a recent thread on multiple other lists might migrate here (or not;-) There's no need to reply, I'll see if this message gets to the archive. S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: O

Re: [perpass] [TLS] wiretapping draft - collecting rebuttal arguments

FYI. Contributions from folks here would be welcome if you're interested, Cheers, S. PS: This relates to ongoing discussion on the TLS list. On 11/07/17 11:48, Stephen Farrell wrote: > > Hiya, > > I've asked the chairs for a slot in Prague to allow > for rebutti

Re: [perpass] [rfc-edi...@rfc-editor.org: RFC 8164 on Opportunistic Security for HTTP/2]

On 16/05/17 15:07, Stephane Bortzmeyer wrote: > Relevant for this (quiet…) list, I think. As is RFC8165 [1]. S. [1] https://tools.ietf.org/html/rfc8165 > > > > ___ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/

Re: [perpass] privacy implications of UUIDs for IoT devices

On 14/10/16 15:55, Paul Kyzivat wrote: > > When looking at devices seen on WiFi the vendor ID is often displayed > and used to figure out which device is which, to correlate problem > symptoms with likely causes, and many other reasons. How often? Compared to how often those are uselessly sent?

Re: [perpass] privacy implications of UUIDs for IoT devices

On 06/10/16 15:09, Michael Richardson wrote: > I will volunteer, and I'll do this publically so that you'll hold me to it. > Expect it by draft cut-off date. > Excellent, thanks! S. signature.asc Description: OpenPGP digital signature ___ perpas

Re: [perpass] privacy implications of UUIDs for IoT devices

communication that is both end-to-end > encrypted and as close to metadata-hiding as possible. > > Thanks! > > Peter > > Forwarded Message > Subject: Re: [core] Implications of IP address / port changes for CoAP & Co > Date: Thu, 6 Oct 2016 00:11

Re: [perpass] New privacy work: broadcast protocols

Thanks Stephane, I hadn't seen that draft before. S On 15/09/16 15:35, Stephane Bortzmeyer wrote: > Currently in Call for Adoption in intarea, privacy issues for > broadcast protocols (remember the issue in Prague with the idea of > capturing the broadcast traffic on the IETF Wi-Fi?): > > http

Re: [perpass] Hello, list of political correctness and rambling, incoherent text

On 26/05/16 20:50, Stephane Bortzmeyer wrote: > A nice rant against us :-) > > http://www.circleid.com/posts/20160526_ietf_descent_into_the_political_rabbit_hole/ So I don't think Tony's on this list any more (or maybe he is) but he forgot to berate us for RFC1984 and Danvers. But maybe extend

[perpass] Three RFCs issued

And in the for-the-record department, yesterday the RFC editor output: RFC 7858 [1] Specification for DNS over Transport Layer Security (TLS) RFC 7844 [2] Anonymity Profiles for DHCP Clients RFC 7824 [3] Privacy Considerations for DHCPv6 I figure all three can be traced back to this list so than

[perpass] a call for papers relevant to this list

Hiya, For those of you who like to publish stuff, this CFP [1] seems like it may be of interest. Note: I've nothing to do with that call, but might consider submitting something about the fine work generated via this list, not sure if I'll have time though - if someone else does have time/energy

Re: [perpass] US intelligence chief says we might use the IoT to spy on you

On 11/02/16 15:02, Russ Housley wrote: > http://www.theguardian.com/technology/2016/feb/09/internet-of-things-smart-home-devices-government-surveillance-james-clapper?CMP=share_btn_fb > > Yeah, that's a shocker eh;-( FYI, I did try to argue for defining a padding scheme in the COSE wg [1] but n

Re: [perpass] Cops hate encryption but the NSA loves it when you use PGP

On 31/01/16 19:03, Dave Crocker wrote: > > On 1/31/2016 10:53 AM, Stephen Farrell wrote: >> Given that much >> SMTP is now transmitted over TLS, I think the opportunity >> for the likes of NSA to record all the PGP ciphertext has >> to be have been significantly di

Re: [perpass] Cops hate encryption but the NSA loves it when you use PGP

Hi Nick, I had a look at the slides and while it's hard to know from just those, I didn't see too much that was new in that so far. But maybe when you build some n/w monitoring kit there may be more to report. As far as using PGP goes, I'm nowhere near as pessimistic as it you appear to be (from

Re: [perpass] Cops hate encryption but the NSA loves it when you use PGP

Anyone got a link to Nick's slides/paper? S. On 30/01/16 16:51, Dave Crocker wrote: > Cops hate encryption but the NSA loves it when you use PGP > It lights you up like a Vegas casino, says compsci boffin > > By Iain Thomson > Jan 27 2016 >

[perpass] commentariat (was: Re: SMTP and SRV records)

subject line change... On 25/11/15 13:28, Robin Wilton wrote: > I’m sure I’m not the only one who has been depressed by a lot of the > public discourse on this topic (present list definitely excepted!), > and the lack of clarity/understanding demonstrated by much of it > (this being a lamentable

Re: [perpass] draft-josefsson-email-received-privacy

On 26/10/15 02:01, John R Levine wrote: >> That sounds like a reasonable plan. Let's start, then. What about having >> interested parties meet at a bar in Yokohama, say Monday evening, and >> start >> drafting the first solution? I would be happy to pay the first round of >> drinks, if that speed

Re: [perpass] draft-josefsson-email-received-privacy

Ned, On 22/10/15 05:27, ned+perp...@mrochek.com wrote: > In summary, the present proposal as presently written is a nonstarter because > it breaks critical email functionality: The ability to detect and block mail > loops. In also unnecessarily causes the removal of highly useful timing and > tra

Re: [perpass] Special keys let officials open any suitcase. What could go wrong?

On 26/09/15 21:57, Brian E Carpenter wrote: > http://www.economist.com/news/united-states/21665010-special-keys-let-officials-open-any-suitcase-what-could-go-wrong-locked-out > > TL;DR: RFC 1984 was right (and also applies to TSA locks). And BCP 200 is (not was) right as well:-) S > >Bri

Re: [perpass] India withdraws encryption policy - Re: India posed to require cleartext, cleartext retention, cipher and backdoor mandates

ts still hold". > > Regards, Hugo Connery -- Head of IT, DTU Environment, > http://www.env.dtu.dk From: > perpass [perpass-boun...@ietf.org] on behalf of Brian Trammell > [i...@trammell.ch] Sent: Tuesday, 22 September 2015 14:04 To: Joseph &

Re: [perpass] India withdraws encryption policy - Re: India posed to require cleartext, cleartext retention, cipher and backdoor mandates

messaging, etc. The update document seems > to have been removed, but is captured here by a news site: > > http://www.medianama.com/2015/09/223-india-draft-encryption-policy/ > > Dan > > On Sep 21, 2015, at 1:07 PM, Stephen Farrell > mailto:stephen.farr...@cs.tcd.ie>>

Re: [perpass] India posed to require cleartext, cleartext retention, cipher and backdoor mandates

Sheesh, there is so much wrong in that document. And they top it off by recommending RC4. Does anyone know if this is a policy that is likely to be enforced or one that'd be more honoured in the breach? S. On 21/09/15 17:45, Joseph Lorenzo Hall wrote: > Obviously, of relevance to those that wil

[perpass] Fwd: RFC 7619 on The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)

I think this was also initially suggested on this list, so another loop closing ceremony is due :-) Cheers, S. PS: I've not posted similarly on the DPRIVE RFC7626 as I think starting DPRIVE was the loop closing for that, but 7626 is a fine thing as well. Forwarded Message Su

[perpass] Fwd: RFC 7624 on Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement

Hiya, Just closing the loop on another bit of promised work that has been completed - well done and thanks to all who helped! And don't forget that this list is still the right place to suggest potential new bits of work the IETF could be doing in this space. (This list being where we do triage

[perpass] Fwd: Last Call: Recognising RFC1984 as a BCP

FYI. I forget if this was mentioned on here before, but it's been discussed on the saag list and at the saag session in Prague. As it says below, please send comments if any to i...@ietf.org (or exceptionally to i...@ietf.org). Thanks, S Forwarded Message Subject: Last Call:

[perpass] Fwd: [mpls] I-D Action: draft-ietf-mpls-opportunistic-encrypt-00.txt

: Adrian Farrel Stephen Farrell Filename: draft-ietf-mpls-opportunistic-encrypt-00.txt Pages : 34 Date: 2015-07-23 Abstract: This document describes a way to apply opportunistic security between adjacent nodes on an MPLS Label Switche

Re: [perpass] perpass: what next?

On 09/07/15 08:38, Stefan Winter wrote: > I'm aiming at either Stephen (as he's on the list and so is informed on > the general topic already; plus he's an eduroam user and sees .1X in > real life every day - now if he is also proud owner of an Android > device, where we've implemented the draft

Re: [perpass] Possible attack on Diffie-Hellman key exchange

f.org/mail-archive/web/cfrg/current/msg06790.html > Is that still out of scope for perpass? Hope the above helps - the main idea of this list is to find the right place for stuff, so asking "where" and getting views on that is entirely correct. (And more are welcome.) S. > >

Re: [perpass] Possible attack on Diffie-Hellman key exchange

Hiya, That's being discussed at length on the TLS list. I figure any conclusions from there will percolate to IPsec etc in good time. Is there another angle we ought be considering too or is that probably ok? Cheers, S. On 26/05/15 17:40, Mike Liebhold wrote: > > -- Forwarded message

[perpass] IESG perpass chat

All, Last week, the IESG met for our annual "retreat" and reviewed the fine work that you've all gotten done related to this list in the last year and a half. The slides we used for that chat are at [1]. The outcome was that the IESG are happy that we're continuing to use this list for triage of

[perpass] Fwd: [saag] draft-smith-encrypted-traffic-management

FYI. As this relates to draft-mm-wg-effect-encrypt and we said we'd use the saag list for that, please head on over there if you'd like to discuss this some more, Ta, S. Forwarded Message Subject: [saag] draft-smith-encrypted-traffic-management Date: Fri, 8 May 2015 15:35:15

Re: [perpass] perpass: what next?

Just adding a factoid... On 18/04/15 05:44, Watson Ladd wrote: > -There has been talk of PGP refreshing, but I don't know if that > happened/is being worked on Yep, there's been nicely active discussion on the openpgp list [1] for the last month and a bit and that may be shaping up to turn into

[perpass] perpass: what next?

Hiya, I think this list has been really useful since we started it back in August 2013. We initiated a bunch of new work on here (e.g. cfrg curves, tcpinc, dprive, rfc7258) and I think the concerns dealt with here have influenced lots of other work in the IETF as well. Many thanks for all that gr

Re: [perpass] https.CIO.gov

On 28/03/15 02:36, d...@geer.org wrote: > In a world where the deployment curve of the IoT > has a 17-month doubling time, who or what is going to do > the key management that you would actually believe in? I'm sorry but the article *you* quoted made just the opposite assumption (that doing "per

Re: [perpass] https.CIO.gov

Eliot On Sat Mar 28 03:08:45 2015 GMT, Eliot Lear wrote: > Hi, > > It seems to me that having an honest discussion about our biases, goals, > and assumptions might help. > > My goal: I want the Internet to continue to grow in a safe way. It > can't do that if people don't trust the infrastruct

Re: [perpass] https.CIO.gov

On 27/03/15 02:11, d...@geer.org wrote: > Encryption everywhere all the time? No, thank you. Much more encryption, done well, almost all the time - yes please:-) > Better said, and at effective length, by David Golumbia > >Opt-Out Citizenship: End-to-End Encryption and >Constitutional

Re: [perpass] draft-bray-privacy-choices-00.html

Folks, On 13/03/15 20:52, Tim Bray wrote: > This was about to expire so I was going to refresh it but uploader is > closed of course. See > https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html > > Just a reminder that if this group wants to do anything in this space, my > editorial serv

[perpass] Fwd: [lisp] I-D Action: draft-ietf-lisp-crypto-00.txt

FYI, for those of you interested in LISP and security, I'm sure Dino would welcome comments Cheers, S. Forwarded Message Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-00.txt Date: Mon, 12 Jan 2015 13:49:18 -0800 From: internet-dra...@ietf.org To: i-d-annou...@ietf.org CC:

Re: [perpass] EFF, Mozilla et al. announce new free certificate authority...

On 21/11/14 14:05, Ted Lemon wrote: > On Nov 21, 2014, at 1:00 AM, Michael Richardson wrote: >> Nobody said that unauthenticated TLS should show a "lock" > > Unfortunately I think more people notice "https://"; than the lock. The relevant proposal here is the httpbis WG draft. [1] I'm not su

Re: [perpass] EFF, Mozilla et al. announce new free certificate authority...

So the plan for questions/comments is just via github or is there a mailing list? Ta, S. > > On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell > wrote: > > > Nice! > > Sounds extremely promising. > > S. > > On 18/11/14 17:50, Joseph Lorenzo Hall wrote: >>&

Re: [perpass] EFF, Mozilla et al. announce new free certificate authority...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nice! Sounds extremely promising. S. On 18/11/14 17:50, Joseph Lorenzo Hall wrote: > > So cool I'll just shut my mouth and let the launch text speak for > itself... (links in the original) > > > > https://www.eff.org/deeplinks/2014/11/cert

[perpass] IAB security/privacy programme PM draft

Hi all, Richard and a few folks started work on documenting a problem statement [1] some time ago. As I think was stated here before it seems like a good plan for that to be progressed as part of the IAB's re-factored security/privacy programme. So Brian Trammell has picked up the pen and pushed

[perpass] Fwd: [saag] new list for discussion of end-to-end email security/privacy improvements

FYI Forwarded Message Subject: [saag] new list for discussion of end-to-end email security/privacy improvements Date: Mon, 25 Aug 2014 19:20:41 +0100 From: Stephen Farrell To: s...@ietf.org Hi all, Following on from discussion in Toronto in appaswg and saag, and a

Re: [perpass] TCP Stealth (Was: I-D Action: draft-kirsch-ietf-tcp-stealth-00.txt

Hiya, This list would be ok I guess though a thread has been started on tcpinc and tcpm. I suspect that tcpm is probably the best overall, as its there where the folks who'd be best able to comment would be found I think. S. On 18/08/14 14:15, Stephane Bortzmeyer wrote: > [The I-D does not ind

Re: [perpass] DHCP privacy considerations

Hi Doug, (dropping dhc chairs for now) On 16/07/14 21:41, Douglas Otis wrote: > Similar considerations may also pertain to hybrid mDNS which is > intended to automatically transfer mDNS resources into DNS to convey > resources beyond the local link to overcome bridge multicast > limitations. Su

[perpass] DHCP privacy considerations

Hiya, The DHC wg are in the process of re-chartering which triggered a side-discussion on the IESG list with the chairs about DHCP and possible information leakage. That is not any sort of pre-requisite for re-chartering since its pretty much covered by the current charter but after chatting the

Re: [perpass] Crypto Won’t Save You Either

Yeah, the NSA-proof thing was overstated, at least as it was taken-up by press. Doesn't mean we don't have work to do though. We do, and its better to focus on that than on any particular term, hyperbolic or not. And things can be done by us, and others, e.g. I was happy to see FB's figures [1] s

[perpass] Fwd: BCP 188, RFC 7258 on Pervasive Monitoring Is an Attack

FYI. Thanks to everyone who contributed, and who is continuing to contribute as we get into the more detailed work... Cheers, S. Original Message Subject: BCP 188, RFC 7258 on Pervasive Monitoring Is an Attack Date: Mon, 12 May 2014 21:45:35 -0700 (PDT) From: rfc-edi...@rfc-ed

[perpass] Fwd: Re: Delivering perpass

Hiya, Trevor was asking me about the state of play here. The answer might be more generally useful so forwarding this (with permission) in case it is. Cheers, S. Original Message Subject: Re: Delivering perpass Date: Fri, 11 Apr 2014 13:14:50 +0100 From: Stephen Farrell To

Re: [perpass] NSA infiltrated RSA security more deeply than thought - study

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There's a thread on the TLS WG list on this. Probably better there than here as the paper is very much specific to TLS. S. On 03/31/2014 06:30 PM, Paul Ferguson wrote: > On 3/31/2014 9:57 AM, Stephane Bortzmeyer wrote: > >> IETF (and one important

Re: [perpass] Wiki for managing PPM reviews of existing RFCs

(bcc'ing perpass and moving this to ietf-privacy which we agreed was a better list for this) On 03/24/2014 03:46 AM, Melinda Shore wrote: > On 3/23/14 6:49 PM, Jiankang Yao wrote: >> it is a good start. thanks. >> since there are thousands of RFCs, it is better that they can be >> reviewd by cate

Re: [perpass] Gmail is now HTTPS-only

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Fred, On 03/21/2014 10:21 PM, Fred Baker (fred) wrote: > Wouldn?t it be interesting to solve the problem at hand rather > than the one we think we might already know how to solve? You're correct. Unfortunately, for mail, despite decades of work o

Re: [perpass] Fwd: [] Draft report on IETF89 PM review lunch meeting report

ks and issues, privacy issues will also be in scope for the reviews. > > - Several Protocols were given as first examples including; >-- DNS (there are already some reviews in circulation) >-- DHCP (There is already an review i this area) > -- URI usage >-- yet to be

Re: [perpass] STRINT w/s audio-out and irc-in

On 02/28/2014 12:03 PM, Stephane Bortzmeyer wrote: > On Fri, Feb 28, 2014 at 11:58:23AM +, > Stephen Farrell wrote > a message of 50 lines which said: > >> The irc is #string on irc.w3.org as someone guessed > > He guessed wrongly, it is #strint :-) Heh. Yo

Re: [perpass] STRINT w/s audio-out and irc-in

We're working on it, and will have an audio URL shortly The irc is #string on irc.w3.org as someone guessed and its on the w/s web site I think. And as Karen said: we start at 1400 UTC:-) S On 02/28/2014 10:29 AM, Karen ODonoghue wrote: > The meeting doesn't start until 2 pm GMT today > > On

Re: [perpass] STRINT w/s audio-out and irc-in

On 02/26/2014 03:41 PM, Phillip Hallam-Baker wrote: > So live blogging the event is OK I presume? Personally, I don't care. I've no idea if anyone else will, but we are not doing Chatham house rules stuff or anything. S. > > > On Mon, Feb 24, 2014 at 8:10 AM, S

Re: [perpass] Lauren Weinstein on Explicit Trusted Proxy in HTTP/2.0: "One of the Most Alarming Internet Proposals I've Ever Seen"

Hi Bjoern, On 02/24/2014 04:20 PM, Bjoern Hoehrmann wrote: >> >What can I do to help kill that proposal? > Understanding https://tools.ietf.org/html/rfc2804 will be useful. Also > note that increasingly proxies that break through end-to-end encryption > are the only means of self-defense availabl

Re: [perpass] Lauren Weinstein on Explicit Trusted Proxy in HTTP/2.0: "One of the Most Alarming Internet Proposals I've Ever Seen"

Hiya, On 02/24/2014 03:50 PM, Andreas Kuckartz wrote: > Stephen Farrell: >>> Explicit Trusted Proxy in HTTP/2.0 >>> draft-loreto-httpbis-trusted-proxy20-01 >>> http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01 >> >> That is NOT an h

Re: [perpass] Lauren Weinstein on Explicit Trusted Proxy in HTTP/2.0: "One of the Most Alarming Internet Proposals I've Ever Seen"

Hi Andreas, On 02/24/2014 03:21 PM, Andreas Kuckartz wrote: > No, I Don't Trust You! -- One of the Most Alarming Internet Proposals > I've Ever Seen > http://lauren.vortex.com/archive/001076.html Yes. That's a bit OTT IMO and unfortunately liable to mislead as to IETF process if not read very ca

[perpass] STRINT w/s audio-out and irc-in

Hiya, A few folks asked me so... We're working on audio-streaming for the STRINT workshop. [1] Goal is something similar to what happens for IETF meeting sessions, but you'll appreciate that its a work-in-progress. When we have the details sorted (which may be very last minute, i.e. Friday), I'

Re: [perpass] Planning to attend perpass lunch mtg on reviews on 3 March 2014?

Hi Brian, My take below fwiw. Be interested in more opinions. On 02/19/2014 12:23 AM, Brian E Carpenter wrote: > To save time and hot air in London, I'm wondering about > a couple of things concerning PM reviews: > > 1) Won't PM review just be folded into the regular security > review for futur

Re: [perpass] Planning to attend perpass lunch mtg on reviews on 3 March 2014?

Thanks Avri, On 02/18/2014 11:04 AM, Avri Doria wrote: > hi, > > In order to figure out whether we have a sufficient size room I have > been asked to initiate a doodle poll on "Attend IETF perpass mtg on 3 > March 2014." To give a little more context, this session is on the topic of reviewing e

Re: [perpass] Updated info for perpass lunch mtg

FWIW, I think its a fine example, showing as it does that not all changes are protocol changes and that some changes to sensible defaults for implementations might depend on how privacy-friendly one wants to be. Analyses like this that make those kinds of thing explicit are very welcome. And we d

Re: [perpass] privacy/PM reviews of existing stuff

of clues for practices and such > that might be something to be worried about. > > avri > > > On 29-Jan-14 08:55, Stephen Farrell wrote: >> >> Hiya, >> >> One idea that came up in Vancouver and that we (meaning at least >> me:-) haven't had a

Re: [perpass] privacy/PM reviews of existing stuff

On 01/31/2014 10:38 AM, Stephane Bortzmeyer wrote: > On Wed, Jan 29, 2014 at 01:55:47PM +, > Stephen Farrell wrote > a message of 33 lines which said: > >> privacy reviews of existing RFCs. > > Just to check that I understand you correctly: do you think tha

Re: [perpass] privacy/PM reviews of existing stuff

On 01/29/2014 02:16 PM, Scott Brim wrote: > First, what are the goals of getting organized? ☺ Fighting chaos chaotically:-) > Some of us already > consider privacy as a matter of course for new drafts (I do gen-art reviews > in addition to WG reviews). I don't think we want to organize a group

[perpass] privacy/PM reviews of existing stuff

Hiya, One idea that came up in Vancouver and that we (meaning at least me:-) haven't had a chance to progress was the idea of trying to get a team of folks together to go do privacy reviews of existing RFCs. Or perhaps slightly differently, reviews that explicitly consider pervasive monitoring, w

[perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt)

On 01/20/2014 03:11 PM, Stephen Kent wrote: >> For example, when the tcpcrypt folks turned up at the IETF a >> couple of years ago I was against it really. That was mostly >> because I figured we already had TLS so why would we want >> another thing that's so similar but partly because they were

Re: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

Hi Ted, On 01/16/2014 07:23 PM, Theodore Ts'o wrote: > That may be true, but the alternative of edge-to-edge security is even > worse. I'm fairly sure you don't mean it that way, but just in case... We'll really be better off not to be talking as if end-to-end (or object) and hop-by-hop (channe

Re: [perpass] STRINT position paper deadline extended to 20 Jan...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Joe, You beat me to it! S. PS: We got 43 submissions so far and I know of a few more that are expected by the extended deadline, which is why we extended. The TPC will have work to do:-) On 01/16/2014 12:10 PM, Joseph Lorenzo Hall wrote: >

Re: [perpass] draft-farrell-perpass-attack architecture issue

On 01/14/2014 10:00 PM, Melinda Shore wrote: > On 1/14/14 12:45 PM, Fred Baker (fred) wrote: >> So the question in the shepherd's report should not be "tell me you >> thought about the EU Data Retention Initiative and whether your >> protocol's data identifies an individual". It should be "what >

[perpass] IETF-89 perpass discussions

Hiya, Was just chatting with Sean about scheduling for London. Given that we have the STRINT workshop before the meeting (and hey, you've a full day left to submit your position paper [1]) we felt that we could report on that and also allocate some time for drafts (e.g. [2]) being discussed on t

Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

On 01/14/2014 12:18 AM, Stephen Kent wrote: > Folks, >>> On Fri, 10 Jan 2014, Stephen Farrell wrote: >>> >>>>> - I understand MPLS traffic is often protected at a higher layer by >>>>> IPsec. If we had a good opportunistic solution for IKE/IPs

Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

Hiya, On 01/10/2014 09:14 PM, Yaron Sheffer wrote: > Hi Stephen, > > I haven't read the protocol yet (although I must say Sec. 4.3 worries > me, it reminds me of the renegotiation vulnerability), but: > > - I understand MPLS traffic is often protected at a higher layer by > IPsec. If we had a g

Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

Hiya, On 01/10/2014 04:42 PM, Watson Ladd wrote: > I think prime field elliptic curves would be more amenable to > implementation in restricted router > hardware. Could be. If this doesn't turn out to be DOA then I'd fully expect a bunch of discussion on that. For now, we just picked MODP to avo

[perpass] Fwd: W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT)

Folks, submissions are starting to roll in so this is a reminder to send yours by Jan 15. We'll be posting more logistics next week(-ish) as well in case you're wondering. Thanks, S. Original Message Subject: W3C/IAB workshop on Strengthening the Internet Against Pervasive Mon

[perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

itle : Opportunistic Encryption in MPLS Networks > Authors : Adrian Farrel > Stephen Farrell > Filename: draft-farrelll-mpls-opportunistic-encrypt-00.txt > Pages : 22 > Date: 2014-01-09 >

Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt

On 01/08/2014 06:59 AM, Eliot Lear wrote: > > On 1/8/14 7:52 AM, Stefan Winter wrote: > >> In short: MAC addresses are NOT necessarily local to the LAN; if they >> leak beyond, privacy is at risk. The LAN may be IEEE's domain; protocols >> that transport information about MAC addresses on the l

Re: [perpass] Fwd: New Version Notification for draft-barnes-pervasive-problem-00.txt

Richard et al. Many thanks for getting this out. I think its a fine start. I guess one thing to check is whether this captures all of the significant points from the various other "problem statement" contributions. Ta, S. On 01/07/2014 02:24 AM, Richard Barnes wrote: > Dear PERPASS, > > Steph

Re: [perpass] Fwd: here's my message to perpass from yesterday, see any problems with it?

On 12/16/2013 02:19 PM, Stephen Farrell wrote: > Ta. That did make it to the ietf list over the weekend > and I replied, but whatever's gumming up the system > for Steve also hit my reply;-) > > The IETF list is the right place for the discussion > though rather than

Re: [perpass] Fwd: here's my message to perpass from yesterday, see any problems with it?

On 12/16/2013 02:08 PM, Sean Turner wrote: > Forwarding on behalf on Steve Kent. Ta. That did make it to the ietf list over the weekend and I replied, but whatever's gumming up the system for Steve also hit my reply;-) The IETF list is the right place for the discussion though rather than this l

Re: [perpass] Tiny stacks

On 12/10/2013 12:43 AM, Phillip Hallam-Baker wrote: > What we can do about this in the IETF is quite limited. Tend to agree. Maybe a good topic for that workshop in London though. [1] :-) S. [1] http://www.iab.org/activities/workshops/strint/ ___ pe

Re: [perpass] Tiny stacks

Oops On 12/10/2013 12:19 AM, Stephen Farrell wrote: > should be rehashed I meant "should not be rehashed" ;-) S. ___ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass

Re: [perpass] Tiny stacks

On 12/10/2013 12:07 AM, Richard Barnes wrote: > On Mon, Dec 9, 2013 at 6:46 PM, Bjoern Hoehrmann wrote: > >> * Richard Barnes wrote: >>> I'm thinking of things like these... >> >>> >>> >>> ... which do not seem like RFC-able things (so, the latter

Re: [perpass] Tiny stacks

On 12/09/2013 11:03 PM, Richard Barnes wrote: > As I recall, the major upshot of the workshop, from a security point of > view, was that (1) security protocols are tough but tractable, and (2) the > really hard problem is the introduction problem. By which I mean: > Smart/IoT devices are going t

Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02

Hi Eliot, I've trimmed the cc list to perpass. (I'll send a link to your mail to i...@ietf.org which is arguably where this discussion should happen since the draft is in IETF LC. But I guess most of the folks who care are on here too so its not a huge deal.) On 12/09/2013 12:29 PM, Eliot Lear w

Re: [perpass] Fwd: Re: perens-perpass-appropriate-response-01

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/08/2013 03:55 PM, Nicholas Weaver wrote: > > On Dec 7, 2013, at 4:09 PM, Bruce Perens wrote: >> Well, we do have some HTTP uses where encryption that hides the >> content won't be allowed, and thus authentication is important. >> >> We can'

Re: [perpass] perens-perpass-appropriate-response-01

Bruce, On 12/07/2013 07:29 AM, Bruce Perens wrote: > On 12/06/2013 01:20 PM, Nicholas Weaver wrote: >> If the attacker can see your fetches he can execute a >> man-on-the-side attack through packet injection. > This is the first one I've seen that is actually compelling. I agree that Nicholas' p

Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

tally improve on the status quo, but given > your adversaries I fear it is already doomed before it has started. > Seriously, best of luck anyway :-) > > Josh. From: Stephen > Farrell<mailto:stephen.farr...@cs.tcd.ie> Sent: ‎05/‎12/‎20

Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

Europe there is > clearly a political appetite to roll pervasive monitoring back, and these > acronyms would be pushing on an open door (and, in fairness, perhaps they > already are but it is not obvious to the outside world). It is not far > from Geneva to Brussels... > > Josh. >

Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

Josh, On 12/05/2013 10:53 AM, Josh Howlett wrote: > > I fully support action to increase security, where it responds to the > prevailing threat environment. But it will be a perpetuation of the > naivety that has characterised this debate to think that this alone will > halt pervasive monitoring

[perpass] Fwd: ID Tracker State Update Notice:

Hi all, We made various tweaks to the draft as a result of the shepherd (Sean) and sponsoring AD (Jari) reviews and Jari has now started an IETF LC. So I guess discussion of this will be on i...@ietf.org now. That should be fun as always, but please do chime in as you see fit - personally I thin

Re: [perpass] "Guide to intranet protection"?

On 11/28/2013 06:08 AM, Randy Bush wrote: >> Randy is quite right. > > has to happen occasionally :-) >> The attacks reported in the news article were against the private >> optical fibers linking the geographically distributed data centers of >> large companies like Google or Yahoo. A discuss

Re: [perpass] DNS confidentiality

On 11/27/2013 11:45 AM, Stephane Bortzmeyer wrote: > On Mon, Nov 11, 2013 at 01:10:27PM +0100, > Stephane Bortzmeyer wrote > a message of 14 lines which said: > >> Done. >> http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy > > Now moved to dnsop, per request of the ADs > > h

Re: [perpass] "Guide to intranet protection"?

On 11/27/2013 02:06 PM, Dave Crocker wrote: > Morning mid-coffee question: > > There have been some recent news articles about various major ISPs > taking steps to encrypt their (internal) traffic. These prompt me to > wonder whether it would be practical and useful for the IETF to produce

[perpass] UTA charter (was: Re: Traffic peeking)

On 11/25/2013 12:10 AM, S Moonesamy wrote: > >> The other protocols will be discussed by the new uta (Using TLS in >> Applications) working group[2]. > > I don't recall joining that mailing list. I'll take a look at it. I don't believe a list was setup for that just yet. The charter was sent

Re: [perpass] "Its an attack" BCP draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks Fred. Interestingly RFC 4949 does define attack but not mitigation (it does define countermeasure). I think its a fair point that these need good definitions and in this document. Pete Resnick btw, was the one who suggested being specific abo

Re: [perpass] "Its an attack" BCP draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Its great how we can all focus in on one word:-) I infer that means you're all ok with all the rest of 'em, but even better if you said that. Meanwhile I got an offlist suggestion: OLD In particular, the term, when used technically, implies no

Re: [perpass] "Its an attack" BCP draft

sion. It would be > safer to use a neutral term ('observer'? 'surveyor'?). Fair point, and "bad-actor" doesn't fit that well anyway. Will find a better term or gladly take suggestions. S. > > Regards >Brian > > On 21/11/2013 11:16, Stephen

[perpass] "Its an attack" BCP draft

Hi all, Following up on item 3a from the status/plan mail [1] I sent last week, Hannes and myself have written up an I-D [2] that tries to capture the consensus in the room from the Vancouver tech plenary and we're proposing as a BCP. We're deliberately trying to keep this short and sweet and to

Re: [perpass] RSA-OAEP

I agree that OAEP is better and would be a better MTI. But that's been tried, and each time, current deployment considerations trumped it and specs choose pkcs#1v1.5. I may well be wrong but I suspect someone putting in a bit of concerted work on coding will be needed before OAEP will get accept

  1   2   3   >