From mark.saad at ymail.com  Mon Feb  3 17:57:46 2020
From: mark.saad at ymail.com (Mark Saad)
Date: Mon, 3 Feb 2020 17:57:46 -0500
Subject: [talk] ceph backups
In-Reply-To: <747109D1-1E7A-42E1-B260-7EC2EA4AF750@polancodesign.net>
References: <747109D1-1E7A-42E1-B260-7EC2EA4AF750@polancodesign.net>
Message-ID: <BE6467F3-10F1-4969-8E4A-5E34A7DF185C@ymail.com>

All
  I use minio https://min.io/ . It?s not ceph it?s a s3 work-a-like but combined with is client you can interact with it as if it?s a standard-ish filesytem . 

Why I like it . It works on FreeBSD , newish illumos , and Linux .  It?s written in go and can be up and running in a few mins . 



---
Mark Saad | mark.saad at ymail.com

> On Jan 31, 2020, at 3:11 PM, Mr. Jose Polanco <jose at polancodesign.net> wrote:
> 
> ?Hello Mr Rosamond.. 
> I have used on Centos and red hat.
> 
> I found this work right out the box
> http://www.petasan.org/
> 
> -Jose 
> 
> 
>> On Jan 31, 2020, at 2:25 PM, John C. Vernaleo <john at netpurgatory.com> wrote:
>> 
>> I'm actually just starting to evaluate ceph for a project (probably next week really).  No prior experience with it though.  Maybe I'll report back in a few weeks when I see how it goes but I'd also love to hear if someone has some existing opinions on it.
>> 
>> -------------------------------------------------------
>> John C. Vernaleo, Ph.D.
>> www.netpurgatory.com
>> john at netpurgatory.com
>> -------------------------------------------------------
>> 
>>> On Fri, 31 Jan 2020, George Rosamond wrote:
>>> 
>>> Honestly had never heard of it before, but had a conversation about it
>>> the other night.
>>> 
>>> https://github.com/ceph/ceph
>>> 
>>> Anyone using it?  I don't plan to, but was curious to hear if others were.
>>> 
>>> g
>>> 
>>> _______________________________________________
>>> talk mailing list
>>> talk at lists.nycbug.org
>>> http://lists.nycbug.org:8080/mailman/listinfo/talk
>>> 
>>> 
>> 
>> _______________________________________________
>> talk mailing list
>> talk at lists.nycbug.org
>> http://lists.nycbug.org:8080/mailman/listinfo/talk
> 
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20200203/5062a7b9/attachment.htm>

From mark.saad at ymail.com  Mon Feb  3 17:57:46 2020
From: mark.saad at ymail.com (Mark Saad)
Date: Mon, 3 Feb 2020 17:57:46 -0500
Subject: [talk] ceph backups
In-Reply-To: <747109D1-1E7A-42E1-B260-7EC2EA4AF750@polancodesign.net>
References: <747109D1-1E7A-42E1-B260-7EC2EA4AF750@polancodesign.net>
Message-ID: <BE6467F3-10F1-4969-8E4A-5E34A7DF185C@ymail.com>

All
  I use minio https://min.io/ . It?s not ceph it?s a s3 work-a-like but combined with is client you can interact with it as if it?s a standard-ish filesytem . 

Why I like it . It works on FreeBSD , newish illumos , and Linux .  It?s written in go and can be up and running in a few mins . 



---
Mark Saad | mark.saad at ymail.com

> On Jan 31, 2020, at 3:11 PM, Mr. Jose Polanco <jose at polancodesign.net> wrote:
> 
> ?Hello Mr Rosamond.. 
> I have used on Centos and red hat.
> 
> I found this work right out the box
> http://www.petasan.org/
> 
> -Jose 
> 
> 
>> On Jan 31, 2020, at 2:25 PM, John C. Vernaleo <john at netpurgatory.com> wrote:
>> 
>> I'm actually just starting to evaluate ceph for a project (probably next week really).  No prior experience with it though.  Maybe I'll report back in a few weeks when I see how it goes but I'd also love to hear if someone has some existing opinions on it.
>> 
>> -------------------------------------------------------
>> John C. Vernaleo, Ph.D.
>> www.netpurgatory.com
>> john at netpurgatory.com
>> -------------------------------------------------------
>> 
>>> On Fri, 31 Jan 2020, George Rosamond wrote:
>>> 
>>> Honestly had never heard of it before, but had a conversation about it
>>> the other night.
>>> 
>>> https://github.com/ceph/ceph
>>> 
>>> Anyone using it?  I don't plan to, but was curious to hear if others were.
>>> 
>>> g
>>> 
>>> _______________________________________________
>>> talk mailing list
>>> talk at lists.nycbug.org
>>> http://lists.nycbug.org:8080/mailman/listinfo/talk
>>> 
>>> 
>> 
>> _______________________________________________
>> talk mailing list
>> talk at lists.nycbug.org
>> http://lists.nycbug.org:8080/mailman/listinfo/talk
> 
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20200203/5062a7b9/attachment-0001.htm>

From raulcuza at gmail.com  Wed Feb  5 18:59:11 2020
From: raulcuza at gmail.com (Raul Cuza)
Date: Wed, 5 Feb 2020 18:59:11 -0500
Subject: [talk] Chartbeat Entrance
Message-ID: <CAOnfn2y5cRWvmmT6HNihDUS46P1DP_Jfs31knOUCO08i-aquqQ@mail.gmail.com>

I am heading to the meeting room. I'll check the door every 10 min or
so to see if there are any late comers. Feel free to reply to this
thread.

Ra?l



From george at ceetonetechnology.com  Thu Feb  6 10:21:34 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Thu, 6 Feb 2020 10:21:34 -0500
Subject: [talk] blacklists
Message-ID: <7705831f-50a4-0b53-343d-e93118d41bd6@ceetonetechnology.com>

Curious to hear about others dealing with (external) blacklists/RBLs,
both from the perspective of getting removed from them or using them
defensively. I'm not referring to blacklists generated locally by spamd
etc. And it's certainly beyond just MTA IPs.

(Yes, I know this seems like a back to 1999 discussion about ???haus,
extortion and email...)

I know there are (still) good and bad lists. I'm finding something
annnoying about an alleged usenix site
(http://www.usenix.org.uk/content/rbl.html). There are lists that aren't
really blacklists, but rather just Tor IP addresses (both all the public
Tor IPs and also just Tor exit nodes).

There's some interesting stuff to dive into here:

https://github.com/hslatman/awesome-threat-intelligence

including apility.io, firehol's, and abuseipb.com, some of which have APIs.

So some questions would be:

* Are there public lists that others trust and utilize either
defensively or that they work to keep off of?

* Does NANOG and similiar groups have some list that I can't find?

* are RBLs now just a playground for the Ciscos etc as proprietary services?

g

PS... i appreciate the offlist replies I get from posts, but public is
preferred if possible.



From pete at nomadlogic.org  Thu Feb  6 13:23:34 2020
From: pete at nomadlogic.org (Pete Wright)
Date: Thu, 6 Feb 2020 10:23:34 -0800
Subject: [talk] blacklists
In-Reply-To: <7705831f-50a4-0b53-343d-e93118d41bd6@ceetonetechnology.com>
References: <7705831f-50a4-0b53-343d-e93118d41bd6@ceetonetechnology.com>
Message-ID: <f3094d10-ff27-5a0b-b1c6-6ebd934d2ac0@nomadlogic.org>



On 2020-02-06 07:21, George Rosamond wrote:
> Curious to hear about others dealing with (external) blacklists/RBLs,
> both from the perspective of getting removed from them or using them
> defensively. I'm not referring to blacklists generated locally by spamd
> etc. And it's certainly beyond just MTA IPs.
>
> (Yes, I know this seems like a back to 1999 discussion about ???haus,
> extortion and email...)
>
> I know there are (still) good and bad lists. I'm finding something
> annnoying about an alleged usenix site
> (http://www.usenix.org.uk/content/rbl.html). There are lists that aren't
> really blacklists, but rather just Tor IP addresses (both all the public
> Tor IPs and also just Tor exit nodes).
>
> There's some interesting stuff to dive into here:
>
> https://github.com/hslatman/awesome-threat-intelligence
>
> including apility.io, firehol's, and abuseipb.com, some of which have APIs.
>
> So some questions would be:
>
> * Are there public lists that others trust and utilize either
> defensively or that they work to keep off of?
>
> * Does NANOG and similiar groups have some list that I can't find?
>
> * are RBLs now just a playground for the Ciscos etc as proprietary services?


I'm glad you brought this up.? Just last week I wanted to improve my ad 
filtering at home and was reading up on the pi-hole linux stuff 
(https://pi-hole.net <https://pi-hole.net/>) and it looked pretty neat 
but seems really linux specific.

i ended up deploying pfblockerNG on my pfsense router at home.? i 
personally think this is still a valid way to add an additional layer of 
security to a network.? i'm not sure i'd go as far as implementing this 
on a per-host basis in a server environment, but for helping protect 
networks it seems pretty sweet.

i understand that this doesn't really address your original question 
about using RBLs for mail servers, but it looked like there were still 
loads of very active and open filtering lists out there...

-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20200206/5cd6bba2/attachment.htm>

From george at ceetonetechnology.com  Mon Feb 10 09:08:05 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Mon, 10 Feb 2020 09:08:05 -0500
Subject: [talk] hardware donations for hambsd
Message-ID: <5a29e453-5b2b-9b70-c7dd-bbd44e680b5c@ceetonetechnology.com>

https://www.hambsd.org/want.html



From ike at blackskyresearch.net  Wed Feb 12 15:41:01 2020
From: ike at blackskyresearch.net (Isaac (.ike) Levy)
Date: Wed, 12 Feb 2020 15:41:01 -0500
Subject: [talk] Encrypted Chat Applications (aka not Signal)
Message-ID: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>

Hi All,

I wanted to ask if folks have any preferred end to end encryption communications software they like, for chat/txt type messaging?  Quite specifically:

I'm looking for:
- Stuff which relies on user-created encryption keys (pgp/gpg or otherwise)
  - optionally, has a distributed trust validation model built in (gpg signing use would do it)
- Stuff which relies on generalized network/messaging infrastructure
  - Anyone remember gpg plug ins for irc clients way back when?
  - Remember when gpg over xmpp got hot?

I am *not* looking for:
- Anything which replaces distributed trust (gpg and human validation), with cenralized authority (Signal, iMessage, ssl/tls/CA based models-)
- Maybe apps can run on popular mobile platforms (iOS, Android)
- Maybe apps which can run on desktop (Pidgn?  Does it have these features?)

Any thoughts?

Best,
.ike



From john at netpurgatory.com  Wed Feb 12 15:54:28 2020
From: john at netpurgatory.com (John C. Vernaleo)
Date: Wed, 12 Feb 2020 15:54:28 -0500 (EST)
Subject: [talk] Encrypted Chat Applications (aka not Signal)
In-Reply-To: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
References: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
Message-ID: <alpine.DEB.2.21.2002121552360.9487@triforce>

I haven't touched it in a few years, but zkc was an interesting attempt at 
an encrypted and zero knowledge irc like system.  ISC license, and good 
stuff like that.  We were using it in production while we were working on 
it but not sure of that status today or if it hits all your points, but 
might be worth taking a look at.

https://github.com/companyzero/zkc

-------------------------------------------------------
John C. Vernaleo, Ph.D.
www.netpurgatory.com
john at netpurgatory.com
-------------------------------------------------------

On Wed, 12 Feb 2020, Isaac (.ike) Levy wrote:

> Hi All,
>
> I wanted to ask if folks have any preferred end to end encryption communications software they like, for chat/txt type messaging?  Quite specifically:
>
> I'm looking for:
> - Stuff which relies on user-created encryption keys (pgp/gpg or otherwise)
>  - optionally, has a distributed trust validation model built in (gpg signing use would do it)
> - Stuff which relies on generalized network/messaging infrastructure
>  - Anyone remember gpg plug ins for irc clients way back when?
>  - Remember when gpg over xmpp got hot?
>
> I am *not* looking for:
> - Anything which replaces distributed trust (gpg and human validation), with cenralized authority (Signal, iMessage, ssl/tls/CA based models-)
> - Maybe apps can run on popular mobile platforms (iOS, Android)
> - Maybe apps which can run on desktop (Pidgn?  Does it have these features?)
>
> Any thoughts?
>
> Best,
> .ike
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/talk
>
>



From raulcuza at gmail.com  Wed Feb 12 16:39:39 2020
From: raulcuza at gmail.com (Raul Cuza)
Date: Wed, 12 Feb 2020 16:39:39 -0500
Subject: [talk] Encrypted Chat Applications (aka not Signal)
In-Reply-To: <alpine.DEB.2.21.2002121552360.9487@triforce>
References: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
 <alpine.DEB.2.21.2002121552360.9487@triforce>
Message-ID: <CAOnfn2ww_KSFNOhr2L=8ZY=AynpGDSH-OQ9Xi__xOeYLwsd1tA@mail.gmail.com>

Anyone know how many (if any) of ike's criteria does Keybase.io meet?
I have not done any work on this. If you have, I am curious what you
found.

Ra?l

On Wed, Feb 12, 2020 at 4:04 PM John C. Vernaleo <john at netpurgatory.com> wrote:
>
> I haven't touched it in a few years, but zkc was an interesting attempt at
> an encrypted and zero knowledge irc like system.  ISC license, and good
> stuff like that.  We were using it in production while we were working on
> it but not sure of that status today or if it hits all your points, but
> might be worth taking a look at.
>
> https://github.com/companyzero/zkc
>
> -------------------------------------------------------
> John C. Vernaleo, Ph.D.
> www.netpurgatory.com
> john at netpurgatory.com
> -------------------------------------------------------
>
> On Wed, 12 Feb 2020, Isaac (.ike) Levy wrote:
>
> > Hi All,
> >
> > I wanted to ask if folks have any preferred end to end encryption communications software they like, for chat/txt type messaging?  Quite specifically:
> >
> > I'm looking for:
> > - Stuff which relies on user-created encryption keys (pgp/gpg or otherwise)
> >  - optionally, has a distributed trust validation model built in (gpg signing use would do it)
> > - Stuff which relies on generalized network/messaging infrastructure
> >  - Anyone remember gpg plug ins for irc clients way back when?
> >  - Remember when gpg over xmpp got hot?
> >
> > I am *not* looking for:
> > - Anything which replaces distributed trust (gpg and human validation), with cenralized authority (Signal, iMessage, ssl/tls/CA based models-)
> > - Maybe apps can run on popular mobile platforms (iOS, Android)
> > - Maybe apps which can run on desktop (Pidgn?  Does it have these features?)
> >
> > Any thoughts?
> >
> > Best,
> > .ike
> >
> > _______________________________________________
> > talk mailing list
> > talk at lists.nycbug.org
> > http://lists.nycbug.org:8080/mailman/listinfo/talk
> >
> >
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/talk



From justin at shiningsilence.com  Wed Feb 12 22:26:54 2020
From: justin at shiningsilence.com (Justin Sherrill)
Date: Wed, 12 Feb 2020 22:26:54 -0500
Subject: [talk] Encrypted Chat Applications (aka not Signal)
In-Reply-To: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
References: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
Message-ID: <CA+YR8=1K7jLPGCkY1VFOzKtYqrEfZD-RzOuRN4gkYjzyW_=O8w@mail.gmail.com>

The place I work has Sigma, which does secure conferencing, chat and
voice, using a FreeBSD base, mobile clients, desktop (it's XMPP), and
runs standalone.  https://redcom.com - it is commercial, though, so
maybe not a fit.

On Wed, Feb 12, 2020 at 3:43 PM Isaac (.ike) Levy
<ike at blackskyresearch.net> wrote:
>
> Hi All,
>
> I wanted to ask if folks have any preferred end to end encryption communications software they like, for chat/txt type messaging?  Quite specifically:
>
> I'm looking for:
> - Stuff which relies on user-created encryption keys (pgp/gpg or otherwise)
>   - optionally, has a distributed trust validation model built in (gpg signing use would do it)
> - Stuff which relies on generalized network/messaging infrastructure
>   - Anyone remember gpg plug ins for irc clients way back when?
>   - Remember when gpg over xmpp got hot?
>
> I am *not* looking for:
> - Anything which replaces distributed trust (gpg and human validation), with cenralized authority (Signal, iMessage, ssl/tls/CA based models-)
> - Maybe apps can run on popular mobile platforms (iOS, Android)
> - Maybe apps which can run on desktop (Pidgn?  Does it have these features?)
>
> Any thoughts?
>
> Best,
> .ike
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/talk



From kmsujit at gmail.com  Thu Feb 13 08:50:46 2020
From: kmsujit at gmail.com (Sujit K M)
Date: Thu, 13 Feb 2020 19:20:46 +0530
Subject: [talk] Encrypted Chat Applications (aka not Signal)
In-Reply-To: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
References: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
Message-ID: <CA+6mNerzvisVewF1QbGNCE7BQr5XkLm4_HgCri01EciCEJim-Q@mail.gmail.com>

On Thu, Feb 13, 2020, 2:11 AM Isaac (.ike) Levy <ike at blackskyresearch.net>
wrote:

> Hi All,
>
> I wanted to ask if folks have any preferred end to end encryption
> communications software they like, for chat/txt type messaging?  Quite
> specifically:
>
> I'm looking for:
> - Stuff which relies on user-created encryption keys (pgp/gpg or otherwise)
>   - optionally, has a distributed trust validation model built in (gpg
> signing use would do it)
> - Stuff which relies on generalized network/messaging infrastructure
>   - Anyone remember gpg plug ins for irc clients way back when?
>   - Remember when gpg over xmpp got hot?
>
> I am *not* looking for:
> - Anything which replaces distributed trust (gpg and human validation),
> with cenralized authority (Signal, iMessage, ssl/tls/CA based models-)
> - Maybe apps can run on popular mobile platforms (iOS, Android)
> - Maybe apps which can run on desktop (Pidgn?  Does it have these
> features?)
>
> Any thoughts?
>
> Best,
> .ike
>

I am not that sure. If you remember the topcoder Google code jams long time
ago. It used tunnels. Similar things can be done chat engines too. But I
would really look at bandwidth and security views before proceeding further.

> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20200213/bdf6fcd1/attachment.htm>

From shawn.webb at hardenedbsd.org  Thu Feb 13 08:56:16 2020
From: shawn.webb at hardenedbsd.org (Shawn Webb)
Date: Thu, 13 Feb 2020 08:56:16 -0500
Subject: [talk] Encrypted Chat Applications (aka not Signal)
In-Reply-To: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
References: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
Message-ID: <20200213135616.s7sc7k6bpx4x3z5h@mutt-hbsd>

On Wed, Feb 12, 2020 at 03:41:01PM -0500, Isaac (.ike) Levy wrote:
> Hi All,
> 
> I wanted to ask if folks have any preferred end to end encryption communications software they like, for chat/txt type messaging?  Quite specifically:
> 
> I'm looking for:
> - Stuff which relies on user-created encryption keys (pgp/gpg or otherwise)
>   - optionally, has a distributed trust validation model built in (gpg signing use would do it)
> - Stuff which relies on generalized network/messaging infrastructure
>   - Anyone remember gpg plug ins for irc clients way back when?
>   - Remember when gpg over xmpp got hot?
> 
> I am *not* looking for:
> - Anything which replaces distributed trust (gpg and human validation), with cenralized authority (Signal, iMessage, ssl/tls/CA based models-)
> - Maybe apps can run on popular mobile platforms (iOS, Android)
> - Maybe apps which can run on desktop (Pidgn?  Does it have these features?)
> 
> Any thoughts?

Back in the day, I used to make heavy use of SILC[1]. I haven't really
kept up-to-date with it, but it seems like it's still maintained.

[1]: https://en.wikipedia.org/wiki/SILC_(protocol)

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

XMPP+OTR:            lattera at is.a.hacker.sx
GPG Key ID:          0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20200213/99764b05/attachment.bin>

From george at ceetonetechnology.com  Thu Feb 13 10:56:26 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Thu, 13 Feb 2020 10:56:26 -0500
Subject: [talk] Encrypted Chat Applications (aka not Signal)
In-Reply-To: <20200213135616.s7sc7k6bpx4x3z5h@mutt-hbsd>
References: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
 <20200213135616.s7sc7k6bpx4x3z5h@mutt-hbsd>
Message-ID: <c134a4fa-1fec-9745-e8ea-f8dd2edf10d2@ceetonetechnology.com>



On 2/13/20 8:56 AM, Shawn Webb wrote:
> On Wed, Feb 12, 2020 at 03:41:01PM -0500, Isaac (.ike) Levy wrote:
>> Hi All,
>>
>> I wanted to ask if folks have any preferred end to end encryption communications software they like, for chat/txt type messaging?  Quite specifically:
>>
>> I'm looking for:
>> - Stuff which relies on user-created encryption keys (pgp/gpg or otherwise)
>>   - optionally, has a distributed trust validation model built in (gpg signing use would do it)
>> - Stuff which relies on generalized network/messaging infrastructure
>>   - Anyone remember gpg plug ins for irc clients way back when?
>>   - Remember when gpg over xmpp got hot?
>>
>> I am *not* looking for:
>> - Anything which replaces distributed trust (gpg and human validation), with cenralized authority (Signal, iMessage, ssl/tls/CA based models-)
>> - Maybe apps can run on popular mobile platforms (iOS, Android)
>> - Maybe apps which can run on desktop (Pidgn?  Does it have these features?)
>>
>> Any thoughts?
> 
> Back in the day, I used to make heavy use of SILC[1]. I haven't really
> kept up-to-date with it, but it seems like it's still maintained.
> 
> [1]: https://en.wikipedia.org/wiki/SILC_(protocol)
> 

Ah SILC.  I was a big fan and user myself.

I sort of think there won't be one answer for Ike's needs... but I'd be
curious to hear more input.

g



From carton at Ivy.NET  Thu Feb 13 12:40:53 2020
From: carton at Ivy.NET (Miles Nordin)
Date: Thu, 13 Feb 2020 12:40:53 -0500
Subject: [talk] Encrypted Chat Applications (aka not Signal)
In-Reply-To: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com> (Isaac
 (.ike) Levy's message of "Wed, 12 Feb 2020 15:41:01 -0500")
References: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
Message-ID: <oqh7zul716.fsf@castrovalva.Ivy.NET>

>>>>> "il" == Isaac ( ike) Levy <ike at blackskyresearch.net> writes:

    il> end to end encryption communications software they like,

matrix.org / riot.im

 - fully open-source client and server.  If they pack up their tent
   and go, you can run your own netowrk without them, just like email
   and XMPP.

 - non-cartel federation.  Unlike irc or SMS, joining the mesh of
   servers doesn't require a higher level of trust than connecting a
   client, so there's no approval barrier to doing this.  You just
   register in DNS and go, just like email and XMPP.

 - modern features: encrypted rooms, scrollback from before you joined
   kept perfectly in sync, multiple devices per user presented to
   others as a single virtual identity and kept in sync (your messages
   and theirs).

 - the "identity server" is factored out.  There's a parallel system
   running under vector.im which attests that people own phone numbers
   or email addresses, which you call "centralized," but when it's
   factored out like that there are other ways to think about it.  In
   any case, I haven't explored it.  I'm chatting with people on
   Matrix and completely ignoring this.  We have the best-case here
   because anyone calling for such features is diverted to the
   existing system and prevented from compromising the core.

 - modern languages (for better or worse)

 - modern client platform.  It's just a web page that you go to.  The
   app on the page keeps working normally when Internet goes away,
   unless you press [Reload].

One thing to watch out for while exploring their ecosystem is that
encryption is "optional"---it has to be turned on in each room or each
1:1 conversation.  This is a reasonable feature because it allows them
to make bridges to irc, and it allowed them to develop incrementally
without which they couldn't sustain this much complexity (the
encryption is "v2" now and has been ripped out and rewritten once
already).  However they're not always honest in promoting it.  They
say they have support for 99 clients on qt and elisp and weechat Lua
plugins and Python libraries all this great stuff, but those clients
either don't support encryption or support now-useless v1 encryption.
If you want a list of clients that has feature parity with riot.im, I
do not have it.  There might be a few, or it might be none at all.

Another thing is more optimistic.  Currently the manual key
verification you are asking for exists, but it's device-to-device, not
user-to-user.  The behaviour of normal users is such that this just
doesn't work at all.  They are absolute spazzes, clearing cookies and
getting and discarding phones tablets and other gadgets constantly.
It doesn't even need to be that frequent to undermine usability.  In a
group text of five people if everyone does it twice a year that's
enough that most people including me will give up on being in the
verified state.  There's a project supposedly nearing completion to
improve the protocol so users verify other users, not devices, and
there's some workflow to add and remove devices that handles theft and
doesn't trust the server.  tl;dr devices share copies of the
overall-user key with each other, always wrapped by the user's login
password [wave hands] in some way that the server can't unwrap, maybe.
If it's not good enough for you run your own server, I guess.

The last thing is just a gotcha.  You need to set up key backup for
the system to act normally.  The idea here is that you have a "tier 2"
password besides your login password wihch undoes PFS.  Without this,
clearing cookies removes your access to scrollback because by
definition that's what PFS is supposed to do, and the protocol has
PFS.  The purpose of backup is not normally explained in this way and
is instead phrased as some emotional nonsense over how much you trust
the server.  That's not the issue, or it shouldn't be.  Key-wrapping
is accepted as a legit thing now.  The new discussion is about
retention limits and their effect on opsec, and the backup situation
is related to that but as currently Matrix doesn't have a good
retention/expire story it's not normally presented in that way.

They're currently running matrix.org on a single-threaded Twisted
Python server.  I don't understand how this can work.  There's a
project to rewrite the server, which is called Synapse, into a
distributed system based on Apache Kafka and several stateless Go
frontends.  However they are throwing most of their energy into the
client and AFAICT not making much progress on Dendrite.

    il> Remember when gpg over xmpp got hot?

no, I don't.

I remember GPG not being reasonable on XMPP because OTR has PFS,
authentication, and repudiation.  An online chat can offer all that
stuff while store and foward cannot, so it should be included.

I also remember them never solving the multi-device problem in the
protocol, so group chats were not possible, and many messages had to
be manually resent for reasons opaque to the user.  I remember it
being total garbage, frankly, and everyone walking away from it
because the programmers were unable to identify and fix the problems
that were obvious to normies.

      > SILC

I think the time for this stuff has passed because of security bugs.

It's ok to write programs in C++ even though "omg pointer safety."
Reasonable people can disagree on this.

It's not ok to write programs in C and write your own parser from
string arithmetic.  It's 9000x not ok to do the same thing when crypto
is involved because it leads to too many exploits.  You need to use
JSON or protobufs or something so that all the code serializing and
deserializing structured data has had the bugs hammered out of it.  I
think running your own SILC server is a great way to get owned, which
is something anyone wanting encrypted chats should care about.  There
are other problems with it, but that's the show-stopper for me.



From edlinuxguru at gmail.com  Thu Feb 13 22:45:21 2020
From: edlinuxguru at gmail.com (Edward Capriolo)
Date: Thu, 13 Feb 2020 22:45:21 -0500
Subject: [talk] Encrypted Chat Applications (aka not Signal)
In-Reply-To: <oqh7zul716.fsf@castrovalva.Ivy.NET>
References: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
 <oqh7zul716.fsf@castrovalva.Ivy.NET>
Message-ID: <CAENxBwxYhPrC_OdHbbjaBCmPWd4avqpRzpLkJeMo-2ofyKLJBg@mail.gmail.com>

On Thu, Feb 13, 2020 at 1:33 PM Miles Nordin <carton at ivy.net> wrote:

> >>>>> "il" == Isaac ( ike) Levy <ike at blackskyresearch.net> writes:
>
>     il> end to end encryption communications software they like,
>
> matrix.org / riot.im
>
>  - fully open-source client and server.  If they pack up their tent
>    and go, you can run your own netowrk without them, just like email
>    and XMPP.
>
>  - non-cartel federation.  Unlike irc or SMS, joining the mesh of
>    servers doesn't require a higher level of trust than connecting a
>    client, so there's no approval barrier to doing this.  You just
>    register in DNS and go, just like email and XMPP.
>
>  - modern features: encrypted rooms, scrollback from before you joined
>    kept perfectly in sync, multiple devices per user presented to
>    others as a single virtual identity and kept in sync (your messages
>    and theirs).
>
>  - the "identity server" is factored out.  There's a parallel system
>    running under vector.im which attests that people own phone numbers
>    or email addresses, which you call "centralized," but when it's
>    factored out like that there are other ways to think about it.  In
>    any case, I haven't explored it.  I'm chatting with people on
>    Matrix and completely ignoring this.  We have the best-case here
>    because anyone calling for such features is diverted to the
>    existing system and prevented from compromising the core.
>
>  - modern languages (for better or worse)
>
>  - modern client platform.  It's just a web page that you go to.  The
>    app on the page keeps working normally when Internet goes away,
>    unless you press [Reload].
>
> One thing to watch out for while exploring their ecosystem is that
> encryption is "optional"---it has to be turned on in each room or each
> 1:1 conversation.  This is a reasonable feature because it allows them
> to make bridges to irc, and it allowed them to develop incrementally
> without which they couldn't sustain this much complexity (the
> encryption is "v2" now and has been ripped out and rewritten once
> already).  However they're not always honest in promoting it.  They
> say they have support for 99 clients on qt and elisp and weechat Lua
> plugins and Python libraries all this great stuff, but those clients
> either don't support encryption or support now-useless v1 encryption.
> If you want a list of clients that has feature parity with riot.im, I
> do not have it.  There might be a few, or it might be none at all.
>
> Another thing is more optimistic.  Currently the manual key
> verification you are asking for exists, but it's device-to-device, not
> user-to-user.  The behaviour of normal users is such that this just
> doesn't work at all.  They are absolute spazzes, clearing cookies and
> getting and discarding phones tablets and other gadgets constantly.
> It doesn't even need to be that frequent to undermine usability.  In a
> group text of five people if everyone does it twice a year that's
> enough that most people including me will give up on being in the
> verified state.  There's a project supposedly nearing completion to
> improve the protocol so users verify other users, not devices, and
> there's some workflow to add and remove devices that handles theft and
> doesn't trust the server.  tl;dr devices share copies of the
> overall-user key with each other, always wrapped by the user's login
> password [wave hands] in some way that the server can't unwrap, maybe.
> If it's not good enough for you run your own server, I guess.
>
> The last thing is just a gotcha.  You need to set up key backup for
> the system to act normally.  The idea here is that you have a "tier 2"
> password besides your login password wihch undoes PFS.  Without this,
> clearing cookies removes your access to scrollback because by
> definition that's what PFS is supposed to do, and the protocol has
> PFS.  The purpose of backup is not normally explained in this way and
> is instead phrased as some emotional nonsense over how much you trust
> the server.  That's not the issue, or it shouldn't be.  Key-wrapping
> is accepted as a legit thing now.  The new discussion is about
> retention limits and their effect on opsec, and the backup situation
> is related to that but as currently Matrix doesn't have a good
> retention/expire story it's not normally presented in that way.
>
> They're currently running matrix.org on a single-threaded Twisted
> Python server.  I don't understand how this can work.  There's a
> project to rewrite the server, which is called Synapse, into a
> distributed system based on Apache Kafka and several stateless Go
> frontends.  However they are throwing most of their energy into the
> client and AFAICT not making much progress on Dendrite.
>
>     il> Remember when gpg over xmpp got hot?
>
> no, I don't.
>
> I remember GPG not being reasonable on XMPP because OTR has PFS,
> authentication, and repudiation.  An online chat can offer all that
> stuff while store and foward cannot, so it should be included.
>
> I also remember them never solving the multi-device problem in the
> protocol, so group chats were not possible, and many messages had to
> be manually resent for reasons opaque to the user.  I remember it
> being total garbage, frankly, and everyone walking away from it
> because the programmers were unable to identify and fix the problems
> that were obvious to normies.
>
>       > SILC
>
> I think the time for this stuff has passed because of security bugs.
>
> It's ok to write programs in C++ even though "omg pointer safety."
> Reasonable people can disagree on this.
>
> It's not ok to write programs in C and write your own parser from
> string arithmetic.  It's 9000x not ok to do the same thing when crypto
> is involved because it leads to too many exploits.  You need to use
> JSON or protobufs or something so that all the code serializing and
> deserializing structured data has had the bugs hammered out of it.  I
> think running your own SILC server is a great way to get owned, which
> is something anyone wanting encrypted chats should care about.  There
> are other problems with it, but that's the show-stopper for me.
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/talk


Sometimes the problem isn't the app. Like in the Stone case everyone is
asking, "how did they got the "super encrypted whats app messages?". They
did not get them from facebook to turn them over. The problem is that some
people do things like backup phone to icloud, or backup this to their
watch, and sync that with their toaster. it's hard to find a vessel to read
your super encrypted 8 time pgp'ed message and ensure the person on the
other side is not backing up things to their toaster.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20200213/ba5b5904/attachment.htm>

From george at ceetonetechnology.com  Fri Feb 14 12:43:12 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Fri, 14 Feb 2020 12:43:12 -0500
Subject: [talk] Encrypted Chat Applications (aka not Signal)
In-Reply-To: <CAENxBwxYhPrC_OdHbbjaBCmPWd4avqpRzpLkJeMo-2ofyKLJBg@mail.gmail.com>
References: <9c98c482-5d68-4b7e-a477-746b8837b2a9@www.fastmail.com>
 <oqh7zul716.fsf@castrovalva.Ivy.NET>
 <CAENxBwxYhPrC_OdHbbjaBCmPWd4avqpRzpLkJeMo-2ofyKLJBg@mail.gmail.com>
Message-ID: <4bbee745-9d65-ebd3-39d1-6e4a96274f6a@ceetonetechnology.com>



On 2/13/20 10:45 PM, Edward Capriolo wrote:
> On Thu, Feb 13, 2020 at 1:33 PM Miles Nordin <carton at ivy.net> wrote:
> 
>>>>>>> "il" == Isaac ( ike) Levy <ike at blackskyresearch.net> writes:
>>
>>     il> end to end encryption communications software they like,
>>
>> matrix.org / riot.im
>>
>>  - fully open-source client and server.  If they pack up their tent
>>    and go, you can run your own netowrk without them, just like email
>>    and XMPP.
>>
>>  - non-cartel federation.  Unlike irc or SMS, joining the mesh of
>>    servers doesn't require a higher level of trust than connecting a
>>    client, so there's no approval barrier to doing this.  You just
>>    register in DNS and go, just like email and XMPP.
>>
>>  - modern features: encrypted rooms, scrollback from before you joined
>>    kept perfectly in sync, multiple devices per user presented to
>>    others as a single virtual identity and kept in sync (your messages
>>    and theirs).
>>
>>  - the "identity server" is factored out.  There's a parallel system
>>    running under vector.im which attests that people own phone numbers
>>    or email addresses, which you call "centralized," but when it's
>>    factored out like that there are other ways to think about it.  In
>>    any case, I haven't explored it.  I'm chatting with people on
>>    Matrix and completely ignoring this.  We have the best-case here
>>    because anyone calling for such features is diverted to the
>>    existing system and prevented from compromising the core.
>>
>>  - modern languages (for better or worse)
>>
>>  - modern client platform.  It's just a web page that you go to.  The
>>    app on the page keeps working normally when Internet goes away,
>>    unless you press [Reload].
>>
>> One thing to watch out for while exploring their ecosystem is that
>> encryption is "optional"---it has to be turned on in each room or each
>> 1:1 conversation.  This is a reasonable feature because it allows them
>> to make bridges to irc, and it allowed them to develop incrementally
>> without which they couldn't sustain this much complexity (the
>> encryption is "v2" now and has been ripped out and rewritten once
>> already).  However they're not always honest in promoting it.  They
>> say they have support for 99 clients on qt and elisp and weechat Lua
>> plugins and Python libraries all this great stuff, but those clients
>> either don't support encryption or support now-useless v1 encryption.
>> If you want a list of clients that has feature parity with riot.im, I
>> do not have it.  There might be a few, or it might be none at all.
>>
>> Another thing is more optimistic.  Currently the manual key
>> verification you are asking for exists, but it's device-to-device, not
>> user-to-user.  The behaviour of normal users is such that this just
>> doesn't work at all.  They are absolute spazzes, clearing cookies and
>> getting and discarding phones tablets and other gadgets constantly.
>> It doesn't even need to be that frequent to undermine usability.  In a
>> group text of five people if everyone does it twice a year that's
>> enough that most people including me will give up on being in the
>> verified state.  There's a project supposedly nearing completion to
>> improve the protocol so users verify other users, not devices, and
>> there's some workflow to add and remove devices that handles theft and
>> doesn't trust the server.  tl;dr devices share copies of the
>> overall-user key with each other, always wrapped by the user's login
>> password [wave hands] in some way that the server can't unwrap, maybe.
>> If it's not good enough for you run your own server, I guess.
>>
>> The last thing is just a gotcha.  You need to set up key backup for
>> the system to act normally.  The idea here is that you have a "tier 2"
>> password besides your login password wihch undoes PFS.  Without this,
>> clearing cookies removes your access to scrollback because by
>> definition that's what PFS is supposed to do, and the protocol has
>> PFS.  The purpose of backup is not normally explained in this way and
>> is instead phrased as some emotional nonsense over how much you trust
>> the server.  That's not the issue, or it shouldn't be.  Key-wrapping
>> is accepted as a legit thing now.  The new discussion is about
>> retention limits and their effect on opsec, and the backup situation
>> is related to that but as currently Matrix doesn't have a good
>> retention/expire story it's not normally presented in that way.
>>
>> They're currently running matrix.org on a single-threaded Twisted
>> Python server.  I don't understand how this can work.  There's a
>> project to rewrite the server, which is called Synapse, into a
>> distributed system based on Apache Kafka and several stateless Go
>> frontends.  However they are throwing most of their energy into the
>> client and AFAICT not making much progress on Dendrite.
>>
>>     il> Remember when gpg over xmpp got hot?
>>
>> no, I don't.
>>
>> I remember GPG not being reasonable on XMPP because OTR has PFS,
>> authentication, and repudiation.  An online chat can offer all that
>> stuff while store and foward cannot, so it should be included.
>>
>> I also remember them never solving the multi-device problem in the
>> protocol, so group chats were not possible, and many messages had to
>> be manually resent for reasons opaque to the user.  I remember it
>> being total garbage, frankly, and everyone walking away from it
>> because the programmers were unable to identify and fix the problems
>> that were obvious to normies.
>>
>>       > SILC
>>
>> I think the time for this stuff has passed because of security bugs.
>>
>> It's ok to write programs in C++ even though "omg pointer safety."
>> Reasonable people can disagree on this.
>>
>> It's not ok to write programs in C and write your own parser from
>> string arithmetic.  It's 9000x not ok to do the same thing when crypto
>> is involved because it leads to too many exploits.  You need to use
>> JSON or protobufs or something so that all the code serializing and
>> deserializing structured data has had the bugs hammered out of it.  I
>> think running your own SILC server is a great way to get owned, which
>> is something anyone wanting encrypted chats should care about.  There
>> are other problems with it, but that's the show-stopper for me.
>>
>> _______________________________________________
>> talk mailing list
>> talk at lists.nycbug.org
>> http://lists.nycbug.org:8080/mailman/listinfo/talk
> 
> 
> Sometimes the problem isn't the app. Like in the Stone case everyone is
> asking, "how did they got the "super encrypted whats app messages?". They
> did not get them from facebook to turn them over. The problem is that some
> people do things like backup phone to icloud, or backup this to their
> watch, and sync that with their toaster. it's hard to find a vessel to read
> your super encrypted 8 time pgp'ed message and ensure the person on the
> other side is not backing up things to their toaster.

Or, just the meta data, which is why over Tor matters.

This might be worth looking at also:

https://dino.im/

Now in OpenBSD...

https://marc.info/?l=openbsd-ports-cvs&m=158159513813583&w=2

g



From nonesuch at longcount.org  Sat Feb 15 14:05:09 2020
From: nonesuch at longcount.org (Mark Saad)
Date: Sat, 15 Feb 2020 14:05:09 -0500
Subject: [talk] rsyslog on freebsd missing kernel events
Message-ID: <CAMXt9NZo2XvEQ78XPgwzh4jPQDA6tUw2pw8ZWgo_qewOiSyL1A@mail.gmail.com>

All
 I am running into an issue that anecdotally is noted on the Internet
as stay away.
Running rsyslog on freebsd in place of the base syslog. The issue that
I have ,as well as a number of other people out there is my kernel
logs go missing when forwarded to a remote host.

I have a fairly basic config

module(load="immark")   # provides --MARK-- message capability
module(load="imuxsock" SysSock.UseSpecialParser="off") # provides
support for local system logging
module(load="imklog")   # kernel logging
module(load="imudp") # needs to be done just once

*.err;kern.warning;auth.notice;mail.crit                /dev/console
*.notice;authpriv.none;kern.debug;lpr.info;mail.crit;news.err
/var/log/messages
security.*                                      /var/log/security
auth.info;authpriv.info                         /var/log/auth.log
mail.info                                       /var/log/maillog
cron.*                                          /var/log/cron

*.*          @iforgot.superlogger.net:1234567


what happens is when a kernel event happens I see it in /dev/console
and /var/log/messages but not at the remote host.

Does anyone out there know what the heck this is ?

-- 
mark saad | nonesuch at longcount.org



From george at ceetonetechnology.com  Sat Feb 15 19:43:52 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Sat, 15 Feb 2020 19:43:52 -0500
Subject: [talk] OpenBSD Tor Browser
Message-ID: <1a44831e-87cf-e891-6aae-293f21d2cbf9@ceetonetechnology.com>

Caspar Schutijser updated www/tor-browser on OpenBSD to the most recent
version 9.0.5 in -current ports.

https://cvsweb.openbsd.org/ports/www/tor-browser/

The package is also ready and more people should test, especially if
they can compare to the same version on another OS, or if you want to
dive into the tb source (https://gitweb.torproject.org/tor-browser.git/)

g



From nycbug-talk at reynolds.users.panix.com  Mon Feb 17 23:06:44 2020
From: nycbug-talk at reynolds.users.panix.com (Brian Reynolds)
Date: Mon, 17 Feb 2020 23:06:44 -0500
Subject: [talk] Local Crypto Exhibit
Message-ID: <20200218040644.GA26771@panix.com>

You may have seen the news recently about Crypto AG (a Swiss supplier
of cryptographic equipment) being owned by the CIA, and the West
German BND.

<https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypto-encryption-machines-espionage/>

<https://arstechnica.com/tech-policy/2020/02/us-german-intel-owned-swiss-crypto-used-by-dozens-of-countries>

It turns out that the National Museum of Math down by Madison Square
Park in Manhattan has a Hagelin M-209 cipher machine as used by the US
Army during WWII and the Korean War.

<https://en.wikipedia.org/wiki/M-209>

This is the machine that started the whole saga.  After the war the
CIA approached Mr. Hagelin about providing weakened machines to some
of his clients, and eventually provided the designs for Crypto AG's
electronic machines.

If you go to the basement exhibit area you'll find a M-209 in a back
corner with a supply of messages to decrypt.  There are instructions
on entering the correct key on the wheels, and then how to decrypt the
messages with the machine.

The last time I was there at least one of the code wheels was
slipping, and every fifth letter of the output message was wrong, but
I was still thought it was the coolest exhibit in the museum.

-- 
Brian Reynolds -- reynolds at panix.com
"Long ago, it was the way of my people to travel to the Moon.  My people
travelled to the Moon in a ship called 'Apollo.' I tell the story of Apollo
in the hope that some day, my people will again travel to the Moon." P. Alway



From george at ceetonetechnology.com  Tue Feb 25 11:19:44 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Tue, 25 Feb 2020 11:19:44 -0500
Subject: [talk] Vixie meeting
Message-ID: <65a3520b-842f-cda8-baff-74bc12676ce5@ceetonetechnology.com>

As some of you may know, the Vixie meeting next week should raise some
interesting issues with DoH and DoT... basically DNS lookups encrypted
over https or tls instead of clear text over UDP.

The issue is a bit more complex than it seems on the surface.

Most broadly, of course DNS lookups should be encrypted, but what's
disturbing is that US FF will be set to go to Cloudflare, who obviously
know this is a wonderful data-mining opportunity.

The whole issue of "privacy" gets distorted too easily.  Yes, you should
have privacy in DNS lookups, but sending encrypted lookups to one
provider is a recipe for privacy from "the other" while centralizing a
few huge collectors of that data.

Yes, more providers should be running DOT servers, but that in itself
isn't the answer.

This link raises the issue, but misses the dangerous implications of DOH:

https://techcrunch.com/2020/02/25/firefox-dns-https-default-united-states/

g



From rick at aliwalas.com  Tue Feb 25 13:09:22 2020
From: rick at aliwalas.com (Rick Aliwalas)
Date: Tue, 25 Feb 2020 13:09:22 -0500 (EST)
Subject: [talk] parking near the NYU Tandon bldg
Message-ID: <alpine.BSO.2.20.9.2002251305130.2325@victoria.noyage.com>

Anyone know the parking situation in the NYU Tandon Building vicinity?
I'm contemplating driving to Bk for the talk next week (from New Haven).

Thanks!
-rick



From george at ceetonetechnology.com  Tue Feb 25 13:28:26 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Tue, 25 Feb 2020 13:28:26 -0500
Subject: [talk] parking near the NYU Tandon bldg
In-Reply-To: <alpine.BSO.2.20.9.2002251305130.2325@victoria.noyage.com>
References: <alpine.BSO.2.20.9.2002251305130.2325@victoria.noyage.com>
Message-ID: <aa35d97e-ffdd-9c5f-28f8-5117bcd493e0@ceetonetechnology.com>



On 2/25/20 1:09 PM, Rick Aliwalas wrote:
> Anyone know the parking situation in the NYU Tandon Building vicinity?
> I'm contemplating driving to Bk for the talk next week (from New Haven).
> 

There's a lot south on Jay Street from Tandon... .before Jay turns into
Smith St.

g



From rick at aliwalas.com  Tue Feb 25 14:21:21 2020
From: rick at aliwalas.com (Rick Aliwalas)
Date: Tue, 25 Feb 2020 14:21:21 -0500 (EST)
Subject: [talk] parking near the NYU Tandon bldg
In-Reply-To: <aa35d97e-ffdd-9c5f-28f8-5117bcd493e0@ceetonetechnology.com>
References: <alpine.BSO.2.20.9.2002251305130.2325@victoria.noyage.com>
 <aa35d97e-ffdd-9c5f-28f8-5117bcd493e0@ceetonetechnology.com>
Message-ID: <alpine.BSO.2.20.9.2002251420360.2325@victoria.noyage.com>

On Tue, 25 Feb 2020, George Rosamond wrote:

> On 2/25/20 1:09 PM, Rick Aliwalas wrote:
>> Anyone know the parking situation in the NYU Tandon Building vicinity?
>> I'm contemplating driving to Bk for the talk next week (from New Haven).
>>
>
> There's a lot south on Jay Street from Tandon... .before Jay turns into
> Smith St.

Thanks George - good to know.



From george at ceetonetechnology.com  Wed Feb 26 08:26:39 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Wed, 26 Feb 2020 08:26:39 -0500
Subject: [talk] Vixie meeting
In-Reply-To: <65a3520b-842f-cda8-baff-74bc12676ce5@ceetonetechnology.com>
References: <65a3520b-842f-cda8-baff-74bc12676ce5@ceetonetechnology.com>
Message-ID: <6d64eb7a-2970-8669-c4a4-3541308d40e5@ceetonetechnology.com>



On 2/25/20 11:19 AM, George Rosamond wrote:
> As some of you may know, the Vixie meeting next week should raise some
> interesting issues with DoH and DoT... basically DNS lookups encrypted
> over https or tls instead of clear text over UDP.
> 
> The issue is a bit more complex than it seems on the surface.
> 
> Most broadly, of course DNS lookups should be encrypted, but what's
> disturbing is that US FF will be set to go to Cloudflare, who obviously
> know this is a wonderful data-mining opportunity.
> 
> The whole issue of "privacy" gets distorted too easily.  Yes, you should
> have privacy in DNS lookups, but sending encrypted lookups to one
> provider is a recipe for privacy from "the other" while centralizing a
> few huge collectors of that data.
> 
> Yes, more providers should be running DOT servers, but that in itself
> isn't the answer.
> 
> This link raises the issue, but misses the dangerous implications of DOH:
> 
> https://techcrunch.com/2020/02/25/firefox-dns-https-default-united-states/
>

This paper is an example of how centralizing DNS lookups is dangerous in
more "outlier" cases with more sophisticated adversaries on the Tor
network for anyone interested in diving deeper (the cached PDF version
should work):

https://www.freehaven.net/anonbib/#dnstor-ndss2017

g



From christos at zoulas.com  Wed Feb 26 08:31:22 2020
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 26 Feb 2020 08:31:22 -0500
Subject: [talk] Vixie meeting
In-Reply-To: <6d64eb7a-2970-8669-c4a4-3541308d40e5@ceetonetechnology.com>
References: <65a3520b-842f-cda8-baff-74bc12676ce5@ceetonetechnology.com>
 <6d64eb7a-2970-8669-c4a4-3541308d40e5@ceetonetechnology.com>
Message-ID: <A965159E-C77D-4A8F-890B-2ED270A11601@zoulas.com>

Here is a good explanation of how it all works:

https://www.netmeister.org/blog/doh-dot-dnssec.html <https://www.netmeister.org/blog/doh-dot-dnssec.html>

christos

> On Feb 26, 2020, at 8:26 AM, George Rosamond <george at ceetonetechnology.com> wrote:
> 
> 
> 
> On 2/25/20 11:19 AM, George Rosamond wrote:
>> As some of you may know, the Vixie meeting next week should raise some
>> interesting issues with DoH and DoT... basically DNS lookups encrypted
>> over https or tls instead of clear text over UDP.
>> 
>> The issue is a bit more complex than it seems on the surface.
>> 
>> Most broadly, of course DNS lookups should be encrypted, but what's
>> disturbing is that US FF will be set to go to Cloudflare, who obviously
>> know this is a wonderful data-mining opportunity.
>> 
>> The whole issue of "privacy" gets distorted too easily.  Yes, you should
>> have privacy in DNS lookups, but sending encrypted lookups to one
>> provider is a recipe for privacy from "the other" while centralizing a
>> few huge collectors of that data.
>> 
>> Yes, more providers should be running DOT servers, but that in itself
>> isn't the answer.
>> 
>> This link raises the issue, but misses the dangerous implications of DOH:
>> 
>> https://techcrunch.com/2020/02/25/firefox-dns-https-default-united-states/
>> 
> 
> This paper is an example of how centralizing DNS lookups is dangerous in
> more "outlier" cases with more sophisticated adversaries on the Tor
> network for anyone interested in diving deeper (the cached PDF version
> should work):
> 
> https://www.freehaven.net/anonbib/#dnstor-ndss2017
> 
> g
> 
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org:8080/mailman/listinfo/talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20200226/86a3a0f9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20200226/86a3a0f9/attachment.bin>

From george at ceetonetechnology.com  Wed Feb 26 08:32:20 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Wed, 26 Feb 2020 08:32:20 -0500
Subject: [talk] Vixie meeting
In-Reply-To: <A965159E-C77D-4A8F-890B-2ED270A11601@zoulas.com>
References: <65a3520b-842f-cda8-baff-74bc12676ce5@ceetonetechnology.com>
 <6d64eb7a-2970-8669-c4a4-3541308d40e5@ceetonetechnology.com>
 <A965159E-C77D-4A8F-890B-2ED270A11601@zoulas.com>
Message-ID: <6a3e9cd7-fd42-abb1-2d86-58efcf37feb9@ceetonetechnology.com>



On 2/26/20 8:31 AM, Christos Zoulas wrote:
> Here is a good explanation of how it all works:
> 
> https://www.netmeister.org/blog/doh-dot-dnssec.html <https://www.netmeister.org/blog/doh-dot-dnssec.html>
> 

Definitely. Jan posted that a while ago... it's a really useful overview.

There's also previous Vixie presentations from vBSDCon, etc on YouTube.

g


> christos
> 
>> On Feb 26, 2020, at 8:26 AM, George Rosamond <george at ceetonetechnology.com> wrote:
>>
>>
>>
>> On 2/25/20 11:19 AM, George Rosamond wrote:
>>> As some of you may know, the Vixie meeting next week should raise some
>>> interesting issues with DoH and DoT... basically DNS lookups encrypted
>>> over https or tls instead of clear text over UDP.
>>>
>>> The issue is a bit more complex than it seems on the surface.
>>>
>>> Most broadly, of course DNS lookups should be encrypted, but what's
>>> disturbing is that US FF will be set to go to Cloudflare, who obviously
>>> know this is a wonderful data-mining opportunity.
>>>
>>> The whole issue of "privacy" gets distorted too easily.  Yes, you should
>>> have privacy in DNS lookups, but sending encrypted lookups to one
>>> provider is a recipe for privacy from "the other" while centralizing a
>>> few huge collectors of that data.
>>>
>>> Yes, more providers should be running DOT servers, but that in itself
>>> isn't the answer.
>>>
>>> This link raises the issue, but misses the dangerous implications of DOH:
>>>
>>> https://techcrunch.com/2020/02/25/firefox-dns-https-default-united-states/
>>>
>>
>> This paper is an example of how centralizing DNS lookups is dangerous in
>> more "outlier" cases with more sophisticated adversaries on the Tor
>> network for anyone interested in diving deeper (the cached PDF version
>> should work):
>>
>> https://www.freehaven.net/anonbib/#dnstor-ndss2017
>>
>> g
>>
>> _______________________________________________
>> talk mailing list
>> talk at lists.nycbug.org
>> http://lists.nycbug.org:8080/mailman/listinfo/talk
> 
> 



From spork at bway.net  Wed Feb 26 14:46:48 2020
From: spork at bway.net (Charles Sprickman)
Date: Wed, 26 Feb 2020 14:46:48 -0500
Subject: [talk] Vixie meeting
In-Reply-To: <A965159E-C77D-4A8F-890B-2ED270A11601@zoulas.com>
References: <65a3520b-842f-cda8-baff-74bc12676ce5@ceetonetechnology.com>
 <6d64eb7a-2970-8669-c4a4-3541308d40e5@ceetonetechnology.com>
 <A965159E-C77D-4A8F-890B-2ED270A11601@zoulas.com>
Message-ID: <DAB6B8D8-C02D-417D-AAC0-F59CD856EFE8@bway.net>


> 
>> On Feb 26, 2020, at 8:26 AM, George Rosamond <george at ceetonetechnology.com> wrote:
>> 
>> 
>> 
>> On 2/25/20 11:19 AM, George Rosamond wrote:
>>> As some of you may know, the Vixie meeting next week should raise some
>>> interesting issues with DoH and DoT... basically DNS lookups encrypted
>>> over https or tls instead of clear text over UDP.
>>> 
>>> The issue is a bit more complex than it seems on the surface.
>>> 
>>> Most broadly, of course DNS lookups should be encrypted, but what's
>>> disturbing is that US FF will be set to go to Cloudflare, who obviously
>>> know this is a wonderful data-mining opportunity.
>>> 
>>> The whole issue of "privacy" gets distorted too easily.  Yes, you should
>>> have privacy in DNS lookups, but sending encrypted lookups to one
>>> provider is a recipe for privacy from "the other" while centralizing a
>>> few huge collectors of that data.
>>> 
>>> Yes, more providers should be running DOT servers, but that in itself
>>> isn't the answer.
>>> 
>>> This link raises the issue, but misses the dangerous implications of DOH:
>>> 
>>> https://techcrunch.com/2020/02/25/firefox-dns-https-default-united-states/
>>> 
>> 
>> This paper is an example of how centralizing DNS lookups is dangerous in
>> more "outlier" cases with more sophisticated adversaries on the Tor
>> network for anyone interested in diving deeper (the cached PDF version
>> should work):
>> 
>> https://www.freehaven.net/anonbib/#dnstor-ndss2017

If I were writing some dystopian sci-fi novel, Cloudflare would be an NSA-run
front for data collection and general spying. ?Hey, HTTPS is hard! Just send
all your encrypted web traffic to our endpoints!?, ?Hey, those dastardly ISPs
are snooping your DNS, why not point all your DNS lookups to us! (please
ignore ways your ISP can figure out where you?re going via looking at your
destination IPs)?.

Please, nobody show me stats on what percentage of web traffic that?s not
the top 100 sites goes through Cloudflare?

C

>> 
>> g
>> 
>> _______________________________________________
>> talk mailing list
>> talk at lists.nycbug.org
>> http://lists.nycbug.org:8080/mailman/listinfo/talk
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20200226/d8433b45/attachment.bin>

From raulcuza at gmail.com  Wed Feb 26 15:30:53 2020
From: raulcuza at gmail.com (Raul Cuza)
Date: Wed, 26 Feb 2020 15:30:53 -0500
Subject: [talk] Vixie meeting
In-Reply-To: <DAB6B8D8-C02D-417D-AAC0-F59CD856EFE8@bway.net>
References: <65a3520b-842f-cda8-baff-74bc12676ce5@ceetonetechnology.com>
 <6d64eb7a-2970-8669-c4a4-3541308d40e5@ceetonetechnology.com>
 <A965159E-C77D-4A8F-890B-2ED270A11601@zoulas.com>
 <DAB6B8D8-C02D-417D-AAC0-F59CD856EFE8@bway.net>
Message-ID: <CAOnfn2wSD3tYjgaRn6=qmMkqCOBkfqW-5mCALvpA9siu-gPNfA@mail.gmail.com>

On Wed, Feb 26, 2020 at 3:12 PM Charles Sprickman <spork at bway.net> wrote:
>
>
> >
> >> On Feb 26, 2020, at 8:26 AM, George Rosamond <george at ceetonetechnology.com> wrote:
> >>
> >>
> >>
> >> On 2/25/20 11:19 AM, George Rosamond wrote:
> >>> As some of you may know, the Vixie meeting next week should raise some
> >>> interesting issues with DoH and DoT... basically DNS lookups encrypted
> >>> over https or tls instead of clear text over UDP.
> >>>
> >>> The issue is a bit more complex than it seems on the surface.
> >>>
> >>> Most broadly, of course DNS lookups should be encrypted, but what's
> >>> disturbing is that US FF will be set to go to Cloudflare, who obviously
> >>> know this is a wonderful data-mining opportunity.
> >>>
> >>> The whole issue of "privacy" gets distorted too easily.  Yes, you should
> >>> have privacy in DNS lookups, but sending encrypted lookups to one
> >>> provider is a recipe for privacy from "the other" while centralizing a
> >>> few huge collectors of that data.
> >>>
> >>> Yes, more providers should be running DOT servers, but that in itself
> >>> isn't the answer.
> >>>
> >>> This link raises the issue, but misses the dangerous implications of DOH:
> >>>
> >>> https://techcrunch.com/2020/02/25/firefox-dns-https-default-united-states/
> >>>
> >>
> >> This paper is an example of how centralizing DNS lookups is dangerous in
> >> more "outlier" cases with more sophisticated adversaries on the Tor
> >> network for anyone interested in diving deeper (the cached PDF version
> >> should work):
> >>
> >> https://www.freehaven.net/anonbib/#dnstor-ndss2017
>
> If I were writing some dystopian sci-fi novel, Cloudflare would be an NSA-run
> front for data collection and general spying. ?Hey, HTTPS is hard! Just send
> all your encrypted web traffic to our endpoints!?, ?Hey, those dastardly ISPs
> are snooping your DNS, why not point all your DNS lookups to us! (please
> ignore ways your ISP can figure out where you?re going via looking at your
> destination IPs)?.
>
> Please, nobody show me stats on what percentage of web traffic that?s not
> the top 100 sites goes through Cloudflare?
>
> C
>

but all the destination IPs belong to Cloudflare.



From george at ceetonetechnology.com  Wed Feb 26 15:45:14 2020
From: george at ceetonetechnology.com (George Rosamond)
Date: Wed, 26 Feb 2020 15:45:14 -0500
Subject: [talk] Vixie meeting
In-Reply-To: <CAOnfn2wSD3tYjgaRn6=qmMkqCOBkfqW-5mCALvpA9siu-gPNfA@mail.gmail.com>
References: <65a3520b-842f-cda8-baff-74bc12676ce5@ceetonetechnology.com>
 <6d64eb7a-2970-8669-c4a4-3541308d40e5@ceetonetechnology.com>
 <A965159E-C77D-4A8F-890B-2ED270A11601@zoulas.com>
 <DAB6B8D8-C02D-417D-AAC0-F59CD856EFE8@bway.net>
 <CAOnfn2wSD3tYjgaRn6=qmMkqCOBkfqW-5mCALvpA9siu-gPNfA@mail.gmail.com>
Message-ID: <bf819309-9fc7-caeb-4087-c569bcedf079@ceetonetechnology.com>



On 2/26/20 3:30 PM, Raul Cuza wrote:
> On Wed, Feb 26, 2020 at 3:12 PM Charles Sprickman <spork at bway.net> wrote:
>>
>>
>>>
>>>> On Feb 26, 2020, at 8:26 AM, George Rosamond <george at ceetonetechnology.com> wrote:
>>>>
>>>>
>>>>
>>>> On 2/25/20 11:19 AM, George Rosamond wrote:
>>>>> As some of you may know, the Vixie meeting next week should raise some
>>>>> interesting issues with DoH and DoT... basically DNS lookups encrypted
>>>>> over https or tls instead of clear text over UDP.
>>>>>
>>>>> The issue is a bit more complex than it seems on the surface.
>>>>>
>>>>> Most broadly, of course DNS lookups should be encrypted, but what's
>>>>> disturbing is that US FF will be set to go to Cloudflare, who obviously
>>>>> know this is a wonderful data-mining opportunity.
>>>>>
>>>>> The whole issue of "privacy" gets distorted too easily.  Yes, you should
>>>>> have privacy in DNS lookups, but sending encrypted lookups to one
>>>>> provider is a recipe for privacy from "the other" while centralizing a
>>>>> few huge collectors of that data.
>>>>>
>>>>> Yes, more providers should be running DOT servers, but that in itself
>>>>> isn't the answer.
>>>>>
>>>>> This link raises the issue, but misses the dangerous implications of DOH:
>>>>>
>>>>> https://techcrunch.com/2020/02/25/firefox-dns-https-default-united-states/
>>>>>
>>>>
>>>> This paper is an example of how centralizing DNS lookups is dangerous in
>>>> more "outlier" cases with more sophisticated adversaries on the Tor
>>>> network for anyone interested in diving deeper (the cached PDF version
>>>> should work):
>>>>
>>>> https://www.freehaven.net/anonbib/#dnstor-ndss2017
>>
>> If I were writing some dystopian sci-fi novel, Cloudflare would be an NSA-run
>> front for data collection and general spying. ?Hey, HTTPS is hard! Just send
>> all your encrypted web traffic to our endpoints!?, ?Hey, those dastardly ISPs
>> are snooping your DNS, why not point all your DNS lookups to us! (please
>> ignore ways your ISP can figure out where you?re going via looking at your
>> destination IPs)?.
>>
>> Please, nobody show me stats on what percentage of web traffic that?s not
>> the top 100 sites goes through Cloudflare?
>>
>> C
>>
> 
> but all the destination IPs belong to Cloudflare.

Spork:

The entire sci-fi genre is based on predictions about the future, not
observations about today!

It's actually interesting to think that years ago, Tor Browser's obvious
weakness was dns lookups, which were unencrypted plain text.  That was a
long time ago.  Then they created a resolver that I wanted to work with
mickey@ (RIP.. it was his bday the other day..) to make portable.

And now DNS lookups are a hot commodity.

Another path is that more providers start running DOT DNS... a long
path, but definitely necessary.

g



From justin at shiningsilence.com  Sat Feb 29 12:24:18 2020
From: justin at shiningsilence.com (Justin Sherrill)
Date: Sat, 29 Feb 2020 12:24:18 -0500
Subject: [talk] Fwd: [GVSAGE] CIS BIND DNS benchmark update
In-Reply-To: <1eb6a825-a3a3-cfd1-c661-359c2247795f@rd1.net>
References: <1eb6a825-a3a3-cfd1-c661-359c2247795f@rd1.net>
Message-ID: <CA+YR8=0A1v=0jqVxWr4O_KvO9Hcq-pTGF012CRH_g5gGwKOjxw@mail.gmail.com>

>From one mailing list to another - overlap.

---------- Forwarded message ---------
From: Ralph Durkee <rd at rd1.net>
Date: Sat, Feb 29, 2020 at 12:04 PM
Subject: [GVSAGE] CIS BIND DNS benchmark update
To: GVSAGE <gvsage at lists.rd1.net>


The Center for Internet Security (https://www.cisecurity.org/) is
currently working on major update to the ISC BIND DNS benchmark to
update the security standard, and we are adding DNSSEC recommendations
for authoritative name servers. I?m leading the effort and I was hoping
to find some DNS admins or other security people that would be
knowledgeable and interested in joining the discussions.  Could you see
if the appropriate person in your organization might be interested?

Thanks,

--
-- Ralph Durkee, CISSP, C|EH, GSEC, GCIH, GSNA, GCIA, GPEN, GXPN
Principal Security Consultant

_______________________________________________
GVSAGE mailing list
GVSAGE at lists.rd1.net
https://ssl.durkee.us/mail-man/listinfo/gvsage