RE: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. matthew black california state university, long beach -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Sunday, April 13, 2014 7:31 AM To: Bengt Larsson Cc: nanog@nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] It's quite plausible that they watch the changes in open-source projects to find bugs. They could do nice diffs and everything. the point of open source is that the community is supposed to be doing this. we failed. randy
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Le 2014-04-14 10:38, Matthew Black a écrit : Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. All modern OSes do that. What's your point? Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
RE: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Also on this same idea, in his book The Puzzle Palace, James Bamford claims that we knew of the pending attack on Pearl Harbor but did nothing, because that would compromise we broke the Japanese Purple Cipher. matthew black california state university, long beach -Original Message- From: William Herrin [mailto:b...@herrin.us] Sent: Friday, April 11, 2014 2:06 PM To: nanog@nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker niels=na...@bakker.net wrote: Please go read up on some recent and less recent history before making judgments on what would be unusually gutsy for that group of people. I'm not saying this has been happening but you will have to come up with a better defense than it seems unlikely to me personally. Let me know when someone finds the second shooter on the grassy knoll. As for me, I do have some first hand knowledge as to exactly how sensitive several portions of the federal government are to the security of the servers which hold their data. They may not hold YOUR data in high regard... but the word sensitive does not do justice to the attention lavished on THEIR servers' security. In WW2 we protected the secret of having cracked enigma by deliberately ignoring a lot of the knowledge we gained. So such things have happened. But we didn't use enigma ourselves -- none of our secrets were at risk. And our adversaries today have no secrets more valuable than our own. -Bill
RE: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
I applaud their effort but please see https://blogs.akamai.com/2014/04/heartbleed-update-v3.html http://lekkertech.net/akamai.txt Kind regards / Vriendelijke groet, IS Group Thijs Stuurman -Oorspronkelijk bericht- Van: Niels Bakker [mailto:niels=na...@bakker.net] Verzonden: Sunday, April 13, 2014 6:53 PM Aan: nanog@nanog.org Onderwerp: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] * ra...@psg.com (Randy Bush) [Sun 13 Apr 2014, 16:52 CEST]: the point of open source is that the community is supposed to be doing this. we failed. Versus all of the closed source bugs that nobody can know of or do anything about? for those you can blame the vendor. BSAFE is almost worse if you go by the recent advisories that have been released about it. Many vendors incorporated OpenSSL into their products and sold the result for commercial profit without doing (in retrospect) enough due diligence. Besides, having a third party to blame doesn't make our data safer... At least one vendor, Akamai is helping out now: http://marc.info/?l=openssl-usersm=139723710923076w=2 I hope other vendors will follow suit. this one is owned by the community. it falls on us to try to lower the probability of a next one by actively auditing source as our civic duty. I donated some money to the OpenSSL project and hope others will do, or have already done, the same. It's clear that they are internet infrastructure and need more support. -- Niels.
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Matthew, On Mon, Apr 14, 2014 at 10:48 AM, Matthew Black matthew.bl...@csulb.eduwrote: Also on this same idea, in his book The Puzzle Palace, James Bamford claims that we knew of the pending attack on Pearl Harbor but did nothing, because that would compromise we broke the Japanese Purple Cipher. I assume you refers to pages 36 through 39 of The Puzzle Palace which is almost entirely a recounting of bureaucratic fumbling and delay. The sensitivity of a Purple Cipher decode did cause the intercepted information to be sent by a less immediate means to the US Naval authorities in Hawaii. Nevertheless, it was sent with every expectation that those authorities would receive it before the time of the attack. We do not know what those authorities would have done it they had received the intercept information as expected, instead of receiving it about 6 hours after the first bomb struck Pearl Harbor. Your implication that Bamford says we decided to do nothing bears no relationship to what Bamford actually wrote. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com matthew black california state university, long beach -Original Message- From: William Herrin [mailto:b...@herrin.us] Sent: Friday, April 11, 2014 2:06 PM To: nanog@nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker niels=na...@bakker.net wrote: Please go read up on some recent and less recent history before making judgments on what would be unusually gutsy for that group of people. I'm not saying this has been happening but you will have to come up with a better defense than it seems unlikely to me personally. Let me know when someone finds the second shooter on the grassy knoll. As for me, I do have some first hand knowledge as to exactly how sensitive several portions of the federal government are to the security of the servers which hold their data. They may not hold YOUR data in high regard... but the word sensitive does not do justice to the attention lavished on THEIR servers' security. In WW2 we protected the secret of having cracked enigma by deliberately ignoring a lot of the knowledge we gained. So such things have happened. But we didn't use enigma ourselves -- none of our secrets were at risk. And our adversaries today have no secrets more valuable than our own. -Bill
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Apr 13, 2014, at 7:52 AM, Randy Bush ra...@psg.com wrote: the point of open source is that the community is supposed to be doing this. we failed. Versus all of the closed source bugs that nobody can know of or do anything about? for those you can blame the vendor. this one is owned by the community. it falls on us to try to lower the probability of a next one by actively auditing source as our civic duty. is that kind of like jury duty? if only it were more like literature, which we could read for enjoyment. randy signature.asc Description: Message signed with OpenPGP using GPGMail
DMARC - CERT?
Just a thought. I keep thinking that Yahoo's publishing of their p=reject policy, and the subsequent massive denial of service to lost of list traffic might be viewed as a computer security incident. Anybody think that reporting via CERT channels might be an appropriate response? (I do, and probably will - but curious what others think.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Yes Matthew it should. The question is whether they do or not. Todd On 4/14/2014 7:38 AM, Matthew Black wrote: Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. matthew black california state university, long beach -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Sunday, April 13, 2014 7:31 AM To: Bengt Larsson Cc: nanog@nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] It's quite plausible that they watch the changes in open-source projects to find bugs. They could do nice diffs and everything. the point of open source is that the community is supposed to be doing this. we failed. randy -- - Personal Email - Disclaimers Apply
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Vladis is %100 on the money here. Lets take this a step farther and ask is there a criminal liability for the person who checked that code in - Oh you bet there is... Todd On 4/11/2014 5:49 PM, valdis.kletni...@vt.edu wrote: On Sat, 12 Apr 2014 07:56:01 +1000, Matt Palmer said: The interesting thing to me is that the article claims the NSA have been using this for over two years, but 1.0.1 (the first vulnerable version) was only released on 14 Mar 2012. That means that either: * The NSA found it *amazingly* quickly (they're very good at what they do, but I don't believe them have superhuman talents); or You seriously think the NSA *isn't* watching the commits to security-relevant open source? Remember - it was a bonehead bug, it's *not* unreasonable for somebody who was auditing the code to spot it. Heck, there's a good chance that automated tools could have spotted it. -- - Personal Email - Disclaimers Apply
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Mon, Apr 14, 2014 at 9:27 AM, TGLASSEY tglas...@earthlink.net wrote: Vladis is %100 on the money here. Lets take this a step farther and ask is there a criminal liability for the person who checked that code in - Oh you bet there is... Todd Thank you--I needed some humour in my morning, I was starting to take the day too seriously. Thank you for putting a smile back on my face, and giving me something to laugh about today. ^_^ Matt
Re: DMARC - CERT?
I don't see what the big deal is here. They don't want your messages and they made that clear. Their policy considers these messages spam. If you really want to get your mailing list messages through, then you need to evade their filters just like every other spammer has to. -Laszlo On Apr 14, 2014, at 4:32 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Well... how about this, from Yahoo's own posting: We know there are about 30,000 affected email sending services, but we also know that the change needed to support our new DMARC policy is important and not terribly difficult to implement. To me - this sure looks, smells, and quacks like a denial-of-service attack against a system I operate, and the subscriber to the lists that I support -- somewhat akin to exploding a bomb in a public square, and then taking credit for it. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DMARC - CERT?
On Mon, 14 Apr 2014 16:56:46 -, Laszlo Hanyecz said: If you really want to get your mailing list messages through, The problem isn't the rest of us trying to mail to Yahoo. The problem is when Yahoo users post to lists that use DMARC, and the result is the yahoo user's mail getting bounced or dumped on the postmaster. pgpb7noPKGPZd.pgp Description: PGP signature
Re: DMARC - CERT?
Isn't it the other way around? They don't want their users to be able to send to mailing lists. They receive traffic from the lists just fine. Their policy considers only effects mail originating from their users. Yahoo subscribers can receive messages form nanog just fine, but they can't send to it. Miles Laszlo Hanyecz wrote: I don't see what the big deal is here. They don't want your messages and they made that clear. Their policy considers these messages spam. If you really want to get your mailing list messages through, then you need to evade their filters just like every other spammer has to. -Laszlo On Apr 14, 2014, at 4:32 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Well... how about this, from Yahoo's own posting: We know there are about 30,000 affected email sending services, but we also know that the change needed to support our new DMARC policy is important and not terribly difficult to implement. To me - this sure looks, smells, and quacks like a denial-of-service attack against a system I operate, and the subscriber to the lists that I support -- somewhat akin to exploding a bomb in a public square, and then taking credit for it. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DMARC - CERT?
By their statement it's obvious that yahoo doesn't care about what they broke. It's unfortunate that email has become so centralized that one entity can cause so much 'trouble'. Maybe it's a good opportunity to encourage the affected mailing list subscribers to use their own domains for email, and host it themselves if possible. -Laszlo On Apr 14, 2014, at 5:05 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Isn't it the other way around? They don't want their users to be able to send to mailing lists. They receive traffic from the lists just fine. Their policy considers only effects mail originating from their users. Yahoo subscribers can receive messages form nanog just fine, but they can't send to it. Miles Laszlo Hanyecz wrote: I don't see what the big deal is here. They don't want your messages and they made that clear. Their policy considers these messages spam. If you really want to get your mailing list messages through, then you need to evade their filters just like every other spammer has to. -Laszlo On Apr 14, 2014, at 4:32 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Well... how about this, from Yahoo's own posting: We know there are about 30,000 affected email sending services, but we also know that the change needed to support our new DMARC policy is important and not terribly difficult to implement. To me - this sure looks, smells, and quacks like a denial-of-service attack against a system I operate, and the subscriber to the lists that I support -- somewhat akin to exploding a bomb in a public square, and then taking credit for it. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 1:03 PM, valdis.kletni...@vt.edu wrote: The problem is when Yahoo users post to lists that use DMARC, and the result is the yahoo user's mail getting bounced or dumped on the postmaster. Basically, this is just like old ORBS. If you were an ISP, you had to check your local users' IP addresses smarthosting through your mail server against ORBS or your mail server would inevitably be listed. Now, as then, the solution is: if the domain has a DMARC listing, mail addresses using it aren't permitted to post to the list. As I tried to say before but was probably too subtle -- just flunk validation for all DMARC-using messages, across the board without exception, and then act on that failure as the DMARC DNS records indicate that the sender wants you to. Especially the ones to abuse@ and your other POCs. That'll clean up the use of DMARC right quick. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 1:25 PM, Laszlo Hanyecz las...@heliacal.net wrote: By their statement it's obvious that yahoo doesn't care about what they broke. It's unfortunate that email has become so centralized that one entity can cause so much 'trouble'. Maybe it's a good opportunity to encourage the affected mailing list subscribers to use their own domains for email, and host it themselves if possible. I sort of wonder if this is really just yahoo trying to use a stick to motivate people to do the right thing? It seems like everyone's been trying for a while to 'make email better'... and that perhaps DMARC will make it somewhat better, and if setup properly this is a non-issue... after much faffing: Welp, how about we whack the mail-lists (and others) with a stick and get movement int he right direction? not sure this is all bad... and i think the fix is pretty straightforward for list folk, right? so all the faffing on this list and others took longer to do than the fix-action? -chris
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 10:25 AM, Laszlo Hanyecz las...@heliacal.netwrote: By their statement it's obvious that yahoo doesn't care about what they broke. It's unfortunate that email has become so centralized that one entity can cause so much 'trouble'. Maybe it's a good opportunity to encourage the affected mailing list subscribers to use their own domains for email, and host it themselves if possible. -Laszlo So, I take it you prefer a world in which there's no sender validation, and receiving floods of spoofed sender email spam is just part of the price of being on the internet? I'm finding myself vaguely annoyed that for so long people have complained that big mail providers need to clean up their act; and now, when one of them decides to respond to the complaints and start taking action to try to clean things up, the response seems to be wait, we were happy just bitching and moaning--we didn't want you to actually *change* anything! Matt
Re: DMARC - CERT?
Christopher Morrow wrote: On Mon, Apr 14, 2014 at 1:25 PM, Laszlo Hanyecz las...@heliacal.net wrote: By their statement it's obvious that yahoo doesn't care about what they broke. It's unfortunate that email has become so centralized that one entity can cause so much 'trouble'. Maybe it's a good opportunity to encourage the affected mailing list subscribers to use their own domains for email, and host it themselves if possible. I sort of wonder if this is really just yahoo trying to use a stick to motivate people to do the right thing? It seems like everyone's been trying for a while to 'make email better'... and that perhaps DMARC will make it somewhat better, and if setup properly this is a non-issue... after much faffing: Welp, how about we whack the mail-lists (and others) with a stick and get movement int he right direction? not sure this is all bad... and i think the fix is pretty straightforward for list folk, right? so all the faffing on this list and others took longer to do than the fix-action? Well, if you consider writing software patches to complicated software simple. And it would certainly help if the guidance on what to do is clearer - last week, dmarc.org's FAQ listed, as among the options for list operators: Add an Original Authentication Results http://tools.ietf.org/html/draft-kucherawy-original-authres-00 (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results. -- which would be transparent to list subscribers but, as of a couple of days ago, that's qualified by: *This is not a short term solution.* Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012. No receivers implementing DMARC are currently known to make use of OAR from external sources. So the low-impact (to end users) fix is now not recommended, and all the other available fixes require changes that degrade long-accepted functionality of mailing lists (e.g., the ability to reply to the author of a message). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 1:33 PM, Matthew Petach mpet...@netflight.com wrote: So, I take it you prefer a world in which there's no sender validation, and receiving floods of spoofed sender email spam is just part of the price of being on the internet? That is clearly not what this issue is about. I'm finding myself vaguely annoyed that for so long people have complained that big mail providers need to clean up their act; and now, when one of them decides to respond to the complaints and start taking action to try to clean things up, the response seems to be wait, we were happy just bitching and moaning--we didn't want you to actually *change* anything! What yahoo didn't do was first tell their users to unsubscribe from all mailinglists. DMARC hasn't cut down on yahoo spam so far. Yahoo's spam problem was (is?) centered on account hijacks. -Jim P.
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker niels=na...@bakker.netwrote: At least one vendor, Akamai is helping out now: http://marc.info/?l=openssl-usersm=139723710923076w=2 I hope other vendors will follow suit. Although it appears they may now be regretting doing so... http://www.techworld.com.au/article/542813/akamai_admits_its_openssl_patch_faulty_reissues_keys/ (Of course, the end result is positive, but...) Scott
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Apr 14, 2014, at 15:47 , Scott Howard sc...@doc.net.au wrote: On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker niels=na...@bakker.netwrote: At least one vendor, Akamai is helping out now: http://marc.info/?l=openssl-usersm=139723710923076w=2 I hope other vendors will follow suit. Although it appears they may now be regretting doing so... http://www.techworld.com.au/article/542813/akamai_admits_its_openssl_patch_faulty_reissues_keys/ (Of course, the end result is positive, but...) [NOTE: I'll just remind everyone up front that I worked at Akamai for a very long time, so take my comments with however many grains of salt you feel appropriate.] If the only thing that happens when a large company steps up to help the open source community is ridicule and/or derision, one should probably not in the same breath ask why no companies are publishing any code. I applaud Akamai for trying, for being courageous enough to post code, and for bucking the trend so many other companies are following by being more secretive every year. Or we can flame anyone who tries, then wonder why no one is trying. -- TTFN, patrick signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Mon, Apr 14, 2014 at 3:59 PM, Patrick W. Gilmore patr...@ianai.net wrote: I applaud Akamai for trying, for being courageous enough to post code, and for bucking the trend so many other companies are following by being more secretive every year. Or we can flame anyone who tries, then wonder why no one is trying. I thought vendors existed primarily as a place to hang the blame when dealing with a manager or customer who just doesn't get it. -Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 04/14/2014 12:59 PM, Patrick W. Gilmore wrote: On Apr 14, 2014, at 15:47 , Scott Howard sc...@doc.net.au wrote: On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker niels=na...@bakker.netwrote: At least one vendor, Akamai is helping out now: http://marc.info/?l=openssl-usersm=139723710923076w=2 I hope other vendors will follow suit. Although it appears they may now be regretting doing so... http://www.techworld.com.au/article/542813/akamai_admits_its_openssl_patch_faulty_reissues_keys/ (Of course, the end result is positive, but...) [NOTE: I'll just remind everyone up front that I worked at Akamai for a very long time, so take my comments with however many grains of salt you feel appropriate.] If the only thing that happens when a large company steps up to help the open source community is ridicule and/or derision, one should probably not in the same breath ask why no companies are publishing any code. I applaud Akamai for trying, for being courageous enough to post code, and for bucking the trend so many other companies are following by being more secretive every year. Or we can flame anyone who tries, then wonder why no one is trying. Agreed ... review is good, comments on needed fixes are good, but saying that Akamai, should not be sending out non-functional, bug ridden patches to the OpenSSL community as Pinckaers did is not constructive. Part of the problem here is the whole You can't play in my sandbox! attitude. Doug
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 11:24 AM, Jim Popovitch jim...@gmail.com wrote: DMARC hasn't cut down on yahoo spam so far. Yahoo's spam problem was (is?) centered on account hijacks. I just checked my spam folder for the past month. Out of about 80 messages from Yahoo, I can see about 3 that went via Yahoo's mail servers. ie, 90% were/would have been blocked using DMARC. Of course, I'm sure the spammers will simply start changing yahoo.com to somethingelse.com once they realize - but from Yahoo's perspective, that's obviously a positive. Whilst I don't agree with the way that Yahoo has done this (particularly around communication), I think the end result is only going to be positive. At a high level it's no different than when people started rejecting mail from hosts without PTR records, or when ISPs started blocking outbound port 25 - they both caused things to break, and both caused people to have to take action to fix the brokenness, but in the long run they were both hugely positive. Scott
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard sc...@doc.net.au wrote: Whilst I don't agree with the way that Yahoo has done this (particularly around communication), how could they have communicated this better? how can we all learn from this? -chris
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Mon, Apr 14, 2014 at 03:59:21PM -0400, Patrick W. Gilmore wrote: On Apr 14, 2014, at 15:47 , Scott Howard sc...@doc.net.au wrote: On Sun, Apr 13, 2014 at 9:52 AM, Niels Bakker niels=na...@bakker.netwrote: At least one vendor, Akamai is helping out now: http://marc.info/?l=openssl-usersm=139723710923076w=2 I hope other vendors will follow suit. Although it appears they may now be regretting doing so... http://www.techworld.com.au/article/542813/akamai_admits_its_openssl_patch_faulty_reissues_keys/ (Of course, the end result is positive, but...) [NOTE: I'll just remind everyone up front that I worked at Akamai for a very long time, so take my comments with however many grains of salt you feel appropriate.] If the only thing that happens when a large company steps up to help the open source community is ridicule and/or derision, one should probably not in the same breath ask why no companies are publishing any code. I applaud Akamai for trying, for being courageous enough to post code, and for bucking the trend so many other companies are following by being more secretive every year. Or we can flame anyone who tries, then wonder why no one is trying. -- TTFN, patrick well, if $vendor publishes code frags, the code must have been vetted and ready for _my_ environment so i'll just cut/paste and then when it doesn't work, its their fault for leading me down the primrose path... $vendor, that why I pay you... to read my mind! darn it. /bill
Re: DMARC - CERT?
On 04/14/2014 01:20 PM, Christopher Morrow wrote: On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard sc...@doc.net.au wrote: Whilst I don't agree with the way that Yahoo has done this (particularly around communication), how could they have communicated this better? how can we all learn from this? The obvious ones would have been to announce a flag day somewhere far enough in advance to give list software devs time to adapt, and to work with list software devs on a solution. Everyone involved in DMARC has known from day 1 that it will break mailing lists. There has been an enormous amount of whinging about this. (If you think NANOG is bad, you should see the IETF lists.) But if Yahoo! had stood up and said, We know that this mailing lists are a problem, but we think that the value of DMARC outweighs this because and then actually set a data, maybe some of the whinging could have turned into actual productive work on fixing the problem. Doug
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard sc...@doc.net.au wrote: Whilst I don't agree with the way that Yahoo has done this (particularly around communication), how could they have communicated this better? how can we all learn from this? They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. They could have made the change not late on a Friday afternoon (or well into the weekend for most of the world). -- Matthias
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton do...@dougbarton.us wrote: The obvious ones would have been to announce a flag day somewhere far enough in advance to give list software devs time to adapt, and to work with list software devs on a solution. where would they communicate this? on the blog that matt pointed at? in bgp announcements? err... homepage? -chris (I watch the ietf list for this, and muted the conversation...)
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi matth...@leisi.net wrote: They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. communicated it where? They could have made the change not late on a Friday afternoon (or well into the weekend for most of the world). a friday change like this is not ideal... but, it looks like any time change like this would have had fallout.
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 4:38 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton do...@dougbarton.us wrote: The obvious ones would have been to announce a flag day somewhere far enough in advance to give list software devs time to adapt, and to work with list software devs on a solution. where would they communicate this? on the blog that matt pointed at? in bgp announcements? err... homepage? What they should have done is followed their (the dmarc spec authors, of which one works for Yahoo) own advice that dmarc wasn't for domains with users. But, hey, we all know it's hard to get good tech press by simply sponsoring and spec'ing a backend tech solution for some dark corner of the internet. -Jim P.
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi matth...@leisi.net wrote: They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. communicated it where? The Internet. A blog entry and a post to a few key relevant mailing lists would have resulted in the message spreading far better than it was. There's no way that they could have communicated it to every mailing list admin on the planet, but they could have at least given a heads-up to some major parts of the community. The great thing about the Internet is that if it's important enough to be shared, you don't need to try too hard to make that happen - others will look after it for you. But you need to make the effort to get it started, and Yahoo didn't do that here (or at least, they did, but they did it by actually making the change by which time it was too late!) Scott
Re: DMARC - CERT?
On 04/14/2014 01:38 PM, Christopher Morrow wrote: On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton do...@dougbarton.us wrote: The obvious ones would have been to announce a flag day somewhere far enough in advance to give list software devs time to adapt, and to work with list software devs on a solution. where would they communicate this? Well mailop for one. on the blog that matt pointed at? I suppose ... there used to be a Yahoo! mail blog but I think it got shut down. BTW, another obvious benefit to announcing a flag day would have been to give more people time to set up DMARC. I haven't yet (on my personal mail server) because there hadn't been sufficient uptake to warrant it. Yahoo! telling everyone that they will be implementing it would have given people incentive. Doug
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 4:39 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi matth...@leisi.net wrote: They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. communicated it where? To their user base? They could have easily sent an email announcement to all their users explaining that the change would cause problems when their users post to mailinglists. -Jim P.
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 4:44 PM, Scott Howard sc...@doc.net.au wrote: On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi matth...@leisi.net wrote: They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. communicated it where? The Internet. I was trying, really, to be not-funny with my question. if you're going to do something that has the potential to affect (say, for example) email to a wide set of people, most of which are NOT your direct users, how do you go about making that public? 'the internet' isn't really a good answer for 'how do you notify'. Doug's note that: email mailops is good... but I'm not sure how many people that run lists listen to mailops? (I don't ... i don't run any big list, but...) I also wonder about update cycles for software in this realm? and for very larger list operators there's probably some customization and such to hurdle over on the upgrade path, eh? so how much leadtime is enough? how much is too much? 1yr seems like a long time - people will forget, 1wk doesn't seem like enough to avoid firedrills and un-intended bugs. A blog entry and a post to a few key relevant mailing lists would have specifically which mail-lists? resulted in the message spreading far better than it was. There's no way that they could have communicated it to every mailing list admin on the planet, but they could have at least given a heads-up to some major parts of the community. The great thing about the Internet is that if it's important enough to be shared, you don't need to try too hard to make that happen - others will look after it for you. But you need to make the effort to get it started, and Yahoo didn't do that here (or at least, they did, but they did it by actually making the change by which time it was too late!) Scott
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 4:44 PM, Doug Barton do...@dougbarton.us wrote: On 04/14/2014 01:38 PM, Christopher Morrow wrote: On Mon, Apr 14, 2014 at 4:28 PM, Doug Barton do...@dougbarton.us wrote: The obvious ones would have been to announce a flag day somewhere far enough in advance to give list software devs time to adapt, and to work with list software devs on a solution. where would they communicate this? Well mailop for one. Or even the dmarc mailing list(s) I've seen Yahoo operate over the years, they are usually much better at orchestrating changes, which suggests that this change wasn't well thought out (or possibly even planned). -Jim P.
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 10:33:40AM -0700, Matthew Petach wrote: So, I take it you prefer a world in which there's no sender validation, and receiving floods of spoofed sender email spam is just part of the price of being on the internet? Sender validation means NOTHING in a world with hundreds of millions of bots and hundreds of millions of email accounts that are either (a) hijacked or (b) created at will by the bot herders. My spamtraps see spam all day every day from all over the world that passes whatever alleged sender validation technology is the flavor-of-the-month. Can it work in some isolated edge cases? Sure. Can it work on an Internet scale? No. As I've said many times, email forgery is not the problem. It's a symptom of the problem, and the problem is rotten underlying security coupled with negligent and incompetent operational practice. But fixing that is hard, and nobody -- not Yahoo and not anybody else either -- wants to tackle it. It's much easier to roll out stuff like this and pretend that it works and write a press release and declare success. ---rsk
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Mon, Apr 14, 2014 at 12:59 PM, Patrick W. Gilmore patr...@ianai.net wrote: I applaud Akamai for trying, for being courageous enough to post code, and for bucking the trend so many other companies are following by being more secretive every year. Just to be clear, so do I! As I said, the end result was net positive - within hours the fact they made this code snippet open source resulted in it be available to many more eyeballs, and bugs in it being found. By releasing the code, Akamai has not only helped the community (at least as a starting point - even if their actual code had issues the concept is good and no doubt will be improved upon by the wider community), but helped themselves by discovering that they were operating under the mistaken impression that their SSL keys were safe when potentially they were not. On Mon, Apr 14, 2014 at 1:07 PM, Doug Barton do...@dougbarton.us wrote: Agreed ... review is good, comments on needed fixes are good, but saying that Akamai, should not be sending out non-functional, bug ridden patches to the OpenSSL community as Pinckaers did is not constructive. Especially when the release specifically stated *This should really be considered more of a proof of concept than something that you want to put directly into production* and *do not just take this patch and put it into production without careful review*. Akamai made mistakes here, but releasing what they obviously believed to be workable code in the way that they did wasn't one of them. Scott
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 4:52 PM, Christopher Morrow morrowc.li...@gmail.com wrote: if you're going to do something that has the potential to affect (say, for example) email to a wide set of people, most of which are NOT your direct users, how do you go about making that public? 'the internet' isn't really a good answer for 'how do you notify'. Doug's note that: email mailops is good... but I'm not sure how many people that run lists listen to mailops? (I don't ... i don't run any big list, but...) I also wonder about update cycles for software in this realm? and for very larger list operators there's probably some customization and such to hurdle over on the upgrade path, eh? so how much leadtime is enough? how much is too much? 1yr seems like a long time - people will forget, 1wk doesn't seem like enough to avoid firedrills and un-intended bugs. First, you don't start by telling mailinglist admins to NOT worry about dmarc as they are a special case that will be handled/whitelisted/etc. The dmarc discussion archives (of which Yahoo is a primary sponsor, and a Yahoo employee is one of the spec authors) are full of discussions that clearly show no cause or care about mailinglists. I was told, several times, that mailinglists would be ok, they would be whitelisted and that there was no need for all my concern (well over 6 months ago). -Jim P.
Re: DMARC - CERT?
Matthias Leisi wrote: On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard sc...@doc.net.au wrote: Whilst I don't agree with the way that Yahoo has done this (particularly around communication), how could they have communicated this better? how can we all learn from this? They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. They could have made the change not late on a Friday afternoon (or well into the weekend for most of the world). On the weekend before tax filings are due in the US! And a couple of days before Passover. Miles -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DMARC - CERT?
Christopher Morrow wrote: On Mon, Apr 14, 2014 at 4:44 PM, Scott Howard sc...@doc.net.au wrote: On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi matth...@leisi.net wrote: They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. communicated it where? The Internet. I was trying, really, to be not-funny with my question. if you're going to do something that has the potential to affect (say, for example) email to a wide set of people, most of which are NOT your direct users, how do you go about making that public? 'the internet' isn't really a good answer for 'how do you notify'. Doug's note that: email mailops is good... but I'm not sure how many people that run lists listen to mailops? (I don't ... i don't run any big list, but...) I also wonder about update cycles for software in this realm? and for very larger list operators there's probably some customization and such to hurdle over on the upgrade path, eh? so how much leadtime is enough? how much is too much? 1yr seems like a long time - people will forget, 1wk doesn't seem like enough to avoid firedrills and un-intended bugs. A blog entry and a post to a few key relevant mailing lists would have specifically which mail-lists? How about the support lists for all the email list packages they could think of - let's start with mailman, majordomo, listserve, listproc, sympa, ezmlm, . Might have been nice if they'd offered some support for patching the open source ones. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 5:24 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Matthias Leisi wrote: On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard sc...@doc.net.au wrote: Whilst I don't agree with the way that Yahoo has done this (particularly around communication), how could they have communicated this better? how can we all learn from this? They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. They could have made the change not late on a Friday afternoon (or well into the weekend for most of the world). On the weekend before tax filings are due in the US! And a couple of days before Passover. and in the middle of Heartbleed. It's enough to make you believe there was absolutely no care or concern for others. -Jim P.
Re: Yahoo DMARC breakage
On 4/10/14 4:29 AM, Rich Kulawiec wrote: An aside: On Wed, Apr 09, 2014 at 05:15:59PM -0400, William Herrin wrote: Maybe this is a good thing - we can stop getting all the sorry I'm out of the office emails when posting to a list. I entirely support that goal, but my preferred solution is the complete eradication of the software (a lot of which makes mistakes that have been well-known as mistakes for decades) and thus the entire practice of setting up out of office messages. As long as we're talking about complete eradication of software, please include inane disclaimers sent to lists (as well as private email). This type of thing NOTICE: This communication may contain confidential and/or privileged information. If you are not the intended recipient or believe that you have received this communication in error you are obligated to kill yourself and anyone else who may have read it, not necessarily in that order. So there. My disclaimer is scarier than yours. Nyaah. You started this silly nonsense. Knock it off and I will too, ok? It's worthless from a legal standpoint and is responsible for the needless suffering of billions of innocent electrons. Nobody reads it anyway. You're not actually reading this, are you? I didn't think so. -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
RE: DMARC - CERT?
Plus I guarantee that something this SIGNIFICANT would catch the attention of many tech news outlets, social sites, and many email lists if they had given due notice and allowed people time to digest the change. But, I guess since everything except their email has become pretty much irrelevant these days, they had to do something to get attention and try to be the big bully again. I personally run only a couple of small email lists in which the subscribers are specifically added by me when someone wants on, and this has caused us, because the submitter has a long time Yahoo email address and will not change, a huge headache. The sender has had to resort to sending email from Yahoo account multiple time in order to get the emails out to the 180+ subscribers. Some people cannot change their email due to having it for so long it is just not practical. Only other work around I have for this user is to give them a private email list on the email server where he can send from that is not a Yahoo address. This causes extra work because every email he wants to forward on, he must now first send it to the new private address, then login to the private email address web mail, then forward. I have to agree with this others out there that Yahoo SHOULD, not COULD, have handled this a lot better. All the other big ISP's out there should be whipping Yahoo's a$$ about right now. But as usual, not a peep! Robert -Original Message- From: Miles Fidelman [mailto:mfidel...@meetinghouse.net] Sent: Monday, April 14, 2014 5:28 PM Cc: NANOG Subject: Re: DMARC - CERT? Christopher Morrow wrote: On Mon, Apr 14, 2014 at 4:44 PM, Scott Howard sc...@doc.net.au wrote: On Mon, Apr 14, 2014 at 1:39 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:34 PM, Matthias Leisi matth...@leisi.net wrote: They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. communicated it where? The Internet. I was trying, really, to be not-funny with my question. if you're going to do something that has the potential to affect (say, for example) email to a wide set of people, most of which are NOT your direct users, how do you go about making that public? 'the internet' isn't really a good answer for 'how do you notify'. Doug's note that: email mailops is good... but I'm not sure how many people that run lists listen to mailops? (I don't ... i don't run any big list, but...) I also wonder about update cycles for software in this realm? and for very larger list operators there's probably some customization and such to hurdle over on the upgrade path, eh? so how much leadtime is enough? how much is too much? 1yr seems like a long time - people will forget, 1wk doesn't seem like enough to avoid firedrills and un-intended bugs. A blog entry and a post to a few key relevant mailing lists would have specifically which mail-lists? How about the support lists for all the email list packages they could think of - let's start with mailman, majordomo, listserve, listproc, sympa, ezmlm, . Might have been nice if they'd offered some support for patching the open source ones. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DMARC - CERT?
On Apr 14, 2014, at 3:58 PM, Rich Kulawiec r...@gsp.org wrote: As I've said many times, email forgery is not the problem. It's a symptom of the problem, and the problem is rotten underlying security coupled with negligent and incompetent operational practice. But fixing that is hard, and nobody -- not Yahoo and not anybody else either -- wants to tackle it. It's much easier to roll out stuff like this and pretend that it works and write a press release and declare success. I think you're on the right track, but still suggesting their is a technical solution. I submit there is not. There is no car alarm that prevents all car thefts, no door lock that prevents all burglaries. No trigger lock that prevents all gun deaths, no lane departure system that prevents all car crashes. Spam cannot, and will never be solved by technological measures alone. They can help reduce the levels in some cases, or squeeze the balloon and move the spam to some other form. Ultimately the way to reduce spam is to catch spammers, prosecute them, and put them in prison. The way we keep all of those other crimes low is primarily by enforcement; making the punishment not worth the crime. With spam, the chance that a spammer will be punished is infinitesimal. There are hundreds, or thousands, or tens of thousands of spammers for every one that is put into jail. If we'd put even 1% of the effort that's been thrown at technical measures over the years into better laws, tools for law enforcement, and helping them build cases we'd be several orders of magnitude better off than technological solutions that are little more than wack-a-mole. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: DMARC - CERT?
Jim Popovitch wrote: On Mon, Apr 14, 2014 at 5:24 PM, Miles Fidelman mfidel...@meetinghouse.net wrote: Matthias Leisi wrote: On Mon, Apr 14, 2014 at 10:20 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard sc...@doc.net.au wrote: Whilst I don't agree with the way that Yahoo has done this (particularly around communication), how could they have communicated this better? how can we all learn from this? They could have communicated, as in listen folks, we are going to make a critical change that will affect mailing lists (etc...) in four weeks time. They could have made the change not late on a Friday afternoon (or well into the weekend for most of the world). On the weekend before tax filings are due in the US! And a couple of days before Passover. and in the middle of Heartbleed. It's enough to make you believe there was absolutely no care or concern for others. And.. it's worth contrasting the community response to Heartbleed - which didn't actually cause widespread denial of service! Miles -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 2:29 PM, Jim Popovitch jim...@gmail.com wrote: They could have made the change not late on a Friday afternoon (or well into the weekend for most of the world). On the weekend before tax filings are due in the US! And a couple of days before Passover. and in the middle of Heartbleed. You might have had a point - if it had been ANY of those. Other than the original claim of Friday afternoon it was none of those things. Scott
Re: DMARC - CERT?
Leo Bicknell wrote: Ultimately the way to reduce spam is to catch spammers, prosecute them, and put them in prison. The way we keep all of those other crimes low is primarily by enforcement; making the punishment not worth the crime. With spam, the chance that a spammer will be punished is infinitesimal. There are hundreds, or thousands, or tens of thousands of spammers for every one that is put into jail. Follow their money trails and take their bank accounts. Counterpunch with DDoS attacks. Attack them with drones. We're investing a lot of tax dollars into offensive cybersecurity - let's give those guys some practice! Makes sense to me!
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 5:48 PM, Scott Howard sc...@doc.net.au wrote: On Mon, Apr 14, 2014 at 2:29 PM, Jim Popovitch jim...@gmail.com wrote: They could have made the change not late on a Friday afternoon (or well into the weekend for most of the world). On the weekend before tax filings are due in the US! And a couple of days before Passover. and in the middle of Heartbleed. You might have had a point - if it had been ANY of those. Other than the original claim of Friday afternoon it was none of those things. 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the last full week before the US tax filing deadline. 7-April: OpenSSL's *public* advisory (after a full week of private notifications, of which yahoo surely was one tech company in on the early notifications) 11-April: Yahoo discusses what needs to be done on their public tumblr account. -Jim P.
RE: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
IIRC, the message was sent via courier instead of cable or telephone to prevent interception. Did the military not even trust its own cryptographic methods? Or did they not think withdrawal of the Japanese ambassador was not very critical? matthew black california state university, long beach From: Donald Eastlake [mailto:d3e...@gmail.com] Sent: Monday, April 14, 2014 8:28 AM To: Matthew Black Cc: William Herrin; nanog@nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Matthew, On Mon, Apr 14, 2014 at 10:48 AM, Matthew Black matthew.bl...@csulb.edumailto:matthew.bl...@csulb.edu wrote: Also on this same idea, in his book The Puzzle Palace, James Bamford claims that we knew of the pending attack on Pearl Harbor but did nothing, because that would compromise we broke the Japanese Purple Cipher. I assume you refers to pages 36 through 39 of The Puzzle Palace which is almost entirely a recounting of bureaucratic fumbling and delay. The sensitivity of a Purple Cipher decode did cause the intercepted information to be sent by a less immediate means to the US Naval authorities in Hawaii. Nevertheless, it was sent with every expectation that those authorities would receive it before the time of the attack. We do not know what those authorities would have done it they had received the intercept information as expected, instead of receiving it about 6 hours after the first bomb struck Pearl Harbor. Your implication that Bamford says we decided to do nothing bears no relationship to what Bamford actually wrote. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.commailto:d3e...@gmail.com matthew black california state university, long beach -Original Message- From: William Herrin [mailto:b...@herrin.usmailto:b...@herrin.us] Sent: Friday, April 11, 2014 2:06 PM To: nanog@nanog.orgmailto:nanog@nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker niels=na...@bakker.netmailto:na...@bakker.net wrote: Please go read up on some recent and less recent history before making judgments on what would be unusually gutsy for that group of people. I'm not saying this has been happening but you will have to come up with a better defense than it seems unlikely to me personally. Let me know when someone finds the second shooter on the grassy knoll. As for me, I do have some first hand knowledge as to exactly how sensitive several portions of the federal government are to the security of the servers which hold their data. They may not hold YOUR data in high regard... but the word sensitive does not do justice to the attention lavished on THEIR servers' security. In WW2 we protected the secret of having cracked enigma by deliberately ignoring a lot of the knowledge we gained. So such things have happened. But we didn't use enigma ourselves -- none of our secrets were at risk. And our adversaries today have no secrets more valuable than our own. -Bill
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 2:59 PM, Jim Popovitch jim...@gmail.com wrote: 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the last full week before the US tax filing deadline. The change was made on the previous Friday, so that date is largely irrelevant. 7-April: OpenSSL's *public* advisory (after a full week of private notifications, of which yahoo surely was one tech company in on the early notifications) Given that many of their main services were vulnerable at the time of public disclosure, I think that's a very large assumption to make... If nothing else, I suspect the odds of it being known by the same people that made the DMARC decision/changes is low. Scott
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 3:21 PM, Scott Howard sc...@doc.net.au wrote: 7-April: OpenSSL's *public* advisory (after a full week of private notifications, of which yahoo surely was one tech company in on the early notifications) Given that many of their main services were vulnerable at the time of public disclosure, I think that's a very large assumption to make... Based on the article below it would appear that Yahoo did NOT know about Heartbleed at the time of public disclosure. http://www.smh.com.au/it-pro/security-it/heartbleed-disclosure-timeline-who-knew-what-and-when-20140414-zqurk.html Scott
Re: DMARC - CERT?
In article cal9jlazjjppz7vzw2ue4qfqwrkcbu7cs1ed3uu1nhudhxxk...@mail.gmail.com you write: On Mon, Apr 14, 2014 at 4:10 PM, Scott Howard sc...@doc.net.au wrote: Whilst I don't agree with the way that Yahoo has done this (particularly around communication), how could they have communicated this better? how can we all learn from this? Well, telling people in advance that they were planning to do it rather than just dropping it on the world over the weekend would be a good start. R's, John
Re: DMARC - CERT?
Jim Popovitch wrote: On Mon, Apr 14, 2014 at 5:48 PM, Scott Howard sc...@doc.net.au wrote: On Mon, Apr 14, 2014 at 2:29 PM, Jim Popovitch jim...@gmail.com wrote: They could have made the change not late on a Friday afternoon (or well into the weekend for most of the world). On the weekend before tax filings are due in the US! And a couple of days before Passover. and in the middle of Heartbleed. You might have had a point - if it had been ANY of those. Other than the original claim of Friday afternoon it was none of those things. 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the last full week before the US tax filing deadline. 7-April: OpenSSL's *public* advisory (after a full week of private notifications, of which yahoo surely was one tech company in on the early notifications) 11-April: Yahoo discusses what needs to be done on their public tumblr account. 14-April: 1st night of Passover 15-April: Tax Filings due in the US -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: DMARC - CERT?
On Mon, Apr 14, 2014 at 6:21 PM, Scott Howard sc...@doc.net.au wrote: On Mon, Apr 14, 2014 at 2:59 PM, Jim Popovitch jim...@gmail.com wrote: 7-April: Monday, Yahoo's dmarc change kicks everyone in the groin, the last full week before the US tax filing deadline. The change was made on the previous Friday, so that date is largely irrelevant. 7-April: OpenSSL's *public* advisory (after a full week of private notifications, of which yahoo surely was one tech company in on the early notifications) Given that many of their main services were vulnerable at the time of public disclosure, I think that's a very large assumption to make... If nothing else, I suspect the odds of it being known by the same people that made the DMARC decision/changes is low. I think you are right on that, but that doesn't change the fact that the sum of those things overburdened a lot of mailinglist operators. It is what it is, and the press has covered it and mailinglists are blocking/unsub'ing yahoo accounts in order to cope. -Jim P.
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 4/14/2014 9:38 AM, Matthew Black wrote: Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. I have been out of the loop for quite a while but my strongly held belief is that such scrubbing would be an enormous (and intolerable) overhead in any but a classified system running up around secret or higher. (I know of a system in Silicon Valley where they would bring us core dumps to print because their system was down so hard. The dump program would take about a third of a box of fanfold and stack it, still blank, as I recall, in the stacker. Seems like the law of the land was If you did not set the value, you can make no assumptions about it. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
for those you can blame the vendor. this one is owned by the community. it falls on us to try to lower the probability of a next one by actively auditing source as our civic duty. is that kind of like jury duty? if only it were more like literature, which we could read for enjoyment. true. also, as someone whacked me, far too many networkers can not read code at all. randy
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 4/14/2014 2:59 PM, Patrick W. Gilmore wrote: Or we can flame anyone who tries, then wonder why no one is trying. Amen. I was just thinking, after reading the umpteenth message here about spam, about the times in the 1990's that I was literally driven away because I was trying to get ahead of the spam problem (which was then a drop in the bucket as compared to now). -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 4/14/2014 3:05 PM, William Herrin wrote: I thought vendors existed primarily as a place to hang the blame when dealing with a manager or customer who just doesn't get it. Truth value very high. Humor value, less than none. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 4/14/14 4:06 PM, Randy Bush wrote: for those you can blame the vendor. this one is owned by the community. it falls on us to try to lower the probability of a next one by actively auditing source as our civic duty. is that kind of like jury duty? if only it were more like literature, which we could read for enjoyment. true. also, as someone whacked me, far too many networkers can not read code at all. It's much, much worse than that. I can still read code plenty fine, but bugs can be extremely obscure, and triply so with convoluted security code where people are actively going after you to find problems in most inventive ways. Openssl, etc, probably need to be treated more like Mars Landers than the typical github forkfest. Mike
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Larry Sheldon writes: On 4/14/2014 9:38 AM, Matthew Black wrote: Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. I have been out of the loop for quite a while but my strongly held belief is that such scrubbing would be an enormous (and intolerable) overhead in any but a classified system running up around secret or higher. (I know of a system in Silicon Valley where they would bring us core dumps to print because their system was down so hard. In 2005, Stanford researchers found that with careful design and implementation, secure deallocation can be accomplished with minimal overhead (roughly 1% for most workloads). https://www.usenix.org/legacy/events/sec05/tech/full_papers/chow/chow.pdf This is for the RAM case rather than the disk case; maybe disk is worse because writes are more expensive. -- Seth David Schoen sch...@loyalty.org | No haiku patents http://www.loyalty.org/~schoen/| means I've no incentive to FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150 |-- Don Marti
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 04/14/2014 07:14 PM, Michael Thomas wrote: It's much, much worse than that. I can still read code plenty fine, but bugs can be extremely obscure, and triply so with convoluted security code where people are actively going after you to find problems in most inventive ways. Openssl, etc, probably need to be treated more like Mars Landers than the typical github forkfest. You mean this one? http://en.wikipedia.org/wiki/Mars_Climate_Orbiter ;)
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
In article 534c68f4@cox.net you write: On 4/14/2014 9:38 AM, Matthew Black wrote: Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. I have been out of the loop for quite a while but my strongly held belief is that such scrubbing would be an enormous (and intolerable) overhead ... It must be quite a while. Unix systems have routinely cleared the RAM and disk allocated to programs since the earliest days. Pre-VM OS/360 may not have. R's, John
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 4/14/2014 7:50 PM, John Levine wrote: In article 534c68f4@cox.net you write: On 4/14/2014 9:38 AM, Matthew Black wrote: Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. I have been out of the loop for quite a while but my strongly held belief is that such scrubbing would be an enormous (and intolerable) overhead ... It must be quite a while. Unix systems have routinely cleared the RAM and disk allocated to programs since the earliest days. Pre-VM OS/360 may not have. HP-UX did not. Exec8 (OS1100) did not. What ever it was we ran on the 1401s and 360/30s (and 9300s) did not. We manually zeroed core on the 707xs but even then we knew it was a wasted 3 minutes because that was only done before the firs run of the day and might not happen again for several days (because each daily cycle took several days in some offices). MS-DOS and Windows (even still?) were notorious for not hurting deleted files. Is the heartbleed bug not proof positive that it is not being done today? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 04/14/2014 05:02 PM, Nathan Angelacos wrote: On 04/14/2014 07:14 PM, Michael Thomas wrote: It's much, much worse than that. I can still read code plenty fine, but bugs can be extremely obscure, and triply so with convoluted security code where people are actively going after you to find problems in most inventive ways. Openssl, etc, probably need to be treated more like Mars Landers than the typical github forkfest. You mean this one? http://en.wikipedia.org/wiki/Mars_Climate_Orbiter ;) That of course wasn't an orbiter, it was a splater. :) Mike
Pearl Harbor
This is getting pretty far afield so I thought I should at least change the subject. There was no initial withdrawal of the Japanese ambassador - it was the Japanese withdrawing from negotiations with the USA over USA demands -- essentially Japan declaring that it had given up on finding compromise and would not accede to USA demands for Japanese troop withdrawals. There were two messages related to the negotiations from the Japanese government to their embassy in Washington. The first was so long and meandering, that it has to be broken into 14 parts for transmission. Only in the final and 14th part, which was transmitted more than 24 hours after the first 13 parts were sent, did it direct the withdrawal from negotiations. This was considered within the Japanese government as tantamount to a declaration of war and it was felt that the attack would be dishonorable if it was not communicated to the USA government before the attack. Thus, there was a second much shorter message that specifically directed that the withdrawal be communicated to the US Government, if possible to the US Secretary of State, no later than 1pm later that day, Sunday December 7th. (It was immediately apparent to the American's reading this message that 1pm in Washington was dawn in Hawaii and probably the time of an attack.) There were some other messages sent about the same time including one ordering the Japanese embassy to destroy all cipher machines and codes. There were delays in USA decryption and translation of all of these messages. Then there was delay in getting what was clearly a threat of war to someone in Washington high enough to take action. But those were accomplished more than two hours before the attack. (The Japanese embassy in Washington was by no means immune to bureaucracy and delay and did not read the messages in time to implement then before the attack.) The fastest way to communicate with the US military in Hawaii would have been analog scrambled telephone which was, correctly, considered to be insecure and inappropriate for information derived from a Purple intercept. Such scrambled calls had been unscrambled by other countries before. So, it was given to the War Department's message center, who said that it would be delivered directly within a half an hour, after they encrypted it and sent it by radio. However, atmospheric conditions blocked that method and the encrypted message was given by the message center to a commercial wire carrier to send. It arrived and was printed out at the carrier's office in Honolulu at 7:33am local time, 22 minutes before the first bomb fell. Although obviously encrypted, it was apparently not marked for any special urgent handling -- remember the sender had though it would arrive directly at the military authorities in Hawaii over an hour earlier. As a result, it was not actually delivered to those authorities until 2:40pm, after the attack was over, and not read until 20 minutes later after decryption. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Mon, Apr 14, 2014 at 6:09 PM, Matthew Black matthew.bl...@csulb.edu wrote: IIRC, the message was sent via courier instead of cable or telephone to prevent interception. Did the military not even trust its own cryptographic methods? Or did they not think withdrawal of the Japanese ambassador was not very critical? matthew black california state university, long beach From: Donald Eastlake [mailto:d3e...@gmail.com] Sent: Monday, April 14, 2014 8:28 AM To: Matthew Black Cc: William Herrin; nanog@nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] Matthew, On Mon, Apr 14, 2014 at 10:48 AM, Matthew Black matthew.bl...@csulb.edu wrote: Also on this same idea, in his book The Puzzle Palace, James Bamford claims that we knew of the pending attack on Pearl Harbor but did nothing, because that would compromise we broke the Japanese Purple Cipher. I assume you refers to pages 36 through 39 of The Puzzle Palace which is almost entirely a recounting of bureaucratic fumbling and delay. The sensitivity of a Purple Cipher decode did cause the intercepted information to be sent by a less immediate means to the US Naval authorities in Hawaii. Nevertheless, it was sent with every expectation that those authorities would receive it before the time of the attack. We do not know what those authorities would have done it they had received the intercept information as expected, instead of receiving it about 6 hours after the first bomb struck Pearl Harbor. Your implication that Bamford says we decided to do nothing bears no relationship to what Bamford actually wrote. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com matthew
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 04/14/2014 05:50 PM, John Levine wrote: In article 534c68f4@cox.net you write: On 4/14/2014 9:38 AM, Matthew Black wrote: Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. I have been out of the loop for quite a while but my strongly held belief is that such scrubbing would be an enormous (and intolerable) overhead ... It must be quite a while. Unix systems have routinely cleared the RAM and disk allocated to programs since the earliest days. When you say clear the disk allocated to programs what do you mean exactly?
Re: [[Infowarrior] - NSA blah blah blah blah....
On Mon, Apr 14, 2014 at 07:47:46PM -0700, Doug Barton wrote: It must be quite a while. Unix systems have routinely cleared the RAM and disk allocated to programs since the earliest days. When you say clear the disk allocated to programs what do you mean exactly? On a clear disc, you can seek forever - with apologies to Barbara S. /bill
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Mon, Apr 14, 2014 at 7:47 PM, Doug Barton do...@dougbarton.us wrote: On 04/14/2014 05:50 PM, John Levine wrote: In article 534c68f4@cox.net you write: On 4/14/2014 9:38 AM, Matthew Black wrote: Shouldn't a decent OS scrub RAM and disk sectors before allocating them to processes, unless that process enters processor privileged mode and sets a call flag? I recall digging through disk sectors on RSTS/E to look for passwords and other interesting stuff over 30 years ago. I have been out of the loop for quite a while but my strongly held belief is that such scrubbing would be an enormous (and intolerable) overhead ... It must be quite a while. Unix systems have routinely cleared the RAM and disk allocated to programs since the earliest days. When you say clear the disk allocated to programs what do you mean exactly? Is that like sudo rm -rf /bin ? ;P Matt
