ARIN NS down?

couldn't get address for 'ns1.arin.net': not found couldn't get address for 'ns2.arin.net': not found couldn't get address for 'u.arin.net': not found couldn't get address for 'ns3.arin.net': not found dig: couldn't get address for 'ns1.arin.net': no more srs@Sureshs-MacBook-Pro-2 19:56:18 <~> $ d

Re: ARIN NS down?

Suresh - We’re aware and working the problem. It looks to me like expired RRSIG/DNSKEY’s for the zone, so if you’re using a DNSSEC validating resolver (e.g. Google, Cloudflare, Cogent) then ARIN.NET is unreachable. ARIN’s engineering team is working on resolution now. /Jo

Re: ARIN NS down?

On Fri, Jan 11, 2019 at 07:57:25PM +0530, Suresh Ramasubramanian wrote a message of 56 lines which said: > couldn't get address for 'ns1.arin.net': not found DNSSEC issue, they let the signatures expire

Re: ARIN NS down?

Is this the right time to ask whether everyone who operates DNSSEC validating resolvers was required to click somewhere on the ARIN website that they agree to be bound by the Relying Party Agreement before their resolver can make DNSSEC lookups against the ARIN nameservers? Or does that logic only

Re: ARIN NS down?

On Fri, Jan 11, 2019 at 07:57:25PM +0530, couldn't get address for 'ns1.arin.net': not found Folks - This has been resolved - arin.net zone is again correctly signed. Post-mortem forthcoming, /John John Curran President and CEO American Registry for Int

Dnssec still inoperable on the internet ?— was ARIN NS down?

Thanks for the update that dnssec STILL causes more real world problems than it solves. . That said, arin is a pro outfit. If they can screw it up, like nasa, so can you. No your threats and deploy wisely -- Forwarded message - From: John Curran Date: Fri, Jan 11, 2019 at 6:

Re: Dnssec still inoperable on the internet ?— was ARIN NS down?

On Fri, Jan 11, 2019 at 07:58:25AM -0800, Ca By wrote a message of 488 lines which said: > No your threats and deploy wisely Say no to the threats :-)

Re: Dnssec still inoperable on the internet ?— was ARIN NS down?

On Fri, Jan 11, 2019 at 8:10 AM Stephane Bortzmeyer wrote: > On Fri, Jan 11, 2019 at 07:58:25AM -0800, > Ca By wrote > a message of 488 lines which said: > > > No your threats and deploy wisely > > Say no to the threats :-) > This is nanog, so i used the cisco no Its like , negate threats :)

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

On Thu, Jan 10, 2019 at 8:23 AM Rich Kulawiec wrote: > > The "dumpsterfire" mailing list is for the discussion of security and > privacy issues related to the IoT (Internet of Things). Arguably, > the entire IoT *is* a security and privacy issue, but we'll get to that > in good time. > > If you w

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

A dumpster fire, indeed. On Fri, Jan 11, 2019, 11:26 AM Yang Yu On Thu, Jan 10, 2019 at 8:23 AM Rich Kulawiec wrote: > > > > The "dumpsterfire" mailing list is for the discussion of security and > > privacy issues related to the IoT (Internet of Things). Arguably, > > the entire IoT *is* a secu

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

No HTTPS?!?! Where are the tar and feathers??!?!! This isn't something that needs HTTPS. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Yang Yu" To: "Rich Kulawiec" Cc: "NANOG list" Sent: Fr

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

On Fri, Jan 11, 2019 at 10:30:57AM -0600, Mike Hammett wrote: > No HTTPS?!?! Where are the tar and feathers??!?!! > > This isn't something that needs HTTPS. > - > Mike Hammett > Intelligent Computing Solutions True, but our browser overlords would condemn it because they seem to believe

Re: Dnssec still inoperable on the internet ?— was ARIN NS down?

It's because you see problems it causes, and do not see problems it solves ;) 11.01.19 17:58, Ca By пише: > Thanks for the update that dnssec STILL causes more real world problems > than it solves.  > > . > > That said, arin is a pro outfit. If they can screw it up, like nasa, so > can you.

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

On Fri, Jan 11, 2019 at 08:23:31AM -0800, Yang Yu wrote: > * no HTTPS HTTPS isn't needed for this application. I'll probably add it anyway when I have a chance, but there are other things ahead of it. > * archive is returning HTTP 403 That is exactly what you should expect to see when a Mai

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

On Thu, Jan 10, 2019 at 10:57:02AM -0600, J. Hellenthal via NANOG wrote: > Unfortunately I don???t see this as having very much connectivity where I am > at. It's not the best-connected or most powerful server, however it's been running a bunch of public/private mailing lists for many years and f

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

Thank you! Forwarded that to the RIPE IoT WG. 10 Jan. 2019 г., 19:23 Rich Kulawiec : > The "dumpsterfire" mailing list is for the discussion of security and > privacy issues related to the IoT (Internet of Things). Arguably, > the entire IoT *is* a security and privacy issue, but we'll get to th

Weekly Routing Table Report

This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@li

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

On Fri, Jan 11, 2019 at 12:17:09PM -0500, Rich Kulawiec wrote: > On Fri, Jan 11, 2019 at 08:23:31AM -0800, Yang Yu wrote: > > * no HTTPS > > HTTPS isn't needed for this application. I'll probably add it anyway > when I have a chance, but there are other things ahead of it. I respectfully disag

Re: Dnssec still inoperable on the internet ?― was ARIN NS down?

> It's because you see problems it causes, and do not see problems it > solves ;) > >> Thanks for the update that dnssec STILL causes more real world problems >> than it solves.  hmmm. has anyone set about to measure that? randy

Re: Dnssec still inoperable on the internet ?— was ARIN NS down?

Maybe a Report-URI for DNSSEC Validation Errors? :-) > On 11 Jan 2019, at 20:16, Randy Bush wrote: > >> It's because you see problems it causes, and do not see problems it >> solves ;) >> >>> Thanks for the update that dnssec STILL causes more real world problems >>> than it solves. > > hmmm.

Re: Dnssec still inoperable on the internet ?— was ARIN NS down?

On Fri, 11 Jan 2019, Ca By wrote: Thanks for the update that dnssec STILL causes more real world problems than it solves. Do you feel the same way about RPKI? -- Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

On 1/11/2019 1:11 PM, Andreas Ott wrote: Admittedly, mailman does send you the password in clear text over SMTP if you ask for it  but if done right, fwiw,, wouldn't that be sent over SMTP using TLS encryption? (but, then again, that ALSO requires a certificate!) -- Rob McEwen, invaluement

Re: Dnssec still inoperable on the internet ?— was ARIN NS down?

On Fri, Jan 11, 2019 at 10:54 AM Mikael Abrahamsson wrote: > On Fri, 11 Jan 2019, Ca By wrote: > > > Thanks for the update that dnssec STILL causes more real world problems > > than it solves. > > Do you feel the same way about RPKI? > Misorgination is a real threat we see all the time (threat o

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

11 Jan. 2019 г., 22:33 Rob McEwen : > but if done right, fwiw,, wouldn't that > be sent over SMTP using TLS encryption So STARTTLS strip is not a problem anymore? -- Töma

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

On 01/11/2019 12:32 PM, Rob McEwen wrote: but if done right, fwiw,, wouldn't that be sent over SMTP using TLS encryption? Oy vey. in-flight vs at-rest encryption. (but, then again, that ALSO requires a certificate!) Let's Encrypt works perfectly fine for that too. }:-) -- Grant. . .

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

On 1/11/19 12:11 PM, Andreas Ott wrote: On Fri, Jan 11, 2019 at 12:17:09PM -0500, Rich Kulawiec wrote: On Fri, Jan 11, 2019 at 08:23:31AM -0800, Yang Yu wrote: * no HTTPS HTTPS isn't needed for this application. I'll probably add it anyway when I have a chance, but there are other thin

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

Additionally, subscribe mail to the email address is bouncing. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification http://www.SuretyMail.com/ Certified Sender DNSBL here: iadb.isipp.com Info here: https://www.isipp.com/email-accreditation/for-isps/ G

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

> On 12 Jan 2019, at 6:36 am, Töma Gavrichenkov wrote: > > 11 Jan. 2019 г., 22:33 Rob McEwen : > > but if done right, fwiw,, wouldn't that > > be sent over SMTP using TLS encryption > > So STARTTLS strip is not a problem anymore? If you deploy DANE (client and server sides) then stripping ST

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

11 Jan. 2019 г., 23:19 Mark Andrews : >> So STARTTLS strip is not a problem anymore? > > If you deploy DANE (client and server > sides) then stripping STARTTLS is > ineffective for the target domain. If you defer to send (and finally bounce) everything targeted at a domain that fails TLSA lookup,

2019-01-11 ARIN.NET DNSSEC Outage – Post-Mortem (was: Re: ARIN NS down?)

On 11 Jan 2019, at 10:39 AM, John Curran mailto:jcur...@arin.net>> wrote: On Fri, Jan 11, 2019 at 07:57:25PM +0530, couldn't get address for 'ns1.arin.net': not found Folks - This has been resolved - arin.net zone is again correctly signed. Post-mort

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

Whaddya expect guys, the mailing list is hosted on an embedded DVR recorder On Fri, Jan 11, 2019 at 12:52 PM Töma Gavrichenkov wrote: > 11 Jan. 2019 г., 23:19 Mark Andrews : > >> So STARTTLS strip is not a problem anymore? > >> > > If you deploy DANE (client and server > > sides) then stripping

SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

Hello NANOG, Belated new year wishes. I would like to gather some feedback from you all. I'm trying to propose two things to the Internet Standard and it's related to SMTP. (1) STARTTLS downgrade protection in a dead simple way (2) SMTPS (Implicit TLS) on a new port (26). This is totally option

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

Having been through this many times, I'd say that probably the best way to advocate for something is to advocate for what the *problem* is much more than what the *solution* is. Invariably, things are more complex than we imagine in the solution space and the people who inhabit that space are m

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On 1/11/19 10:38 AM, Viruthagiri Thirumavalavan wrote: Hello NANOG, Belated new year wishes. I would like to gather some feedback from you all. I'm trying to propose two things to the Internet Standard and it's related to SMTP. (1) STARTTLS downgrade protection in a dead simple way (2) SMTP

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On Fri, Jan 11, 2019 at 4:22 PM Viruthagiri Thirumavalavan wrote: > What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional > security than a downgrade protected STARTTLS. Let's not waste a port." In addition, it bypasses all the security folks have built around the idea of b

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan wrote: >> In addition, it bypasses all the security folks have built around the >> idea of blocking port 25 traffic from sources which should not be >> operating as mail servers. Let's not make the network less secure in >> the name of mak

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

Hello Doug, it's happening in ietf-smtp. This is my first proposal. So haven't created the I-D yet. I'm not sure how to create one. That's why I published my proposal in the medium. Please see the medium link I posted earlier. Thanks. On Sat, Jan 12, 2019, 6:46 AM Doug Royer On 1/11/19 10:38 A

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

> > In addition, it bypasses all the security folks have built around the > idea of blocking port 25 traffic from sources which should not be > operating as mail servers. Let's not make the network less secure in > the name of making it more so. I already addressed this issue in the "security con

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

> > While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed Come on Mr. Herrin. Blocking a port is much easier than deprecating a heavily used protocol. Google stats show ~75% use IPv4. On Sat, Jan 12, 2019 at 7:30 AM William Herrin wrote: > On Fri, Jan 11, 2019 at 5:52 PM Vir

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

But why do you think creating an out of band verification channel and separate port is going to work for this? There is plenty of local policy available as well to mandate that tls be negotiated with a set of allowed ciphers and prohibit others —srs From: NAN

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On Fri, 11 Jan 2019 at 20:01, William Herrin wrote: > > On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan > wrote: > >> In addition, it bypasses all the security folks have built around the > >> idea of blocking port 25 traffic from sources which should not be > >> operating as mail serv

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On Fri, Jan 11, 2019 at 6:14 PM Viruthagiri Thirumavalavan wrote: >> While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed > > Come on Mr. Herrin. Hi Viruthagiri, If you don't want to face the hyperbole then don't stick your head in the sand. Unless you grossly underestimate th

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On 1/11/19 9:52 PM, William Herrin wrote: Your other idea of signaling via DNS that a man in the middle is present if the target SMTP server fails to support encryption could have merit. I think the specific mechanism (overloading the host name) is unwise but I'd be interested to see the concept

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

If you all think my prefix proposal have some merits, it still paves the way for future smtps proposals. So I have no issues with killing smtps part of my proposal. As for signalling, I'm not sure whether moving the signalling part to another record type is a good idea. Because my signalling prop

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now? How much more of a problem will it be over the next year or two as older hardware is retired and new servers + software deployed, or as is more likel

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

Hello Mr. Ramasubramanian, When I originally drafted the SMTPS proposal, I thought those plaint text part before the STARTTLS command leaks some sensitive info. e.g. 220 mail.ashleymadison.com AshleyMadison ESMTP Service Ready Those text will always be transferred in plain text. So I thought Imp

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On Fri, 11 Jan 2019 at 22:00, Suresh Ramasubramanian wrote: > Most new MTA implementations over the past several years default to TLS with > strong ciphers. So how much of a problem is low or no TLS right now? The real problem is that opportunistic StartTLS stops being opportunistic the minute

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

Any place that has a TLS misconfig will pretty much notice it very quickly indeed Opportunistic just means use TLS if it is advertised as available else continue encrypted. Not sure why encountering a starttls negates it. To the OP - what's the point of hiding the hostname in the smtp banner?

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said: > When I originally drafted the SMTPS proposal, I thought those plaint text > part before the STARTTLS command leaks some sensitive info. So - given that multiple people have explained to you on the ietf-smtp list that there's n

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said: > But I still want the future of email to adopt Implicit TLS. So someday we > can kill Opportunistic TLS. I already lost the case for security. So my > smtps part of the proposal not gonna fly. I'm just here to learn whether > Im

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

> To the OP - what's the point of hiding the hostname in the smtp banner? > You already know from the dns. Concerned about the MTA version? You can > configure postfix to claim it is exchange or avian carrier for that matter I was concerned about the Brand name right next to the 220 hostname exam

Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

On Fri, 11 Jan 2019 at 22:51, Suresh Ramasubramanian wrote: > Any place that has a TLS misconfig will pretty much notice it very quickly > indeed I disagree. Plenty of evidence that Microsoft/Hotmail doesn't notice / doesn't care. Many people don't notice / don't care about Hotmail, either. G

Re: Announcing: "dumpsterfire", the mailing list for IoT security/privacy issues

On 1/11/2019 2:50 PM, Grant Taylor via NANOG wrote: On 01/11/2019 12:32 PM, Rob McEwen wrote: but if done right, fwiw,, wouldn't that be sent over SMTP using TLS encryption? Oy vey.  in-flight vs at-rest encryption.  which is why i said "fwiw", acknowledging upfront that TLS transmission e